16 ms·

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

• ramkalari 11y ago
  Play Framework
  • jroper 11y ago
    I like Play too.
    • wsargent 11y ago
      So much great code being checked in.
• richardwhiuk 11y ago
  Why are you tied to using the JVM?
  • KajMagnus 11y ago
    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)
• neya 11y ago
  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 11y ago
    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 11y ago
      +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 11y ago
        How do you find the GC/profile/coverage/tuning of the server side node process compared to the jvm?
        • pookeh 11y ago
          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.
    • duaneb 11y ago
      Lift works well but is utterly incomprehensible. Play is better written and maintained.
  • neverminder 11y ago
    I agree with Play/Scala combination. Play is light enough for simple tasks, but at the same time it's a feature-complete powerful beast - built on Akka and capable of potentially handling millions of requests.
  • joostdevries 11y ago
    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.
    • duaneb 11y ago
      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.
      • partisan 11y ago
        Agreed. Squeryl provides a really easy and intuitive API for querying and updating data. Slick seems to be less easy to use.
      • neya 11y ago
        I second Squeryl over slick.Had a very nice experience.
      • david04 11y ago
        +1 for Squeryl!!!
  • mike_hearn 11y ago
    If you're looking for a Play-like framework but that's just Java, not Scala, you could check out Ninja Framework. I tried it for a simple CRUD app last year and it worked out pretty well. It's not as widely used or as maintained as Play though (+Play does have a Java API).
  • thoman23 11y ago
    Glad to see support for Scala/Play sprinkled throughout the responses here. I love working with both. Now I'm considering taking the next step and adopting ScalaJS for some small internal apps.
    • brianwawok 11y ago
      I made the ScalaJS leap. Good for all my internal JS stuff. Interfacing with legacy JavaScript libs sucks (similar problems to using Typescript).
  • tajen 11y ago
    I don't agree because 1. Play!2.x is asynchronous, and you need to find NIO-compatible libraries, 2. I like Jersey for REST resources better than Play!2.x's "routes" file. I had to build a stack this year for an app which needed to share code with another Spring app. I've chosen DropWizard because I could share the Jersey resources and I didn't have to learn everything again.
    • brianwawok 11y ago
      You do not NEED to find NIO libraries. It sure helps, yes. But it comes with a wrapper of a webservice library, and slick does the RDBMS nicely (and offshoots like phantom to do cassandra, etc).
• oweiler 11y ago
  On the server: Spring Boot + Spring MVC + Spring Data + Gradle On the client: React
  • slantedview 11y ago
    This is like the software engineering equivalent of someone who only wears Nike clothes.
• raugustinus 11y ago
  http://www.dropwizard.io/ http://www.dropwizard.io/ combined with reactjs
• Gonzih 11y ago
  Clojure + ClojureScript + Reagent/Om as an abstraction on top of React
• aSig 11y ago
  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 11y ago
    If you're favoring Boot, why not just use a newer version of Grails?
    • StevePerkins 11y ago
      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.
• vbezhenar 11y ago
  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).
  • georgerobinson 11y ago
    I attempted to learn Spring framework about a year ago since I wanted to build a quick CRUD app on the JVM too. However, I found the Getting Started guides really difficult to learn from. In addition, I found myself quite confused as to which templating engine to use and how to use it in Spring. I stopped working on CRUD for other reasons (pursuing an MSc where I mostly wrote C code).
    • Aker89 11y ago
      Yep, similiar situation here. The getting started guides often just introduce a single concept and stops there. Many seems outdated as well. However, Spring Boot with whatever DB choice you make is a winner imho. Found it really easy to get going after just investigating a sample project.
  • jeremyjh 11y ago
    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.
