Re: To GWT or Not to GWT
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: Happy shrinking! /dmc On Fri, Dec 17, 2010 at 9:58 AM, bkard...@gmail.com wrote: > 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 > 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." > [/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
Re: To GWT or Not to GWT
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 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." [/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. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" gro
Re: To GWT or Not to GWT
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 On Dec 17, 10:30 am, Matt Hill wrote: > 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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 On Dec 16, 3:31 pm, "bkard...@gmail.com" wrote: > 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 > wrote: > > > > 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". > > > On Thu, Dec 16, 2010 at 7:34 AM, yves wrote: > > > 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 > > > > On 15 déc, 21:40, zixzigma wrote: > > > > 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 pro
Re: To GWT or Not to GWT
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 -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. On Dec 16, 12:44 pm, Ian Bambury wrote: > 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 -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
Sure in that regard you'll have some duplication, not any way around that that I can see. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 :) -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 wrote: > > 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". > > > > > > On Thu, Dec 16, 2010 at 7:34 AM, yves wrote: > > 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 > > > On 15 déc, 21:40, zixzigma wrote: > > > 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 > > > maintai
Re: To GWT or Not to GWT
> > 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". On Thu, Dec 16, 2010 at 7:34 AM, yves wrote: > 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 > > > > On 15 déc, 21:40, zixzigma wrote: > > 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 > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- Christian Goudreau www.arcbees.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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 On 15 déc, 21:40, zixzigma wrote: > 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 -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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/ 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, bkard...@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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
I'm not really sure how to respond to that other than to say, "yes, we understand the alternatives and the theory/practice" :) Thanks. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 wrote: > 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 > > > On Wed, Dec 15, 2010 at 3:08 PM, David Chandler > wrote: >> >> 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. >> >> 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 >> >> On Wed, Dec 15, 2010 at 2:31 PM, bkard...@gmail.com >> wrote: >> > 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? >> > >> > -- >> > 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-web-tool...@googlegroups.com. >> > To unsubscribe from this group, send email to >> > google-web-toolkit+unsubscr...@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-web-tool...@googlegroups.com. >> To unsubscribe from this group, send email to >> google-web-toolkit+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- David Chandler Developer Progr
Re: To GWT or Not to GWT
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 On Wed, Dec 15, 2010 at 3:17 PM, Myles Bostwick 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. > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 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 wrote: > > > On Dec 15, 11:07 am, clintjhill 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-web-tool...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com > cr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. > > -- > Christian Goudreauwww.arcbees.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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 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 wrote: > > > On Dec 15, 11:07 am, clintjhill 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-web-tool...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com > cr...@googlegroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-web-toolkit?hl=en. > > -- > Christian Goudreauwww.arcbees.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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
> > 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 wrote: > > > On Dec 15, 11:07 am, clintjhill 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- Christian Goudreau www.arcbees.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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
On Dec 15, 11:07 am, clintjhill 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 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. > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
> > 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, On Wed, Dec 15, 2010 at 3:18 PM, Brian Kardell wrote: > 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 > > > > On Wed, Dec 15, 2010 at 3:08 PM, David Chandler wrote: > >> 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. >> >> 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 >> >> On Wed, Dec 15, 2010 at 2:31 PM, bkard...@gmail.com >> wrote: >> > 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? >> > >> > -- >> > 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-web-tool...@googlegroups.com. >> > To unsubscribe from this group, send email to >> google-web-toolkit+unsubscr...@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-web-tool...@googlegroups.com. >> To unsubscribe from this group, send email to >> google-web-toolkit+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > googl
Re: To GWT or Not to GWT
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 On Wed, Dec 15, 2010 at 3:08 PM, David Chandler wrote: > 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. > > 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 > > On Wed, Dec 15, 2010 at 2:31 PM, bkard...@gmail.com > wrote: > > 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? > > > > -- > > 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-web-toolkit@googlegroups.com > . > > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. 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 On Wed, Dec 15, 2010 at 2:31 PM, bkard...@gmail.com wrote: > 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? > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
> > 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 On Wed, Dec 15, 2010 at 2:46 PM, bkard...@gmail.com wrote: > 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 received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- Christian Goudreau www.arcbees.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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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 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 > > HTH, > /dmc > > > > > > > > > > On Wed, Dec 15, 2010 at 12:14 PM, clintjhill wrote: > > 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"? > > > On Dec 15, 10:05 am, "bkard...@gmail.com" wrote: > >> 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? > > > -- > > 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-web-tool...@googlegroups.com. > > To unsubscribe from this group, send email to > > google-web-toolkit+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/google-web-toolkit?hl=en. > > -- > David Chandler > Developer Programs Engineer, Google Web > Toolkithttp://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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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" with http://code.google.com/webtoolkit/doc/latest/DevGuideCodeSplitting.html HTH, /dmc On Wed, Dec 15, 2010 at 12:14 PM, clintjhill wrote: > 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"? > > On Dec 15, 10:05 am, "bkard...@gmail.com" wrote: >> 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? > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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, On Wed, Dec 15, 2010 at 12:14 PM, clintjhill wrote: > 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"? > > On Dec 15, 10:05 am, "bkard...@gmail.com" wrote: > > 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? > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- Christian Goudreau www.arcbees.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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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"? On Dec 15, 10:05 am, "bkard...@gmail.com" wrote: > 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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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, bkard...@gmail.com wrote: > 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? > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. On Wed, Dec 15, 2010 at 12:05 PM, bkard...@gmail.com wrote: > 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? > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@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 -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
OK, fair enough. I just wasn't sure if you had the Gadget problem space specifically in mind. On Wed, Dec 15, 2010 at 10:10 AM, bkard...@gmail.com wrote: > 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? > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@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 -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: To GWT or Not to GWT
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. On Tue, Dec 14, 2010 at 4:57 PM, bkard...@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? > > -- > 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-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@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 -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
To GWT or Not to GWT
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? -- 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-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
