Live data from Hacker News

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

news.ycombinator.com

171–180 of 213 posts

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

#171
post #165

Earlier quoted context omitted.

Grails is great for building a REST API. Especially the latest version. It makes it dead simple. I do SPA frameworks on the front and JSON APIs from the back.

Grails is great to get things done quickly (scaffolding). But if you want to write vendor independent code, Grails makes your life unnecessarily hard by providing a full stack from Database to UI. Somewhere something leaks into the business logic. This is less the case if you can pick and control exactly what Database and REST technology you use. Of course you can ignore the DB part in Grails and plug your own thing,…

Fair point. Grails 3 provides "profiles" for this reason. So if you don't need the view layer and everything that goes with it won't be loaded.

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

#173

My background, which informs my personal taste here: - Most recent 8 years, have used dynamic languages on the server (Node.js, Ruby, PHP, some Python) - Have dabbled in C# (ASP.NET MVC and WPF) - First 4 years professional experience as a Java web developer (servlets, Struts, Spring, Hibernate, etc) - Have needed recently to generate greenfield Java apps for relatively straightforward CRUD web apps / JSON APIs I per…

Why Maven rather than Gradle? Gradle has all the libraries in Maven Central. Gradle also has an extensive set of useful plugins built in [1], and many more available externally [2]. In particular, there's a plugin for making a fat jar [3], and even without a plugin, it's a few lines of code [4]. Or you can also make something more exotic like a capsule [5] or a shell script [6], or my preferred format, a 'distribution zip' file containing loose jars and a shell script [7] - which you can even make executable, because i wanted to troll my boss one day [8]).

And there's no XML, it's pretty concise (Groovy syntax, convention over configuration, sensible defaults), and although its raw speed is no better than Maven's, it is smart enough to only execute tasks which are needed (rather than everything, every time, as Maven does), and can run as a daemon to avoid startup costs [9], so in practice it's far faster than Maven. Still downloads the internet now and then, though.

But extension is an absolute joy - there is simply no comparison to Maven. There's a very satisfying spectrum of ways to define your own tasks, from blocks of code right in the build script, to classes defined in the build script [10], to externally packaged plugins, all of which are easy to do and integrate fully with the existing machinery (task dependencies, handling files, inputs and outputs, and so on).

Then there's the stuff you might not even notice until you get off Maven. Gradle builds are graphs of tasks, not sequences of lifecycle phases, so it's trivial to add more tasks, rearrange, tasks, etc. Concrete example: Maven provides a single test task (surefire); if you want a second (say, for functional tests), you can use a plugin (failsafe); if you want a third (say, for external contract tests), you'll need to write a plugin. In Gradle, you'd just make another instance of the test task. It's a few lines of code.

Sorry if i sound like a fanboy or a shill, but Gradle, while far from perfect, is so much better than Maven in every way that it pains me to see a fellow human being suffering under the latter. Seriously, Maven is obsolete. Just use Gradle. Until something better comes along.

[1] https://docs.gradle.org/current/userguide/standard_plugins.h...

[2] https://plugins.gradle.org/

[3] https://github.com/johnrengelman/shadow

[4] at its simplest, something like:

  jar {
    dependsOn configurations.runtime
    from {
        configurations.runtime.collect { zipTree(it) }
    }
  }
[5] https://github.com/danthegoodman/gradle-capsule-plugin

[6] https://github.com/cinchapi/jarsh

[7] https://docs.gradle.org/current/userguide/application_plugin...

[8] https://github.com/pivotal/executable-dist-plugin

[9] https://gradle.org/why/high-performance-builds/

[10] https://github.com/tomwhoiscontrary/PanettoneSpike/blob/mast...

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

#174

Django on Jython

The nice thing about Django is the combo of its model layer and forms library handle the most boring bits of CRUD without generating a bunch of code or being tied into a particular templating library. I'd be tempted to go with this answer if the frontend is going to be a basic forms 'n links affair.

Is there anything comparable to django.forms in Java yet? There wasn't the last time I went looking a few years ago.

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

#175

I don't see how this question is answerable in any meaningful way in its current form. You're going to get a list of basically every JVM framework there is, and you speak nothing of your front-end requirements.

151 replies so far, and it's not even close to every JVM framework there is!

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

#177

Earlier quoted context omitted.

If you're favoring Boot, why not just use a newer version of Grails?

I don't understand the question, beyond the fact that Spring and Grails both had the same corporate sponsorship at one point in the past. Spring Boot is a rapid, flexible, and fairly tight (as far as Java frameworks go) foundation for building Java applications. Grails is a Groovy-based wrapper layer around Spring and Hibernate. So if you want to use Groovy for application development, then Grails is certainly there…

flyhighplato may be referring to Grails 3, which is built atop Spring Boot: https://grails.github.io/grails-doc/latest/guide/introductio...

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

#178
post #28

I'm building something with React + Relay + Sangria and it's working out well so far. There's a sample sangria project showing how to use it on akka-http, and if you write a pure web app like this, you could serve the javascript client from somewhere dumb like S3. Plus with this stack you can plug in react-native apps as well once your server is written.

how are you running React on the JVM - Are you using Nashorn or Rhino here?

Not really related, but Nashorn is dead to me now that I've found J2V8.
Post reply on HN