Ask HN: What stack would you use to build a CRUD web app on the JVM today? - networked
======
neya
I second Play Framework. Have used it and Scala is a very nice language to
learn. If I had invested in so much into the JVM, Play Framework would be it.
But, if it's just a simple CRUD app, and if you had a choice, I'd recommend
you to give Ruby on Rails a try. Hope this helps!

~~~
jakozaur
Scala and Play is a great choice. Another good Scala framework is Lift:
[http://liftweb.net/](http://liftweb.net/)

If JVM is not a must, consider using Meteor.

~~~
pookeh
+1 for Meteor. We've been using Meteor for about 8 months now and are amazed
with the productivity and no-boilerplate code. To give some context, we were
previously a JVM-only shop. In the past we've used Spring+Hibernate+GWT for
one project, Ninja for another project, and a full blown custom stack + Dojo
client side in a third project.

If JVM is your only choice because you want to connect to legacy Java API,
consider wrapping the Java API with REST interfaces and use them with Meteor.

~~~
duaneb
How do you find the GC/profile/coverage/tuning of the server side node process
compared to the jvm?

~~~
pookeh
TBH, we didn't have to do much performance tuning. The Meteor app we are
building is heavy on the database CRUD (like real heavy) so there is not much
to tune code-wise other than define good data structures for your db. And
really, if you have to do any GC tune up for your node app, you really have to
ask yourself if there's something you could do instead in your code first.

I must admit that initially it seemed that node js profiling sucks, but it's
just that we are still not used to the internal intricacies of V8. When we did
profile a couple of times (we use Webstorm so just used flag in the run
config), there were too many things out of the context of our code showing up.
I think if you show a snapshot of YourKit to someone who hasn't worked with
JVM before they would have a similar reaction.

------
ff_
Definitely Clojure with http-kit [1]. Easy to use, minimalist and supports
websockets.

However, it depends from your use-case. Could add some detail please?

[1]: [http://www.http-kit.org/](http://www.http-kit.org/)

~~~
147
I used to be a big fan of http-kit, but it seems like it's not maintained
anymore. I've since moved on to Immutant 2, which seems to offer much more.
The primary difference between Immutant 2 over 1 is that it's not monolithic
and you can just import what you need. And I believe it's faster too.

Also, yesterday I announced that I am writing a book on developing REST API's
in Clojure, if anybody's interested in learning:
[http://christopherdbui.com/announcing-practical-rest-apis-
in...](http://christopherdbui.com/announcing-practical-rest-apis-in-clojure/)

~~~
Scarbutt
looking up to it!

------
vbezhenar
Spring MVC + Hibernate. I'm familiar with those libraries and they provide
almost everything I usually need.

For frontend I would choose either JSP or Thymeleaf, both are good, depends on
your taste and whether you're writing HTML markup. Another option is a
JavaScript-powered SPA website. You have plenty of choices there.

And I highly suggest using Intellij Idea Ultimate + JRebel. Those technologies
provide tremendous productivity boost and I can't imagine working without
them. Though they are not free (AFAIK you can get JRebel for free).

~~~
jeremyjh
For people whose impression of Spring and Hibernate was formed a decade ago,
its really worth another look now. You can completely manage them with
annotations in your code and lots of the boilerplate will be generated for you
based on naming conventions.

JHipster ([https://jhipster.github.io/](https://jhipster.github.io/)) provides
a Yeoman generator to make a basic project template as well as generate
entities and screens using an Angular, Spring Boot & Hibernate stack which
makes it super easy to get started with all of these components.

An open source alternative to JRebel is
[https://github.com/dcevm/dcevm](https://github.com/dcevm/dcevm) \- it works
great with Java 8, Intellij, Spring & Hibernate.

~~~
userbinator
It doesn't change my impression much if the answer to "lots of boilerplate" is
to use another tool to generate it automatically...

~~~
jeremyjh
Actually the example I was thinking of is the finder methods which require
only an interface definition conforming to a naming convention. Bytecode is
generated at runtime - there is no generated source to manage.

Not much of what Jhipster generates could be considered boilerplate - the
application code is pretty DRY. I've used Rails off and on since 2005 and it
is fairly comparable in that respect at this point though Java is more verbose
of course.

~~~
mercurial
It's difficult to take Spring seriously after trying Jersey. Resource
traversal is a powerful concept. Also, recent or not, Spring still comes with
way too much complexity and magic. I'd really go for something more
Sinatra/Flask-like. Haven't tried Dropwizard, but from what I saw it looks a
lot more sane.

~~~
jacques_chester
> _It 's difficult to take Spring seriously after trying Jersey_

I'm using Spring Data REST at work. We have a dozen endpoints. We've had to
write code for one of them.

The rest were generated by introspecting our models. Complete with HATEOAS
links, sorting, searching, paging and HAL. It made a whole bunch of work
simply disappear -- even compared to Rails.

------
aSig
Spring Boot backed with Postgres and Maven to wrap it all up. Spring Boot is
really years of distilled knowledge of creating web servers in Java. Its
opinionated but for good reason; you'll very quickly get everything you need
for a RESTful API and there's extensions for almost everything you'd need.
Need to work with websockets? Just add a few lines to your POM. Need
scheduling? Include an annotation on your main class. It really is a solid
framework.

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

~~~
StevePerkins
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 for you. However, I don't think it's the most competitive
option. I think Groovy's great as a scripting language, and I use it for
things like automated testing, but I wouldn't enjoy using it for primary
application development because it's not a statically-typed language.

Although recent versions of Groovy allow you to designate typesafe "areas"
within your code, it is still fundamentally non-typesafe. Because of this,
tooling is always going to be weaker than it is for typesafe languages.
IntelliJ is probably the best Groovy IDE out there, and it's still frustrating
to work with because it can't detect autocomplete options most of the time.

If you're doing development on the JVM in the first place, then odds are you
favor static typing. Plain Java, or Scala, or most of the fringe options like
Kotlin or Ceylon. If you're in the minority camp who want to use a language
with dynamic typing, even THEN there are better options than Groovy for
application development. JRuby has a much broader and more active community,
and Clojure will give you more "Internet cool points" on HN or Reddit or
wherever.

Finally, the last time I looked at Grails, it was FAT. Building an application
took forever. I'm sure they've (hopefully) optimized or rebuilt things since
then. However, since it's a wrapper around Spring and Hibernate, it's never
going be any lighter or faster than Spring and Hibernate.

I don't mean any disrespect to Groovy. I've been using it forever, and it
comes in handy with certain use cases. However, it's primary niche is being
the dynamic JVM language that most "enterprise" shops have become comfortable
with... and so if you're trapped in an "enterprise" shop and are dying to use
something other than plain Java, it's the thing you'd most likely be allowed
to use.

~~~
monksy
For the most part you don't need to rebuild to test your changes. Live reload
works.

------
dommer
I would not start with technology stack and build around them. You look at
your use cases and build out. Pick your frameworks and databases judiciously
and as late as possible.

Read: [https://blog.8thlight.com/uncle-
bob/2012/05/15/NODB.html](https://blog.8thlight.com/uncle-
bob/2012/05/15/NODB.html)

Read: [http://www.amazon.co.uk/Growing-Object-Oriented-Software-
Gui...](http://www.amazon.co.uk/Growing-Object-Oriented-Software-Guided-
Signature/dp/0321503627)

[EDIT] Removed the unnecessary/unhelpful opening statement.

~~~
inglor
Just because uncle Bob says something doesn't mean it's true.

Frameworks and stacks provide templates for building CRUD apps. Building CRUD
apps (read: database skins) isn't a big technological challenge most of the
times anyway. So picking a stack that abstracts most of it for you could be a
great help to only focus on the parts you care about.

Not every project requires astronaut architecture and grand design. Half the
internet runs perfectly fine without these considerations.

Scaffolding a project through the tooling of a framework (tooling matters!)
and having something up in a day instead of philosophical debates about your
data is huge. Having something up in production super fast because you didn't
stop to think about architecture is perfectly fine for 95% of software
projects that are just CRUD.

~~~
dommer
My inclusion of these two reading resources were only meant as examples. The
reader is still required to make their own mind up.

I haven't suggested astronaut architecture; the question didn't indicate the
size/scale/importance either.

50% of the internet runs perfectly fine without consideration...wow! Have you
looked at all the source code yourself to make such a ridiculous conclusion.

Tooling does matter, but I'm suggesting the point of focus to start with is
the requirements.

~~~
inglor
As a data point, 20% of the internet runs WordPress [1], think these people
spent a lot of time thinking about architecture.

A lot of time the problem being solved _is_ in fact simple enough and easy
enough to solve without thinking about architecture, not everything is a hard
problem - and there is nothing noble about solving things over and over.

The point I was disagreeing with was "Pick stacks as late as possible". _If_
you have a large project by all means do that, if you're just building a REST
API in microservice architecture, or you're building a blog or something
that's fairly simple to model - you're perfectly fine picking a framework you
like first.

[1]
[http://w3techs.com/technologies/overview/content_management/...](http://w3techs.com/technologies/overview/content_management/all/)

~~~
dommer
I'll skip the flame about WordPress developers as I don't know any, or, viewed
their work.

If you think building micro service architecture can be done without
consideration I'm lost for words.

The question–as I've been rightly reminded–was 'CRUD Web App in JVM';
furthermore, we now know that the domain part of the application is already
done, so my comment is moot.

That just leaves CRUD, Web, and JVM.

------
Borkdude
I would pick Clojure. Here is a CRUD web app example in Clojure(Script),
backed by a RDBMS: [https://github.com/borkdude/full-stack-clojure-han-
okt-2015](https://github.com/borkdude/full-stack-clojure-han-okt-2015)

If you want to learn more, I'd check out
[http://www.luminusweb.net/](http://www.luminusweb.net/).

------
Gonzih
Clojure + ClojureScript + Reagent/Om as an abstraction on top of React

------
davidkellis
Backend:

Scala

Spark - [http://sparkjava.com](http://sparkjava.com)

ScalikeJDBC - [http://scalikejdbc.org](http://scalikejdbc.org)

Postgres

Coming from Rubyland (and AR specifically), I despise writing a bunch of
dao/repo code, so I've resorted to codegen-ing my daos/repos.

Frontend:

Aurelia - [http://aurelia.io](http://aurelia.io)

~~~
thinkdevcode
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/](http://scalatra.org/))

~~~
fokinsean
What makes you say it is future proof?

~~~
jethro_tell
I assume he's been to the future, that's the only way one could know.

------
slantedview
Probably playframework [1] or maybe Spark [2] if it's a really simple app,
along with jOOQ for persistence [3]. If I was just writing a REST API, then
Dropwizard [4].

The reason I would not choose Spring despite the fact that it is better now
than it was 10 years ago is because it still approaches things with the wrong
mindset, IMO. The reason JVM technologies are so loathed is because of the
stupid, pointless complexity that's so pervasive, where Spring is/was the
poster-child. Building generation after generation of newer APIs on top of the
old stuff doesn't remove the fact that the old stuff is still there. Hiding
complexity with code generation doesn't remove the fact that code still needs
to be generated. And the same with annotation driven programming. And
JPA/Hibernate/etc.

Simplicity isn't about hiding mountains of legacy complexity under a shiny new
API, or annotations, or code gen - it's about having a stack that is
understandable and easy to use from top to bottom without requiring magician's
toolbag of tricks to hide the complexity. I get the feeling that most JVM
developers don't even know what this looks like - Dropwizard is a great
example. Other languages/ecosystems tend to not have this legacy baggage, so
you can't blame their developers for thinking that the mainstream JVM
frameworks are ridiculous. Because they are.

/end-rant

[1] [https://www.playframework.com/](https://www.playframework.com/)

[2] [http://sparkjava.com/](http://sparkjava.com/)

[3] [http://www.jooq.org/](http://www.jooq.org/)

[4] [http://www.dropwizard.io/](http://www.dropwizard.io/)

~~~
reitanqild
I really like annotations.

And I really enjoy working on JavaEE.

For anyone who still thinks it means loads and loads of boilerplate code but
wants to check, read Adam Bien, check out the TomEE examples, the Wildfly
examples etc.

~~~
smoyer
This is so true! ... I was ready to give up on J2EE (prior to the name change
and version 1.5). Java EE 7 is wonderful and more tools are coming. It's no
longer an XML configuration nightmare with 10 classes to define all the
required interfaces and implementation.

To reduce even more boiler-plate, I've recently started using project Lombok
[1]. Code generation provides all the standard methods and allows JPA @Entity
objects or JAX-B objects to be completely declarative. Start with @Data and
@Value.

[1] [https://projectlombok.org/](https://projectlombok.org/)

~~~
slantedview
My argument isn't about using tools that reduce boilerplate through codegen or
annotations, it's to use tools where boilerplate doesn't exist. Why do you
need JPA? Why do you need EE? Chances are, you don't.

~~~
reitanqild
Boilerplate and annotations are two wildly different beasts on my
understanding :

Boilerplate is things I have to repeat mindlessly every time I want to do
something.

Annotations on the other hand usually is one single line of code.

Disclaimer : not a native English speaker although I am fairly sure about
this.

Edit: look at hodao from the tomitribe GitHub account. Or DeltaSpike from
Apache.

------
mindcrime
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 looked).

Still, it works, it's easy to learn, there's a rich assortment of plugins for
adding functionality, GSP's are nice, it's easy to make custom taglibs, etc.,
etc.

~~~
anthony_d
I would have agreed till Grails 3. It doesn't work in so many different ways
and it's never clear why. The reload stuff seems completely broken if you have
dependencies that use many Java 8 features.

~~~
mindcrime
Aah, that may well be a fair point. We haven't upgraded to the 3.x series yet,
so everything I said should be taken as referring to 2.x.

~~~
anthony_d
I had about 6 months experience with Grails 2 and loved it then got forced
into updating to 3. Now we're trying to replace it completely.

------
dcposch
Many of these suggestions here sound really complicated.

At Addepar, we use plain Java. A REST API can be served with Jetty + Jersey.
We have zero XML configuration of any kind. JOOQ for DB access. HikariCP for
connection pooling.

Use Postgres, if possible.

Start with the data models and keep it simple. Favor composition over
inheritance. The inheritance-heavy Java you see in old parts of the standard
library and certain "Programming 101"-type courses is really bad, in my
experience. Use Java 8. Modern Java can be v clean.

If you're starting a new project, use buck as the build system. At Addepar, we
migrated from Gradle to buck, and our builds became less flaky and 2x-5x as
fast. The build files are cleaner and more concise.

~~~
cryptos
Composition is very comfortable with Kotlin. I think one of the reasons why
inheritance is used so much in Java, is that composition always leads to a lot
of boilerplate code. Kotlin (and Scala) fixes it.

------
humbleMouse
Grails/groovy with postgre. Grails is so ridiculously simple to set up and
code with... you can literally parse JSON out of a request and map it to an
object with "Object yourObject = request.getJSON". Then you can save it with
another line like "yourObject.save()".

~~~
andretti1977
I agree, building crud in grails is really fast. I'm just sorry grails is not
so much adopted.

~~~
humbleMouse
Honestly it blows my mind why more people don't use it. Grails wraps
Hibernate/Spring, the two most robust java abstractions that exist. Then, it
adds the out of the box ability to do things like parse JSON, re-direct,
handle AJAX calls easily, manage session object, ect. ect. In my experience
coding web apps there is nothing that even comes close to touching the
simplicity of Grails.

~~~
reitanqild
Obviously I was unlucky : my experience was things didn't work and was next to
impossible to reason about. This was 4 years ago and I went with (and burned
myself on) Play Framework.

------
carsongross
SparkJava ([http://sparkjava.com/](http://sparkjava.com/)) + jooq
([http://www.jooq.org/](http://www.jooq.org/))

Minimalist and powerful enough. It's as close as you can get to sinatra +
active record in the java world.

And, of course, I would use intercooler.js for the front-end:

[http://intercoolerjs.org/](http://intercoolerjs.org/)

to keep things simple.

~~~
balamaci
And to go even lighter I use
pippo([https://github.com/decebals/pippo](https://github.com/decebals/pippo)).
I like the modular way that allows me to tailor my apps to be <1MB final size.
Really helps with lightning fast deployments on my many DigitalOcean smallest
512MB instances.It also works great on raspberry pies - I was using nodejs
webapps until pippo because they were lighter on resources(I rather hate js
and nodejs and hence the praise for pippo) . I also pair it with jooq for db
access when needed.

~~~
ww520
Pippo looks pretty sweet. How does it compare to Spark?

~~~
reactor
I'm trying pippo for the last couple of weeks, its quite lightweight and
really fast. I could customize it for whenever the need arises, better than
sparkjava. For eg: I couldn't customize the Jetty server params with
sparkjava, I could with pippo.

------
raugustinus
[http://www.dropwizard.io/](http://www.dropwizard.io/) combined with reactjs

------
flaie
Definitely Spring Boot with spring-data (if it supports your database/nosql
system) since you're going to do a CRUD app, it will manage a lot for you. Add
it spring-data-rest and you've got your models exposed on REST for free. If
you want to secure some REST operations, spring-security got you covered.

Then on the client side you can add some hype using React or what's hot at the
moment. Joke aside, on the server side Spring is solid, the whole thing is
well engineered and it got you covered on every aspect of this kind of app,
and then more.

------
cweagans
Probably start with `rm` of the current project and start over with something
else.

I call it rm-driven development. It'll be a thing in a year.

In all seriousness, I'd probably look at Scala and Play if JVM was absolutely
required, but I'd first look into why that requirement is in place and if the
requirement can be removed.

------
steven2012
Does anyone have any opinions on DropWizard as a framework? Is it the
minimalist web framework for Java, similar to Flask for Python?

~~~
siavosh
I've heard good things about it, but my understanding is it's ideal for
creating REST endpoints, so it doesn't have some standards MVC stuff out of
the box. Spark is a JVM version of Sinatra which may be closer to what you're
looking for.

~~~
twic
"The dropwizard-views-mustache & dropwizard-views-freemarker modules provides
you with simple, fast HTML views using either FreeMarker or Mustache":

[https://dropwizard.github.io/dropwizard/manual/views.html](https://dropwizard.github.io/dropwizard/manual/views.html)

"The dropwizard-forms module provides you with a support for multi-part forms
via Jersey":

[https://dropwizard.github.io/dropwizard/manual/forms.html](https://dropwizard.github.io/dropwizard/manual/forms.html)

If you can render HTML in responses and accept multipart/form-data in
requests, does Jersey become an adequate MVC framework? If not, what is it
missing?

------
jamn333
Grails hands down. I work on an enterprise team and every time we pull a
developer in who has no experience with it they fall in love. It's just so
easy to work with. We spend maybe 2% of the time configuring something and 98%
solving the business problem.

------
hobarrera
If I _had_ to use JVM today, I'd try JRuby + Ruby ON rails:

[https://github.com/jruby/jruby/wiki/JRubyOnRails](https://github.com/jruby/jruby/wiki/JRubyOnRails)

~~~
stevepike
I actually did this. Our main app is a rails app with MRI, which has worked
well but comes with a bunch of opts complexity (even with heroku / AWS you're
still setting up background workers, caching, queues, etc).

We built an internal webapp using torquebox
([http://torquebox.org/](http://torquebox.org/)). It's kind of a weird project
(run your rails app on JBoss of all things), but it's actually worked out
_wonderfuly_ for us. I know it's all the rage to build your app out of a bunch
of separate services right now (and the next version of torquebox is split out
into smaller pieces), but for our small team wrapping all the stuff you need
for an app up into one box has been great. Torquebox gives you:

\- In-memory cache

\- Message queue

\- DSL for defining services (can be singletons or not) which torquebox will
ensure are running. Your services are plain ruby classes but they can access
to your rails environment.

\- Threads! Coming from MRI it's really nice to "background" some things via
threads.

\- Mount other rack apps at "/app" and they share the environment (e.g.,
queue)

It's been running rock solid for a year with basically no ops maintenance. I'd
encourage anyone building webapps to read through the torquebox documentation,
it's clearly written by a team of people with experience deploying and
maintaining "serious" stuff.

------
Mikera
Clojure on the back end and ClojureScript on the front end.

Some reasons:

1\. It's a proper full-stack solution. You can share code between client and
server if you need to.

2\. There is some amazing front end technology (Om, figwheel etc.) that can
change the way you think about front end development.

3\. It is hard to match Clojure for productivity / interactive development.
You can code almost everything at the REPL without restarting (no restarts or
edit/compile cycle time needed)

4\. You can use all the Java libraries very easily (although idiomatic Clojure
wrappers exist for almost everything you are likely to need)

5\. The usual Clojure reasons: functional programming, concurrency,
immutability, Lisp macro etc.

------
jareds
Grails, I really like Groovy as a language. Grails provides a lot out of the
box and is good enough performance wize for small to medium sites with no
tuning.

~~~
sandGorgon
this is a comment posted yesterday criticizing the management of Groovy -
[https://news.ycombinator.com/item?id=10293508](https://news.ycombinator.com/item?id=10293508)

~~~
mindcrime
Meh... vorg posts on nearly every thread that mentions Groovy and rants about
all the perceived wrong-doings in the Groovy community. Some of his points
have some merit, but he seems to tend to make mountains out of mole-hills.

~~~
vorg
You didn't comment on any of the specifics mentioned in that linked-to
comment, instead you attacked my behavior, just like one replier to that
comment.

You mentioned Groovy moving to the ASF in another comment above, but if only
two people control the DNS name and physical access to that server in Germany
hosting the websites, receiving the Nabble mail archive and Apache website
redirects, creating the phantom downloads from Maven and Bintray, etc, then
the list of committers and mentors at ASF for Groovy is meaningless. Because
Groovy _isn 't_ really protected by the ASF guidelines, its future is
uncertain.

As for Grails you also mentioned, Grails 3 also has an uncertain future, what
with so few people upgrading from version 2, just like with Python version 3.
Grails 3 bundles all of Gradle, and its business case seems less about
modernizing Grails 2 than about its founder wanting to muscle in on the Gradle
consulting market, just like he did with Spring in Grails 1, until
SpringSource bought his company to protect their cashflow. He's trying the
same with Gradleware.

~~~
mindcrime
_instead you attacked my behavior, just like one replier to that comment._

Have you considered that your behavior might be at issue then? Seriously man,
you seem to go out of your way to find any and every thread that mentions
Groovy in any way, and then launch into your rant about all the evils of the
Groovy community.

The thing is, I _said_ that you have some merit in what you say. But the
repetitiveness and the vitriolic presentation make you look like somebody who
has an axe to grind or something, instead of a dispassionate observer.

 _You mentioned Groovy moving to the ASF in another comment above, but if only
two people control the DNS name and physical access to that server in Germany
hosting the websites, receiving the Nabble mail archive and Apache website
redirects, creating the phantom downloads from Maven and Bintray, etc, then
the list of committers and mentors at ASF for Groovy is meaningless._

When existing, long-established projects move to the ASF, they always deal
with shit like this. It takes time to sort this stuff out, that's why there's
an incubator. And if it doesn't work out, then so be it. At that point, I'd
reconsider my position of advocating for Groovy. But I'm not going to rush to
judgment and focus on all the negatives, which is what you seem to do.

~~~
vorg
> you seem to go out of your way to find any and every thread that mentions
> Groovy in any way, and then launch into your rant

The most significant thing you've really said here is that I generally post
comments under my own name, as I suspect you also do, given how active your
"mindcrime" user is and the implicit assumption in your above comment that
you're seeing the entire picture by looking at who's posting comments. Have
you considered that other "entrepreneurs" involved with Groovy keep hundreds
of HN logins each to obfuscate their mischief here and engage in illicit
surveillance of people whose comments they don't like? This I don't say in my
comments, instead I keep what I say seemly and do it in my _own name_. It's
_because_ I use my own name that I "seem to go out of my way to find any and
every thread ..."

~~~
mindcrime
_Have you considered that other "entrepreneurs" involved with Groovy keep
hundreds of HN logins each to obfuscate their mischief here and engage in
illicit surveillance of people whose comments they don't like?_

Honestly? No, the thought never crossed my mind. And now that you mention it,
it doesn't sound terribly likely to me. Not "hundreds* of such people anyway.
Maybe two or three. Why do I say that? Simply because Groovy just doesn't come
up that often to begin with. And a decent percentage of the time, when it
does, I'm the one bringing it up, and know where I stand. And while
"mindcrime" clearly isn't my birth name, my HN account is clearly linked to my
real world identity, so no one can really claim that I'm trying to hide
anything here.

One other person here to mentions Groovy / Grails occasionally is @mgkimsal,
and I also know him in the Real World, and have no suspicion that he's up to
anything nefarious.

That said, people never cease to surprise me and clearly some people post on
HN largely for commercial gain. I don't think anyone questions that. I just
don't see what you seem to see, in terms of large numbers of users here trying
to manipulate the discourse around Groovy in particular.

~~~
vorg
> other "entrepreneurs" involved with Groovy keep hundreds of HN logins each

> post comments under my own name, as I suspect you also do

I would agree probably 2 or 3 people -- I _never_ said "hundreds" of people,
and I specifically said you post comments under your own name, _not_ the
opposite.

------
elliottburris
I'm going to go with a unique answer here:

Java + MySQL, using these awesome libraries

\- Bowser (webapp):
[https://github.com/mirraj2/bowser](https://github.com/mirraj2/bowser)

\- EZDB (MySQL wrapper):
[https://github.com/mirraj2/ezdb](https://github.com/mirraj2/ezdb)

\- Ox (IO and Json):
[https://github.com/mirraj2/Ox](https://github.com/mirraj2/Ox)

These bad boys make writing Java wonderful again.

------
playing_colours
If that's only me or me and a few experienced Scala developers I would use
more cutting edge stuff - Akka HTTP. If the team is less experienced or have
more experience with traditional web apps - I would go with Play framework.
It's well supported, not difficult to get into.

~~~
AdieuToLogic
A nice complement to Akka is Spray.io[1]. Not really meant for CRUD type apps
that is the subject of the original question, but very well suited for REST
systems.

1 - [http://spray.io/introduction/what-is-
spray/](http://spray.io/introduction/what-is-spray/)

~~~
playing_colours
As redtuesday correctly noticed, Akka HTTP is a successor of Spray.io. Mathias
Doenitz, the main author of Spray.io, worked on Akka HTTP as well. They are
similar in many places, just powered by different "engines". Akka HTTP is
built above new Akka Streams, while Spray.io is powered by plain Akka. But,
for example, routing DLS is very similar. Our main API is in Spray, but when I
tried Akka HTTP for a new microservice, I actually reused most of things from
our customised stuff above Spray.

------
notinventedhear
Also agree with the combination of Play + Scala for flexibility and ease of
use.

------
pigpen34
Not a popular opinion here, I'm sure. But I would no doubt use a newer CFML
platform, either ColdFusion 10+ or Lucee.

------
brianwawok
Another vote for Play + Scala here. What I built my last app on, and plan to
keep building on it.

For simple CRUD it may be overkill, but it scales nicely for when you go past
CRUD.

~~~
narrator
Slick has a bit of a learning curve, but it's really a thing of beauty once
you figure it out. I never make syntax errors in queries any more. Getting the
code generation from the DB model going is a must. It makes things go really
fast, especially for a large data model.

------
granchi
Play Framework (Java or Scala)

------
timclark
ReactJS + DropWizard + JDBI (or JOOQ) if you like JAX-RS.

ReactJS + Spark framework (or Vert.x 3 or Ratpack) + JDBI if you don't like
JAX-RS.

I don't like JAX-RS, but it is hard to beat DropWizard if you do.

------
a-saleh
It depends.

If I were to work mostly alone on a smaller project, I would use
clojure/clojure-script, because I used it at my work for a year and really
liked it.

If I were to work with more people, I would first ask them.

Do they have dislike for dynamic typing? Scala+Play sounds good.

Are they really comfortable with EE java? Spring MVC + Hibernate + JSP ...
e.t.c

------
emsy
First of all, I have to agree with dommer. You pick the stack depending on the
use case.

That being said, in most use cases I've encountered I would've gone with a
REST API on the server for CRUD operations and an SPA framework on the UI
side. I've found that the use of a classical UI Framework like Play, Grails or
JSF make seperation of UI and business logic harder, rather than easier.
Especially Grails is a huge vendor lock in and the framework leaks through all
layers.

To "scaffold" your REST+SPA application, I've found Spring Datas automagic
generation pretty useful, but you're free to use any technology you like.

~~~
jamn333
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.

~~~
emsy
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, but then, why should I use Grails in the first
place?

~~~
jamn333
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.

------
stefs
i recently wrote a small blog engine in vert.x
([http://vertx.io/](http://vertx.io/)). i'm not fluent with reactive
programming yet (so i didn't use RxJava), but the callback hell was manageable
enough. among the upsides are the seamless integration and handling of
websockets. the blog engine is a bit of an outlier though because it's
embedded and fully single threaded. there are a lot more advantages if you
leave out the embedding, like several more languages (several languages with
interpreters available on the JVM).

~~~
slantedview
Vert.x is fantastic.

My honest opinion is that JVM folks love complexity though. It's a mix of
popularity, job security and good marketing that allow the traditional bloat-
powerhouses to remain popular while technologies like Vert.x remain criminally
under-utilized (see the rest of this thread for evidence). I don't know how or
if this will ever change, but the downside for the JVM ecosystem overall is
that people associate the JVM with things like Spring and Hibernate rather
than things like Vert.x. And that's a shame.

------
sscarduzio
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](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...](https://github.com/vert-x3/vertx-examples/tree/master/web-examples)

~~~
cryptos
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).

------
ajg360
Web based?

Apache Wicket ([http://wicket.apache.org/](http://wicket.apache.org/)).

Java + HTML. Can't get any simpler than that. Java 1.8.0 makes me not miss
Groovy at all.

------
ramkalari
Play Framework

~~~
jroper
I like Play too.

~~~
wsargent
So much great code being checked in.

------
Pyppe
In scala-land, I've got experience from Scalatra, http4s and Play framework.
We've recently migrated a large Scala project from Scalatra to http4s. I would
not recommend using the current 2.x version of Scalatra. The biggest issue
I've got with it is it's lack of type-safety. Each REST-endpoint in Scalatra
is basically a function from Request to Any. So you can return anything and
cross your fingers it works runtime (see e.g.
[https://github.com/scalatra/scalatra/issues/534](https://github.com/scalatra/scalatra/issues/534)).
I believe many of the core Scalatra-contributors are nowaday much more active
in development of the http4s (see
[https://github.com/scalatra/scalatra/graphs/contributors](https://github.com/scalatra/scalatra/graphs/contributors)
vs
[https://github.com/http4s/http4s/graphs/contributors](https://github.com/http4s/http4s/graphs/contributors)).

I really like the design of http4s; services compose really nicely -- each
service/server is just a partial function from Request to Response. It
utilizes Scalaz Tasks for asynchronous opeartions / streaming. On the other
hand, I would not consider http4s very mature yet. We've encountered some
issues during refactoring from Scalatra to http4s. Also, they offer support
for both Servlet- and Blaze NIO -servers, but I've had the feeling that
Servlet-support feels a bit like second-class citizen. Maybe not so thoroughly
tested (I'm just spitballing here)? But still.. I like it and based on current
experience would not advice against using it. Also, I've had great help from
their Gitter-channel. :)

Play framework, is nowadays pretty mature. I've used it in multiple projects,
and love that nowadays it's sbt compatible (just declare the dependencies) --
I think in the past you had to download a separate distribution for using it.

I think http4s and Play are both excellent choices. Play feels a bit bloatish
and maybe opionated compared to http4s, but on the other you've got everything
ready (play-ws, play-json, play-twirl etc.). Once http4s gets a bit more
mature, I believe it'll be awesome! :)

P.S. With http4s my current recommendation would be: Argonaut for JSON, and
Slick for RDMS-support (Postgres all the way).

------
estefan
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.

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

~~~
estefan
Sangria is scala. React is the client in the browser. That doesn't run on the
JVM.

~~~
sandGorgon
can you talk a bit more ? How do you write your views and integrate them with
sangria. I'm coming from nodejs .. where everything is JS, so I'm trying to
understand how this stack works.

~~~
estefan
Sangria is a scala GraphQL server. Facebook released an initial reference
implementation in javascript, but I wanted the type-safety that scala gives.
If you're more comfortable with JS you could check that out. See
[https://facebook.github.io/relay/](https://facebook.github.io/relay/).

With GraphQL you don't write views per se, but you make data available. The
client can pick and choose which of the exposed attributes it needs to render
a view. So if you have, say, a user profile page, you might use relay to
declare that you need something like:

    
    
        user(id: $userId) {
          username
          age
        }
    

Then relay will hit your graphql server and add this data to your react props.

It's a similar thing with mutations - you expose operations through your
server and then relay handles calling it with the necessary data, and
propagating back the response into the UI.

I've found this approach to be very powerful and quick to develop in (once I
got my head around it). With REST, you have to keep on adding new endpoints or
fiddling with your server if you need more attributes from it. E.g. say you
also want the user's gender. With traditional REST you'd need to make this
change in your client (to request that extra data) and update your server to
expose it. Or perhaps you'd add a new endpoint that returned more data about a
user. Then you may also need to decide what happens with legacy clients.
Should they fail if they receive extra, unexpected data, or do you version
your API, etc.?

With GraphQL you can choose to expose all of the different attributes on your
user model (with authentication/authorisation, etc as appropriate) in-advance,
and then if clients need the gender, they can just request it via relay.

After I tried writing an app using REST and continually feeling like I was
walking in mud, this is a real breath of fresh air, and I feel productive
again. I definitely recommend checking it out.

~~~
sandGorgon
thanks for that!

I'm assuming your views are written in React.js - how does that get served to
your clients ? does the Scala relay server serve it ... or do you have a
separate client webapp ?

~~~
estefan
Yeah the views are all just react.js. The JS for the webapp is dumb so can be
served by S3 (i.e. no server-side rendering). It's basically REST++ - a pure
server that just serves data (sangria/graphQL server) and a decoupled client
(which in my case happens to be a react web app for now).

------
elchief
Server-generated HTML or browser-generated HTML?

Spring Data REST makes a good HATEOAS JSON REST api for you, somewhat
automatically.

Spring Data JPA alleviates the drudge of writing your DAO layer.

Spring 4.2 does websockets and server-sent events nicely.

PostgreSQL 9.5 (out soon). Regular JDBC driver for regular stuff, but try the
pgjdbc-ng driver to listen to NOTIFYs.

------
metacity
Ninja Framework
([http://www.ninjaframework.org](http://www.ninjaframework.org)) with Ebean
ORM ([http://ebean-orm.github.io](http://ebean-orm.github.io)). Ninja's
SuperDevMode rocks.

------
Tinned_Tuna
It depends on your needs, and what you want to do. If you're a big Pythonista,
perhaps Jython is worth a look in. Lisper? Look more towards Clojure. Need to
be able to hire developers? Plain Java will help you on that front.

Often, choosing a JVM language does not lock you into that language, as
there's good interoperability. Be prepared that the first choice of language
for a project might not be the best choice.

In response to the question, Java, Spring, Hibernate, and Postgres have served
me well on a variety of projects. However, you need to take it with a grain of
salt -- my needs will likely be different to your needs, and my skill set is
almost certainly different.

------
svieira
I'm actually building one right now using Scala + skinny-micro-framework [1] +
Slick and it's going pretty well. Very nicely composable, easy to work with
Futures (unlike Scalatra) and very easy to extend to handle new types
globally. (Just added an `Option -> response getOrElse 404` and if I need it I
can add `actorRef -> Future -> rest-of-pipeline` too.).

http4s and rho also look interesting, but they suffer from the magic operator
soup that made dispatch a pain to work with (IMO).

[1]: [https://github.com/skinny-framework/skinny-
micro](https://github.com/skinny-framework/skinny-micro)

------
oweiler
On the server: Spring Boot + Spring MVC + Spring Data + Gradle

On the client: React

~~~
slantedview
This is like the software engineering equivalent of someone who only wears
Nike clothes.

------
zubairq
If you don't mind Clojure then you could also try Clojure on Coils:
[http://coils.cc/](http://coils.cc/)

------
richardwhiuk
Why are you tied to using the JVM?

~~~
KajMagnus
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)

------
siavosh
We use Play for www.faqt.co, and it's been nice, but (like any framework) you
start hitting random limitations that takes a lot of work and occasional Scala
code to get around. Sometimes I wonder if using something like dropwizard.io
for a single page app would of been better.

But if your project is only going to be a crud app with limited traffic
volume/life time, I'd personally probably pick an interpreted language and
framework.

------
pete23
Om / ClojureScript ??? / Clojure (I need to check out the options here - REST
is good for CRUD but Liberator scares me a bit) Datomic atop Postgres

------
kyle_u
Being the author, I'm of course biased, but I made Boilerplay
([https://github.com/KyleU/boilerplay](https://github.com/KyleU/boilerplay))
for this very reason. It's a Play/Scala app, uses postgres-async for database
access, and provides most of the boilerplate you'd need for non-trivial apps
(admin, metrics, reporting, sign-in, etc).

------
reitanqild
One of the things I actually do at my current job.

I use JavaEE, more specifically TomEE.

JavaEE has improved massively since last time I used it and is now quite good.

------
kwhinnery
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 personally would have a hard time going back to Spring or JEE. I initially
looked at Play, which is very cool in many respects, but comes with a high
complexity/magic level that makes me nervous. Probably it's great, my old
bones just can't deal with another long walk to mastery like with Rails.

Here's the stack I have been most comfortable with - note that this has been
for relatively simple CRUD app development, and may or may not suit your
hyper-enterprise-iot-multitenant-whatever use case:

 _Web Framework:_

Spark 2 (requires Java 8)

[http://sparkjava.com/](http://sparkjava.com/)

Kevin likes: Easy to generate single runnable jar, simple route configuration,
no heavy abstraction over HTTP (easy to filter, redirect, return status codes,
set cookies, etc), support for a variety of modern template engines.

Kevin dislikes: pretty small community around the software

 _Template Engine:_

jade4j

[https://github.com/neuland/jade4j](https://github.com/neuland/jade4j)

Kevin likes: terse syntax I came to enjoy from Node/Ruby, can easily re-use
templates on the front end if needed in Backbone. Integrates easily with
Spark.

 _Model:_

Morphia (MongoDB)

[http://mongodb.github.io/morphia/](http://mongodb.github.io/morphia/)

Kevin likes: <troll>it's web scale</troll>, no schema maintenance, easy to
configure for dev/test/prod, easy to create fat models, doesn't require a ton
of annotation for persistent fields.

Kevin dislikes: sparse documentation

 _Dependencies /Build:_

Maven (duh)

[https://maven.apache.org/](https://maven.apache.org/)

Kevin likes: doesn't matter if I like it, all Java packages live there. Lots
to use and choose from both for build tasks and in your code. Make note of the
Shade plugin, which makes it easy to generate a single runnable "fat jar":

[https://maven.apache.org/plugins/maven-shade-
plugin/](https://maven.apache.org/plugins/maven-shade-plugin/)

Kevin dislikes: OMG XML. Super verbose. Pretty slow. Seems to frequently
download the Internet. Not fun to extend - consider shelling out to your own
scripts:

[http://www.mojohaus.org/exec-maven-plugin/](http://www.mojohaus.org/exec-
maven-plugin/)

With the above tools, I found that it's easy to take advantage of the great
software packages that do exist for Java, without making my brain hurt too
much.

HTH!

~~~
twic
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...](https://docs.gradle.org/current/userguide/standard_plugins.html)

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

[3]
[https://github.com/johnrengelman/shadow](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](https://github.com/danthegoodman/gradle-capsule-plugin)

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

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

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

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

[10]
[https://github.com/tomwhoiscontrary/PanettoneSpike/blob/mast...](https://github.com/tomwhoiscontrary/PanettoneSpike/blob/master/build.gradle#L42)

~~~
vorg
> 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](http://bazel.io/docs/bazel-user-manual.html)

~~~
twic
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](https://github.com/bazelbuild/bazel/releases)

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

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

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

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

~~~
vorg
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.

------
rendambathu
Spring Boot + Spring Data

~~~
slantedview
Because you can't go wrong with all things Spring (tm), amiright?

------
bhagyas
That would be Spring Roo, along with roostrap.

[http://bhagyas.github.io/roostrap/](http://bhagyas.github.io/roostrap/)

and [http://projects.spring.io/spring-roo/](http://projects.spring.io/spring-
roo/)

~~~
brillio
I second this. while creating a CRUD app for a college project, springroo
helped me bootstrap it to the point that i was able to complete the entire app
in 6 hours.

------
jacques_chester
At my office we've got a whole bunch of Spring Boot projects happening. A
workmate of mine began making a screencast series, "Annotated Spring", a la
Railscast.

[http://www.annotatedspring.com/](http://www.annotatedspring.com/)

------
oberstein
If using Java and not Clojure, maybe I'd use enunciate again on top of the
standard JavaEE stuff.
[http://enunciate.webcohesion.com/](http://enunciate.webcohesion.com/) Deploy
with tomcat.

------
davelnewton
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.

~~~
arenaninja
I admit OP's question is a little vague, but as someone who hasn't touched
Java in a while, I appreciate it. True, the answers are just as vague as the
questions, but to someone who is familiar with Java and not the frameworks for
web development it does enumerate the options that can be explored

------
moondowner
JHipster [http://jhipster.github.io/](http://jhipster.github.io/)

It's a yeoman generator actually, generates a Spring based project with all
the CRUD stuff ready for you.

~~~
jdubois
I'm the creator of JHipster, thanks for the link :-)

Yes we do generate CRUD entities, from the database (SQL, Cassandra, MongoDB)
to the view layer (AngularJS/Bootstrap). All this with security, caching,
monitoring, documentation, tests... So this is very different from Play,
Dropwizard or even vanilla Spring Boot (on top of which JHipster is built).

I'm not saying it's better or worse, just that it's a totally different beast:
depending on your needs, JHipster can be a huge time-saver.

------
jbrisson
I'd say it depends on your data model. If it is fairly simple, Ruby on Rails
is quite awesome. I didn,t experiment with Clojure, Scala, etc. but RoR is a
quite impressive toolset to do CRUD on simple stuff.

------
BjoernKW
JHipster, i.e. Spring Boot and AngularJS:
[https://jhipster.github.io/](https://jhipster.github.io/)

------
neeleshs
Scala + Spray + ScalikeJDBC, though I miss Spring's DI sometimes. None of the
scala DI pieces felt natural & clean. So stuck with scala implicits

------
xpto123
spring mvc for the rest controllers with spring data jpa for the repository
layer. The frontend in Angular 1, nothing beats that in terms of simplicity
and flexibility.

Dont try to do your frontend in java using jsf, wicket, gwt, vaadin, play
framework the scala compiled templates or anything they are too complex and
unflexible compared to what you can do with angular in the browser in a
fraction of the time.

------
richardwooding
Grails is great. I'd avoid Grails 3 for the moment use 2.5.1. It has the power
of Spring and HIbernate, but really easy to use and configure.

------
skzo
Jhipster has a nice stack (
[https://jhipster.github.io/](https://jhipster.github.io/) )

~~~
justforonce
+1

------
reactor
[http://pippo.ro](http://pippo.ro) with Spring JDBC. Quite light weight,
modular and very fast.

------
xentronium
jruby / rails

------
PaulHoule
Right now I am making something simple based on Spring Web, Freemarker
templates, and DynamoDB. It works.

------
zengr
Play (scala) even if I am more comfortable using java, I prefer using scala
just to use play.

------
ExpiredLink
Java EE - _the_ standardized Java stack for Enterprise Web-Applications.

------
ishener
Jersey + Hibernate for a RESTful service. AngularJS in the frontend

------
walkingolof
Scala + Akka HTTP + database that fits the data type in question

------
njharman
Django on Jython

~~~
insin
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.

------
crudbug
I would look at vertx.io with reactjs.

------
rip747
Lucee with CFWheels

------
dvh
StrawBerry on Beryl as backend and Torque or Glass as frontend

------
warbon123
Java spark or vertex + hiberate or sql2o + freemarker

------
andyl
rails / jruby

~~~
kristianp
How about Padrino / JRuby?

------
yegor256a
Try Takes Framework: www.takes.org

~~~
dommer
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.

------
fleitz
jruby / rails

