To GWT or Not to GWT
346 views
Skip to first unread message
bkar...@gmail.com
Dec 14, 2010, 4:57:32 PM12/14/10
to Google Web Toolkit
GWT's monolithic compile makes for really efficient JavaScript/
Resource downloads. In terms of providing a solution to the sort of
"traditional" kinds of web app problems, it's hard to argue that GWT
couldn't optimize whatever a developer would write because developers
write for flexibility - whereas the compile is about "there is 1 use
at the end of the day and everything else is just noise".
I'm sort of wondering though, are there classes of problems that GWT
is admittedly not a good fit for (specifically, according to the GWT
team itself) specifically because of that approach?
It's kind of hard to explain a concrete example, but let's try this:
If every gadget for iGoogle had to be developed in GWT - each iGoogle
gadget would contain everything that it needed and rely on nothing
shared, despite the fact that most gadgets would (according to the
compile reports) potentially share as much as 99% of their
dependencies. Simply because they are disparate compiles, the
compiler's view into the world is just too small...
Hypothetically speaking, if the average gadget were something like
50k, and something like 48k of that was just "core stuff", this
implies that a page with 10 gadgets would be something like 500k (of
just script), but 480k of that was largely just "repeated" core code.
I suppose it guarantees that things won't "break" to an extent with
versioning, but wouldn't it be more efficient in this hypothetical
example to have coded the flexibility into the gadget "container"
once? In other words - if the core were provided and the gadgets
merely used it, the total size of the page would be 68k instead of
500... Right? And the more gadgets are there, the bigger the
"savings".
In this kind of case - would the GWT team say "GWT is the right
choice" or no?
Resource downloads. In terms of providing a solution to the sort of
"traditional" kinds of web app problems, it's hard to argue that GWT
couldn't optimize whatever a developer would write because developers
write for flexibility - whereas the compile is about "there is 1 use
at the end of the day and everything else is just noise".
I'm sort of wondering though, are there classes of problems that GWT
is admittedly not a good fit for (specifically, according to the GWT
team itself) specifically because of that approach?
It's kind of hard to explain a concrete example, but let's try this:
If every gadget for iGoogle had to be developed in GWT - each iGoogle
gadget would contain everything that it needed and rely on nothing
shared, despite the fact that most gadgets would (according to the
compile reports) potentially share as much as 99% of their
dependencies. Simply because they are disparate compiles, the
compiler's view into the world is just too small...
Hypothetically speaking, if the average gadget were something like
50k, and something like 48k of that was just "core stuff", this
implies that a page with 10 gadgets would be something like 500k (of
just script), but 480k of that was largely just "repeated" core code.
I suppose it guarantees that things won't "break" to an extent with
versioning, but wouldn't it be more efficient in this hypothetical
example to have coded the flexibility into the gadget "container"
once? In other words - if the core were provided and the gadgets
merely used it, the total size of the page would be 68k instead of
500... Right? And the more gadgets are there, the bigger the
"savings".
In this kind of case - would the GWT team say "GWT is the right
choice" or no?
Eric Ayers
Dec 14, 2010, 5:03:13 PM12/14/10
to google-we...@googlegroups.com
So, I think this discussion might be a bit moot in the gadget case. I
thought that gadgets were loaded into their own iframes (at least they
were at one point) and could not share code by design.
thought that gadgets were loaded into their own iframes (at least they
were at one point) and could not share code by design.
> --
> 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.
>
>
--
Eric Z. Ayers
Google Web Toolkit, Atlanta, GA USA
bkar...@gmail.com
Dec 14, 2010, 5:09:25 PM12/14/10
to Google Web Toolkit
Sure, as I said, it's a little bit hard to describe a concrete
example... But you can imagine, I think, given the description what I
am talking about... Right?
example... But you can imagine, I think, given the description what I
am talking about... Right?
bkar...@gmail.com
Dec 15, 2010, 10:10:48 AM12/15/10
to Google Web Toolkit
Just in case it is not clear what I am trying to ask...
The original question post began by (I thought) implying that this is
not a concrete example and is peppered with words and phrases like "if
every gadget", "potentially", "hyptothetically speaking" "in this
hyptothetical example" and "in this kind of case". What I'm asking is
- from the GWT team's POV, are there potentially classes of problems
for which the whole thing "cannot be compiled" (some kind of mashup of
disparate, but - for simplicity sake - somehow trustable code bases)
in which GWT would just have too little insight to the problem at
large to actually optimize - thereby effectively making it a non-ideal
choice... Or if the GWT team had such a problem at hand - would they
choose GWT, and if so, how would they deal with the implications
spelled out above?
The original question post began by (I thought) implying that this is
not a concrete example and is peppered with words and phrases like "if
every gadget", "potentially", "hyptothetically speaking" "in this
hyptothetical example" and "in this kind of case". What I'm asking is
- from the GWT team's POV, are there potentially classes of problems
for which the whole thing "cannot be compiled" (some kind of mashup of
disparate, but - for simplicity sake - somehow trustable code bases)
in which GWT would just have too little insight to the problem at
large to actually optimize - thereby effectively making it a non-ideal
choice... Or if the GWT team had such a problem at hand - would they
choose GWT, and if so, how would they deal with the implications
spelled out above?
Eric Ayers
Dec 15, 2010, 11:53:53 AM12/15/10
to google-we...@googlegroups.com
OK, fair enough. I just wasn't sure if you had the Gadget problem
space specifically in mind.
space specifically in mind.
bkar...@gmail.com
Dec 15, 2010, 12:05:59 PM12/15/10
to Google Web Toolkit
I see "Google Web Toolkit, Atlanta, GA USA" after your name, so I
expect that you are just the kind of person whose opinion I'm looking
for... What say you?
expect that you are just the kind of person whose opinion I'm looking
for... What say you?
Eric Ayers
Dec 15, 2010, 12:43:42 PM12/15/10
to google-we...@googlegroups.com
I chimed in because I maintain the gwt-gadgets API.
Personally, I could come up with some pathological cases, can't think
of a single good reason to not use GWT :-)
There, now maybe you will get some responses.
> --
> 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.
>
>
--
Eric Z. Ayers
David Chandler
Dec 15, 2010, 1:11:41 PM12/15/10
to google-we...@googlegroups.com
Hi bkardell,
I think you're not getting many responses because
1) The subject of "to use GWT or not" comes up on the list about once
a month and it's getting old
2) This forum is for people wanting to use GWT, not for people who are
wanting to not use GWT
3) You've asked a general question. Please posit a specific example
and we can better guide you. If you can't think of one, you should use
GWT :-)
/dmc
On Wed, Dec 15, 2010 at 12:05 PM, bkar...@gmail.com <bkar...@gmail.com> wrote:
> --
> 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.
>
>
--
David Chandler
Developer Programs Engineer, Google Web Toolkit
http://googlewebtoolkit.blogspot.com/
clintjhill
Dec 15, 2010, 12:14:57 PM12/15/10
to Google Web Toolkit
I'll ask the same question in a different way.
There are 2 widgets. The first is for Alerts and the second is for
Messages.
Both share a library for their services (get/parse JSON data).
Both share a library for their UI (extending GWT or composites).
Both are separate GWT projects (code base is separate).
When both are compiled they both receive separate JavaScript for the
following same things:
1. GWT core
2. library for services
3. library for UI
When both are used on a single page you end up with essentially
duplicated downloads from different JavaScript files. However the
desire would be that the GWT core, service and UI libraries be
"shared" and not downloaded twice.
In this example - would GWT be chosen - or is this an example where
GWT doesn't "fit"?
There are 2 widgets. The first is for Alerts and the second is for
Messages.
Both share a library for their services (get/parse JSON data).
Both share a library for their UI (extending GWT or composites).
Both are separate GWT projects (code base is separate).
When both are compiled they both receive separate JavaScript for the
following same things:
1. GWT core
2. library for services
3. library for UI
When both are used on a single page you end up with essentially
duplicated downloads from different JavaScript files. However the
desire would be that the GWT core, service and UI libraries be
"shared" and not downloaded twice.
In this example - would GWT be chosen - or is this an example where
GWT doesn't "fit"?
Christian Goudreau
Dec 15, 2010, 1:27:32 PM12/15/10
to google-we...@googlegroups.com
Why don't you compile them together ? If you're going to use it on the same page, then compile it together for that page and then, you wont have duplicated code.
I personally use a lot of Gwt projects inside my own and this is a non issue. I really don't see why I wouldn't compile my app and everything it needs together. Even a gadget library, I would use efficiently code splitting functionality and just compile everything together. Then when the user navigate through my library to add widgets to his personal page, I would load the widget code and show it.
Cheers,
--
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.
David Chandler
Dec 15, 2010, 1:29:19 PM12/15/10
to google-we...@googlegroups.com
In the example you've given, GWT would compile the shared code into
the module containing the Widgets, so there is only one copy.
Furthermore, any unused methods in the libraries are not compiled or
downloaded, as the GWT compiler eliminates dead code.
the module containing the Widgets, so there is only one copy.
Furthermore, any unused methods in the libraries are not compiled or
downloaded, as the GWT compiler eliminates dead code.
Furthermore, you can break up an app into multiple pieces that get
loaded "just in time" with
http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html
HTH,
/dmc
On Wed, Dec 15, 2010 at 12:14 PM, clintjhill <clint...@gmail.com> wrote:
> --
> 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.
>
>
--
clintjhill
Dec 15, 2010, 2:07:32 PM12/15/10
to Google Web Toolkit
To add an important part to the conversation.
Widget #1 is developed by a team in CA.
Widget #2 is developed by a team in AZ.
They both have access to and utilize the 3 shared libraries.
Furthermore - the intent is that these widgets be capable of landing
in the same page but also possibly separately in different pages.
On Dec 15, 11:29 am, David Chandler <drfibona...@google.com> wrote:
> In the example you've given, GWT would compile the shared code into
> the module containing the Widgets, so there is only one copy.
> Furthermore, any unused methods in the libraries are not compiled or
> downloaded, as the GWT compiler eliminates dead code.
>
> Furthermore, you can break up an app into multiple pieces that get
> loaded "just in time" withhttp://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html
> > For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en.
Widget #1 is developed by a team in CA.
Widget #2 is developed by a team in AZ.
They both have access to and utilize the 3 shared libraries.
Furthermore - the intent is that these widgets be capable of landing
in the same page but also possibly separately in different pages.
On Dec 15, 11:29 am, David Chandler <drfibona...@google.com> wrote:
> In the example you've given, GWT would compile the shared code into
> the module containing the Widgets, so there is only one copy.
> Furthermore, any unused methods in the libraries are not compiled or
> downloaded, as the GWT compiler eliminates dead code.
>
> Furthermore, you can break up an app into multiple pieces that get
bkar...@gmail.com
Dec 15, 2010, 2:31:59 PM12/15/10
to Google Web Toolkit
Ok, a few things.
1) Thanks for the response.
2) Please have some patience, I'm really trying my best to communicate
what seems to me a perfectly rational question that I feel like I am
directing at exactly the right people. If I come across unclearly, I
will be more than happy to try to clarify.
3) The examples that both @clintjhill and I gave specified that these
are disparate code bases that _can not_ be compiled together. It is
possible to specify things that can and can't be used, even an API -
but they aren't owned by the same entity... That's really why I tried
to use "something like" iGoogle as an example because it's sort of the
most analogous thing I can think of... It's a Mashup situation where
there can potentially be many, many components shoved together from
disparate (but trusted) sources. If I recall, I think that the gadget
container actually _does_ provide some common API for tabs and rpc and
things... I'm not sure if that's re-incuded every time, but that's the
idea - do we have to reinclude it every time? I think that
@clintjhill's example is more literal/concise so if you are more
comfortable with that, the only addition I would like to make is that
it is perhaps a little too small (not just repeated, but repeated
potentially many, many times) to demonstrate my concern....
4) Note the end of the question above "... if the GWT team had such a
problem at hand - would they choose GWT" is followed immediately by
"... and if so, how would they deal with the implications spelled out
above?"
I just want to say... There are languages and tools that I use, that I
_love_ in fact, which would just be the wrong choice if that's not the
problem space that they are focused on solving. I think, if I had no
desire to use GWT - why would I be asking...right?
1) Thanks for the response.
2) Please have some patience, I'm really trying my best to communicate
what seems to me a perfectly rational question that I feel like I am
directing at exactly the right people. If I come across unclearly, I
will be more than happy to try to clarify.
3) The examples that both @clintjhill and I gave specified that these
are disparate code bases that _can not_ be compiled together. It is
possible to specify things that can and can't be used, even an API -
but they aren't owned by the same entity... That's really why I tried
to use "something like" iGoogle as an example because it's sort of the
most analogous thing I can think of... It's a Mashup situation where
there can potentially be many, many components shoved together from
disparate (but trusted) sources. If I recall, I think that the gadget
container actually _does_ provide some common API for tabs and rpc and
things... I'm not sure if that's re-incuded every time, but that's the
idea - do we have to reinclude it every time? I think that
@clintjhill's example is more literal/concise so if you are more
comfortable with that, the only addition I would like to make is that
it is perhaps a little too small (not just repeated, but repeated
potentially many, many times) to demonstrate my concern....
4) Note the end of the question above "... if the GWT team had such a
problem at hand - would they choose GWT" is followed immediately by
"... and if so, how would they deal with the implications spelled out
above?"
I just want to say... There are languages and tools that I use, that I
_love_ in fact, which would just be the wrong choice if that's not the
problem space that they are focused on solving. I think, if I had no
desire to use GWT - why would I be asking...right?
bkar...@gmail.com
Dec 15, 2010, 2:46:28 PM12/15/10
to Google Web Toolkit
So Christian... I get what you are saying and that is actually what
you would do if you owned it all as one thing, I totally agree... I
think that the showcase app is probably like that and I have no
problem with it... Makes sense.
However in the iGoogle-esq example/question, those widgets are
developed by different companies, or different parts of
companies...They are created or updated all the time and whenever that
happens, they need to be registered and immediately become
available... Are you saying that you would recompile and redeploy the
whole app every time this happens?
Any other ideas? The only other idea which we can see is that they
are compiled separately - this creates the kind of situation described
above, which we're looking for advice on...
you would do if you owned it all as one thing, I totally agree... I
think that the showcase app is probably like that and I have no
problem with it... Makes sense.
However in the iGoogle-esq example/question, those widgets are
developed by different companies, or different parts of
companies...They are created or updated all the time and whenever that
happens, they need to be registered and immediately become
available... Are you saying that you would recompile and redeploy the
whole app every time this happens?
Any other ideas? The only other idea which we can see is that they
are compiled separately - this creates the kind of situation described
above, which we're looking for advice on...
Christian Goudreau
Dec 15, 2010, 3:04:52 PM12/15/10
to google-we...@googlegroups.com
Are you saying that you would recompile and redeploy the whole app every time this happens?
Well if you're thinking about a plug in-like application where third parties register plug in for your application and that your clients must have access to those newly added plug in. Well, yes. Anyway automatic adoption of any plug in or any third parties application is unsecured, I prefer having a team that investigate newly added plug in, then compile the entire app to add that plug in to the library. After that, every users would be able to it to their profile and be assured that the plug in isn't malicious.
That can be done and there's even some projects around that are about sharing resources to make compile time faster. Anyway, there's too much variable to take into account to have a straight answer. At least you can assume that if you compile everything separately, you'll end up with duplicated code and that you must compile somehow to fully take advantages of Gwt.
Cheers
--
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.
--
Christian Goudreau
David Chandler
Dec 15, 2010, 3:08:29 PM12/15/10
to google-we...@googlegroups.com
Fair enough, bkardell. GWT cannot optimize code that cannot be
compiled together. If it's a requirement for you that each widget is a
separate JavaScript, then you'd have to compile a few and see whether
the GWT optimizations such as dead code elimination outweigh the
effects of compiling multiple times the commonly used parts of the
shared libraries.
compiled together. If it's a requirement for you that each widget is a
separate JavaScript, then you'd have to compile a few and see whether
the GWT optimizations such as dead code elimination outweigh the
effects of compiling multiple times the commonly used parts of the
shared libraries.
GWT's sweet spot, IMHO, is building rich Internet applications that
feel like a desktop app but run in a browser. GWT can break the app
into multiple pieces using code splitting (runAsync), but if the
pieces aren't part of the same compile as in your case, that won't
help.
/dmc
Myles Bostwick
Dec 15, 2010, 3:17:20 PM12/15/10
to google-we...@googlegroups.com
Even if the code is not being compiled together, it seems like a library module could be created that could then be shared by all widgets in this scenario. Someone please correct me if I'm wrong.
Brian Kardell
Dec 15, 2010, 3:18:49 PM12/15/10
to google-we...@googlegroups.com
Thanks David.
I'll say that before posting anything on here I spent hours searching through these groups and found a lot of people looking for some kind of reuse very much related to this same kind of problem - but nothing especially helpful in the way of a solution... It almost seems like it should be doable with just a little bit more the compiler side or something.
Is the compiler source available? I have looked briefly into linkers, but I fear that the big hangup for us is really the base stuff which probably isn't addressable from the linkers. Any advice on somewhere I can follow up with those kinds of interests?
-Brian
Christian Goudreau
Dec 15, 2010, 3:28:07 PM12/15/10
to google-we...@googlegroups.com
Even if the code is not being compiled together, it seems like a library module could be created that could then be shared by all widgets in this scenario. Someone please correct me if I'm wrong.
I think so too, but then you will need something to communicate between every module using JSNI...
Cheers,
Brian Kardell
Dec 15, 2010, 3:28:11 PM12/15/10
to google-we...@googlegroups.com
Yeah - it really would seem that way at the outset, but from what I'm seeing first hand and reading in the groups it's kind of not that way... If you have two things that are GWT at both ends (as opposed to say 1 external JS and 1 GWT) you can share GWT modules - but each compile that uses it grabs only what it needs from that module during the compile, thus each compile that uses the module would re-optimize for that specific use (re-include the bits they use).
If that's not right... would be excellent.
On Wed, Dec 15, 2010 at 3:17 PM, Myles Bostwick <cth...@gmail.com> wrote:
Even if the code is not being compiled together, it seems like a library module could be created that could then be shared by all widgets in this scenario. Someone please correct me if I'm wrong.
--
zixzigma
Dec 15, 2010, 3:29:22 PM12/15/10
to Google Web Toolkit
On Dec 15, 11:07 am, clintjhill <clint.h...@gmail.com> wrote:
> To add an important part to the conversation.
>
> Widget #1 is developed by a team in CA.
> Widget #2 is developed by a team in AZ.
> They both have access to and utilize the 3 shared libraries.
doesnt matter they are in different rooms or different continents,
they commit to same Source Code Repository!
Christian Goudreau
Dec 15, 2010, 3:30:28 PM12/15/10
to google-we...@googlegroups.com
Distributed Teams, should use Distributed Version Control Systems. doesnt matter they are in different rooms or different continents, they commit to same Source Code Repository!
I have to agree with that !
--
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.
--
Christian Goudreau
bkar...@gmail.com
Dec 15, 2010, 3:33:40 PM12/15/10
to Google Web Toolkit
Yeah... That's a red herring, let's not pursue that any further :) It
has nothing to do with anyone's location - everything to do with
separate codebases/projects.
On Dec 15, 3:30 pm, Christian Goudreau <goudreau.christ...@gmail.com>
wrote:
> > .
has nothing to do with anyone's location - everything to do with
separate codebases/projects.
On Dec 15, 3:30 pm, Christian Goudreau <goudreau.christ...@gmail.com>
wrote:
> > Distributed Teams, should use Distributed Version Control Systems. doesnt
> > matter they are in different rooms or different continents, they commit to
> > same Source Code Repository!
>
> I have to agree with that !
>
>
>
>
>
> On Wed, Dec 15, 2010 at 3:29 PM, zixzigma <zixzi...@gmail.com> wrote:
>
> > On Dec 15, 11:07 am, clintjhill <clint.h...@gmail.com> wrote:
> > > To add an important part to the conversation.
>
> > > Widget #1 is developed by a team in CA.
> > > Widget #2 is developed by a team in AZ.
> > > They both have access to and utilize the 3 shared libraries.
>
> > Distributed Teams, should use Distributed Version Control Systems.
> > doesnt matter they are in different rooms or different continents,
> > they commit to same Source Code Repository!
>
> > --
> > 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<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > matter they are in different rooms or different continents, they commit to
> > same Source Code Repository!
>
> I have to agree with that !
>
>
>
>
>
> On Wed, Dec 15, 2010 at 3:29 PM, zixzigma <zixzi...@gmail.com> wrote:
>
> > On Dec 15, 11:07 am, clintjhill <clint.h...@gmail.com> wrote:
> > > To add an important part to the conversation.
>
> > > Widget #1 is developed by a team in CA.
> > > Widget #2 is developed by a team in AZ.
> > > They both have access to and utilize the 3 shared libraries.
>
> > Distributed Teams, should use Distributed Version Control Systems.
> > doesnt matter they are in different rooms or different continents,
> > they commit to same Source Code Repository!
>
> > --
> > 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
> > .
clintjhill
Dec 15, 2010, 3:34:42 PM12/15/10
to Google Web Toolkit
On the face of it. Sure.
But until you understand a development environment - don't be hasty
with absolutes.
On Dec 15, 1:30 pm, Christian Goudreau <goudreau.christ...@gmail.com>
wrote:
> > .
But until you understand a development environment - don't be hasty
with absolutes.
On Dec 15, 1:30 pm, Christian Goudreau <goudreau.christ...@gmail.com>
wrote:
> > Distributed Teams, should use Distributed Version Control Systems. doesnt
> > matter they are in different rooms or different continents, they commit to
> > same Source Code Repository!
>
> I have to agree with that !
>
>
>
>
>
>
>
>
>
> On Wed, Dec 15, 2010 at 3:29 PM, zixzigma <zixzi...@gmail.com> wrote:
>
> > On Dec 15, 11:07 am, clintjhill <clint.h...@gmail.com> wrote:
> > > To add an important part to the conversation.
>
> > > Widget #1 is developed by a team in CA.
> > > Widget #2 is developed by a team in AZ.
> > > They both have access to and utilize the 3 shared libraries.
>
> > Distributed Teams, should use Distributed Version Control Systems.
> > doesnt matter they are in different rooms or different continents,
> > they commit to same Source Code Repository!
>
> > --
> > 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<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > matter they are in different rooms or different continents, they commit to
> > same Source Code Repository!
>
> I have to agree with that !
>
>
>
>
>
>
>
>
>
> On Wed, Dec 15, 2010 at 3:29 PM, zixzigma <zixzi...@gmail.com> wrote:
>
> > On Dec 15, 11:07 am, clintjhill <clint.h...@gmail.com> wrote:
> > > To add an important part to the conversation.
>
> > > Widget #1 is developed by a team in CA.
> > > Widget #2 is developed by a team in AZ.
> > > They both have access to and utilize the 3 shared libraries.
>
> > Distributed Teams, should use Distributed Version Control Systems.
> > doesnt matter they are in different rooms or different continents,
> > they commit to same Source Code Repository!
>
> > --
> > 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
> > .
zixzigma
Dec 15, 2010, 3:40:51 PM12/15/10
to Google Web Toolkit
if you use JQuery or any other Library,
there is a core JSLibrary,
and third party plugins.
in a typical app/site you end up adding plugin after plugin to your
site/app.
each of those plugins are developed by separate developer somewhere in
the world.
they might have used similar utility library, but when you use them
together you have no idea.
so this problem is not a GWT related problem.
your team/company should put in a place a process regarding code-
reuse.
one alternative could be to rely on only one 3rd party provider, such
as Ext,
you can be pretty sure that they have a common base library
underneath.
you might have to pay. well decisions are about tradeoff.
the other alternative is assembling random plugins over the internet,
developed by developers with varying degree of skills.
you end up with bloated tangled JavaScript code, where plugin after
plugin,
contains duplicate code. this is the case with JQuery plugins.
JQuery itself is a neat library,
but if you assemble random plugins you found over the internet,
the problem you described also applies.
and it is not just JavaScript,in any programming language,
if you rely on third-party packages/libraries, there is a good chance
there might be a fair amount of duplication,
resulting in larger size of file.
thats why in Java World, build tools such as Maven, help manage
dependencies, so you don't use more than what you need.
but even then, each of the .jar in your project, might have used
custom String/Math/Algorithms utility classes.
it is not a GWT problem, becareful when using external libraries.
tradeoff: you get a piece of functionality out of the box VS
maintainability and duplication
there is a core JSLibrary,
and third party plugins.
in a typical app/site you end up adding plugin after plugin to your
site/app.
each of those plugins are developed by separate developer somewhere in
the world.
they might have used similar utility library, but when you use them
together you have no idea.
so this problem is not a GWT related problem.
your team/company should put in a place a process regarding code-
reuse.
one alternative could be to rely on only one 3rd party provider, such
as Ext,
you can be pretty sure that they have a common base library
underneath.
you might have to pay. well decisions are about tradeoff.
the other alternative is assembling random plugins over the internet,
developed by developers with varying degree of skills.
you end up with bloated tangled JavaScript code, where plugin after
plugin,
contains duplicate code. this is the case with JQuery plugins.
JQuery itself is a neat library,
but if you assemble random plugins you found over the internet,
the problem you described also applies.
and it is not just JavaScript,in any programming language,
if you rely on third-party packages/libraries, there is a good chance
there might be a fair amount of duplication,
resulting in larger size of file.
thats why in Java World, build tools such as Maven, help manage
dependencies, so you don't use more than what you need.
but even then, each of the .jar in your project, might have used
custom String/Math/Algorithms utility classes.
it is not a GWT problem, becareful when using external libraries.
tradeoff: you get a piece of functionality out of the box VS
maintainability and duplication
David Chandler
Dec 15, 2010, 3:50:40 PM12/15/10
to google-we...@googlegroups.com
Myles,
If your library code is JavaScript, you can always use JSNI methods in
GWT to call it. You could turn off optimizations in order to make GWT
produce such a JS, but GWT is designed to produce a highly-optimized
JavaScript for your app, not lots of little library JavaScripts, each
with potentially unused code.
I'm pretty sure a "shared library" feature has been requested on the
issue tracker, but I can't find it at the moment. For the time being,
code splitting (which requires a single Java code base) is the only
way to break a large GWT app into multiple JavaScripts.
/dmc
David Chandler
Dec 15, 2010, 3:54:47 PM12/15/10
to google-we...@googlegroups.com
Brian,
Yes, all of GWT is open source. For more info, see
http://code.google.com/webtoolkit/makinggwtbetter.html
Happy exploring.
/dmc
On Wed, Dec 15, 2010 at 3:18 PM, Brian Kardell <bkar...@gmail.com> wrote:
bkar...@gmail.com
Dec 15, 2010, 5:36:14 PM12/15/10
to Google Web Toolkit
I'm not really sure how to respond to that other than to say, "yes, we
understand the alternatives and the theory/practice" :)
Thanks.
understand the alternatives and the theory/practice" :)
Thanks.
Paul Robinson
Dec 15, 2010, 5:57:10 PM12/15/10
to google-we...@googlegroups.com
I haven't used gwt-exporter, or any non-trivial JSNI, so what I'm about
to say may be rubbish.
http://code.google.com/p/gwt-exporter/
to say may be rubbish.
http://code.google.com/p/gwt-exporter/
If you want multiple gadget-like things to work together that have been
compiled separately, you could:
(1) Put each gadget-like thing into its own project
(2) Use gwt-exporter to create a javascript API
(3) Compile your gadget-like thing, and publish the resulting javascript
with its API.
(4) Create a GWT wrapper that uses JSNI to talk to the javascript API,
creating a GWT Java API
(5) Distribute the javascript compiled in (3) together with the java
source code for the wrapper you created in (4)
Then somebody could pull many of these gadget-like things together in a
big mashup.
If you wanted to add these gadget-like things together at *runtime*, you
could do that if you just rely on the javascript API. If you're happy to
GWT-compile the mashup, then you could use the GWT java wrappers so that
the mashup could avoid JSNI, relying on the wrappers doing JSNI for you.
However:
(a) I don't know what, if any, bootstrapping you'd need to do for each
of the gadget-like things.
(b) You might suffer from some duplication that a monolithic compile
could optimize away. But you could provide common services into another
gadget-like thing, and let other gadget-like things call its GWT wrapper.
(c) All this might be made to work, but there may be a better way that
doesn't involve GWT
(d) I've no idea how you'd debug it as a whole
Paul
On 14/12/10 21:57, bkar...@gmail.com wrote:
> GWT's monolithic compile makes for really efficient JavaScript/
> Resource downloads. In terms of providing a solution to the sort of
> "traditional" kinds of web app problems, it's hard to argue that GWT
> couldn't optimize whatever a developer would write because developers
> write for flexibility - whereas the compile is about "there is 1 use
> at the end of the day and everything else is just noise".
>
> I'm sort of wondering though, are there classes of problems that GWT
> is admittedly not a good fit for (specifically, according to the GWT
> team itself) specifically because of that approach?
>
> It's kind of hard to explain a concrete example, but let's try this:
> If every gadget for iGoogle had to be developed in GWT - each iGoogle
> gadget would contain everything that it needed and rely on nothing
> shared, despite the fact that most gadgets would (according to the
> compile reports) potentially share as much as 99% of their
> dependencies. Simply because they are disparate compiles, the
> compiler's view into the world is just too small...
>
> Hypothetically speaking, if the average gadget were something like
> 50k, and something like 48k of that was just "core stuff", this
> implies that a page with 10 gadgets would be something like 500k (of
> just script), but 480k of that was largely just "repeated" core code.
> I suppose it guarantees that things won't "break" to an extent with
> versioning, but wouldn't it be more efficient in this hypothetical
> example to have coded the flexibility into the gadget "container"
> once? In other words - if the core were provided and the gadgets
> merely used it, the total size of the page would be 68k instead of
> 500... Right? And the more gadgets are there, the bigger the
> "savings".
>
> In this kind of case - would the GWT team say "GWT is the right
> choice" or no?
>
>
yves
Dec 16, 2010, 7:34:52 AM12/16/10
to Google Web Toolkit
Hi,
Some times ago I had same kind of questions than bkardell.
Actually I would reformulate it another way : I compare the problem to
an .exe that is using .dll files
If you build a new .exe app you may reuse existing .dlls
I understand that this is not possible with GWT as when you compile
your GWT-app, you compile the entire code in once.
The big advantage is the javascript optimization.
But would it be possible in the future to allow building GWT-app by
reusing previously built "GWT-dlls" ?
This implies that those "GWT-dlls" have a know API-contract used by
the main "GWT-exe"
In a distributed and disparate environment this has been solved with
the SOA concept using SOAP, an ESB,... with all the paylod and
complexity allowing the communication between the components.
So I don't have in mind an ESB solution, as the environment is not
distributed nor disparate.
But in the context of GWT, would it be nonsense (for the future of
course) to build new app by using pre-compiled building blocks having
their own life-cycle independant of each other ?
Yves
Some times ago I had same kind of questions than bkardell.
Actually I would reformulate it another way : I compare the problem to
an .exe that is using .dll files
If you build a new .exe app you may reuse existing .dlls
I understand that this is not possible with GWT as when you compile
your GWT-app, you compile the entire code in once.
The big advantage is the javascript optimization.
But would it be possible in the future to allow building GWT-app by
reusing previously built "GWT-dlls" ?
This implies that those "GWT-dlls" have a know API-contract used by
the main "GWT-exe"
In a distributed and disparate environment this has been solved with
the SOA concept using SOAP, an ESB,... with all the paylod and
complexity allowing the communication between the components.
So I don't have in mind an ESB solution, as the environment is not
distributed nor disparate.
But in the context of GWT, would it be nonsense (for the future of
course) to build new app by using pre-compiled building blocks having
their own life-cycle independant of each other ?
Yves
Christian Goudreau
Dec 16, 2010, 9:00:53 AM12/16/10
to google-we...@googlegroups.com
But would it be possible in the future to allow building GWT-app by reusing previously built "GWT-dlls"
It is already possible. Just build your "dll" project and export a Jar to be used within your ".exe".
--
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.
--
Christian Goudreau
bkar...@gmail.com
Dec 16, 2010, 9:31:24 AM12/16/10
to Google Web Toolkit
I think you're still not understanding the distinction Christian,
since GWT is Java let's try to use an appropriate Java analogy rather
than .exe's... The distinction is more like whether a class is on the
environment/server classpath (even part of the JRE itself like Swing)
vs each app having a distinct copy of it. The JRE is kind of the most
obvious example - in theory, we could compile up only the relevant
bits of the JRE and deliver one hyper-optimal download for each app.
Given Java's classloading architecture, anything above the JRE level
is probably less analogous. So that's kind of the two things that I'd
like to see...
1) Some way to deliver a single sort of desktop "JRE" which would
include the GWT JavaScript JRE stuff + an exposed base of the whole
"WT" part which the rest of my projects can just use... Just like the
regular JRE, I'm totally willing to say "go ahead and get the whole
thing, because I only have to get it once per version no matter how
many programs I develop against it"... I can stick it on a CDN and
I'll never have to "re-get", in fact, if more people did it, most apps
would never even pay the initial cost. Even in IE6, the memory
required for that whole kit to be there once loaded is comparatively
negligible.
2) (ideally) Something more or less analogous to a specialized URL
classloader for this (and potentially of things like it) where I can
provide a URL to point it at some GWT lib resource, effectively
putting it on the classpath and accounted for by the compiler by not
attempting to optimize it, but merely reference.
On Dec 16, 9:00 am, Christian Goudreau <goudreau.christ...@gmail.com>
wrote:
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .
since GWT is Java let's try to use an appropriate Java analogy rather
than .exe's... The distinction is more like whether a class is on the
environment/server classpath (even part of the JRE itself like Swing)
vs each app having a distinct copy of it. The JRE is kind of the most
obvious example - in theory, we could compile up only the relevant
bits of the JRE and deliver one hyper-optimal download for each app.
Given Java's classloading architecture, anything above the JRE level
is probably less analogous. So that's kind of the two things that I'd
like to see...
1) Some way to deliver a single sort of desktop "JRE" which would
include the GWT JavaScript JRE stuff + an exposed base of the whole
"WT" part which the rest of my projects can just use... Just like the
regular JRE, I'm totally willing to say "go ahead and get the whole
thing, because I only have to get it once per version no matter how
many programs I develop against it"... I can stick it on a CDN and
I'll never have to "re-get", in fact, if more people did it, most apps
would never even pay the initial cost. Even in IE6, the memory
required for that whole kit to be there once loaded is comparatively
negligible.
2) (ideally) Something more or less analogous to a specialized URL
classloader for this (and potentially of things like it) where I can
provide a URL to point it at some GWT lib resource, effectively
putting it on the classpath and accounted for by the compiler by not
attempting to optimize it, but merely reference.
On Dec 16, 9:00 am, Christian Goudreau <goudreau.christ...@gmail.com>
wrote:
> > .
Myles Bostwick
Dec 16, 2010, 9:54:28 AM12/16/10
to google-we...@googlegroups.com
If you turn off optimization when you compile with that library module, it should be the same for each app which should allow you to share it. Essentially that's what it sounds like you've been asking this whole time. Can I use GWT to follow the same paradigm that is used for prototype and jquery, which is can I include one library to rule them all and just share that. Turning off optimization in the compiler should accomplish that.
bkar...@gmail.com
Dec 16, 2010, 11:07:44 AM12/16/10
to Google Web Toolkit
Myles,
Help me to understand what you are saying, because I am getting the
sense that there is still a disconnect... If anyone feels that they
can help facilitate this conversation, please jump in...
Let's take the simplest possible case that I was describing above
where what I'm trying to download the whole WT part of GWT just once
and still use GWT to develop further small, 1 or two widget project
that just reuses it rather than recompiling the whole "JRE/WT" part,
which can account for a pretty big percentage (97% or better) of the
code in a compile of 1 or two widgets. You are saying, I think, is
that I can just turn off the optimization and then viola, it's done.
Is that right? First - do you have any example of this? I've tried
several things to even get the full JRE/WT part to spit out, but I'm
not sure how... And then if it is, it is exposed appropriately? I
think it won't be. You'd need something like GWT exporter - only for
the actual _GWT_ code... right?
Further though, my addition GWT projects beyond it wouldn't know
anything about it unless I can also tell the compiler "don't include
this stuff, because it'll be there already - I promise". I think
you'd have to do some gyrations to make that work, and I'm not even
sure how... I guess one way would be to write JSNI wrappers that would
then merely "point" to the stuff exported above - but... I'll just let
you think about the implications there as it's ugly to even think
about much less write... Additionally I'm not sure if turning
optimization "off" is what I want at all... "Optimization" isn't an
all or nothing kind of thing - even in GWT out of the box... Any time
you talk about optimization, it's subject to the context and what you
weigh as important... Right? That's why GWT introduced code-splitting
I think... In some cases, it is suboptimal to get the whole thing at
once. In the case I am describing, some things that would generally
be done as part of optimization could still apply, others not.
Throwing out the whole thing, I think, would be a mistake, even if
that would work... though, at least it would be a starting point.
So... Am I totally missing something obvious? It would be awesome if
you could tell me that I was, but I get the feeling that I'm not.
Help me to understand what you are saying, because I am getting the
sense that there is still a disconnect... If anyone feels that they
can help facilitate this conversation, please jump in...
Let's take the simplest possible case that I was describing above
where what I'm trying to download the whole WT part of GWT just once
and still use GWT to develop further small, 1 or two widget project
that just reuses it rather than recompiling the whole "JRE/WT" part,
which can account for a pretty big percentage (97% or better) of the
code in a compile of 1 or two widgets. You are saying, I think, is
that I can just turn off the optimization and then viola, it's done.
Is that right? First - do you have any example of this? I've tried
several things to even get the full JRE/WT part to spit out, but I'm
not sure how... And then if it is, it is exposed appropriately? I
think it won't be. You'd need something like GWT exporter - only for
the actual _GWT_ code... right?
Further though, my addition GWT projects beyond it wouldn't know
anything about it unless I can also tell the compiler "don't include
this stuff, because it'll be there already - I promise". I think
you'd have to do some gyrations to make that work, and I'm not even
sure how... I guess one way would be to write JSNI wrappers that would
then merely "point" to the stuff exported above - but... I'll just let
you think about the implications there as it's ugly to even think
about much less write... Additionally I'm not sure if turning
optimization "off" is what I want at all... "Optimization" isn't an
all or nothing kind of thing - even in GWT out of the box... Any time
you talk about optimization, it's subject to the context and what you
weigh as important... Right? That's why GWT introduced code-splitting
I think... In some cases, it is suboptimal to get the whole thing at
once. In the case I am describing, some things that would generally
be done as part of optimization could still apply, others not.
Throwing out the whole thing, I think, would be a mistake, even if
that would work... though, at least it would be a starting point.
So... Am I totally missing something obvious? It would be awesome if
you could tell me that I was, but I get the feeling that I'm not.
Myles Bostwick
Dec 16, 2010, 11:19:19 AM12/16/10
to google-we...@googlegroups.com
Your simple case is not quite what I'm referring to. Take instead your simple case, but you have to recompile everything. However, when you deploy, because you didn't optimize, and because you've separated your reusable code into separate libraries, you will have identically named files that each sub-app if you will can share. There is potentially some need for creative code splitting there so that the libraries are actual files to download, but those filenames are based on an md5 sum as I recall, so if the same content is in there, they are the same file.
The reason I say optimization would need to be turned off is so that you don't get a different file generated by the compiler. Essentially giving you every library call a sub-app could use. Very much like the prototype or jquery model.
Ultimately, it's not the way GWT was intended to be used, but you'd still get the Java development environment and the permutation logic which is pretty big in the web world, so you *could* do it.
bkar...@gmail.com
Dec 16, 2010, 11:40:03 AM12/16/10
to Google Web Toolkit
Myles, thanks for not giving up and your continued efforts to want to
see that we come to a common understanding :)
I still think that we are talking past one another though... When you
compile your one file, it has JRE/WT stuff in it. Above that - I can
see how codesplitting and your Md5 example could conceivably come into
play, but without addressing that, the rest is comparatively minor.
How can you conceivably generate a file that has just JRE/WT and hope
that the others will exclude it... I'm not seeing how you can. Again,
I could be totally wrong, I am understanding correctly, you seem to be
pretty convinced that you can and it almost sounds like it's
trivial... I hope so - that would be excellent for me... So - Can you?
Sticking the JRE/WT out on GitHub or something would be a huge step
forward in proving the case... Then you only have to tell me how I can
get/keep it excluded from the rest of my compiles :)
see that we come to a common understanding :)
I still think that we are talking past one another though... When you
compile your one file, it has JRE/WT stuff in it. Above that - I can
see how codesplitting and your Md5 example could conceivably come into
play, but without addressing that, the rest is comparatively minor.
How can you conceivably generate a file that has just JRE/WT and hope
that the others will exclude it... I'm not seeing how you can. Again,
I could be totally wrong, I am understanding correctly, you seem to be
pretty convinced that you can and it almost sounds like it's
trivial... I hope so - that would be excellent for me... So - Can you?
Sticking the JRE/WT out on GitHub or something would be a huge step
forward in proving the case... Then you only have to tell me how I can
get/keep it excluded from the rest of my compiles :)
Myles Bostwick
Dec 16, 2010, 11:58:26 AM12/16/10
to google-we...@googlegroups.com
Sure in that regard you'll have some duplication, not any way around that that I can see.
bkar...@gmail.com
Dec 16, 2010, 12:12:26 PM12/16/10
to Google Web Toolkit
Thanks again Myles, that's what I expected, but wanted to keep
pursuing just in case.
For the record though, I just want to point out that the case here is
that we will have _most_ duplication, not some, and that is why it is
problematic. In our tests, as much as 99% of the code generated for
these (again, relevant to the approach we have, not usually a problem
with GWT) belonged to GWT, not us... In this case, it really is sort
of like downloading a significant portion of the JRE for each
widget... You can see why that would be wasteful in our case.
pursuing just in case.
For the record though, I just want to point out that the case here is
that we will have _most_ duplication, not some, and that is why it is
problematic. In our tests, as much as 99% of the code generated for
these (again, relevant to the approach we have, not usually a problem
with GWT) belonged to GWT, not us... In this case, it really is sort
of like downloading a significant portion of the JRE for each
widget... You can see why that would be wasteful in our case.
Ian Bambury
Dec 16, 2010, 12:44:42 PM12/16/10
to google-we...@googlegroups.com
Hi bkardell,
I think the simple answer is that in extreme cases such as the one you cite, GWT is not a good fit.
The easiest response is to ask you to give it a bit of time and wait until you understand what GWT is before you ask these questions :-)
But quickly:
* GWT came into being in order to make JavaScript easier to write by allowing you to write in Java instead and therefore be able to use all the tools that are available to Java developers.
* Obviously this means come sort of conversion from the Java-syntax plain text into a JavaScript script
* In doing so, the Google chaps went a bit beresk in trying to optimise the code produced. And well done them, they have done a fantastic job at it.
* One of the aims was to produce a monolith that could be uploaded (at a time-price) initially, but thereafter would be, like a desktop app, already on the client's machine and only gets re-uploaded if it changes (i.e. an update)
* Due to the take-up of GWT and the scale of projects people tried to produce (e.g. a corporate web site in one .js file) code splitting was added so that not all the code (pages, whatever) was uploaded unless needed.
Basically, though, GWT is aimed at creating a one-page (as in HTML) web site, not at producing little live-alone gadgets to stick into an existing page.
I don't think there will, in the near future, be any way to allow tens of GWT gadgets to access core GWT functionality via a DLL-like common library. For one thing, my tiny 25kb (currently) gadget, on first use, if it were the first gadget to be used (and maybe the only one, too) would have to download a library with code for every single thing that GWT can do, including all deprecated, outdated and weird widgets. The overhead is pointless.
On the other hand, ten 30k (before compression) widgets is nothing these days with internet speeds being what they are (and what they will be soon).
So yep, if you have a hundred medium to large sized gadgets that get updated on a daily basis, GWT is probably not for you unless you write some kind of gadget-framework in GWT and use some kind of meta-code to control it.
You are very good at coming up with corner cases of a theoretical nature. May I humbly suggest that you tell us what you are actually trying to do so that the people in this community can address a concrete problem you have rather than 'yes but what if...' scenarios.
Specific is good :-)
Ian
bkar...@gmail.com
Dec 16, 2010, 2:47:38 PM12/16/10
to Google Web Toolkit
Hi Ian,
My example is not a nebulous hyper-pathelogical theoretical case meant
to stymie the group and prove something about GWT. It is the real
world environment/problem that I have in front of me - almost exactly
as I have described (although, actually more pathological than I have
indicated IMO, this is the crux). So given all of these things I have
no control over, I think to myself "You know... Given the problem, it
seems somehow contrary to GWT's whole notion to me. Maybe GWT just
wouldn't be the right tool for this kind of thing - OR - perhaps I'm
missing something... Let's ask the GWT list - more specifically the
GWT team - and see what they think. They ought to know."
Anyway, I think I've gotten my answer a few times over now - but
thanks :)
BTW - I'm not sure which part of my posts have made it sound like I
don't understand GWT. Is it just the title? The nature of the
question? Ironic if so given the above. I kind of feel like I
understand it pretty well - this isn't the first time I'm seeing it or
anything, in fact, it's what I know about GWT that makes me question
whether it's the right tool for this problem in the first place.
My example is not a nebulous hyper-pathelogical theoretical case meant
to stymie the group and prove something about GWT. It is the real
world environment/problem that I have in front of me - almost exactly
as I have described (although, actually more pathological than I have
indicated IMO, this is the crux). So given all of these things I have
no control over, I think to myself "You know... Given the problem, it
seems somehow contrary to GWT's whole notion to me. Maybe GWT just
wouldn't be the right tool for this kind of thing - OR - perhaps I'm
missing something... Let's ask the GWT list - more specifically the
GWT team - and see what they think. They ought to know."
Anyway, I think I've gotten my answer a few times over now - but
thanks :)
BTW - I'm not sure which part of my posts have made it sound like I
don't understand GWT. Is it just the title? The nature of the
question? Ironic if so given the above. I kind of feel like I
understand it pretty well - this isn't the first time I'm seeing it or
anything, in fact, it's what I know about GWT that makes me question
whether it's the right tool for this problem in the first place.
Ian Bambury
Dec 16, 2010, 3:44:53 PM12/16/10
to google-we...@googlegroups.com
I don't think I said you were stymying the group. Sorry if my reply gave that impression.
I don't know how much you know about GWT. I don't even know how much of GWT I don't know. That's the trouble with the unknown. Presumably you don't understand this particular little bit or you wouldn't be asking.
Apologies again,
Ian
StrongSteve
Dec 17, 2010, 3:53:33 AM12/17/10
to Google Web Toolkit
Hello,
After reading the whole thread - it has gotten quite large, I would
like to share some thoughts, too. ;)
Personally I regard creating something like a desktop JRE for GWT to
be a suboptimal solution. From my point of view all GWT application/
projects/... already have a common base - HTML 4, CSS and JS. Every
new GWT application is based on these three components. So in a
certain way this can be seen as a - and I quote you - "desktop GWT
JRE".
Creating a common library with GWT logic that may or may not be needed
by every new application sure sounds promising when thinking about
filesizes and transfer time. After all this library would have to be
transferred only once to the client and live on inside the browser
cache for some time.
BUT the code inside this "library" would not be optimized for your
specific application. Moreover it would contain code for all possible
browsers supporting all of their "weird interpretations".
One of the strength of GWT is the compile step and the optimization of
the produced code for one specific application - one specific problem.
And for the next project the code will be optimized again - but maybe
in a different way.
So personally I can not honestly see your problem.
Greetings
Stefan
After reading the whole thread - it has gotten quite large, I would
like to share some thoughts, too. ;)
Personally I regard creating something like a desktop JRE for GWT to
be a suboptimal solution. From my point of view all GWT application/
projects/... already have a common base - HTML 4, CSS and JS. Every
new GWT application is based on these three components. So in a
certain way this can be seen as a - and I quote you - "desktop GWT
JRE".
Creating a common library with GWT logic that may or may not be needed
by every new application sure sounds promising when thinking about
filesizes and transfer time. After all this library would have to be
transferred only once to the client and live on inside the browser
cache for some time.
BUT the code inside this "library" would not be optimized for your
specific application. Moreover it would contain code for all possible
browsers supporting all of their "weird interpretations".
One of the strength of GWT is the compile step and the optimization of
the produced code for one specific application - one specific problem.
And for the next project the code will be optimized again - but maybe
in a different way.
So personally I can not honestly see your problem.
Greetings
Stefan
Matt Hill
Dec 17, 2010, 4:30:14 AM12/17/10
to google-we...@googlegroups.com
I don't understand the discussion of widgets here because GWT is clearly not designed to be used for multiple embedded widgets on the same page.
You can do it, but it'll require using some lesser-known features and maybe even hacks to get it to run as get the initial download for all of the gadgets as small as it would be with other libraries. As GWT clearly isn't designed for gadgets this discussion is meaningless.
StrongSteve
Dec 17, 2010, 4:48:19 AM12/17/10
to Google Web Toolkit
Very brave of you to point out that this discussion is meaningless.
Especially when your understanding of GWT is to have one widget on the
same page at a certain time.
Good luck with that. I am very eager to see one of your applications
having one label or one button or one textbox on the same page. ;)
So, and now back to the topic:
I think we all got a little bit mixed up with the wording widget -
composite - gadget. Because of that I think - or at least I hope - you
are not referring to a widget but to a more complex user-built GUI
object - an composite.
And honestly I can not see anything wrong with having different
composites on one page.
I would go even further and say that this behavior - having
independent composites within one page - should be the only way to go
for it.
Greetings
Stefan
Especially when your understanding of GWT is to have one widget on the
same page at a certain time.
Good luck with that. I am very eager to see one of your applications
having one label or one button or one textbox on the same page. ;)
So, and now back to the topic:
I think we all got a little bit mixed up with the wording widget -
composite - gadget. Because of that I think - or at least I hope - you
are not referring to a widget but to a more complex user-built GUI
object - an composite.
And honestly I can not see anything wrong with having different
composites on one page.
I would go even further and say that this behavior - having
independent composites within one page - should be the only way to go
for it.
Greetings
Stefan
bkar...@gmail.com
Dec 17, 2010, 9:58:51 AM12/17/10
to Google Web Toolkit
Stefan,
Let's lay aside the issue of a windowing toolkit just a moment and
talk about your general comment because I think that there may
actually be two separate issues worth discussing that are stemming
from this same observation/question and there's something I want to
clarify. You said:
[quote]
...the code inside this "library" would not be optimized for your
[/quote]
As I have tried to explain repeatedly throughout the thread, I don't
have a problem with GWT: What I have is a specific use case over which
I have no control, for which it seems to me that GWT would be a sub-
optimal choice as things currently stand... But I'm open to hearing
how it could work, or maybe even opening up the discussion as to
whether these kinds of use cases are worth GWT addressing in the
future. I think you are largely responding to the later - suggestions/
questions around how it might be supported. Nothing that I have said
should imply anything contrary to most of GWTs optimizations - I have
not suggested in any way that GWTs deferred binding and generation of
independent files for N browser permutations is problematic - in fact
- I quite like it and see no reason why the same wouldn't apply.
Let's look at something a little more finite: Lay aside the WT part
of the problem for a minute. I'm not making up the abstraction of a
JRE for GWT - it exists. JavaScript does not contain things like the
Number abstractions that Java does, so it's ported/adapted by the GWT
compiler. In this respect, JRE and gwtLang are, to some extent, in
every single build of every single GWT compile. IE compile variants
are generally the most pathological and also the least efficient, so
let's look at those as a case study... From my soyc reports I'm seeing
that the JRE size appears to be always _about_ 11KB... It looks to
differ from build to build by only a trivial number of _bytes_. But,
for argument sake, lets say they differed by even roughly 20-25% in
size because of optimization by the compiler... That would be
comparatively kind of huge, but it still means that between 9K and 13k
of essentially "GWT adapter" code is downloaded every time you use
something compiled by GWT.
If you run a single GWT app for some very specific purpose - you
probably say "who cares". Well, if your premise is that that cutting
out somewhere between a few bytes to 2k is an optimization - my
question is: Is it?
If you're really aiming for efficiency, there are many things to
consider: download size, number of connections required, the projected
connection speed of your users, runtime speed, interpretation speed,
runtime memory use - and not trivially, your ability to cache it for
long, long periods of time. The fastest download is the one that
never happens.
GWTs single optimal download/infinite caching is based on a coarse-
grained download for each compile - but the supporting JRE
permutations are roughly the same for an entire GWT release. Which
revs more often - every app that uses GWT - or GWT? Would it be more
optimal to pull those in as a separate download from a CDN? Not for
the first time someone used a GWT app, but from then on - yes - and
it's a benefit that would be realized across every single GWT app that
a user used and doing so would increase the resource usage timestamp
on those, thus decreasing the likelihood that your browser will evict
it from cache (i.e., fewer cache misses). Perhaps that seems like a
small win but compared to the tiny, tiny optimization difference that
is there now for this space of the problem - it's potentially huge,
and you don't even have to have my particular situation: Imagine that
you work for a company whose enterprise has adopted GWT - they might
have 10 or even 100 separate GWT apps that release updates on bi-
weekly schedules. The number of bytes "saved" is number of apps *
number of releases. In fact, if you're real lucky, some of your users
will use some other GWT-based app too and your app wouldn't even pay
the initial price.
Given the situation above - and mine - there may be additional
benefits to something similar for at least a base of what's required
for WT... At least for this class of problem.
Anyway - those are just thoughts... I think reasonable people could
disagree, but the more I look at it, the more I think I'm seeing
situations where at least some compiler switch or something for
supporting this sort of thing might be a cool/useful idea if it could
be incorporated.
Let's lay aside the issue of a windowing toolkit just a moment and
talk about your general comment because I think that there may
actually be two separate issues worth discussing that are stemming
from this same observation/question and there's something I want to
clarify. You said:
[quote]
...the code inside this "library" would not be optimized for your
specific application. Moreover it would contain code for all possible
browsers supporting all of their "weird interpretations". One of the
strength of GWT is the compile step and the optimization of the
produced code for one specific application - one specific problem. And
for the next project the code will be optimized again - but maybe in a
different way... So personally I can not honestly see your problem."
browsers supporting all of their "weird interpretations". One of the
strength of GWT is the compile step and the optimization of the
produced code for one specific application - one specific problem. And
for the next project the code will be optimized again - but maybe in a
[/quote]
As I have tried to explain repeatedly throughout the thread, I don't
have a problem with GWT: What I have is a specific use case over which
I have no control, for which it seems to me that GWT would be a sub-
optimal choice as things currently stand... But I'm open to hearing
how it could work, or maybe even opening up the discussion as to
whether these kinds of use cases are worth GWT addressing in the
future. I think you are largely responding to the later - suggestions/
questions around how it might be supported. Nothing that I have said
should imply anything contrary to most of GWTs optimizations - I have
not suggested in any way that GWTs deferred binding and generation of
independent files for N browser permutations is problematic - in fact
- I quite like it and see no reason why the same wouldn't apply.
Let's look at something a little more finite: Lay aside the WT part
of the problem for a minute. I'm not making up the abstraction of a
JRE for GWT - it exists. JavaScript does not contain things like the
Number abstractions that Java does, so it's ported/adapted by the GWT
compiler. In this respect, JRE and gwtLang are, to some extent, in
every single build of every single GWT compile. IE compile variants
are generally the most pathological and also the least efficient, so
let's look at those as a case study... From my soyc reports I'm seeing
that the JRE size appears to be always _about_ 11KB... It looks to
differ from build to build by only a trivial number of _bytes_. But,
for argument sake, lets say they differed by even roughly 20-25% in
size because of optimization by the compiler... That would be
comparatively kind of huge, but it still means that between 9K and 13k
of essentially "GWT adapter" code is downloaded every time you use
something compiled by GWT.
If you run a single GWT app for some very specific purpose - you
probably say "who cares". Well, if your premise is that that cutting
out somewhere between a few bytes to 2k is an optimization - my
question is: Is it?
If you're really aiming for efficiency, there are many things to
consider: download size, number of connections required, the projected
connection speed of your users, runtime speed, interpretation speed,
runtime memory use - and not trivially, your ability to cache it for
long, long periods of time. The fastest download is the one that
never happens.
GWTs single optimal download/infinite caching is based on a coarse-
grained download for each compile - but the supporting JRE
permutations are roughly the same for an entire GWT release. Which
revs more often - every app that uses GWT - or GWT? Would it be more
optimal to pull those in as a separate download from a CDN? Not for
the first time someone used a GWT app, but from then on - yes - and
it's a benefit that would be realized across every single GWT app that
a user used and doing so would increase the resource usage timestamp
on those, thus decreasing the likelihood that your browser will evict
it from cache (i.e., fewer cache misses). Perhaps that seems like a
small win but compared to the tiny, tiny optimization difference that
is there now for this space of the problem - it's potentially huge,
and you don't even have to have my particular situation: Imagine that
you work for a company whose enterprise has adopted GWT - they might
have 10 or even 100 separate GWT apps that release updates on bi-
weekly schedules. The number of bytes "saved" is number of apps *
number of releases. In fact, if you're real lucky, some of your users
will use some other GWT-based app too and your app wouldn't even pay
the initial price.
Given the situation above - and mine - there may be additional
benefits to something similar for at least a base of what's required
for WT... At least for this class of problem.
Anyway - those are just thoughts... I think reasonable people could
disagree, but the more I look at it, the more I think I'm seeing
situations where at least some compiler switch or something for
supporting this sort of thing might be a cool/useful idea if it could
be incorporated.
David Chandler
Dec 17, 2010, 10:44:02 AM12/17/10
to google-we...@googlegroups.com
Brian,
You raise valid points. As I mentioned early in the thread, GWT's
sweet spot is rich Internet applications IMHO. In a typical GWT app,
the amount of user code dwarfs the JRE. In a relatively small app I've
built, the JRE is 43kB and allOther is 169kB. If there were an 11kB
core JRE on a CDN somewhere, it just wouldn't help that much.
The use case you've given (many, many widgets that cannot be compiled
together) is definitely not in GWT's sweet spot. If your analysis
shows that it would be better to use another approach, by all means
run with it!
For those of you who haven't muted this thread yet in Gmail, here's a
size reduction tidbit that's not written up anywhere else yet AFAIK.
When you do your final production compile, you can set a property in
your .gwt.xml to remove client-side stack trace info, which may save
up to 15% in code size:
<set-property name="compiler.stackMode" value="strip"/>
Happy shrinking!
/dmc
> --
> 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.
>
>
--
David Chandler
Developer Programs Engineer, Google Web Toolkit
http://googlewebtoolkit.blogspot.com/
Twitter: @googledevtools
Reply all
Reply to author
Forward
0 new messages