If JVM is not a must, consider using Meteor.
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.
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.
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.
However, it depends from your use-case. Could add some detail please?
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?
In short it's component + system + monger + om on the frontend
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...
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).
JHipster (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 - it works great with Java 8, Intellij, Spring & Hibernate.
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.
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.
Java + Spring is still a very safe (albeit boring) option for a lot of different types of web apps today.
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.
Read: https://blog.8thlight.com/uncle-bob/2012/05/15/NODB.html
Read: http://www.amazon.co.uk/Growing-Object-Oriented-Software-Gui...
[EDIT] Removed the unnecessary/unhelpful opening statement.
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.
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.
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.
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/...
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.
That is sufficient to start looking for a framework, in my opinion. Cases where that is wrong aren't simple.
On a different note, I would also recommend to not start picking the framework or stack: Instead I would start by creating a couple of basic classes that represent the business logic.
I would also write tests for those classes. Furthermore I would probably introduce some repository classes that would interface with the database. Lastly I would try to find a library that handles HTTP routing - if the CRUD app was meant to have an HTTP I/O channel.
Not everyone wants to "go fast and break things" or blindly let their codebase depend on a third-party framework. This is usually what ends up happening when you don't think about architecture.
Check out the most popular Angular posts on HN this year [1]. Notice a trend?
[1] https://hn.algolia.com/?query=angular&sort=byPopularity&pref...
How would you do that without deciding on a language/framework?
Suppose the goal is a shared calendar and message boards plus some way to buy ski passes. Doing this using SharePoint is going to be vastly different than Ruby on Rails.
We know nothing of OP's case so the best thing we can do is trying to answer his question instead of answering to go read some lengthy book.
OP might be in a team that needs to develop an API for a product that will be deployed to millions of people(I doubt it) or could be someone that just wants to know what is the current fashion to develop a CRUD application while learning a new stack that is up to date.
In the first case, you might want to learn more of the situation you are in and pick around that. In the second case, there is nothing wrong with just picking one and hacking away.
https://github.com/akullpp/awesome-java
Or other awesome stuff at the parent project.
"simple CRUD app"
That is more than sufficient to pick a framework/database and start working. I'm not sure how many simple CRUD apps you have built, but the challenge tends to come when you put them in front of users who can't figure out the interface. Consequently, I'd argue to choose a framework quickly and get it in front of a user as fast as you can.
If you want to learn more, I'd check out http://www.luminusweb.net/.
Scala
Spark - http://sparkjava.com
ScalikeJDBC - 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
Out of curiosity, why Spark over Scalatra? (http://scalatra.org/)
Spring Data does this very well, in a fashion partly inspired by ActiveRecord. You define a Repository interface with whatever search methods suit your case; a concrete class is built and injected for you. The same interface can back onto JPA databases, Mongo, Redis and I forget what else.
If you add Spring Data REST, you get a complete RESTful API -- complete with HATEOAS, paging, sorting, searching and HAL -- automagically.
Use Spring Boot and you won't need to do any more than include the dependencies in your Maven POM or build.gradle file.
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
If you can swing it for your project, I would suggest trying to sidestep ORM altogether by using a NoSQL database like MongoDB.
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.
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.
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.
Everything already configured and tested to work out of the box, including transactions.
Yes, you might get away with a smaller initial download with something else but the server is a onetime download and your deployed apps are small.
Include JOOQ, if that's what you want.
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.
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.
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:
to keep things simple.
- 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
[2] http://www.pippo.ro/doc/templates.html
[3] http://www.pippo.ro/doc/server.html
[4] http://www.pippo.ro/doc/static-files.html
[5] http://www.pippo.ro/doc/session.html
[6] http://www.pippo.ro/doc/content-types.html
[7] http://www.pippo.ro/doc/internationalization.html
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.
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.
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
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?
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/maste...
We built an internal webapp using torquebox (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.
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.
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.
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.
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 ..."
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.
> 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.
Java + MySQL, using these awesome libraries
- Bowser (webapp): https://github.com/mirraj2/bowser
- EZDB (MySQL wrapper): https://github.com/mirraj2/ezdb
- Ox (IO and Json): https://github.com/mirraj2/Ox
These bad boys make writing Java wonderful again.
For simple CRUD it may be overkill, but it scales nicely for when you go past CRUD.
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.
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
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.
But only because I'm used to nodejs and this is the jvm equivalent.
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.
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...
Apache Wicket (http://wicket.apache.org/).
Java + HTML. Can't get any simpler than that. Java 1.8.0 makes me not miss Groovy at all.
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).
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
}
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.
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 ?
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.
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.
http4s and rho also look interesting, but they suffer from the magic operator soup that made dispatch a pain to work with (IMO).
On the client: React
Edit: Oh I misunderstood your question. (Did you perhaps edit your comment, added "tied to"? Didn't notice that the first time)
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.
I use JavaEE, more specifically TomEE.
JavaEE has improved massively since last time I used it and is now quite good.
- 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)
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
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/
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)
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/
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/
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!
And there's no XML, it's pretty concise (Groovy syntax, convention over configuration, sensible defaults), and although its raw speed is no better than Maven's, it is smart enough to only execute tasks which are needed (rather than everything, every time, as Maven does), and can run as a daemon to avoid startup costs [9], so in practice it's far faster than Maven. Still downloads the internet now and then, though.
But extension is an absolute joy - there is simply no comparison to Maven. There's a very satisfying spectrum of ways to define your own tasks, from blocks of code right in the build script, to classes defined in the build script [10], to externally packaged plugins, all of which are easy to do and integrate fully with the existing machinery (task dependencies, handling files, inputs and outputs, and so on).
Then there's the stuff you might not even notice until you get off Maven. Gradle builds are graphs of tasks, not sequences of lifecycle phases, so it's trivial to add more tasks, rearrange, tasks, etc. Concrete example: Maven provides a single test task (surefire); if you want a second (say, for functional tests), you can use a plugin (failsafe); if you want a third (say, for external contract tests), you'll need to write a plugin. In Gradle, you'd just make another instance of the test task. It's a few lines of code.
Sorry if i sound like a fanboy or a shill, but Gradle, while far from perfect, is so much better than Maven in every way that it pains me to see a fellow human being suffering under the latter. Seriously, Maven is obsolete. Just use Gradle. Until something better comes along.
[1] https://docs.gradle.org/current/userguide/standard_plugins.h...
[2] https://plugins.gradle.org/
[3] https://github.com/johnrengelman/shadow
[4] at its simplest, something like:
jar {
dependsOn configurations.runtime
from {
configurations.runtime.collect { zipTree(it) }
}
}
[6] https://github.com/cinchapi/jarsh
[7] https://docs.gradle.org/current/userguide/application_plugin...
[8] https://github.com/pivotal/executable-dist-plugin
[9] https://gradle.org/why/high-performance-builds/
[10] https://github.com/tomwhoiscontrary/PanettoneSpike/blob/mast...
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
Firstly, it's still in beta - 0.1.0 is out [1], and there's plenty to do before 1.0. [2].
Secondly, according to the article on Bazel currently floating up on HN [3]:
"Blaze was designed to work for Google's unified codebase and Bazel is no different. The implication of a unified source tree is that all dependencies for a given software component exist within the tree. This is just not true in the open source world where the vast majority of software packages have dependencies on other libraries or tools, which is a good thing. But I don't see how Bazel copes with this, if at all."
How would i use Bazel to build a project which uses dependencies from Maven Central, or my company's internal repository? It seems that Bazel can fetch jars from Maven repositories [4], but i don't think it does transitive dependencies.
Also, the extension story looks a bit weird [4]:
"Skylark is a superset of the core build language and its syntax is a subset of Python. The following constructs have been added to the core build language: if statements, for loops, and function definitions. It is designed to be simple, thread-safe and integrated with the BUILD language. It is not a general-purpose language and most Python features are not included."
Whilst i'm no fan of Groovy, it's nice to be able to write plugins in a general-purpose language. For example, in one of the build scripts i linked to in my comment, i have a custom build step which processes templates by running another Java program (which was downloaded as a JAR from Maven), and in other builds i've written plugins which call directly into Java libraries (again, which were downloaded as JARs from Maven). Could i do that with Skylark?
[1] https://github.com/bazelbuild/bazel/releases
[2] http://bazel.io/roadmap.html
[3] http://julipedia.meroh.net/2015/04/on-bazel-and-open-source....
> 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.
It's a yeoman generator actually, generates a Spring based project with all the CRUD stuff ready for you.
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.
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.
Is there anything comparable to django.forms in Java yet? There wasn't the last time I went looking a few years ago.
Class names with Ft or Bk or Rs or [add two letters] prefixes don't work for adoption and clarity of expression.