I have same problem... First of all, I like so much gxt components.
to help you: gxt must calculate in javascript every component resize (look this in firebug), and this components have so many listeners and many hierarchy. In some cases, I prefer build my own components using just gwt component base and css. I saw in Google IO 2009 the Lombardi presentation, where they talk about build the raw html first, and put some click behaviours after all. http://code.google.com/events/io/sessions/EffectiveGwt.html .. and you can use DeferredCommand to build or adjust UI when browser was idle. http://www.java2s.com/Code/Java/GWT/UsedeferredCommand.htm http://techzone.enterra-inc.com/?p=25 On Jul 7, 12:14 pm, JacoGr <[email protected]> wrote: > Hi all, > > I'm not 100% sure how to address this, or who/where to log it, so I > thought I'll start here... > > We are close to launching a new medium-sized application using GWT > 1.5.3 + GXT 1.2.4. At this point the application is around 81,000 > lines (61K of this is the actual web client, the remainder is the > server-side), along with another 4,300 DTO objects used in the RPC > (don't ask), translated into 3 languages (600+ strings per language) > and weighs in at a (not-too small) 5,632KB compiled size. > > Up to a week ago, everything was fine and then FireFox 3.5 happened. > (Our main target for our enterprise app is IE and FF, as an ISV that > seems to be where the action is although I personally would love more > Chrome & Safari users...) > > At the end of last week, straight after the release of FF 3.5, the > application started reporting the following errors when executing: > (All other browsers are fine) > > "script too large" > > This week (with some code added in the meantime) the original error > was replaced by a > > "script stack space quota is exhausted" > > Judging by these and the work that happened in the JS engine in the FF > 3.5 release, I'm starting to assume that this browser release is not > too friendly to our sized compiled GWT applications. I'm not too > excited by the fact that we will need to ship without FF 3.5 upport, > but that seems to be the current scenario. (We could try to address > this with the next release when we are planning to go 1.6.4 + > runAsync) > > Are there any work-around that we may be able to try in the short- > term? I can see these coming back to haunt us again, but I'm looking > more to a "breather" as to a permanent solution. (If we can cut now > and get things smaller, we will no-doubt run into this again - soon > enough.) Anybody else out there who has started to run into browser > limits? > > Thanks for any pointers, > Jaco --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
