I think the point of decoupling the server from the client is the most important one here as Yuri points out. After that, there doesn't need to be an argument on which technology to build the client in. The community will decided for itself by building whatever clients they like.
~Michael On 6/12/13 8: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 >> > >>
