Ask HN: What stack would you use to build a CRUD web app on the JVM today? | Hacker News Reader

Ask HN: What stack would you use to build a CRUD web app on the JVM today?

30 pointsnetworked43 comments

2015 thread: https://news.ycombinator.com/item?id=10302879. How have things changed since?

View on HN

I highly recommend the following stack:

JVM Language: Java 11+

Webserver: https://javalin.io/

Templating: https://j2html.com/

Enhanced html attributes: https://htmx.org/

Database helper: http://jdbi.org/

Database: Sqlite or Postgres depending on the expected scale.

The startup time is very fast. I usually see times under a second, which makes iterative changes significantly less painful than something like Spring.

Also setup is ridiculously simple, just throw those libraries in a pom file and use a CDN for htmx. No front end build tools needed since htmx removes the need for most if not all of your javascript.

The whole setup feels kind of old school, but man it makes developing CRUD apps dead simple again.

Lastly, project onboarding is as simple as having someone download intelij and pulling the project. The built in maven and jdk to intelij is all they need. That is as long as you don't need them to run their own Dev database instance, but that's not the end of the world if you utilize docker.

Even if you decide on something else take a look at the above libraries, they're all pretty fantastic.

That looks awesome! Shouldn't also be too hard to create a GraalVM native image from that.

They actually have a tutorial for GraalVM here:

https://javalin.io/2018/09/27/javalin-graalvm-example.html

- Backend: Clojure (with Reitit[0] for the API)

- Database: Postgres or SQLite

- Frontend: None, the backend serves html + js by combining htmx[1] and hiccup[2]

[0] https://github.com/metosin/reitit

[1] https://htmx.org/

[2] https://github.com/weavejester/hiccup

Spring Boot. But that's because I don't mind big binaries, fastest to be productive(for me!), every tool is just another autoconfigured include...

I would consider trading these for faster build times... I heard good things about javalin.

I would definelty use Java. I like it and there are tonns of new features in the 11+ versions. Boilerplate is greatly reduced by Lombok.

I would consider Kotlin for even less boilerplate and null handling.

I don't have much backend background, but I worked with Spring before, and coming from that Ktor was a lot more fun to work with. I don't think I would use it in a huge project, as I feel there a lot of things still missing, but eventually I think it'll be great. Otherwise, Spring Boot + Kotlin is still a great combo.

Would anyone use Scala? If so, any recommendations on server libraries or frameworks? Had an interview with a relatively new company and surprised their backend was all Scala (Data science company so maybe it expanded from just using it for Spark).

I would use it at work because I know it. There are a LOT of libraries in Scala for HTTP up to database stuff, and it really depends on what kind of ecosystem you're walking into:

* Scala as Python: https://github.com/com-lihaoyi/cask, maybe https://github.com/getquill/quill

* Scala as Haskell: HTTP4s, https://tpolecat.github.io/doobie/

* Scala as Rails: Play

Play is the closest thing to Rails-like CRUD productivity IMO, and honestly for CRUD most times I would like to write as little code as possible and just get it done, even using low/no-code solutions (postgrest, hasura, htmx), but that wasn't the question :)

Please understand that this is subjective - some people will have good experiences with a language, and some people won't, and thats okay. That's the nature of languages.

But yeah, I use Scala at work for what should be a simple crud app, and I absolutely hate it. Never felt less productive in my life.

The biggest problem with Scala is the type system. Types are great for catching bugs _within_ a program, but don't really help much for catching bugs when the program interacts with the outside world, which CRUD apps do a lot with a database. So I'm paying the cost of having to learn this complex type system and all the wacky ways the type checker can fail, but I'm not reaping much of the benefits that comes from actually using Scala's type system.

And if I'm not using Scala's type system, then what's the compelling reason for choosing it over Kotlin, or even Java?

My work was doing the same (scala for crud app) and I gave a lightning talk at about exactly this - the expressiveness of the type system is hamstrung by the capabilities/quirks/documentation quality of the various serdes required to move scala objects into some other domain and back. Made everything so much harder than it should be.

