Hacker News Reader

Comment by winrid | Hacker News Reader

Quarkus and Vaadin is pretty productive.

Quarkus is just a little too much like magic for me. Too many annotations hides what's going on underneath, which makes me feel a bit uncomfortable. But I'll accept that's probably just me.

Vertx on the other hand, which it is built on and which itself builds on Netty, is excellent, and very performant for typical backend services. It now has support for virtual threads too.

>Vertx on the other hand, which it is built on and which itself builds on Netty

What does the highlighted part above mean?

I know what Netty is, but did not understand that phrase above,

Vertx uses Netty as the event loop handler for concurrent IO. Vertx adds a simplified asynchronous API on top of Netty (whose API can be pretty complicated), making backend services that need to handle large numbers of concurrent connections easy to implement. HTH

Please DO NOT build a large application on raw Vertx. Quarkus gives you things like auto generated openapi specs etc.

Quarkus is just compile time stuff around vertx, and you write simple synchronous code. Again, DO NOT use vertx directly for building APIs. It'd be like using just expressjs and writing your api specs manually... in 2025...

No capitals needed. I have written many backend services around raw Vertx very successfully. It's simple, well documented and predictable, mainly because everything is done in code.

Deviating from Quarkus's standard behaviour was comparatively difficult, either tracking down the correct configuration properties and what to change them to, or which api to implement and override and what it needs to do.

I prefer to develop OpenAPI specs separately from the code too, mainly because it's a joint effort with other teams. Vertx can incorporate them easily.

If you're generating the vertx route handlers from the spec then I guess that's fine.

I gave Vertx a chance a few years back and while it worked, it's not great for building services on, unless your needs are extreme scale. And in the latter case, you might be better off with a language like Go. It's very async/reactive and a bit of magic hides behind those nice builder patterns.

My advice: If you are just building a regular service that doesn't need to scale (and 90% of apps do not need Twitter scale), just stick with sync.

I don't know. I still find Vaadin's pricing way over what I could spend on a startup project. But it could just be me.

edit: People also forget that Eclipse RAP still exists and although it's probably not that "modern", it works.

https://eclipse.dev/rap

The vast majority of people don't pay anything for Vaadin as it's Apache 2 licensed. Out of curiosity: Why do you feel you have to spend on it – is it some part of the tooling or are the support alternatives the reason? (I work for the company behind Vaadin, thus honestly curious).

AFAIR, it was the "Grid Pro" and "Dashboard" features that were needed, but they were out of budget for our infant phase of the product and we went with React. It was a long time ago anyway, I last worked with Vaadin 7. I will however say, that I really enjoyed working with it at that time.

If you used React back then, what do you miss from the Vaadin world and what was easier in React in comparison ?

Have you tried one of the latest versions?

Disclaimer: I work for Vaadin.

I can't imagine seriously showing RAP to a CEO and saying we're using that.

I don't pay for Vaadin, you don't need to unless you want the extra components, and even if you do it's affordable, much cheaper than building the same system in React.

Modern Java (21+), Spring Boot backend, and Vaadin Hilla (https://vaadin.com/hilla) frontend is a great startup combo

Reply on news.ycombinator.com