| I hear you. I personally stand by the title choice because IMHO there are two facets to Java EE. I'm not saying that it's a fact (I simply don't have the data to back it up), but those 2 facets I see are: * huge installed enterprise base * modernisation of the platform aiming it a both small and big users I've been active in Java/Java EE for some time, and I know that these facets can be at odds with each other. For instance Java EE people wanting to support enterprises exclusively still think in needs of enterprises, which means there's always a dedicated ops team, an installed server that nobody but ops can touch and developers that communicate with ops via tickets. This warrants having data sources and security modules configured outside the application and maintained by ops. For small users this is silly overhead. When you're the only one developing an app the security module can be right inside the app. Some Java EE people have introduced mechanisms to do so, but the enterprise people who are still there hate it, saying a server should always be maintained by an ops team. The very idea that a small shop doesn't have an ops team just doesn't occur to them. Long story, but the simplifications that are making Java EE incresingly suitable for small shops and startups, while maintaining access to the power of the full platform to me doesn't seem well known yet. |
> huge installed enterprise base
This is more a reason for a consulting shop to pick JEE.
All in all I think the article more describes why one cannot get around JEE for enterprise work. And how JEE is not as terrible as it was.
That last point assumes levels of "terribleness" are well understood by by many.
When it comes to "startup secret weapons" (except maybe for startups that have to tie in with enterprise systems), I think JEE is the last thing that comes to my mind. Even after reading the article.