You can use types to help with the outside world by making error states explicit encoding them in types. ZIO for example.

I can write programs without code covering all scenarios by stubbing out methods with types, using ADTs etc then it’s a case of implementing a function to run it all.

However, I completely understand where you are coming from.

I had some of the same issues until I worked with a great team who showed me the abstractions, why they are useful and how they work.

If I hadn’t of worked with the team I did I would likely of still been agreeing with you. I think the biggest problem is it’s hard to understand on your own unless you are deep in to the theory. You don’t need to know the theory deeply to use the abstractions but unless someone shows you how to apply them it’s hard to discover.

With that your last comment is exactly right. If you are not utilising Scala type system and other features Kotlin or Java will be better. Java is moving quick these days and Kotlin is closer to a better Java than Scala is.

During the interview process with the company I referred to above, I found out they were moving to a micro service based arch around TypeScript/Express which seemed like a bit of a 180. I was up for a front end position, but spent a couple weeks looking at Scala. The divisiveness between the pure functional and multi-paradigm communities left me confused on the preferred approach and syntax, and obviously this results in different library/framework preferences. I really want to like the language, but some of the build tools, like SBT seem to come from the JVM legacy, when more modern tooling like Mill exist.

Since when do types not help with "the outside world"? People model "the outside world" with strong types all the time and have been doing so for years. SQL, typed API bindings, typed errors, etc

Also I've spent some time with Kotlin now and ... it is just pure shit lol - its ADT support is comically inadequate. It's like the designers wanted them but only made a superficial copy without the hard part (real pattern matching.) Amatuerish. The language is pure sugar.

Yes.

Http4s, zio-json, zio-config, scalate templates, doobie for the db.

These are libraries not frameworks but the way it’s designed you don’t need a framework as so easy to slot together.

Think of it as writing a crud app with Express on NodeJS. Or one of the other bare bones HTTP server/routers.

Admittedly it’s an acquired taste but if understand them it’s the most flexible/simple I’ve used across various languages.

You also have Play framework which is a full stack framework, Java like but Scala syntax and closer to Spring Boot than Http4s etc.

Clojure(script) with re-frame and figwheel, nothing else comes even close

Microprofile or Quarkus world be my votes. Java is still the performance king, and Java 17 in the fall is going to further cement that position.

I think if I had to start new project based on Java I would definitely have Micronaut [0] on my shortlist. I have used it in small personal projects and I have to say that it was a nice change of pace compared to Spring Boot.

My understanding is that Micronaut and Spring can be used together [1].

[0] https://micronaut.io/ [1] https://micronaut-projects.github.io/micronaut-spring/latest...

Lucee.io all the way. It was featured here on hn awhile back. Basically dynamic ecmascript on the JVM. Great for quickly prototyping apps with. I’ve also built many highly scalable enterprise applications with it.

DropWizard is great. Spring Boot was based off it.

It's a nice mix of simplicity and effectiveness.

If you want performance above all else, Vert.X isn't too hard to use. But the async API's are a PITA, much like ExpressJS.

JEE, or if you prefer Jakarta EE, as always.

If a CMS solution is required, LifeRay or Adobe Experience Manager.

Preferably with Oracle as database, and most performance critical queries written in PL/SQL.

Although I am sure this is a not welcomed solution in this side of Internet.

I'm experimenting with Ktor and Kotlin. Ktor seems really well featured with baked in co-routines based concurrency and Kotlin feels a far more sophisticated and productive as a server side language than Go or Python.

I managed to skip few years of front end development. The last time I was at it, the Go was all rage and express JS. What would you use today to be valuable on the job market?

Lucee application server, with ColdBox framework.

100% Lucee is amazing! However I prefer Wheels framework for more of a Ruby on Rails feel.

Why not just use Rails then? Several years ago, I attempted to rewrite our main app (running on Railo and FW/1) in Wheels, and ultimately, that process led me to determine that Rails was a better fit for our project.

