Thanks for the reply Lucas - yeh, didn't really answer my question but
thanks anyway ;o)

The problem is where I work I am the only front-end engineer/designer
everyone else is a java programmer - so they *need* something that
enables them to write java and forget about the rest - we have been
using Echo2 (against my recommendation) and are now looking at GWT -
again, against my recommendation (there isn't anything that GWT or
Echo2 or AnotherJavaToJavascript Framework can do that a dedicated
team of front-end engineers can't do... but I guess thats GWTs (et al)
biggest selling point), don't get me wrong I think what the GWT
engineers have been able to produce is *very* clever...

Is there no one else listening/reading that has come accross this
issue/problem of packing reusable modules?


On Aug 17, 9:04 pm, Lucas Neves Martins <snown...@gmail.com> wrote:
> Yeah I know the feeling,
>
> My app was taking around 20-30 seconds to load for the first time -
> after the first load it was nearly instant
>
> I've tested with Google Page Speed and Page Activity as well, and I
> come to realize that the biggest problem is the huge amount of JS
> scrips ( at least for me ), Gzip compression helped a lot, in my case,
> around 7-10 seconds.
>
> As the GWT application itself is just pure JS in the client side, a
> "solution" I've used that helped a lot the user experience, is to load
> the application in the background.
>
> In my case, I load the login screen first - and it does it very
> quickly, around 1-2 second(s) - and while the user is still logging in
> the application I load all the other parts of the application,
> starting from the parts I think the user will use first. So while the
> user logs in, and take a look to the main page, all the application is
> loading without his perception - except for the firefox status
> spinner : P
>
> And then 10-15 seconds comes to be a acceptable time, since my users
> take just around that time to make a login and try to use any other
> funcionality after doing it.
>
> But of course, I agree that GWT could be better in both performance
> and best practices, but if you look at the generated code, you will
> see that that ship is sailed.
>
> The browsers are not so compliant to the standards as they could, and
> the guys from the GWT team can't do miracles.
>
> Take a look at gzip compression and and partitioned loading for gwt
> apps,
>
> I know I didn't actually answered you question, but this might help
> your performance.
>
> Good luck!
>
> On 17 ago, 07:12, Rodders <david.andrew.chap...@googlemail.com> wrote:
>
> > GWT comes with "default" CSS. If I create a bunch of reuseable Modules
> > (packaged as Jars for use by some of our other internal development
> > teams) with our own corporate style, the compiled application loads 2
> > stylesheets (the "default", and "company" for example).
>
> > If one of our development teams uses those Modules to create a new app
> > and adds some CSS specific to that app the compiled application loads
> > 3 stylesheets ("default", "company" and "application").
>
> > These stylesheets are not "minified" or combined, this can't be
> > correct as Google's own page performance tool states that HTTP
> > requests should be reduced and css files combinded - I must be doing
> > something wrong?
>
> > However, one of the GWT example apps I've seen is loading over 1Mb
> > data in 59 http requests and takes about 11 secs to load...
>
> > Can anyone point me at a good tutorial on how to create reuseable
> > modules that don't break web app performance best practices?
>
> > Thanks.
> > Rodders
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to