On Thu, Apr 16, 2009 at 12:04 PM, Jason Essington <jason.essing...@gmail.com> wrote: > Their reasoning was that object instantiation was orders of magnitude slower > than simply building the HTML. in some cases even building HTML on the > client was too slow, so they would shuttle it off to the server. The > application would decide at runtime which way was faster, and use the > fastest method. > For a quick rendering test, you can try to create a 100x100 table (grid) > using GWT widgets, and then do the same thing using setInnerHTML() (with a > string that ultimately has the same DOM) ... you'll find that while the > setInnerHTML() is nearly instantaneous, the creation of the widgets takes > some time. It really depends on what you're trying to do isn't it. If you have a static grid that you populate, why would you ever be modifying the DOM structure? You just create your grid to begin with & then simply iterate over the widgets & set the data. You also get the added benefit that your code is far more flexible & maintainable (you don't have to worry about introducing typos in your HTML generator).
If you have a dynamic UI then maybe it might be more advantageous, but then again those tend to use absolute positioning which means DOM modifications do not cause a reflow (only a repaint). > Creation of individual DOM elements in javascript seems to be pretty slow > (it is a bit faster in the new generation browsers ff3, Safari4 and chrome) > but setInnerHTML() doesn't create those elements in javascript, it is done > natively in the browser and thus is much faster. I'd need to see a benchmark that that is indeed the case. I don't have time right now (I'll experiment later if I have the chance). But it seems wrong that creating the DOM elements in javascript is slower than having the browser do it natively (the cost of modifying the DOM should be the dominant factor by far). > Another technique that I use when populating multiple "cells" that have the > same HTML structure is to embed a hidden "template" in the host page. This > template has all of the HTML structure, but no content. I have GWT find and > store the elements that will be bound with data (traverse the DOM of the > template only once) from my model objects, then when I need to fill the > cells, I setInnerText, or setInnerHTML() on each of the found elements from > the template, and once the databinding is complete, perform a getInnerHTML() > on the template, and use that string to setInnerHTML() on the "cell" ... > this works great as there is really no DOM object creation happening in > Javascript, and is considerably faster than building up the widgets > individually. How is this different than building up the HTML structure using widgets as I mention above? > > -jason > > > On Apr 16, 2009, at 9:44 AM, Vitali Lovich wrote: > > Can you point out the relevant segments within the presentation? I skimmed > through some parts, & it seemed like they went for just building the raw > HTML on the client side (hence the reason they transfer HTML from the > server). > > Also, they're presentation is for 1.4, so they're reasons might not be > relevant any more (especially since 1.5 included a lot of improvements & 1.6 > introduced improvements with the event subsystem). > > Also, they don't seem to be using deferred binding for some reason to get > around > > On Thu, Apr 16, 2009 at 11:19 AM, Jason Essington > <jason.essing...@gmail.com> wrote: >> >> You might want to tell the Lombardi Blueprint guys that ... as it turns >> out, they discovered in the development of their application that you are >> mistaken on all points. >> Feel free to watch their presentation from Google I/O last year if you'd >> like to check my references: >> >> http://sites.google.com/site/io/using-gwt-to-build-a-high-performance-collaborative-diagramming-tool >> -jason >> On Apr 16, 2009, at 9:10 AM, Vitali Lovich wrote: >> >> I dunno about that one two fronts: >> >> 1) All the same DOM elements still have to be created. This would only >> help if you have such a slow JS engine in your browser that running the DOM >> manipulations in Javascript is so slow that it outweighs the cost of >> actually performing the manipulations (which I believe would always be done >> in native code anyways) >> >> 2) You're transmitting more data across the pipe - the extra markup is >> unnecessary data & can bloat your transfer by quite a bit, slowing down your >> responsiveness. >> >> 3) It's not scalable. Your moving rendering code from the client to the >> server which places more load on the server. Performing string >> concatenations also isn't cheap (unless you build your own string class that >> offers fast concatenation through pointers to strings & perform all the >> stream output yourself). Obviously if the number of users is limited you >> don't care. >> >> So all 3 reasons together (mainly 1 & 2 though), I don't see how that >> would help. Obviously some hard numbers are needed as all this is just hand >> waving guesses of expected behaviour. >> >> On Thu, Apr 16, 2009 at 10:55 AM, Arthur Kalmenson <arthur.k...@gmail.com> >> wrote: >>> >>> Just asked a GWT wizard on IRC and turns out I was incorrect. He >>> offered an interesting alternative solution. Build the table as HTML >>> and send that down instead. >>> >>> -- >>> Arthur Kalmenson >>> >>> >>> >>> On Thu, Apr 16, 2009 at 10:46 AM, Ian Bambury <ianbamb...@gmail.com> >>> wrote: >>> > 2009/4/16 Vitali Lovich <vlov...@gmail.com> >>> >> >>> >> You seem to be saying that: >>> >> >>> >> tree t = new tree() >>> >> t.addItem("abc"); >>> >> t.addItem("def"); >>> >> RootPanel.get().add(t); >>> >> >>> >> will have fewer reflows than >>> >> >>> >> tree t = new tree() >>> >> RootPanel.get().add(t) >>> >> t.addItem("abc") >>> >> t.addItem("def") >>> >> >>> >> According to you (at least from what you've said so far) is that the >>> >> 1st >>> >> snippet will cause 1 DOM reflow whereas the below snippet will cause >>> >> 2, >>> >> which isn't actually the case AFAIK. Both will only cause 1 & will be >>> >> equally fast. >>> > >>> > I think you are both right, depending on the browser you are in. >>> > FF2 (IIRC) will rerender during a sequence where most other browsers >>> > won't. >>> > I don't know when it decides to do that, but most other browsers would >>> > be >>> > still displaying your splash screen while FF2 has hidden it and has >>> > stuff >>> > dancing about on the screen. >>> > OTOH, if you widget is not attached and you are setting percentage >>> > heights >>> > and widths, for example, they will fail. >>> > Ian >>> > >>> > http://examples.roughian.com >>> > > >>> > >>> >>> >> >> >> >> >> >> >> > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