Developer quality of life. Lucee and CFWheels gives you the best of both worlds. Also, I hate Ruby syntax. I’d sooner use Golang.

Clojure with usual suspects; e.g. Ring, etc.

As always, the answer is, it doesn't matter.

Whichever stack gets you to build your mvp fastest, or the one you already know and enjoy, or the new shiny one you've been dying to try out, or the one your buddy challenged you to use..

They are just tools, which you pick is a matter of preference. Just pick one unless you enjoy spending your time thinking about which to pick rather than get to work and build your project

I get the sentiment and it’s appealing to just pick something and go with it. I work with people that constantly churn on frameworks. They pick one and the first semi-difficult roadblock and they’re changing things up. To balence that out though. Picking something involves a significant investment and a long term commitment. That advice wouldn’t sound as good if you said,”Don’t worry about who you marry. Just pick one and go with it and make things work”

OP didn't provide any context so it's hard to answer. Is it for a personal project? Is it for a startup?

For example, Clojure is a very expressive and fun programming language but I would never build a startup on that as it would be far more challenging to find experienced developers.

I think I misunderstood the sentiment of the question anyway. It was trying to start a discussion rather than get a pragmatic answer :-)

Spring/Lombok/Postgres/React - exactly the same as I would have used in 2015.

spring boot works. https://news.ycombinator.com/item?id=10302913

Spring Boot or Quarkus.

Spring boot, Java 15+, Gradle, Tomcat (in built), Thymeleaf

Quarkus would be my choice.

Step 1: Pick anything other than JVM language

Why people like suffering so much? )

Sorry for being emotional and slightly off topic, but why would you fire a cannon at sparrows?

“Today” some things changed, new more team-scalable and simple languages matured. Old one got more performant and stable (like nodejs, ruby etc).

What’s there in CRUD that you win with jvm?

I don't think an ask thread is a good spot for a rant, but the JVM languages have changed a lot over the years.

You imply that Java is big and heavy when JS/Node Python and Ruby use more ram and run slower than Java in basically every benchmark. And V8 runtime and JS language complexity is just as big as Java these days.

Java is very scalable. If I was force to work on a million+ line project I would pray it was Java or C#.

Java ain't going to win any beauty pageants but it's a solid all rounder. The guy you keep on roster because he can fill any position, not because he's the star hitter.

Java is too scalable for simple crud. That’s my point.

I’ve worked a lot both with java and nodejs. Your words about js complexity “just as big” are simply wrong.

Think about multithreading for starter. And all the bugs and developer mental overhead that comes with it.

Multi threading has zero overhead in normal Java web frameworks. It's thread-per-request so you don't need to worry about thread safety any more than you do in JS. That you didn't know that implies you haven't worked with many Java web frameworks.

JS has become a huge language, just as big as Java. So is the runtime, V8 is gigantic, comparable to JVM. I use both every day.

Vert.X is nearly identical to Express JS including all the callback stuff. And that's one of the harder Java frameworks to use

Its very unprofessional and not polite of you to assume my knowledge from few words.

As for java frameworks like spring they mostly suck because of way too verbose java syntax and over engineering mentality usually coming with any java framework.

Also i never said express js is a great example of web framework.

But i know for sure that i can spin up simple crud with db, tests and some logic behind it in less than hour in rails.

While java devs still arguing about “right” architecture.

That was rude especially for HN, my apologies. I'm a big Java fan but you're right about verbosity and ceremony about startup. There's ways around it but not stuff you would read in a book. Tribal knowledge really like starting a project using a maven archetype and using lombok judiciously.

Java gets a bad rap which bothers me because it's really a good choice for backend work even today. Sometimes it bothers me enough that I lash out needlessly.

I'm with you, I love Java, really do. JVM is a masterpiece, undoubtedly.

And i also lash out sometimes when people (especially beginners) trying to solve simple problems with heavy artillery, sorry.

Peace.

Reply on news.ycombinator.com