SC meeting Wednesday morning (Oct 23), 9am PST
Bhaskar Janakiraman
Colin Alworth
Oct 23 steering call notes
Bhaskar, Colin, Daniel, Artur, Joonas, Ray, Stephen
In the future, we’ll meet more regularly, schedule a recurring call, then cancel if nothing needs to be discussed. Expected time will be 9am pacific time, second Wednesday of each month.
Red Hat may put forward a name as a possible nominee for steering committee
Document from Vaadin wrt deprecation
Preliminary results from survey:
45% of users need ie8 in 2014
36%, 44% of users need java 6 (server env, development env)
Initial Conclusions:
dropping ie8/9 provide technical benefits (more than just dropping 8), but would affect many users
dropping java6/7 provides technical benefits (more than just dropping 6), but would affect many users
Discussion, paraphrased:
Daniel: go ahead and make the cut, make them use gwt 2
Joonas: what about making gwt 3 do both?
Ray: better modularization might give us that, if we break out gwt2 widgets from gwt-user, new web component system in its own new jar
Stephen: massive manpower requirement, the potential upset could be limited by keeping gwt 2 around, need a watershed event to make gwt 'fun'
Bhaskar: how many users will jump forward to use gwt 3 and drop 2?
Raniel/Ray: gwt3 needs to be new and cool, more like modern js dev experience, access to browser features
Ray: swing vs awt vs swt, same with gwt2 vs gwt3; modular compilation and such will still benefit users using gwt2 widget
Daniel: switching to feature-based properties will mean more permutations, none of which can include old browsers
Ray: 'modern browser' profile vs 'compatibility' profile, no polyfills for scoped stylesheets, webgl, typed arrays,
Bhaskar: fundamental question is 'what does gwt 3.0 look like', not only from browser perspective, but language perspective
Daniel: at least on the server, java6 has to be around for at least the next year or two, but on the client side, java8 makes the development process cleaner
Ray: on the client side, we run our own compiler with our own jdt - a java6 sdk could compile java8 code through that jdt. The real issue is shared code (and maybe dev env? IDE?)
Artur: can we catch issues of using java8 libs in java6 code?
Ray: java.util.functions and .streams would need to be cut out of the classpath when compiling for pre-8
Matt: IDE should already behave here
Ray: even inside google, its going to be at least a year before java8 is supported across the board. gwt 3.0 should introduce non-backward compatible features that are supporting the future, but not-not run on things we need to run on today
Bhaskar: whats our guiding principle for 3.0 - if you have an existing app, will it work?
Ray: old event listeners are a problem - if we have two methods with the same name that both take a single-event interface, we have a problem. for gwt3 we should remove event listeners
Joonas: breaking applications turns out not to be a big deal from our experience, provided we're making it better, and stay stable for a significant period of time after that
Ray: what if new features that were added just didn't get ie8 support by default - makes for a cleaner codebase, but you need to willingly give up older browsers
Daniel: hard to pull off, since we don't want to have the entire gwt event system
Ray: that goes to my point about 'swing vs awt', the new model will have certain guarantees about performance, limitations about browsers
Bhaskar: timecheck - lets go and consider what our guiding principle of gwt 3.0 should be
Daniel/Ray/Stephen: testing old browsers is time consuming, have to decide if we're going to just allow stuff to rot in place
Colin/Joonas/Bhaskar: what does it look like for enterprise users
Ray: how about a fireside chat at gwt.create to discuss what kinds of constraints people are under
Daniel: maybe they should stay under gwt 2
Ray/Bhaskar: then the compiler changes need to be put in 2 or backported to 2 after the fact
Bhaskar: lets try to break things in 3, then not for a while
Joonas: if that is to be the case, then the release model should change then to not be tick/tock
Ray: lets see what the 3.0 doc looks like try to document what will be lost in 3.0
Ray: have to be careful that we don't break too much, might end up alienating users to other projects
Bhaskar/Ray: need to take a vote on ie8 being dropped/supported, need to decide what it means to 'drop'/'support' ie8, ray will do a brief doc on this
Joonas: then vaadin and sencha can try to bring their own perspectives back, along with other edits from other steering committee members
Colin/Stephen: more design docs from inside of google
Ray: good idea, will also serve as advertising for upcoming new features
Meeting concluded that more discussion is required after we’ve seen the document that Ray is working on, looking at what the options are for balancing future features and existing browsers.
Next call is planned for Wednesday, November 13.