Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

151–160 of 213 posts

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

#151

Post by slantedview »

smoyer wrote: post #145
reitanqild wrote: post #140

Earlier quoted context omitted.

I really like annotations. And I really enjoy working on JavaEE. For anyone who still thinks it means loads and loads of boilerplate code but wants to check, read Adam Bien, check out the TomEE examples, the Wildfly examples etc.

This is so true! ... I was ready to give up on J2EE (prior to the name change and version 1.5). Java EE 7 is wonderful and more tools are coming. It's no longer an XML configuration nightmare with 10 classes to define all the required interfaces and implementation. To reduce even more boiler-plate, I've recently started using project Lombok [1]. Code generation provides all the standard methods and allows JPA @Entity…

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

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

#152

Post by fokinsean »

thinkdevcode wrote: post #98
davidkellis wrote: post #90

Backend: 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

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

What makes you say it is future proof?

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

#153

Post by reitanqild »

slantedview wrote: post #150
reitanqild wrote: post #140

Earlier quoted context omitted.

I really like annotations. And I really enjoy working on JavaEE. For anyone who still thinks it means loads and loads of boilerplate code but wants to check, read Adam Bien, check out the TomEE examples, the Wildfly examples etc.

I'm guessing you like annotations because they're less painful than what you were used to previously. You don't need an EE server to serve up a basic web app. Or even a complex one.

You don't need, but they are free and wonderful.

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.

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

#154

Post by slantedview »

stefs wrote: post #23

i recently wrote a small blog engine in vert.x ( 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, l…

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.

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

#155

Post by reitanqild »

slantedview wrote: post #151
smoyer wrote: post #145

Earlier quoted context omitted.

This is so true! ... I was ready to give up on J2EE (prior to the name change and version 1.5). Java EE 7 is wonderful and more tools are coming. It's no longer an XML configuration nightmare with 10 classes to define all the required interfaces and implementation. To reduce even more boiler-plate, I've recently started using project Lombok [1]. Code generation provides all the standard methods and allows JPA @Entity…

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

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

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

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

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

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

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

#157

Post by elchief »

Server-generated HTML or browser-generated HTML?

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

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

Spring 4.2 does websockets and server-sent events nicely.

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

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

#158

Post by slantedview »

carsongross wrote: post #70

SparkJava ( http://sparkjava.com/ ) + jooq ( 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/ to keep things simple.

The need for codegen to approach LINQ-level magic on the JVM is unfortunate, but jOOQ is killer compared to the JPA/ORM bloat that most folks can't seem to stop themselves from using.
Post reply on HN