• skzo 11y ago
  Jhipster has a nice stack ( https://jhipster.github.io/ https://jhipster.github.io/ )
  • justforonce 11y ago
    +1
• ishener 11y ago
  Jersey + Hibernate for a RESTful service. AngularJS in the frontend
• xentronium 11y ago
  jruby / rails
• ff_ 11y ago
  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/
  • Scarblac 11y ago
    That looks like it is a HTTP server. What parts of CRUD does it help with, does it have say an ORM (or equivalent way to interface with a database) and some sort of default interface so the user can work with it?
    • pjagielski 11y ago
      I picked some best library choices in this repo https://github.com/pjagielski/modern-clj-web https://github.com/pjagielski/modern-clj-web In short it's component + system + monger + om on the frontend
  • 147 11y ago
    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-clojure/ http://christopherdbui.com/announcing-practical-rest-apis-in...
    • Scarbutt 11y ago
      looking up to it!
  • johnbellone 11y ago
    I can personally second this. It is pretty quick to get a micro service up and running with Clojure. My team has been using the Duct[0] generators which set up a nice scaffolding. It also includes some decent examples writing components, models and endpoints. Plus swagger is free out of the box. [0]: https://github.com/weavejester/duct https://github.com/weavejester/duct
• warbon123 11y ago
  Java spark or vertex + hiberate or sql2o + freemarker
• notinventedhear 11y ago
  Also agree with the combination of Play + Scala for flexibility and ease of use.
• jareds 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
• timclark 11y ago
  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.
  • deleted 11y ago
    [deleted]
• granchi 11y ago
  Play Framework (Java or Scala)
• a-saleh 11y ago
  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
• stefs 11y ago
  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).
  • k__ 11y ago
    I would recommend vert.x too. But only because I'm used to nodejs and this is the jvm equivalent.
  • slantedview 11y ago
    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.
• bhagyas 11y ago
  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 11y ago
    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.
• dvh 11y ago
  StrawBerry on Beryl as backend and Torque or Glass as frontend
• estefan 11y ago
  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 11y ago
    how are you running React on the JVM - Are you using Nashorn or Rhino here?
    • estefan 11y ago
      Sangria is scala. React is the client in the browser. That doesn't run on the JVM.
      • sandGorgon 11y ago
        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 11y ago
          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.
• dommer 11y ago
  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-Guided-Signature/dp/0321503627 http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui... [EDIT] Removed the unnecessary/unhelpful opening statement.
  • untitaker_ 11y ago
    Particular things have to be decided upfront. You can't just add an app framework as an afterthought to your code.
    • dommer 11y ago
      I'm unsure about that and I think it depends greatly on what is the goal. You can very easily do DI without Spring. (yes I know Spring is more than DI) As the project grows you can simple add Spring if brings 'real' value. You can defer the choice of data store very late in a project without hinder its progress. I'm not anti-framework/tooling, I just want to make sure it is required before I add it. Most, if not all, frameworks require some specific bootstrapping/configuration that is extra to the job at hand.
  • inglor 11y ago
    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.
• andyl 11y ago
  rails / jruby
  • kristianp 11y ago
    How about Padrino / JRuby?
• flaie 11y ago
  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.
• sscarduzio 11y ago
  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-examples https://github.com/vert-x3/vertx-examples/tree/master/web-ex...
  • cryptos 11y ago
    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).
• emsy 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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.
• moondowner 11y ago
  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 11y ago
    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.
• playing_colours 11y ago
  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 11y ago
    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/
    • redtuesday 11y ago
      Akka-http is basically the successor to spray if I remember correctly. At least I believe jonas boner said so. Not sure I would invest much time in spray at this point in time.
    • playing_colours 11y ago
      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.
    • saryant 11y ago
      Akka HTTP is Spray.io.
  • cryptos 11y ago
    I find the Akka HTTP API pretty ugly.
• Borkdude 11y ago
  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/.
• jbrisson 11y ago
  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.
