4 ms·

I really don't like Quarkus approach. It's full of magic. It's everything I'd love to get rid of. I'm using Spring which is kind of full of magic but I spent 15

I really don't like Quarkus approach. It's full of magic. It's everything I'd love to get rid of. I'm using Spring which is kind of full of magic but I spent 15 years learning to deal with this magic, so it's bearable to me. But it does not mean that I like it. I liked Helidon SE approach (not MP, MP is the same EE crap). It's 100% code, no magic. What I didn't like is reactive, I don't need reactive, so I don't use Helidon SE for my projects, I still endure Spring. But if someone enjoys reactive programming and wants zero-magic approach, I can recommend it. Helidon Nima might be a saviour to me. I didn't research it yet.

rr888 4y ago
I'm not sure the point of Quarkus. Its an easy way to get started with GraalVM development, but pre-compiled Java isn't any use for dev work. The autoreload classes is easy in most dev environments already too.
- vbezhenar 4y ago
  It seems to me that the point of Quarkus is to allow old EE applications to be ported to Graal Native. For example they did that with KeyCloak, it was Java EE application running on top of JBoss Application Server, now it uses Quarkus.
mwcampbell 4y ago
I agree with you about both magic and reactivity (meaning, IIUC, asynchronous rather than blocking APIs). Helidon Nima looks interesting. But what I'd really like in Java is a non-magic, non-reactive server-side web framework that's designed to be used for full-stack, server-side web applications, including things like strongly-typed HTML templates, form validation and rendering, cookie-based authentication, and CSRF protection. Something we can use to develop a complete server-side web application, the kind that everyone used to write before the division into back-end API and front-end SPA became popular. Helidon Nima might be a good starting point for such a framework. Another starting point worth looking at is Javalin [1]. [1]: https://javalin.io/ https://javalin.io/
- hiram112 4y ago
  This is essentially the Java Servlet specification with JSPs (or if you don't like those, just bolt on Thymeleaf or one of the older templating languages). Nearly all of these newer frameworks like Spring, Helidon, Quarkus, etc. just reuse the internal Sevrlet spec themselves. Otherwise, they're reinventing a TON of code that would be insane to do in order to deal with the general HTTP request / response cycle.
- cutler 4y ago
  Then you're going to need something like Turbo/Stimulus as in Rails. I don't know of any Java implementation.
grishka 4y ago
I can't stand any magic, it always inevitably feels like a massive liability to me and always bites me in the ass sooner or later. I use http://sparkjava.com http://sparkjava.com in my projects. It's as tiny as web frameworks get, it only handles routing and request/response, and you get to do everything else manually. Only thing I had to hack into it was response streaming. The one most internally convoluted and enterprise-y dependency I use is, surprisingly, the official MySQL driver. GraalVM complains about it as well.
- switchbak 4y ago
  The idea that someone would reuse the "Spark" name though? Not sure how that got past a cursory review, that must make googling endlessly difficult.
  - mring33621 4y ago
    https://javalin.io/ https://javalin.io/ is similar to sparkjava and has a name that does not overlap with a well-known, big data framework.
    - rochak 4y ago
      This looks extremely similar to ExpressJS. Interesting. I kinda like it.
    - karmakaze 4y ago
      I actively looked for a lighter framework for microservices that could start up much faster than a Spring/Boot app. Tried SparkJava and later decided that Javalin is a better choice which is now what I reach for. Also using JDBI to go along with it.
  - grishka 4y ago
    Thing is, it's so simple and straightforward, you don't have to google anything. Reading the sources and poking things with a debugger has been enough for me so far.
- 4y ago
BenoitP 4y ago
> What I didn't like is reactive > Helidon Nima might be a saviour to me Well, Helidon Nima is getting a Loom-based implementation; so you'll get to keep performance without the reactive headaches.

rr888 4y ago

I'm not sure the point of Quarkus. Its an easy way to get started with GraalVM development, but pre-compiled Java isn't any use for dev work. The autoreload classes is easy in most dev environments already too.

vbezhenar 4y ago
It seems to me that the point of Quarkus is to allow old EE applications to be ported to Graal Native. For example they did that with KeyCloak, it was Java EE application running on top of JBoss Application Server, now it uses Quarkus.

mwcampbell 4y ago

I agree with you about both magic and reactivity (meaning, IIUC, asynchronous rather than blocking APIs). Helidon Nima looks interesting. But what I'd really like in Java is a non-magic, non-reactive server-side web framework that's designed to be used for full-stack, server-side web applications, including things like strongly-typed HTML templates, form validation and rendering, cookie-based authentication, and CSRF protection. Something we can use to develop a complete server-side web application, the kind that everyone used to write before the division into back-end API and front-end SPA became popular. Helidon Nima might be a good starting point for such a framework. Another starting point worth looking at is Javalin [1]. [1]: https://javalin.io/ https://javalin.io/

hiram112 4y ago
This is essentially the Java Servlet specification with JSPs (or if you don't like those, just bolt on Thymeleaf or one of the older templating languages). Nearly all of these newer frameworks like Spring, Helidon, Quarkus, etc. just reuse the internal Sevrlet spec themselves. Otherwise, they're reinventing a TON of code that would be insane to do in order to deal with the general HTTP request / response cycle.
cutler 4y ago
Then you're going to need something like Turbo/Stimulus as in Rails. I don't know of any Java implementation.

grishka 4y ago

I can't stand any magic, it always inevitably feels like a massive liability to me and always bites me in the ass sooner or later. I use http://sparkjava.com http://sparkjava.com in my projects. It's as tiny as web frameworks get, it only handles routing and request/response, and you get to do everything else manually. Only thing I had to hack into it was response streaming. The one most internally convoluted and enterprise-y dependency I use is, surprisingly, the official MySQL driver. GraalVM complains about it as well.

switchbak 4y ago
The idea that someone would reuse the "Spark" name though? Not sure how that got past a cursory review, that must make googling endlessly difficult.
- mring33621 4y ago
  https://javalin.io/ https://javalin.io/ is similar to sparkjava and has a name that does not overlap with a well-known, big data framework.
  - rochak 4y ago
    This looks extremely similar to ExpressJS. Interesting. I kinda like it.
  - karmakaze 4y ago
    I actively looked for a lighter framework for microservices that could start up much faster than a Spring/Boot app. Tried SparkJava and later decided that Javalin is a better choice which is now what I reach for. Also using JDBI to go along with it.
- grishka 4y ago
  Thing is, it's so simple and straightforward, you don't have to google anything. Reading the sources and poking things with a debugger has been enough for me so far.
4y ago

BenoitP 4y ago

> What I didn't like is reactive > Helidon Nima might be a saviour to me Well, Helidon Nima is getting a Loom-based implementation; so you'll get to keep performance without the reactive headaches.