Hacker News Reader

Comment by zvqcMMV6Zcr | Hacker News Reader

Why would you compare Eclipse GlassFish instead to Payara or Wildfly/JBoss? Anyway, that bickering between JEE application server vendors is what caused Spring to win. It doesn't matter it has update churn that is almost as bad as in JS ecosystem, just the fact you don't have to think about AS helped adoption. Well that and significantly easier testing. And Spring Data with generating queries from method names. And you can't recruit people with JEE knowledge anyway, they all know only Spring.

View on HN

Spring and JEE (or Quarkus) are very similar, from the viewpoint of an application developer both have the same JAX-RS REST and Hibernate/JPA API's.

IMO the kind of person who only knows Spring and doesn't understand modern JEE is exactly the kind of person you don't want to recruit.

Spring won. Why would anyone want to learn the standard aside from it being a standard that few people use? Spring itself is a wildly adopted standard. It is a semi open standard in that anyone can use it freely, but in that it's not supposed to be implemented by others.

The same is true for Micronaught or Quarkus. Learn the frameworks. But they are not a new open standard.

Except people keep forgetting they implement the standards on their very foundation.

> Spring won. Why would anyone want to learn the standard aside from it being a standard that few people use?

People don't really talk about Jakarta EE as "the standard". Haven't been doing that for quite some time.

You learn it so you don't hand Spring the ultimate monopoly. I thought we all didn't like monopolies? Why give Broadcom one?

Yes please, though this is largely driven by my personal dislike of Spring Boot. The bloat and magic sucks so much of the joy out of programming to me. That said, I never lived in Spring Boot exclusively. I've heard people say that it's an "all in" kind of thing and once you go all in and learn the thing really well, you start to like it.

There's nothing to be gained by picking a winner, especially if it doesn't really matter because the important APIs are the same.

Newer frameworks like Quarkus are specifically built for container usage and applications built with it are a bit faster and smaller than Spring boot.

I'm saying the spec lost to Spring. There are many historical reasons for the loss, but Spring won.

It looks like the industry is moving away from architectures like EE. The desire now is more like a Go deployment: single, self contained deployable. There are make frameworks that support this goal. Maybe EE is one of them, but it's not essential like it was in the early 2000s.

> single, self contained deployable

EE doesn't exclude that model at all.

For the most part, maybe like 99%, the Jakarta APIs are agnostic of what the deployment model is. They are APIs to validate input, service HTTP requests, store data in databases, look up roles, connect to identity providers, etc etc.

People like simple life with as few choices they have to make as possible, right? It's now very simple to start a Java project, when the obvious choice is Spring and everybody uses it.

But is it what everybody really wants? To have a single choice? GlassFish provides a choice for those that don't want to become stuck with the "only" option that everybody uses. Java itself provides a lot of options - Oracle JDK, Azul JDK, Corretto JDK and many others. And that's a good thing. Options in frameworks and application servers are a good thing too. The best option wins. Except, there's rarely the best option for every case. And it's good to have all the other options too, in case the most popular option isn't a good one for you.

I used to work for Red Hat middleware, and I love JBoss. Bickering is not why Spring did so well.

Spring just made things easy. It also had only one implementation, so you couldn’t be confused because a deployment descriptor worked on one platform and not another. Some random blog post on setup always worked when Spring was in use. If you were following a WebLogic cookbook, good luck on Websphere.

In the end, Easy always wins. Make something hard easier to use, the world will beat a path to your doorway.

Yet the WebAssembly bros are into replicating application servers with Kubernetes pods running WebAssembly containers, go figure.

I know right? Who wants sub-millisecond readiness, sub-second image replication and a measly couple of megs worth of memory alloc per service when everyone can just get themselves a 2 gig springboot heap by default?

FWIW Wasm is hitting kubernetes because that's what customers are explicitly asking for, and the majority of enterprise Wasm-on-k8s afopters are doing so precisely because they want to eradicate Spring bloat and the associated supply chain risks from their engineering orgs.

There are plenty of supply chain attacks without Spring into the picture.

Also, are you sure you are talking about Kubernetes performance over there?

Reply on news.ycombinator.com