>Spring therefore is, was, and always will be at least a generation or two ahead.
It should indeed be the idea that Java EE is behind. Its stated purpose is to standardize that what has been proven to work. It doesn't aim to be highly innovative. Instead, it aims to be a stable base on which other technologies can build without having to be afraid that the platform changes underneath them every few months, and without much fear that the platform suddenly changes directions radically.
Keeping that in mind it's funny that CDI is so much more innovative, modern and powerful when compared to Spring Beans. CDI (and by extension Java EE) engaged in the no-XML revolution when Spring was still trying to put MORE code into their proprietary XML format. I've seen Spring applications that were ~50k lines of Java code and ~150k of Spring XML code. Gives a whole other meaning to the term XML hell.
And let's not start about the -contextual- injections and the powerful extension mechanism that CDI pioneered well before Spring was even thinking about such things.
Here Spring is at least 2 generations behind Java EE. And before you start about it, no, CDI was not inspired by Spring. Guice and both JSF native beans and EJB were CDI's inspirations.
>JEE requires an old-school big honking app server such as WebLogic or JBoss. Lighter-weight alternatives such as TomEE are only just now starting to become suitable for production use.
JBoss is NOT old-school and big honking (whatever that means). The download size of JBoss is about 110MB, and it starts in about a second. 10 seconds with an app that contains hundreds to thousands of beans.
Compare that to a typical Spring app, where the downloaded size of all things you need easily exceeds 200MB and the war itself is a 100MB or so. A war for Java EE is often some 1 to 2MB for a BIG application. Go figure.
A Spring app with so many beans takes up a minute to boot, at least. Granted, I last checked about 2 years ago, maybe it's better now.
TomEE has been viable to be used for quite some time, and next to TomEE there's also Resin and Liberty web profile which are about as small (some 30MB).
>Moreover, "standards" notwithstading... you do get locked in to your particular app server, and will experience breakage when migrating to a different vendor who bundles different libraries implementing those standards.
You may get small breakages, but you at least have a chance to migrate!
Imagine migrating your 500k loc application from Spring to Play. Not going to happen. With Java EE I've migrated applications between all major servers. Sure, there were small things breaking, but on average it took me and the team about 2 weeks to fix. 2 weeks is NOTHING compared to a total migration to another platform which can take years.
>With modern Spring Boot, everything you need gets bundled into a self-contained and safe archive file.
This is only a fairly recent development for Spring, and Java EE vendors have solutions here as well. TomEE has been capable of doing this for years, and recently there have been solutions for GlassFish (http://www.payara.co.uk/introducing_payara_micro) and JBoss (http://wildfly.org/news/2015/05/05/WildFly-Swarm-Released/)
>Putting an app server inside your JAR might sound inefficient at first, but it's a devops dream and is ideally suited for today's trend toward microservice architecture.
From the very article this HN post links to, that startup is doing something like that already with Java EE.
>Besides, a typical app with Spring and Tomcat bundled is STILL a fraction of TomEE's size.
Yeah, sure. See my comment above. TomEE is some 35 MB and contains nearly everything you need. Try adding Spring libs and all their dependencies, as well as Hibernate and a transaction manager to your war. That 35MB gets eaten away pretty quickly. And please don't think that just because you only put dependencies in the pom.xml file that the data is not really there. Take a look at the final war that's build. This is often way larger than 35MB when Spring is used.
>I find JEE's CDI to be a clunky mess in contrast
I think it's exactly the other way around...
>Spring these days steers developers toward Thymeleaf templates, which are consistent in usage with most of the modern JavaScript frameworks they are likely using already. JEE steers developers toward JSF, which even in its modern form tries to simulate concepts from .NET WebForms
Thymeleaf unfortunately is not very memory efficient compared to JSF's Facelets. See http://www.jsfcentral.com/articles/understanding_jsf_perform...
And Facelets/JSF uses modern templating based on plain HTML these days.
>Microsoft has meanwhile walked away from this as outdated bad practice)
No, Microsoft walked away since they had never been able to put the effort in to create a next gen version of their platform. In JSF terms WebForms is still at JSF 1.1/1.2.
ASP.NET WebForms never had its JSF 2.0 release, and it doesn't have things like PrimeFaces and OmniFaces.
PrimeFaces DID try to make a component set for WebForms, but gave up because the underlying technology was just too outdated.
>If you take a Spring problem to StackOverflow, you will have an answer within minutes.
Uhm, you can't be serious here, are you?
Ever heard of BalusC?
The JSF community is HUGE on stackoverflow, things are answered pretty quickly and there are about twice as many questions (and answers!) there compared to Spring MVC.
>By comparison, the JEE "community" is practically non-existent...
On the contrary, it's really big. Every sub spec has a public JIRA where anyone can submit ideas and looking at the last release indeed many ideas have been implemented that were proposed by the community.
I think you have 2003/2004 in mind and never looked back. Things have changed drastically since then.