Thanks for writing a very balanced and clear-headed response. > code is, how much easier would it be for you to have done it in > JQuery?
Well, I'm about to find out empirically. I'm not sure -- it might end up being a draw for my particular application -- but it will at least be a learning experience. I'll try to remember to keep track of my impressions and post them for others to benefit. Adam On Nov 23, 10:57 am, Adam T <[EMAIL PROTECTED]> wrote: > I wouldn't say "contradiction", I believe all aspects mentioned > (inertia/retooling/SEO/experience/through life cost/future development > cost/others) all combine to inform the decision of what technology to > eventually use. In certain circumstances some aspects will weigh > higher than others. > > Your example is a good case in point - did GWT naturally fit your > design? How easy was it to do, how managed do you feel the resulting > code is, how much easier would it be for you to have done it in > JQuery? How much do you think your design was influenced by thinking > of a GWT application as a multi-page app as opposed to a single page > one? How much more complex is your application to some of those > examples shown using JQuery? > > There are many questions that feed into stuff, which makes it hard to > say why one is better than another. Though, if I'm going to build a > complex application from scratch, then I would evaluate other > technologies on a basis of why would I use it instead of GWT as I > think GWT should be the starting point that others need to reach. > > Right now I would say the world is JavaScript focussed and there are > many JavaScript coders out there, and hence the natural choice is > JavaScript libraries. As we push the boundaries on complexity, so we > need better and better tools/environments etc, and I believe GWT is > well placed for when complexity catches up. > > Just for interest, there is a JQuery library for > GWT:http://code.google.com/p/gwtquery/ > > //Adam > > On 23 Nov, 16:16, adam <[EMAIL PROTECTED]> wrote: > > > Adam T, > > > Thank you for your thorough and thoughtful explanation. There appears > > to be a contradiction running through the thread of your explanation > > and I'm wondering if you or anyone else would like to comment on it. > > You write: > > > > version. Sure, you can do a similar thing with GWT but not in such an > > > elegant manner - but the point of GWT is to build applications not web > > > sites. > > > This seems to imply that the awkwardness of using GWT with > > "traditional" web sites -- ones whose separate pages are requested > > from a server -- may be a good reason to choose non-GWT tools for > > them. This would mean that the creators of the sites listed on the > > jQuery site are not refraining from using GWT on account of inertia or > > the cost/benefit ratio of training and retooling, as you suggest > > elsewhere in your reply. Rather they would be using the result of a > > decision-making process that, given the necessity of SEO as a premise, > > concludes it's necessary to create a web site rather than a web > > application and chooses a non-GWT javascript solution on account of > > its relative elegance. > > > I've actually created web sites (again, separate html pages generated > > on server) using GWT. My strategy has been to include a javascript > > variable in a script block on each page, the string value of which > > corresponds to an Enum defined in GWT-generated code. As a given page > > loads, that variable is read by a JSNI call in my EntryPoint and, in a > > long switch based on the value of the Enum, a PageView subclass is > > instantiated. The PageView -- which is coded in GWT, of course -- in > > turn widgetizes parts of the html or generates widgets to insert into > > html placeholders. It also instantiates a PageController subclass, > > again coded in GWT. The way I see it, I am a creating a web app, > > albeit one whose execution environment (i.e. html content) is > > constructed differently by my server-side JSP code on each page load. > > It's been a few years since I've created a hand-coded Javascript app, > > but I think I'm going to give it a shot. Although this doesn't really > > amount to a study, I would be very happy to thoughtfully analyze the > > results and post them here. > > > Thanks again for your very complete response, > > Adam > > > On Nov 23, 3:37 am, Adam T <[EMAIL PROTECTED]> wrote: > > > > First a couple of rhetorical questions to you: > > > > a) why do you think JQuery and GWT are equivalent? > > > b) why do you think the sites of the JQuery list are probably led by > > > some smart, deep-thinking, open-minded individuals (IBM's web site > > > might not necessarily be built by IBM....)? > > > c) why do you think the GWT list you pointed to is definitive? (try > > > this as at least one update:http://www.gwtsite.com/whos-using-gwt/) > > > > You use the tools appropriate to the job and for which is the "least" > > > cost to you. > > > > To me, JQuery is a "simple" library best suited to evolving aspects to > > > a web site using the JavaScript language; GWT is more suited to > > > building applications and is more than just using Java - you get, > > > amongst other things: > > > > a) One base code that drives code for all browsers with the well > > > managed approach called deferred binding when you hit across a > > > situation where one browser (we know the now) does things differently > > > - driving down you costs of development. > > > > b) The same code for browsers can quickly become widgets and gadgets, > > > using different linkers - again driving down cost of development. > > > > c) You use modern development practices and tools - IDE with > > > autocomplete, refactoring, JUnit, Maven, Ant etc - there's a real > > > reason why we've enhanced software development over the years to > > > invent and use these tools; they will drive down costs for > > > (complicated) developments. > > > > d) You get generators that allow you to combine / generate new stuff > > > from source stuff - ok that's vague, but this is a real example of > > > where GWT is more than just a Java to JavaScript compiler. You get > > > ImageBundles, meaning in source you manage your images separately and > > > you let GWT pull those together into one image at compile time that > > > can be accessed as "sprites" in run-time - you save wire-space, cut > > > down on server requests meaning increased user experience, and there > > > are more like this is on the way. Yes you can do all this by hand, > > > but that all costs time and money, with GWT it comes for free when > > > hitting the compile button. > > > > e) Same language client and sever side, but with flexibility to use > > > whatever server side you want. > > > > f) Aggressive reduction in code size from libraries, both your own and/ > > > or 3rd party libraries - all decreasing load size and increasing user > > > experience > > > > g) Ability (soon) seemlessly defer loading of functionality until it's > > > needed - i.e. if you have a 4 tab application load only the code for > > > tabs as they are needed - again decreasing initial application load > > > and increasing user experience > > > > h) I would argue in Java it is easier to see how to "defer" creation > > > of objects in order to decrease initialisation time of applications - > > > maybe that is just me, but the ability to use IDE and refactoring to > > > support this greatly helps. > > > > Look at the sites on your JQuery list, and most are really web sites/ > > > pages that are using JQuery to add some fancy effects or some > > > manipulation of DOM - it doesn't identify, for example, how much of > > > the site uses JQuery - whereas your GWT list is pure GWT applications > > > on mostly the whole site; the lists are not really comparable in terms > > > of functionality; I do though, get your point on why aren't IBM, Dell, > > > BBC using GWT - the answer I suggest is three-fold > > > > a) These are (mostly) web sites not web applications and have lots of > > > legacy content. They are going to possibly struggle to justify the > > > benefit of GWT in comparison to cost already sunk, and a large number > > > of them don't need to - why move to mechanised looms if your > > > comfortable with your current cloth being produced? > > > > b) Look at the basic purpose of most of those sites, especially the > > > featured ones; they are effectively brand advertising, and as such > > > need to be indexed by search engines otherwise their return on > > > investment is zero. JQuery is good at keeping that, as you generally > > > load HTML which is then manipulated by JavaScript - this way, the > > > search engine can index the HTML and the user sees a slightly flashier > > > version. Sure, you can do a similar thing with GWT but not in such an > > > elegant manner - but the point of GWT is to build applications not web > > > sites. > > > > c) The teams behind it would probably need investement in retooling > > > and training to use GWT and certainly given the first point above, > > > this cost could outweigh any benefit. > > > > If you're building a new web application, then GWT is certainly a top > > > candidate that should be investigated, why would you not want > > > something that is promising to cut down your overall through life > > > costs (apart from the cost of retooling your team)? I would also > > > argue that with GWT you can build more complicated web applications > > > simpler than you could with JQuery. For example, look at Chronoscope > > > (http://timepedia.org/chronoscope/) and it's associated blog to see > > > how it was developed and available in many many different forms from > > > single GWT base. > > > > What would be fascinating to see is the results of an actual study on > > > the comaprison of the development of a web application using several > > > of the competing and complimentary libraries/toolkits/frameworks. > > > > So back to the first point, use the tool that is most appropriate for > > > what has to be done, within the constraints you may have and the > > > expectations users/client has. > > > > //Adam > > > > On 23 Nov, 07:42, adam <[EMAIL PROTECTED]> wrote: > > > > > I'm not sure which people you're talking about, but I can't believe > > > > that the people who head large projects like the ones mentioned in the > > > > jQuery link don't update their knowledge of available tools and their > > > > development status on a regular basis. I think the answer must lie > > > > elsewhere. > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
