Thanks for all the feedback.  I feel very comfortable with the solution.
 Thanks!

On Wed, May 2, 2012 at 4:21 PM, Jens <[email protected]> wrote:

> Thats what code splitting is for. But don't create 500 split points (each
> split point has some overhead), e.g. one for each screen! Make it more
> meaningful so you may end up with 20 split points or so.
>
> As of today, when you introduce split points in your code you have to make
> sure that the code behind that split point is exclusive to that split
> point. Everything thats not exclusive to a single split point will be
> loaded on app start.
> Example: You have 2 pages and each is behind a code split point. If both
> pages make heavy use of the same GWT Widgets, all these widgets will be
> downloaded when the app starts although they are behind a split point.
> Thats because they are not exclusive to a single split point anymore.
> So if you choose your split points larger, you have a better chance to
> have more exclusive code behind that split point.
>
> In an upcoming release (hopefully GWT 2.5) a new code splitting algorithm
> will be introduced that uses heuristics to merge smaller split points into
> larger ones to make more code exclusive to a split point and thus reducing
> the initial download when the app starts. With such an algorithm you could
> define 500 split points in your code but may end up with 20 real split
> points after compiling the app.
>
> Also keep in mind if your split points have a certain size, its a good
> idea to give the user some feedback that your apps now loads additional
> code from the server.
>
> -- J.
>
>
>
> Am Mittwoch, 2. Mai 2012 22:38:15 UTC+2 schrieb Blake:
>
>> Greetings,
>>
>> Unless I misunderstand something, I just found out that GWT apps get
>> transmitted to, and treated by, the client as a single web page - albeit
>> with JavaScript code that clears sections and puts different content on it
>> to make it look like different pages are being loaded.  This is cool in
>> terms of minimizing client interaction delays, but raises serious concerns
>> on my part when attempting to build a very large application.
>>
>> For example, if my application had 500 screens (or what appeared to the
>> user as 500 different screens), I would hate to think that, even though the
>> client only currently needs 20 screens, he/she is going to get all 500 up
>> front!  The initial load would take an unnecessarily long time too.
>>
>> If I understand correctly, this model is great for small apps but could
>> be a very significant problem as an application grows considerably.
>>
>> I would really appreciate feedback on this issue.  Has this been an issue
>> for others?  Is there a simple way to make pages load on an as-needed basis?
>>
>> Thanks for the feedback!
>>
>> Blake McBride
>>
>>
> Am Mittwoch, 2. Mai 2012 22:38:15 UTC+2 schrieb Blake:
>
>> Greetings,
>>
>> Unless I misunderstand something, I just found out that GWT apps get
>> transmitted to, and treated by, the client as a single web page - albeit
>> with JavaScript code that clears sections and puts different content on it
>> to make it look like different pages are being loaded.  This is cool in
>> terms of minimizing client interaction delays, but raises serious concerns
>> on my part when attempting to build a very large application.
>>
>> For example, if my application had 500 screens (or what appeared to the
>> user as 500 different screens), I would hate to think that, even though the
>> client only currently needs 20 screens, he/she is going to get all 500 up
>> front!  The initial load would take an unnecessarily long time too.
>>
>> If I understand correctly, this model is great for small apps but could
>> be a very significant problem as an application grows considerably.
>>
>> I would really appreciate feedback on this issue.  Has this been an issue
>> for others?  Is there a simple way to make pages load on an as-needed basis?
>>
>> Thanks for the feedback!
>>
>> Blake McBride
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-web-toolkit/-/rjnoJmdpP0YJ.
>
> 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.
>

-- 
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.

Reply via email to