Re: The point of splitting application into multiple modules

[Francesco Calabri]

First of all, thanks a lot for you answers.
 

> So overall I would save "massive performance loss" is clearly overstating 
> and I am pretty sure you don't have numbers to correct me ;-)
>

You're right, that's only what i've read in many places about the topic.
 

> Well and as you said the most prominent use case is to be able to build 
> libraries.
>

Probably some kind of linker that separate the fragments in a way that is 
clear what has been updated and lets you replace only the updated 
fragments... I don't know... Certainly having different output folders for 
the modules was misleading.


However for your use case you have to adopt the Turducken pattern: 
> http://de.slideshare.net/RobertKeane1/turducken-divide-and-conquer-large-gwt-apps-with-multiple-teams.
>  
> 
>

Yes, I've seen these slides but the iframe thing isn't really what I 
wanted.. I'll stay with the monolithic app.

Thanks again

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: The point of splitting application into multiple modules

[Kirill Prazdnikov]

We have decided to not use code splitting. 
Our problem was the performance.
New dynamically loading modules are huge strings and parsed by eval.

This causes serious performance problems. 
Consider you are in the web-app and open a new tool window that loads 10M 
of one string code.
This will hang you app for a second or two.
This is unacceptable for client app.

On Monday, February 22, 2016 at 5:57:04 PM UTC+3, Francesco Calabri wrote:
>
> Hi all,
> i was thinking of ways to break a big large GWT application into multiple 
> modules to be able to develop modules independently.
> I've read some things in the forum and in the documentation but I'm still 
> quite confused.
>
> The ideal solution:
> Have a core/main shell module with the menu and one module for each 
> application view.
> All this should run in the same url with the same session.
> Each view module should be loaded when needed: if the user clicks on the 
> menu, the relative module is loaded (something like split points).
> Some state/session information initialized in the main module should be 
> available in the sub modules.
> Most important: I should be able to edit one submodule and update only 
> that part of the application, having it updated the next the user requests 
> that submodule, possibly without the need to trigger a deploy, but simply 
> swapping the output of that module.
>
> I've tryed to split my code into modules, having the main inherits the 
> submodules and lauching them from the menu.
> Soon I realized that even if I compile the submodules separately, any 
> change made to a submodule will be visible only if I compile the main 
> module, and the sunmodule output in never really used.
>
> For what I understood, if I would like to go further in splitting logic 
> into modules I should load the submodules "manually" by using them into an 
> iframe (and have some published javascript objects from the main module 
> read to achieve communication and information sharing between modules).
> Unfortunately this leads to massive performance loss since the monolithic 
> js is way better and more optimized.
>
> So, other than creating gwt-legit libraries, what's the point of multiple 
> modules?
>
> Thanks
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: The point of splitting application into multiple modules

[Jens]

> Unfortunately this leads to massive performance loss since the monolithic 
> js is way better and more optimized.
>

I don't think thats true. If you combine all your small apps and the main 
app then, yes, the download size will be larger than just one big app 
because all your small apps will need to include the same GWT SDK code 
(e.g. each small app contains the code for a GWT button). However each 
small app can use code splitting on its own to optimize its "download 
performance" and once its downloaded everything is cached.

The actual JS performance shouldn't be any different unless you made a bad 
decision and you suddenly need to send a large amount of messages between 
the main app and the small app loaded through your menu item and 
serialization/deserialization of messages starts to become an issue.

So overall I would save "massive performance loss" is clearly overstating 
and I am pretty sure you don't have numbers to correct me ;-)

 

> So, other than creating gwt-legit libraries, what's the point of multiple 
> modules?
>

Within a single app a module is mostly for configuration organization. 
Especially if you have lots of generators and deferred binding 
configuration its nice that you can split your module XML up into smaller 
parts. They also help during development because if done right you should 
be able to start only a subset of your large application which can speed up 
SuperDevMode as it has less code to manage. Well and as you said the most 
prominent use case is to be able to build libraries.

However for your use case you have to adopt the Turducken 
pattern: 
http://de.slideshare.net/RobertKeane1/turducken-divide-and-conquer-large-gwt-apps-with-multiple-teams

-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

The point of splitting application into multiple modules

[Francesco Calabri]

Hi all,
i was thinking of ways to break a big large GWT application into multiple 
modules to be able to develop modules independently.
I've read some things in the forum and in the documentation but I'm still 
quite confused.

The ideal solution:
Have a core/main shell module with the menu and one module for each 
application view.
All this should run in the same url with the same session.
Each view module should be loaded when needed: if the user clicks on the 
menu, the relative module is loaded (something like split points).
Some state/session information initialized in the main module should be 
available in the sub modules.
Most important: I should be able to edit one submodule and update only that 
part of the application, having it updated the next the user requests that 
submodule, possibly without the need to trigger a deploy, but simply 
swapping the output of that module.

I've tryed to split my code into modules, having the main inherits the 
submodules and lauching them from the menu.
Soon I realized that even if I compile the submodules separately, any 
change made to a submodule will be visible only if I compile the main 
module, and the sunmodule output in never really used.

For what I understood, if I would like to go further in splitting logic 
into modules I should load the submodules "manually" by using them into an 
iframe (and have some published javascript objects from the main module 
read to achieve communication and information sharing between modules).
Unfortunately this leads to massive performance loss since the monolithic 
js is way better and more optimized.

So, other than creating gwt-legit libraries, what's the point of multiple 
modules?

Thanks

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.