• carsongross 11y ago
  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 11y ago
    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 11y ago
      Pippo looks pretty sweet. How does it compare to Spark?
      • reactor 11y ago
        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.
      • decebals 11y ago
        I don't know many things about Spark, so I can't make a full comparison. I will try bellow to enumerate some advantages of Pippo: - modular [1] (spark uses a giant static singleton architecture) - support (via modules) for many Template Engines [2] (Freemarker, Jade, Groovy, Trimou, Pebble) - support (via modules) for many Servers [3] (Jetty, Undertow, TJWS); spark depends on Jetty - directly serving of static resources [4], support for WebJar - content type negotiation - custom session [5] (support for cookie based implementation) - support (via modules) for many ContentTypeEngines [6] (Plain text, Json - Gson/Fastjson, Xml - Jaxb/Xstream, Yaml - SnakeYaml) - i18n [7] (in java or directly in template) - support (via modules) for many IoC [8] (Guice, Spring) - support metrics [9] (via modules - Ganglia, Graphite, InfluxDB, Librato) - custom (template) error pages - regex routes Unfortunately the actual documentation of Pippo it's a little bit behind of the implementation (from documentation are missing some nice concepts: named routes, finally filters, custom route context, ...) and from this reason I cannot give you more useful links but I will fix this aspect asap. Another difference in Pippo to other (micro) java web framework (spark, ninja) is that a RouteHandler it's a real endpoint (the handle method return void). You can finalize/commit the response using send, render, redirect. Everything is transparent. [1] http://www.pippo.ro/doc/modularity.html http://www.pippo.ro/doc/modularity.html [2] http://www.pippo.ro/doc/templates.html http://www.pippo.ro/doc/templates.html [3] http://www.pippo.ro/doc/server.html http://www.pippo.ro/doc/server.html [4] http://www.pippo.ro/doc/static-files.html http://www.pippo.ro/doc/static-files.html [5] http://www.pippo.ro/doc/session.html http://www.pippo.ro/doc/session.html [6] http://www.pippo.ro/doc/content-types.html http://www.pippo.ro/doc/content-types.html [7] http://www.pippo.ro/doc/internationalization.html http://www.pippo.ro/doc/internationalization.html [8] http://www.pippo.ro/mod/spring.html http://www.pippo.ro/mod/spring.html [9] http://www.pippo.ro/mod/metrics.html http://www.pippo.ro/mod/metrics.html
• deleted 11y ago
  [deleted]
• rendambathu 11y ago
  Spring Boot + Spring Data
  • slantedview 11y ago
    Because you can't go wrong with all things Spring (tm), amiright?
• humbleMouse 11y ago
  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 11y ago
    I agree, building crud in grails is really fast. I'm just sorry grails is not so much adopted.
    • humbleMouse 11y ago
      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 11y ago
        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.
• davelnewton 11y ago
  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 11y ago
    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
  • reitanqild 11y ago
    This isn't stackoverflow.com and getting a list is totally ok.
  • deleted 11y ago
    [deleted]
  • ahmacleod 11y ago
    I'm actually pretty amazed at the diversity, and how few of these frameworks I'm familiar with.
  • twic 11y ago
    151 replies so far, and it's not even close to every JVM framework there is!
• fleitz 11y ago
  jruby / rails
• elliottburris 11y ago
  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.
• mindcrime 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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.
  • mgkimsal 11y ago
    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.
• crudbug 11y ago
  I would look at vertx.io with reactjs.
• siavosh 11y ago
  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.
• davidkellis 11y ago
  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 11y ago
    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/)
    • davidkellis 11y ago
      I used Scalatra on one other project, and I found it to be difficult to deploy. Whether it's true or not, my impression is that Spark is a little simpler to use and deploy than Scalatra. Scalatra is my second choice though.
    • fokinsean 11y ago
      What makes you say it is future proof?
      • jethro_tell 11y ago
        I assume he's been to the future, that's the only way one could know.
      • thinkdevcode 11y ago
        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.
  • jacques_chester 11y ago
• kwhinnery 11y ago
  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 11y ago
• PaulHoule 11y ago
  Right now I am making something simple based on Spring Web, Freemarker templates, and DynamoDB. It works.
