The highlight of the recent Vaadin 15 release is the new capability to write UIs using TypeScript on the client side. Notwithstanding this, most of our recent effort has in fact gone into adding new value for Java-based UI development. These improvements target the upcoming minor releases of Vaadin 14. As elaborated on in an earlier blog post, 14 is the recommended version for most users, because of its long term support (LTS) status and the stability it provides. Even though the new Java features will also land up in the quarterly major releases too, 14 remains the recommended version. Java-based UI development will also be at the core of the next LTS version when it sees the light of day - my best guess would be in 2021.
This blog post is an update on some of the improvements in the pipeline on the Java framework side.
Improving reliability and speed of frontend builds
Our mission is to make Vaadin developers happy and productive. To achieve this, we want to hide all unnecessary distractions, like build tooling and dependency management. Things should just work - and to make this so, we’ve put a lot of effort lately into the integration of a modern frontend tool stack.
I’ll admit that in 14.0 the new npm and webpack-based frontend build still had a few rough edges. It was smoothed to some extent with fixes and overhaul in 14.1, but still did not achieve what we were aiming for. In 14.2, I’m happy to announce that we have taken significant strides forward. The improvements below are introduced in their order of appearance when you run a Vaadin 14.2 app.
Automatic Node.js install
Starting from versions 14.2 and 16 the Node.js install (which includes npm) happens automatically. It is installed to a .vaadin folder inside the home folder, and reused from there for all Vaadin projects. There is no need to use the frontend-maven-plugin for all projects or to install Node globally on your system. And don’t worry, Node is (still) only used to build the frontend side of things; it does not run after you deploy for production!
Frontend dependency management that just works - pnpm
Behind the scenes, npm has been used to manage frontend dependencies since 14.0. It has caused a lot of obscure issues when updating Vaadin versions that could only be fixed by manually deleting files. This is unacceptable and we have addressed it by adding support for pnpm. Compared to npm, pnpm introduces the following benefits:
- Faster build: pnpm only downloads packages once and reuses them from a local cache. This works in the same way as Java dependency-management systems that you are familiar with. It reduces downloads and IO operations, saving precious build time on your local machine and CI system. The framework CI build time dropped by 50 % when we switched from npm to pnpm, because we have a lot of IT modules.
- Improved reliability and reduced complexity: no need to delete package.json, lock file or the node_modules folder when updating the Vaadin version in your project.
In 14.2 npm is still used by default, but we encourage you to test pnpm and give us feedback. Trying pnpm is easy: there is no migration, just enable it by using a configuration property or Maven plugin configuration. You can learn more about pnpm here.
Skipping ES5 transpilation for faster development-mode frontend builds
When writing Vaadin code, developers typically actively use one or two browsers and later test separately with the older browsers (Hello Internet Explorer 11). Starting from 14.2, the transpilation of JavaScript code to ES5 (required by IE11) is not done by default in development mode, but you can still enable it with configuration, if necessary. For production builds with the build-frontend goal, it is still done by default.
This makes a surprisingly big difference for the initial webpack startup and frontend compilation time, reducing it significantly from for example 20 seconds to 5 seconds. Even subsequent frontend compilations (webpack caches some parts) are 1-3 seconds faster than before.
I have to admit that slowdown was actually a regression introduced by us in 14.1 (compared to 14.0), when we disabled the optimization of the frontend bundle in development mode. This saved significant time, but at the same time added time for the frontend build. From this we learnt that sometimes you need to take it slow when you’re trying to make it fast.
There is more to come
The changes mentioned above are only a small sample of the improvements for Java developers in the upcoming 14.2 release. You can read about all the framework changes in the latest prerelease notes for version 2.2.
You can also expect enhancements on the web components side; the long awaited DateTimePicker component is coming and Dialog is getting a resizing feature. We’ll update you about the upcoming component improvements in 14.2 when the beta period starts. When the time comes, please give 14.2 beta a spin and send us your feedback!
14.3 is on the horizon
Currently, we are also working on new Vaadin 16 features. These will most likely land up in version 14.3, which is expected to be a feature-driven version and does not yet have a release date. On the framework side, the focus stays on improving the development experience:
- Live reload of the web browser after Java changes when using Spring devtools, Hotswap agent, or JRebel. This is already possible with Spring Boot apps using devtools and a separate browser plugin, but we want to make it available consistently for all developers.
- Improved support for route parameters. we’ve made it possible to have parameters in the middle of the URL and also permit several parameters.
- Running the frontend build as a separate process to enable faster server startup time. This is still in the prototype phase, but can potentially further improve the server startup time both locally and when running ITs on your CI system.
- Taking advantage of the upcoming Webpack 5. This is only speculative and we have not yet started, but we are excited by the promised performance improvements and the possibility to skip the frontend build for Vaadin components using the new module federation feature.
Towards the end of our spring, the framework development focus will gradually move from development turnaround improvements to data provider and form building improvements - which is something every Vaadin application needs. Hopefully, we’ll be able to tell you more about these in May.