Vaadin Roadmap: Seeking planning advice

Vaadin and community,

I’ve been using Vaadin now for 5 years or so. Vaadin 7.0. SQL table query. Ivy. setImmediate(true), whatever that is. All the latest stuff. My one and only Vaadin project is my “Hello World” project. No previous coding experience. 50 UIs, 150K lines, hundreds of class files. I’ve followed the train now up to Vaadin 8.7.2, Java 12, Eclipse 2019-03 etc. My project is in commercial operation, dispatching aircraft all over Southern Ontario in Canada. Overall, Vaadin has been great - it has enabled an idea based on business logic to become a working multi-user enterprise system.

But there has been pain. Table query is no longer the state of the art apparently. Maven is the golden haired boy, Ivy terrible now. Yup, I’ve endured all the transitions, one by one, to DataProviders, parameterized grids… The conversion to V8 consumed ~3 months.

So now I stand at the the edge of the grand canyon, with Vaadin 13 on the other side. Deep breath, wondering which year of my life I’d most like to sacrifice. 2020? 2021? One of them has to go. I’m not complaining - progress is progress and this is life in a fast-changing software business.

But I would be greatly aided by visibility of a roadmap that minimizes the disruptions going forward. For example:

  1. If I select Maven, with whispering Gradle voices in the background, will I again be using the “old” build/dependency system in a few months? What do the crystal balls in Finland say? Will Maven or Gradle or something else be the favourite 5 years from now?

  2. Components. GWT was the big thing only a few years ago: “We’re on the committee with Google”. Let’s celebrate. Now it’s old news, nearly dead. Polymer, next favourite child, is showing signs of discontinuation, yet is the basis of the new Vaadin. LitElement, apparently is next? If I were to hop onto the V13 train now, should I expect a discontinuity in components some time soon? Should I wait for this to stabilize to avoid a foreseeable component transition? There is a limit to the number of times I can re-write 80 highly articulated Grids, and still keep smiling.

  3. What else? I don’t mind change, but it would be wonderful to have a plan. How to maximize the return on effort and get the most out of every precious coding hour?

This is an emerging business for me. Its no longer an experiment. Too big to be called a hobby, but too small to be called a real business. There are insufficient resources (yet) to spend on having Vaadin re-engineer my work, or probably even evaluate it. But a few honest forecasts, best guesses, right or wrong would go a long way towards me making some decisions and crossing the chasm. I imagine there are some other Vaadin developers pondering a similar situation.

  1. I foresee Maven to be around in 5 years still. In Vaadin we currently use Maven and Bower. Maven for Java and Bower for the WebComponents (Polymer). Some people prefer Gradle and Bower will be replaced by npm.

  2. We are committed to support Web Standards. WebComponents is the standard component model for the Web and we trust it is here to stay. It will evolve and change as any standard but the base is now solid. Currently we use Polymer helper library as our base for Vaadin components. In 5 years time I foresee that we’ll use other libraries for our components as well. I consider those changes to be “implementation details” that should not affect APIs but tooling will be affected.

  3. We aim to provide stability in sometimes chaotic appearing web development area. I think that will be valuable. Do you agree? Major changes were made in Vaadin 10 in components and we added capabilities to extend the development model beyond Java-only. Since June 2018 we’ve been busy adding capabilities that our users asked for. With V14 we think we’ll be done with most major changes.

Juha

I’ll charge straight on in a Finnish fashion and leave the small talk to someone more culturally inclined to such pleasantries.

To start with, Maven looks like a really safe bet at this time. When we started using Ivy, it was mostly seen as the least bad compromise. In comparison, the position of Maven is much stronger.

Things get more interesting when it comes to components. The frontend world is moving quite quickly which makes it difficult to know what to expect. It does look like Web Components is still a standard that will be here to stay. The beauty of Web Components is that it (mostly) doesn’t matter how the components are implemented.

The Polymer library that we are currently using has effectively deprecated itself, but that’s not really a big problem because the Web Component standards remain. We can (and most certainly will) update our components to use another Web Component helper library with quite small impact on application code. You have yet another layer of protection against such changes when you’re using the components through their Java APIs. There would be more changes to expect for an application that implements views using Polymer’s template syntax.

The next architectural frontier for Vaadin will most likely be related to offline functionality. The basic idea would be that would to use client-side logic for views that should work while offline while you’d be free to keep using the established server-side approach for other views. This still means that logic for bootstrapping the application and choosing which view to show would have to be moved to the client. We don’t yet know exactly how this would affect existing applications, but this is still the area that would be most likely to require some backwards incompatible changes.

In any case, Vaadin 8 will still be fully supported for another 3.5 years while the upcoming Vaadin 14 LTS version will be around for 5 years.

Thanks guys, the hard work and excellent results of the Vaadin team is most appreciated. A few facts and a request from me:

  1. Vaadin’s magic is that a semi-compentent developer can focus primary attention on a customer’s business and only secondary attention on the underlying technology. That allows scarce resources to be applied optimally.
  2. In optimizing resource use, planning is much more important than executing. There is no use doing “the thing” right, if you’re doing the wrong thing.
  3. Good planning requires forward looking data. What are the most likely platform decisions? What technologies will rise to the forefront, which fade away? Forward looking data is never perfect. It involves some guesswork. Decisions change, environmental factors change. So we all apply our intuition.
  4. Vaadin’s intuition about the future will be better than mine, 99 times out of 100.

So my request: Please freely communicate your best guesses about what’s coming up at all times. Don’t worry about being wrong. Your early view of discontinuities is especially important. Being clear on the roadmap as far in advance as possible and planning around that makes the end result the best it can be.

I fully agree with your reasons for being as open as possible with where we’re heading. This is also the direction the open source enthusiast inside me wants to go.

At the same time, there are from time to time also factors that make this sharing slightly difficult:

  1. The [Osborne effect]
    (https://en.wikipedia.org/wiki/Osborne_effect) is real. Our open source product development is funded by consulting and subscription sales that are mostly happening when new projects are started. If we make announcements that cause many developers to postpone their projects until they can use the next big thing, then we are indirectly also making it more difficult for us to actually deliver the next big thing.
  2. Meaningful communication takes lots of effort, especially when the topic is tricky. When there’s a risk of being misunderstood, the easiest way out is usually to remain silent. This issue also exists on a spectrum: it’s easier to make forward looking statements in a private one-to-one discussion than as an official announcement in the company blog. In that sense, answering questions in forums and such is usually a good middle ground.
  3. There’s some balance to be had between offering a consistent view and continuously changing one’s mind.

In all these cases, the trick is of course to have some kind of balance. I hope we’re somewhere close to that, but it’s really hard to know for certain since there are so many different factors to take into account.

I suppose the Osborne effect is a hurdle made higher by the attractiveness of Vaadin 8. You guys did a good job and it’s going to be hard to say goodbye to this old friend. Scores of HTML tooltips, highly dressed up by CSS will need to be somehow re-worked to avoid a customer revolt… And many other such things, but no matter - those are details.

What’s important is to trust in the direction. Waking up in the morning to find that “Touchkit is dead” is a history I’d not like to repeat. Unexpected dead ends consume resources and erode trust.

I will be looking for the earliest possible opportunity to jump onto the V10+ train. And help you avoid Osborne by renewing a subscription. As soon as I sense the risk/effort/reward ratios are tipped in the right direction, it will be done.

Thanks for your insights Leif. I believe you have the balances right. Finnish integrity, directness and clarity will be the key to keeping them right.