• hobarrera 11y ago
  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
  • antiffan 11y ago
    I love the idea of JRuby, but I found the community was weak when I did my exploration. Granted, that was about 1.5 years ago.
  • stevepike 11y ago
    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.
• steven2012 11y ago
  Does anyone have any opinions on DropWizard as a framework? Is it the minimalist web framework for Java, similar to Flask for Python?
  • siavosh 11y ago
    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 11y ago
      "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?
  • brianwawok 11y ago
    It's ok for Java. Much rather be in Scala land though, and exploit the JVM for all it's worth.
  • logn 11y ago
    I've used all the technologies in DropWizard, but not DropWizard itself. I do think their project is on the right track and pretty much my ideal solution. But because they've designed a one-size-fits-all stack for any project, it looks overkill for a lot of apps. I.e., you can just use plain Jersey+Grizzly/Jetty+Freemarker. I've been meaning to put a simple project together which ties all those into a functioning web and app server. The trick to turning Jersey into a web server (for static files) is along the lines of this: https://github.com/MachinePublishers/ScreenSlicer/blob/master/webapp/src/com/screenslicer/webapp/WebAppConfig.java https://github.com/MachinePublishers/ScreenSlicer/blob/maste...
• cweagans 11y ago
  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.
• reitanqild 11y ago
  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.
• ajg360 11y ago
  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.
• brianwawok 11y ago
  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 11y ago
    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.
• njharman 11y ago
  Django on Jython
  • insin 11y ago
    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.
• pigpen34 11y ago
  Not a popular opinion here, I'm sure. But I would no doubt use a newer CFML platform, either ColdFusion 10+ or Lucee.
• rip747 11y ago
  Lucee with CFWheels
• elchief 11y ago
  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.
• slantedview 11y ago
  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/
  • antiffan 11y ago
    +1 for Dropwizard. Setting up Dropwizard was a breathe of fresh air in the Java world. If you can swing it for your project, I would suggest trying to sidestep ORM altogether by using a NoSQL database like MongoDB.
    • slantedview 11y ago
      Indeed. I recently received a pull request to swap Hibernate into a Dropwizard project with a relatively simple data model that was operated on by some simple JDBI repository implementations. The pull requester obviously spent a lot of time on it, and I felt bad rejecting it, but in total the Hibernate impl would have added several thousand lines of code to something that worked perfectly fine as it was. I really don't understand the need to use complex things just because they're popular.
• deleted 11y ago
  [deleted]
• xpto123 11y ago
  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.
• oberstein 11y ago
  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.
• pete23 11y ago
  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
• jamn333 11y ago
  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.
• ExpiredLink 11y ago
  Java EE - the standardized Java stack for Enterprise Web-Applications.
• zubairq 11y ago
  If you don't mind Clojure then you could also try Clojure on Coils: http://coils.cc/ http://coils.cc/
• BjoernKW 11y ago
  JHipster, i.e. Spring Boot and AngularJS: https://jhipster.github.io/ https://jhipster.github.io/
• Tinned_Tuna 11y ago
  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.
• kyle_u 11y ago
  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).
• svieira 11y ago
  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
• neeleshs 11y ago
  Scala + Spray + ScalikeJDBC, though I miss Spring's DI sometimes. None of the scala DI pieces felt natural & clean. So stuck with scala implicits
• jacques_chester 11y ago
  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/
• yegor256a 11y ago
  Try Takes Framework: www.takes.org
  • dommer 11y ago
    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.
• richardwooding 11y ago
  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.
• walkingolof 11y ago
  Scala + Akka HTTP + database that fits the data type in question
• dcposch 11y ago
  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 11y ago
    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.
• metacity 11y ago
  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.
• zengr 11y ago
  Play (scala) even if I am more comfortable using java, I prefer using scala just to use play.
• Mikera 11y ago
  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.
• Pyppe 11y ago
  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).
• reactor 11y ago
  http://pippo.ro http://pippo.ro with Spring JDBC. Quite light weight, modular and very fast.