Why we built Hilla

Does the world really need yet another frontend framework? We believe it does, because different frameworks have different underlying assumptions that lead to optimizing for different things. Let's take a look at the principles that have led us to build Hilla as a framework that integrates Spring Boot backends with reactive TypeScript frontends.

We've come to see that the typical approach to web application development isn't perfectly aligned with the needs of typical business applications. We want to help out by building a framework that is specifically designed for those types of applications.

We strongly believe in Java as a good backend language for business applications. The language helps big teams with varying skill levels write maintainable (albeit sometimes verbose) code, while the JIT and the highly tunable garbage collection implementations contribute to efficient runtime performance. Nowadays, Spring Boot brings most parts of the Java ecosystem together in a way that works based on conventions, with minimal need for separate configuration.

For the frontend, we see TypeScript as an excellent choice, with its native web foundation as a JavaScript superset combined with a strong type system that brings the same structure as Java. Contrary to conventional wisdom about separating the frontend and the backend, we're looking for opportunities to optimize based on bringing server-side Java and client-side TypeScript closer to each other.

What are the optimization needs for business applications?

Whereas a typical consumer application can have a huge number of users concentrated on a handful of different use cases and application views, the situation is the opposite for many business applications. Here, we have complex business processes, huge data volumes and a user base that is often counted in hundreds or thousands, rather than millions. These factors lead to relatively low hosting costs (ignoring backend functionality, such as data stores and system integrations) combined with a massive development effort to cover all the different views needed for the application. In other words, development effort dominates the total cost of the application and any gain in productivity will have a massive total impact.

A big part of any business application is centered around loading complex data from the backend to be shown in the browser, and then submitting changes back to the backend. By focusing on making this part very easy to implement, we are freeing up your time to either spend more time on tweaking each use case to better serve your users' needs, or alternatively to get more use cases implemented in the same amount of time.

Business application development is also more than passing data around and validating it. Hilla brings all the capabilities you need for building and connecting the application's UI to a Java backend. This includes the following:

• a unified project setup that covers both Java and TypeScript
• a comprehensive set of UI accessible components
• single-page application bootstrapping and routing
• automatic integration with Spring Security for JWT-based authentication and authorization

We see all these concerns as generic concepts that can be readily integrated and maintained as a whole, so that you won't have to spend time choosing libraries and making sure they remain compatible over upgrades. This brings us to one more reason for building Hilla: you should be able to focus on functionality specific to your own business needs.

Hilla combines server-side Java and client-side TypeScript for increased productivity

At the core of Hilla is the assumption that the UI of the application doesn't end at the network boundary between the web browser and the server. Instead, applications are built by feature teams with responsibility for a dedicated part of the application's UI and at least the "outermost" layer of the backend functionality used for that UI. This is known as the "backends for frontends" pattern.

A very prominent example of the productivity gains from this model is the way you only need to add an @Endpoint annotation to a Java class to make public methods from that class available to the frontend (and bypass the strong defaults for authorization in this case).

@Endpoint
@AnonymousAllowed
public class HelloEndpoint {
    public String greet(String name) {
        return "Hello " + name;
    }
}

Since Hilla handles both the frontend and the backend, it can generate TypeScript to call those endpoint methods directly. You don't need to define exactly how data is sent over the network, since this part of the backend is intended specifically for its corresponding generated frontend, rather than a generic REST client.

const greeting = await HelloEndpoint.greet('Hilla');
console.log(greeting);

The benefits from this simple example go much deeper than just the apparent absence of boilerplate code. What isn't visible from the code snippet is the way the IDE can help the developer with auto-completion and type information based on the TypeScript type for HelloEndpoint. Yet another big benefit becomes obvious when refactoring an endpoint, since any change to the Java signature will immediately trigger TypeScript errors for any corresponding frontend code that also needs updating.

Generating TypeScript based on Java doesn't just make a server-side method easily callable from the client. There's also TypeScript types for the business objects that you would pass as arguments to endpoint functions or get back in a response based on the server-side return value. Furthermore, Hilla also generates metadata to easily bind that data to a form, including client-side form validation based on bean validation (JSR-380) annotations on the Java types. And, as if this wasn't enough, you can also send a business object instance over the network for additional server-side validation and get any validation errors back.

Hilla is backed by Vaadin

We are building Hilla as an open source framework. The use of free, open source software can, in some cases, lead to risks in the form of not having any specific vendor for maintenance and support. Hilla is backed by Vaadin, which has over 20 years of experience in building, maintaining, and supporting open source web development frameworks. The software that we're building, and sharing as open source, is itself the core of our business. We know the ins and outs of what we've built. We provide first-party support for Hilla and we plan our roadmaps based on the needs of our users and customers.

Why should I use Hilla?

Vaadin's roots are in combining extensive and complex business applications, Java, and web development. We believe that our experience and perspectives can help bring that subset of the ecosystem forward.

This is what has led us to build Hilla as a first-party-supported open source web framework optimized for business applications using Spring Boot. We believe this kind of application is very well served by an architecture that allows Java and TypeScript to support each other, rather than keeping them separated. In our world, feature teams are using the "backends for frontends" pattern to rapidly build comprehensive applications that exceed users' expectations.