I've had some terrible experiences with migrating, and maintaining, Java EE apps before. But every single one of those were caused by how the teams built the sy

I've had some terrible experiences with migrating, and maintaining, Java EE apps before. But every single one of those were caused by how the teams built the system, and not by Java EE itself. The added complexity, and choices, imposed by Java EE require a degree of understanding, maturity, and ability to abstractly design that is beyond the average programmer that just quickly wants to hack together a couple of REST services. I'm not trying to paint successful Java EE developers as some sort of elite here, but there is no doubt that people with a solid understanding can, and have, built long-lasting systems of beauty with it, whereas the average un-informed team, having managed to soundly lock themselves into awful pre-2005 app servers, have created conterted messes of Java code beyond belief. Both Java EE, and OSGi, are soundly beautiful in their own ways, but both have suffered from some awful implementations and libraries that have caused a lot of pain. For the past 5 years, my experiences with Java EE has been everything but "heavyweight". I consider it a rapid application development environment. Especially now that nobody does any server-side view frameworks anymore (it's all ECMAScript in the browser). In this world, I challenge any environment to put more horsepower behind your REST services, for less effort.