> --
> 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
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
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/
--
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.
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.
>
>
--
Are you saying that you would recompile and redeploy the whole app every time this happens?
--
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.
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
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.
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.
--
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.
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
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:
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?
>
>
But would it be possible in the future to allow building GWT-app by reusing previously built "GWT-dlls"
--
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.
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