PP, Thanks, all very good points. I don't want to try to split the hair too finely, but since compile time and object sizes are key factors in perceived performance, perhaps there's some overlap there.
To your point, if we do have a GWT environment for an app, then it could be used to develop clients that can be used when its traits are most optimal, but for other types of use and data, other clients can be potentially lighter, faster and receive more wide adoption more rapidly, perhaps, whilst the APIs allow access to the same underlying data sets. So as I suggested, I am not sure that we have a clear-cut baby-versus-bathwater situation. However, I'd like to see the default demo client default to the highest performance options for mobile platforms. My guess is that this will not be a GWT-based client, but let's see what you folks come up with. It's true that many/most of the available options will work in HTML5, the question is which ones will take advantage of the most advanced features of HTML5 in a way that will ensure access to the best performance and the most inputs from sources such as mobile sensors using the most advanced libraries and runtime environments. Like an army getting ready for battle, we need to me mindful of what the war is that we're fighting today, not the best way to fight yesterday's wars. This is especially important in terms of Google's initiatives towards so-called "Packaged Apps" for Chrome browsers, for example, and similar efforts by Mozilla for Firefox. About a year from now this sort of apps methodology is likely to start having some real impact on how people develop, package and use apps on both mobile and desktop/laptop platforms. So think about that one to three year horizon, in which Wave marketing will be unfolding more robustly. How can we make the best technology decisions now to meet the market where it's moving? Many thanks, John On Wed, Jun 12, 2013 at 3: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 > > > > > >
