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 >
