The Vaadin team was at Devnexus 2020, the largest Java developer conference in the US. The event was sold out and there were 2400 attendees, mostly from the US, but also from many other countries around the world.
To me, as a Product Owner at Vaadin, events like this are not only a chance to learn and be inspired by industry-leading speakers, but are also a great opportunity to meet the people behind the tools and frameworks I use every day.
I spoke to about a hundred people who wanted to learn more about Vaadin, or to share their current experiences with it. While walking them through the Vaadin booth coding challenge, I asked about their background, team structure and tech stack. This helps me better understand the developer community, and it helps us at Vaadin build a better product for our users.
Below are my 6 key takeaways from the conference.
Java teams go full-stack
Full-stack teams are becoming the default. A lot of Java developers said they work on full-stack teams, where both frontend and backend devs work together. However, the DX and ergonomics for such teams has a lot of room for improvement. They still tend to keep their frontend and backend code in different repos, and sometimes use different IDEs and different build systems, even though it’s expected that every developer in the team can work on any part of the app.
REST is used blindly everywhere
REST is the default interface and communication method between frontend and backend. Even if there is only one backend and only one frontend, they still interact over REST. The reason given to support this approach is “it’s easy to swap the frontend / backend implementation in the future if the need arises”. I think that in the case of a tightly coupled frontend / backend this seems unnecessary, but this does not seem to dissuade people from using REST anyway.
JavaScript is a very common choice for the UI
Most teams build the UI layer of their web apps using one of the mainstream JavaScript UI frameworks. There are very few exceptions and this does not make developers with mostly Java background happy, because of the fast pace of changes in the JavaScript ecosystem, and the constant need to change / update / rewrite the UI code. However, most of the developers try to adapt and learn the new stack.
Developers with many years of Java experience, mostly on the backend, increasingly find themselves being “promoted” to full-stack. At this point, they have to learn a frontend UI framework, like React or Angular, and many are scrambling to do so. There is a lot of potential for a full-stack UI framework that can bridge the gap between frontend and backend, and this is what we are aiming at with the new TypeScript views support in Vaadin 15.
Vaadin components are awesome
Vaadin components do create interest and wow reactions, among Java and JavaScript developers alike. People ask if they can use Vaadin components in their React / Angular UIs, and whether or not they support the Google Material and Bootstrap themes.
REST boilerplate is accepted but is annoying
In Angular and React people end up creating their own typed wrappers for REST endpoints manually. This is boilerplate code, but the developers do not actively complain about this. Auto-generated TypeScript wrappers for Vaadin 15 Endpoints do spark a wow, this is cool! Reaction. Often developers ask if the auto-generated TypeScript wrappers can be added on top of their stacks, not as replacements for them.
Full-stack teams are looking for full-stack type safety
Static typing and automatic type checking is taken for granted in backend development. It is gaining adoption in frontend development as well, thanks to the increasing popularity of TypeScript. However, the advantages of strong typing often disappear in code that accesses backend APIs, because of the low-level REST abstractions, like URLs, HTTP verbs and JSON payloads that leak through.
When developers see that all API access is statically typed, and automatic type checking covers the entire code base, end-to-end, it does create a wow response. This is not something that developers have come to expect from REST APIs.