I agree, Joseph, just trying to give you a target to shoot at. I am here to help you gain a market, and hopefully your decisions are market-worthy.
All the best, John Blossom email: jblos...@gmail.com phone: 203.293.8511 google+: https://google.com/+JohnBlossom On Wed, Jun 12, 2013 at 4:08 PM, Joseph Gentle <jose...@gmail.com> wrote: > 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 > >> > > >> >
