Full page in GWT or just parts?

[Ed]

I am setting up a new page/app with only 2 dynamics parts that are
controlled through GWT.

In the past I would make the page fully static and only control the
dynamic parts with GWT.

I am considering creating the complete page with GWT (with UiBinder)
as it results in some advantages like:
- resource control: all images are controlled through GWT that uses
image striping and perfect caching.
Styles are controlled through GWT that gives some syntax checking,
obfuscating, etc...

But I am still not completely convinced and like to know the
experiences of others?

Thanks,
Ed

[Nicolas Antoniazzi]

You can build the full page with GWT but you have to keep in mind, that it will bring some problems too.

The main problem will be Search Engine. You will have to rely on htmlunit to fix it (generates static version of webpages).

The other problem, is that pages will be a bit slower to load (for two pages, it should not be too much) because you have to load a piece of javascript that will be interpreted on the client before rendering. However, you can still optimize it by including the javascript content inside your html/jsp/php page. You can use code splitting to improve it too.

In my opinion, it is really interresting to use GWT if this is for a project that is going to grow. GWT brings good developments models/tools (MVP, activities, eventbus) and good practice (unit tests, dependency injection). But it can be a lost of time if all these points are not thought before starting.

We released our website in full gwt (http://www.weecod.com), so it is possible to build a full website with the framework, but it can be really slower depending of the size of the project.

In my opinion, for two pages, just keep simple pages with gwt modules. But if you want to build more page later, you can think of a full integration.

[Ed]

Thanks for the feedback.

> The main problem will be Search Engine. You will have to rely on htmlunit to
> fix it (generates static version of webpages).

The search engine result isn't important.
What do you main by "htmlUnit to fix it"?

> you can still optimize it by including the javascript content inside your
> html/jsp/php page. You can use code splitting to improve it too.

What do you mean by "putting javascript in the html page directly"?
Isn't gwt bootstrapping already directly contained in html and in
control of loading all the resources as such that you have to wait
till gwt performed all the bootstrapping through his own js files...

> But it can be a lost of time if all these points are not thought before
> starting.

In my case it concerns 3 existing gwt app's that contains code
splitting and MVPC.
I am setting up new html pages to change the look and feel.

These app's should be one but the code splitting isn't optimal yet
such that the left over becomes too big.
See issue 6612 about this: (http://code.google.com/p/google-web-
toolkit/issues/detail?id=6612)

The advantage of having a full page gwt is also that these
applications can more easily integrated later on.

> We released our website in full gwt (http://www.weecod.com), so it is

Thanks for the link, it gives me a good example about a full page gwt
app.

I think I go for the full page gwt app. If it get's too slow, it's
easy to change it.

- Ed

[Nicolas Antoniazzi]

> The main problem will be Search Engine. You will have to rely on htmlunit to
> fix it (generates static version of webpages).

The search engine result isn't important.
What do you main by "htmlUnit to fix it"?

HtmlUnit is a tool that embed a browser (firefox) and can execute javascript code to produce an html output. It allows you to write website in Javascript/Ajax and give something to parse to search engine which are not able to parse javascript

http://code.google.com/intl/fr-FR/web/ajaxcrawling/docs/getting-started.html

http://code.google.com/intl/fr-FR/web/ajaxcrawling/docs/html-snapshot.html

 

> you can still optimize it by including the javascript content inside your
> html/jsp/php page. You can use code splitting to improve it too.

What do you mean by "putting javascript in the html page directly"?
Isn't gwt bootstrapping already directly contained in html and in
control of loading all the resources as such that you have to wait
till gwt performed all the bootstrapping through his own js files...

It is only to avoid an extra round trip. A typical scenario is :

1 - Client -> Get HTML index Page (with <scipt src="module.nocache.js" ... inside) (Connection 1)

2 - Client parse the html page and get the Javascript (module.nocache.js) (Connection 2)

3 - Client parse and execute the javascript (bootstrap)

4 - Client detects browser version and retrieve correct module from server (EAZKJ23A123131.cache.js) (Connection 3)

5 - Your module will certainly need to get some data to display from the server with an RPC request (Connection 4)

You can optimize two connection from this scenario :

Step 1 : Instead of referencing an external javascript (module.nocache.js), directly include the js content in you html page (easy to do with jsp)

Step 5 : All data dedicated to the first page can directy be included inside the html page too. You can then read those informations with JSON instead of doing a new RPC call.

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Ed Bras]

Nice.

Thanks,

- Ed

[Uemit]

I think GWT is best utilized in a full page scenario because of "code sharing" of re-usable components.

If you go the other route and "just" embed GWT code in different host pages (i.e. application with multiple entry points) you lose the benefits of javascript code re-use of reusable components because every entrypoint will have its own module.nocache.js file which has to be transferred to the client. If you create a re-usable component (let's say a CellTable component) which is used in different places  (in both entry points) the same code will be part of the module.nocache.js file and thus downloaded two times. 

It probably doesn't make a big difference for small web-sites where some parts are done with GWT but for complex apps where you might re-use a lot of components it might be an issue. 

However in case you go with the one host page (one entry point) solution you will probably not use any of the your backend's flow controls (MVC) but it will solely act as a data-backend. 

[Ed]

@Uemit: I agree but not completely as your comment aren't suited for
larger app's (in my case).

Don't forget that the current code splitting isn't perfect such that
the left-over fragment can become rather large, as in my case.
As such, that the simple login screen results with a big initial load,
whereas if I split it from the core application part, it becomes very
small. This is important as you don't want the user to wait too long
for the login screen to appear.

But of course I would like to make it as one gwt app, but this
currently results in bad results.

Apart from the code reuse, for me at this moment it's all about
resource management that GWT performs well as explained above.

- Ed

[Tomasz Gawel]

@Uemit
you can write one module to be used in all pages and use code
splitting feature to download only what is needed by the particular
page.
i do that this way.
another habit i worked out over years using gwt is to use onModuleLoad
method only to register js callbacks. how does the module behave on
particular page is then "scripted in javascript". however i had to
slightly "enhance" bootstraping script :).
generally my pattern is to write "whole client logic" with gwt (using
code splitting and merging modules as much as possible) an then
slighlty "script it" on page to customize its behaviour.

[Ed Bras]

@Thomas

Thanks for the feedback. I use the same pattern as you describe.

I have many commons modules that every application include if required.

- Ed