When we started designing Vaadin Framework in the year 2000—then called Millstone Framework—we had a clear vision of creating a platform that would make building web applications fast, easy, and modular; something that we wanted to use by ourselves in the process of building business-oriented web applications. We envisioned a full stack of technologies starting from a web server, an object relationship mapping tool, a rich set of user interface components, and an extensible theme system. Everything built from scratch with a tiny team with no funding and little experience. Fortunately we did not have a clue about the size and complexity of the task or the lack of our experience—otherwise we would have never dared to start working on such a huge task. Finally, it took two years and three complete rewrites to understand the value of focusing solely on the user interface layer and being able to release something solid that has outgrown all the expectations we had.

Now when I look back at the design principles we chose for Vaadin, three principles in particular seem to have contributed to the longevity of the framework. First, we reasoned that the diversity and incompatibility of the web browsers we experienced back in the year 2000 was not going away—quite the contrary. While the Web is today the de facto platform for building all kinds of user interfaces, the capabilities of web browsers seem almost unlimited today and the number of web browsers has grown to include smartphones and tablets in addition to the handful of desktop browsers that should be supported by most applications. So we chose to embrace this complexity and abstract away from the browser to make it easier for developers to support "all" browsers at once. Secondly, we set our optimization target to be developer efficient, which in most cases can be roughly measured by the number of code lines in the user interface layer of the program. This has been a good choice as developers continue to be a more expensive resource in business application projects than servers. Finally, we recognized the need to support the heterogeneous teams where some developers might be more experienced than others. Some of the mechanisms to support the teams include theme packaging, multiple levels of abstraction, support for data bindings side-by-side with internal data in components, and deep inheritance hierarchies for user interface components to name a few.

Vaadin 7 has been the holy grail to our team for as long as I can remember. Somewhere after releasing IT Mill Toolkit 4 in 2007 we started dreaming of all the changes we should be making to the core of the framework to remove some of the shortcomings we felt it had. We started building up a huge backlog of things we should fix sometime soon when we have the time to do so and the courage to tear down parts of the old design. Then came IT Mill Toolkit 5 with the GWT-based client side and later on Vaadin 6. While they both included important features, they skipped many of the hard design choices in our "someday when we have the time" backlog. And we still believed that the time to do these would come really soon after the release of Vaadin 6. What happened was that we underestimated the success of Vaadin 6 and ended up releasing eight minor releases to it during 2009 to 2012. This took all of our focus and we pushed Vaadin 7 even further. Finally near the end of 2011, we decided that we cannot push Vaadin 7 any further and this would be the right time to make all the important changes we have been dreaming of.

While we thought we succeeded in cutting down the number of features in the release to an amount that it would be doable and fully finished in nine months, we ended up using almost twice that time and even then had to leave big things out from the release. But oh boy! We managed to get in over 60 new features, including a huge deal of merging Google Web Toolkit directly inside the Vaadin Framework. With this release, we also shifted the underlying philosophy of the framework by recognizing that all the three layers of abstraction that the framework implements should be equally accessible to the software developers: server-side Java, client-side compiled Java, and client-side JavaScript. This effectively changed Vaadin from being a server-side only framework that abstracts away from the Web to being a full stack framework that bridges Java and HTML5 platforms in a coherent way that supports the developers on all of its levels.

I have always been a huge fan of open source since being introduced to it by starting to play around with Linux kernel 0.3 and early Linux distributions. Working on, living in, and breathing open source did make it natural to choose to release Vaadin with an open source license and to build a community around it. After years of trying and failing to build an impactful community, all pieces finally clicked together in 2009 with the release of Vaadin 6. Seeing how people all over the world started to use Vaadin for building applications their businesses depended on for years to come had been great. What has been even more amazing is how people have started to contribute back to Vaadin—in terms of add-on components, helping each other on the forums, and promoting the framework to their peers. At the end of the day, a lively and friendly community and an ecosystem around Vaadin has been the key to the rapid growth of adoption.

I think that I first heard of Nicolas Fränkel by reading one of his many insightful blog posts some years back. I also remember him being one of the more active Vaadin community members helping others on the forum. At one time Nicolas invited me to a really nice dinner in Geneva where I was visiting the SoftShake conference to discuss about Vaadin and overeat the excellent Swiss fondue. During the dinner, we ended up talking about the need for a book that would tutor beginners through Vaadin and would introduce them to common patterns for Vaadin development. I remember getting contacted by Packt Publishing about getting in touch with potential authors for such a book. Nicolas had quite a lot of Vaadin experience and I asked if he would be interested in considering writing the book. To my surprise he agreed and the first edition of this book was born. Later on when Vaadin 7 was published, Nicolas decided to update the book to cover this newly released Version 7. I am sure that Nicolas underestimated the effort needed in writing about Vaadin 7 the same way as our team did while developing it. Maybe even for the same reason—the list of new things in Vaadin 7 is huge.

You might be familiar with Book of Vaadin—a free book about Vaadin. While being a very complete reference to Vaadin and anything related to it, the amount of content and the reference-like approach can make it overwhelming for a beginner. This book takes another approach. Instead of trying to be a reference, it teaches Vaadin concepts by introducing them one-by-one in an order natural for learning. It is written as a journey of building a simple Twitter client while learning the most important aspects of Vaadin—one-by-one.

In conclusion, I'd like to give my deep thanks to Nicolas for taking the challenge of writing this book, which I am sure, will help many people to get a quick start for writing Vaadin-based applications. I hope that these applications will benefit the companies investing in them as well as save a lot of time and frustration from the end users. But at the end of the day, it is most important to me—and I am sure that Nicolas shares this too—that you as a developer of those applications will save your time and frustration and be able to accomplish something that would not be possible otherwise.

Dr. Joonas Lehtinen

CEO and Founder, Vaadin