Thanks for your input, but this decision should be made by people who actually contribute code.
-J On Wed, Jun 12, 2013 at 12:08 PM, Pratik Paranjape <pratikparanj...@gmail.com> wrote: > Two points John, someone has to speak for GWT :) > GWT has its demerits (compilation time, monolithic output), but the 2 > mentioned above are not among them. > > 1) GWT produces large output because that is the kind of projects it is > used for. No one uses GWT for average size website or general dom > manipulation. But, if you use GWT and Javascript for the same > _heavy-weight_ project, in general GWT trumps in performance and size. > There are experiments online to prove that. > a) > http://www.youtube.com/watch?feature=player_embedded&v=sl5em1UPuoI#t=1543s(gwtquery > vs others selector engine benchmarks, 2009, but still makes a > point. very funny too) > b) Open two pages: > http://www.smartclient.com/smartgwt/showcase/#main (GWT demos) > http://smartclient.com/#Welcome (JS demos) > Check memory and CPU usage in chrome's task manager. > > In fact, GWT makes micro-optimizations and obfuscation which practically, > manually can't be done > > 2) Except for Webworkers, everything in HTML5 can be used in GWT. I am > using it, I am sure others are using them too. Even webworkers are usable, > but its not as straightforward. > > > > > On Thu, Jun 13, 2013 at 12:04 AM, John Blossom <jblos...@gmail.com> wrote: > >> To all, >> >> I have been reading this thread carefully, and I am very appreciative of >> the strong contributions from the community. This could go a number of >> ways, obviously, but perhaps I can provide some focus, especially in light >> of some specific projects that I am trying to get funded that could benefit >> from Wave technologies: >> >> - Light and fast is best - highly portable, even better. One of the heavy >> downsides to GWT from my perspective is that it seemed to result in big, >> resource-hungry apps and runtime environments. If we are to have Wave >> succeed in a mobile-dominated Web world - almost two-thirds of Web users >> are now mobile-first users - efficiency is key. To that point, more recent >> client-side technologies that center around JS and its variants in an HTML5 >> environment would seem to provide a powerful intersection of runtime >> performance, the most advanced mobile Web integration tools and wide >> developer awareness and support. It's not a matter of trendiness, it's a >> matter of going where performance meets available talents. >> >> - There seems to be a fairly broad consensus that splitting client/server >> functions is the best thing to do. The sooner the better, so that a >> well-defined API and toolkit can enable a wide array of apps to be >> developed. Conceivably one variant might be GWT adapted to the API, to >> satisfy those people still having project commitments to it. Server-side >> you can argue any number of ways, but the light and fast paradigm should >> apply there also as much as complex data management issues warrant. The >> Wave data model is the core of its potential success, so anything that >> serves the data model efficiently is good. >> >> - It's true that we should leave the door open for people to code client >> apps in whatever environment works for them, though in saying that we need >> to accept that our "benchmark" demo app may have a superset of features >> that some apps may not support. Where we draw the line in calling those >> apps "Wavey" may become an issue at some point. I think that having a >> benchmark app is very important, because it can show people how to manage >> more advanced potential Wave capabilities, such as editing and data >> management in an offline mode for clients (in essence a small-server >> model), peer-to-peer Wave-based communications and the use of Wave as an >> email app/embedded app platform for Wave data. >> >> I want developers to form their own consensus on the "how" issues, but my >> view is that there are a broad array of Wave components that would benefit >> from a "clean sheet" approach, using some of the best lessons learned from >> implementations such as Rizzoma and aiming towards the objectives that I >> laid out in my earlier slide deck. As Christian pointed out earlier, such >> an approach doesn't mean that we should necessarily abandon 0.4 work or >> feel that Apache would not welcome a new candidate based on new code. >> Lessons can be learned from 0.4 for those needing to understand what should >> and should not be done in the future. But overall, the focus should move >> aggressively towards developing a code base that is modern, >> high-performance, readily adapted for networked and offline mobile use and >> easy to use for developing a wide array of powerful UIs and >> applets/gadgets. I think that we have the core of a community that can help >> us to move in that direction. I will weigh in on the "how" from time to >> time, but overall I am most interested in the "x" - it's your solution. >> >> >> All the best, >> >> John Blossom >> >> email: jblos...@gmail.com >> phone: 203.293.8511 >> google+: https://google.com/+JohnBlossom >> >> >> On Wed, Jun 12, 2013 at 2:05 PM, Bruno Gonzalez (aka stenyak) < >> sten...@gmail.com> wrote: >> >> > On Wed, Jun 12, 2013 at 7:45 PM, Joseph Gentle <jose...@gmail.com> >> wrote: >> > >> > > Really? With the exception of google, I don't know of anyone who still >> > > uses GWT. The web is mostly moving to plain javascript. Amongst other >> > > things, a javascript web client would let us take the slow GWT >> > > compiles out of the edit-run loop. It would also run faster & be >> > > easier to optimize, it would let us use all the great frontend JS >> > > libraries that are around now and be more attractive to other >> > > developers. Oh, and it would dramatically reduce the client side JS >> > > download. >> > > >> > > This is just a data point, but the main project I'm working on at work >> > uses GWT, and other than the sometimes tedious compilation time, I was >> > under the impression that GWT was the only sane way to develop a complex >> > software (read: as dynamic and complex as a traditional desktop client) >> > that has to run on a variety of browsers. Note that I'm not a web dev, so >> > this impression could be wrong. >> > >> > -- >> > Saludos, >> > Bruno González >> > >> > _______________________________________________ >> > Jabber: stenyak AT gmail.com >> > http://www.stenyak.com >> > >>
