A couple of weeks ago, I posted the roadmap for Vaadin. Only the timeline was laid out – not the what we are actually doing. After a lot of planning, we have come up with a list of things we want to have – and believe we could fit – in Vaadin 7. The list is sorted by the preferred implementation order – not in the order of importance. We want to start from the things that need the most feedback from you. This should give us more time to sort out any design problems the community points out before the release.
While the list of what we'll do is a long one, it can be simply summarized to the three major things we want to achieve in Vaadin 7:
- Give more power and freedom to developers.
- Make extending and plugging Vaadin simpler.
- Clean up where it smells.
1. Empower Developers
Vaadin has an exceptional model of providing three layers of abstraction for the web user interface development:
- Server-side user interface development with any JVM compatible language,
- Java-based client-side development model provided by GWT, and
- full power of HTML5 by developing in JavaScript.
Sometimes you want to go through the abstractions to get more control on the finer details. This is supported in Vaadin 6, but often could be easier. Sometimes it feels like we would be trying to argue "you do not want to do it, it is the wrong way to do it, it should not be too easy – just to keep you safe". We should not.
With Vaadin 7, we try to remove abstractions where they really do not add value, and try to better support you when you want to go through the abstractions, but are also careful not to loose any of the "wow this is easy" magic we have built into Vaadin 6.
Some of the things we'll do:
- Split the "browser window" API into a lower- and a higher-level API that
- Give full control over how windows are managed,
- Give easy access to HttpServletRequest and PortlerRequest, and
- Provide a much simpler built-in API for view management.
- Move layout calculations back to the browser in order to
- Improve rendering performance (a lot), and
- Allow full control of the look and feel in CSS themes, including borders, margins and paddings.
- Use theme selectors on a per-component basis to allow you to easily override themes for any given component – or possibly even mix themes.
- Let you inject pieces of CSS on the server side for simple dynamic changes to components.
- Allow declaring Javascript callbacks on the server side to let you more easily integrate Vaadin to other JavaScript components on the web-page.
- Ease the embedding of Vaadin in JSPs with a special tag lib that makes it trivial to start adding small Vaadin-based parts to existing JSP and JSF applications.
- Give you centralized control of CSS and JS loading to ease the use of existing JavaScript libraries.
- Provide a built-in API for on-the-fly translations of all texts and resources in UI components.
2. Embrace Extendability
Probably the best decisions we have done in Vaadin 6 was to make creating, packaging and distributing add-ons really easy. Because of this and especially thanks to you, there are now 213 add-on components for Vaadin in the directory. We were so exited about this that we even started to release additions to the core framework as add-ons in the directory before integrating them in the framework.
We want to take this even further. We want to open up more and clearer extension points, and make it even simpler for you to build and distribute components and features on top of the Vaadin framework.
Some of the planned things:
- Create two new communication APIs for connecting the client- and server-side of your UI components:
- A clean remote procedure call (RPC) API,
- a shared-state API to let the framework handle state sharing for you, and
- possibly clean up the current "variable"-based communications.
- Alleviate language limitations for multiple inheritance: We'll add a plugin API for easily adding features to the Application servlet without extending it.
- Add a new plugin type will to make it easy to develop add-ons that are not widgets but still need to plug into a client-side widget set.
- Provide a generic component to port and package JavaScript widgets to Vaadin without requiring GWT compilation.
- Provide a generic decorator interface to plug new features into any user interface and distribute these features as add-ons. Think of client-side validations and floating info bubbles.
- Make creation of component containers easier by removing unnecessary features from the interface.
- Add a mechanism to package CSS and images with server-side add-ons to ease creation of server-side composition-based add-on components.
- Create a plug-in API for server-push add-ons, plus a push add-on that provides support for web sockets.
3. Clean Up
During the previous 10 years when we have been building this framework, we have left some garbage lying around and some rooms in the house are in need of some new paint. Parts of the API still are over-generic and confusing, because in 2002 we wanted to support other terminals in addition to web. The web won and now there is no need to overgeneralize any more.
With Vaadin 7, we are going to clean up the parts of the API we are not proud of anymore.
Some of the renovations planned:
- Re-design forms to make it a lot simpler to build more powerful forms.
- Clearly separate "sub-windows" by renaming the "browser-level window" to "Root"
- Remove unnecessary abstractions built around the Application class to simplify learning and give more control.
- Replace integer constants with enums, remove the unnecessary
Container.Orderedinterface and remove already deprecated APIs. - On the client side, review the APIs to better support decoupling of widgets from the server-side communications. This would make it possible to
- do client-side compositions out of Vaadin widgets,
- use GWT Designer to design client-side compositions, and
- easily move parts of the UI logic to the client side.
- Improve session management:
- Never see those red error messages again.
- Keep sessions open while the browser is open by default.
- Default to one server-side "Root" per one page to make applications more "web-like"
- Provide seamless support for running more than one Vaadin application per web page.
- Add built-in support for HTML sanitation to make it easier to build secure applications.
- Provide better support for accessibility standards – more specifically, WAI-ARIA.
Compatibility
We have been very happy how Vaadin 6 has turned out and how we've been able to iteratively add features and build on it while keeping it backwards compatible. In fact, for the most parts, Vaadin 6 is backwards compatible back to (Millstone) version 3 – released way back in the end of the year 2002.
Major releases are not guaranteed to maintain backwards compatibility. With Vaadin 7, we would like to take the opportunity of cleaning up and making the release better for everyone – even if this would mean less backwards compatibility. The guidelines for us are the questions:
- How much work it would be take to port your application from Vaadin 6 to Vaadin 7?
- Can we write clear guidelines for upgrading?
We want to keep the pain of moving from 6 to 7 minimal but at the same time be able to make Vaadin cleaner, simpler and better. For some features we will provide cleanly separated backwards compatibility support APIs – possibly as add-ons – to ease the transition.
One major change is that we will be dropping support for Internet Explorer versions 6 and 7. Without these ancient and somewhat broken browsers, we are able to make the code much cleaner and move layout calculations back to the browser. If you really have to support these browsers, you have two options:
- Use Vaadin 6 (it will be supported until the year 2014), or
- Get your users to install the Chrome Frame plugin.
Details
A detailed list of all changes is available at the Vaadin 7 wiki. Furthermore, our design process is open and design documents will be maintained there while we are planning and experimenting.
Please give us comments on the forum:
- What do you think of the plan as a whole?
- Have we omitted something crucial?
- Is our design flawed?
And please test the results as soon as we get the first alpha release out – by the end of the year.