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

191–200 of 213 posts

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

#191

If Scala is an option, try Finatra 2. Much simpler than Akka* and Play, well done, performant and battle tested (as opposed to akka-http). https://www.youtube.com/watch?v=7dsX0S0WsEk If Scala is not your thing, you should definitely check out Vert.x 3 with vertx-web https://github.com/vert-x3/vertx-examples/tree/master/web-ex...

Unfortunately the documentation is pretty poor. You'll definitely run into troubles with any non trivial app due to the lack of proper documentation (and there is not much third-party documentation around).

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

#193
post #181
post #173

Earlier quoted context omitted.

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 'distributio…

> Maven is obsolete. Just use Gradle. Until something better comes along. Google released Bazel a few months ago, which runs on Linux, tho not Windows, and fully supports JVM-hosted software. It's better than Gradle, so why not move straight from Maven to Bazel? See http://bazel.io/docs/bazel-user-manual.html

Definitely worth considering! I've never used Bazel, so can't give a very helpful answer. Two things discourage me.

Firstly, it's still in beta - 0.1.0 is out [1], and there's plenty to do before 1.0. [2].

Secondly, according to the article on Bazel currently floating up on HN [3]:

"Blaze was designed to work for Google's unified codebase and Bazel is no different. The implication of a unified source tree is that all dependencies for a given software component exist within the tree. This is just not true in the open source world where the vast majority of software packages have dependencies on other libraries or tools, which is a good thing. But I don't see how Bazel copes with this, if at all."

How would i use Bazel to build a project which uses dependencies from Maven Central, or my company's internal repository? It seems that Bazel can fetch jars from Maven repositories [4], but i don't think it does transitive dependencies.

Also, the extension story looks a bit weird [4]:

"Skylark is a superset of the core build language and its syntax is a subset of Python. The following constructs have been added to the core build language: if statements, for loops, and function definitions. It is designed to be simple, thread-safe and integrated with the BUILD language. It is not a general-purpose language and most Python features are not included."

Whilst i'm no fan of Groovy, it's nice to be able to write plugins in a general-purpose language. For example, in one of the build scripts i linked to in my comment, i have a custom build step which processes templates by running another Java program (which was downloaded as a JAR from Maven), and in other builds i've written plugins which call directly into Java libraries (again, which were downloaded as JARs from Maven). Could i do that with Skylark?

[1] https://github.com/bazelbuild/bazel/releases

[2] http://bazel.io/roadmap.html

[3] http://julipedia.meroh.net/2015/04/on-bazel-and-open-source....

[4] http://bazel.io/docs/build-encyclopedia.html#maven_jar

[5] http://bazel.io/docs/skylark/concepts.html

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

#194

Earlier quoted context omitted.

I also highly recommend Aurelia. It's a fantastic and future proof front-end library. Out of curiosity, why Spark over Scalatra? ( http://scalatra.org/ )

What makes you say it is future proof?

By future-proof I didn't actually mean forever. It heavily makes use of es6/es7, so it was designed with "forward-thinking" design choices (forward thinking is what I intended when I wrote future proof). Right now it relies on babel, but as es6/es7 gains adoption it'll grow out of requiring it. Similar to Angular 2.0, which is also being developed with a forward thinking mindset.

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

#195

Try Takes Framework: www.takes.org

Despite its four fundamental principles this framework does not read well and I personally wouldn't recommend it.

Class names with Ft or Bk or Rs or [add two letters] prefixes don't work for adoption and clarity of expression.

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

#196

Groovy / Grails. It's what we chose to base all of our products on and it has worked out really well for us. If there's any complaint / negative, it might be that the ecosystem is in a bit of a "state of flux" with Pivotal dropping support for Groovy and the language moving to the ASF, etc. One bit of fallout from that, for example, is that the GGIDE isn't available for Eclipse Mars yet (or it wasn't last time I look…

I'm hoping v3 support turns a corner soon - IntelliJ 15 public preview now supports Grails 3. I'm thinking this may get more people back in to it, and more contributions back. It's been in a limbo state since April, and seeing jetbrains support it (finally) gives me more reason to continue to support it.

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

#197

Earlier quoted context omitted.

How do you feel about Spring Boot? It's a very similar concept to Dropwizard: one project that does all the basics out of the box. Include JOOQ, if that's what you want.

Spring boot is fine, but it was basically created as an answer to Dropwizard, so why not just use the original thing?

It works great for me. I'm not into original-er-than-thou as a way to settle engineering questions.

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

#198

Why are you tied to using the JVM?

Because of Scala, in my case, and because I can run React.js server side in the JVM. And because it's fast.

Edit: Oh I misunderstood your question. (Did you perhaps edit your comment, added "tied to"? Didn't notice that the first time)

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

#199
post #89

Earlier quoted context omitted.

I agree. And I'd add that the continuous compilation of the Play framework allows for a great, fast workflow. Even in combination with non-JVM compilation like for Typescript. The last version comes with Slick integration which brings Ling-for-Sql style persistency to the JVM. In combination with support for Postgress JSON persistency that makes for a great fast prototyping stack.

I highly, highly recommend squeryl over slick. Much more readable as you're basically writing SQL in scala; you don't have to translate constantly between orm methods and SQL.

+1 for Squeryl!!!

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

#200
post #193
post #181

Earlier quoted context omitted.

> Maven is obsolete. Just use Gradle. Until something better comes along. Google released Bazel a few months ago, which runs on Linux, tho not Windows, and fully supports JVM-hosted software. It's better than Gradle, so why not move straight from Maven to Bazel? See http://bazel.io/docs/bazel-user-manual.html

Definitely worth considering! I've never used Bazel, so can't give a very helpful answer. Two things discourage me. Firstly, it's still in beta - 0.1.0 is out [1], and there's plenty to do before 1.0. [2]. Secondly, according to the article on Bazel currently floating up on HN [3]: "Blaze was designed to work for Google's unified codebase and Bazel is no different. The implication of a unified source tree is that all…

You could be right about Bazel's unsuitability for open source software.

> The following constructs have been added to the core build language: if statements, for loops, and function definitions

The whole point of using a declaratively-configured build product rather than procedural scripts is to simplify the logic and be easily extendable. Maven provided the declarative DSL and removed totally the procedural language so you needed an addon like polyglot-maven to do anything "out of the box". Gradle then added the whole procedural language back in to be used with the DSL, but it's hardly used as most build scripts out there are just standard 30-liners. Perhaps Bazel's way of providing just enough procedural features (sequencing, selection, iteration, subroutines), and no more, with the declarative DSL is the best mix.

Post reply on HN