Ask HN: Why are there so few apps being built with JSP?

From what I've seen/heard, I think the lack of cheap hosting was one of the biggest things that kept Java from catching on as a preferred platform for the kinds of webapps that you see people building with PHP and/or RoR. That problem has, IMO, been mitigated somewhat by the emergence of cheap VPS providers... now hosting is hosting, and what you run on your server is entirely up to you. But by the time cheap VPS's became commonplace, it had become "cool" to hate Java. And, to be fair, there is a little more of a learning curve to get started with Java and most of the Java based webapp stacks, compared to, say, RoR or whatever.

Also, to be fair, other platforms have "caught up" to what were some of the early advantages of Java. For example, at one time I would have cited JMS and the easy accessibility of async messaging from Java as a big advantage. But now there are a bazillion messaging systems and most (if not all) of the major ones have easy to use client libraries in Perl, Python, Ruby, etc.

OTOH, Groovy/Grails brings a lot of the advantages of a RoR type framework to a JVM based ecosystem, as does Rails on JRuby, so more and more things are evolving to where the various platforms are approaching parity.

On the low end, I've always thought java has a significant disadvantage: memory footprint. In particular, this is compared to PHP/Perl/RoR/etc.

When you start your java app you pre-allocate all the memory you're going to need for the process' lifetime. This could be 512MB, this could be 2GB+, but it's never small. And this is unaffected by your initial traffic volume. It's the same for 0.001 hits/sec or 5 hits/sec.

On the other hand, if you drop a bunch of PHP scripts on a server, Apache only uses the memory it needs. Sure, you may have some pain scaling it later, but to get up and running you can get a cheap server and run your code.

Also, while I have your attention, have you ever tried installing an enterprise java webapp? It's not like you can pile a bunch of them into one JVM on a machine. I run confluence/jira/bamboo. Each has it's own requirements and basically need to run in their own tomcat servers tuned with their own settings. It's a huge PITA and eats up a ton of memory.

I can't speak for PHP but if you follow the usual Rails conventions for db structure, URL layouts, etc then it takes significantly less time to build (and maintain) a Rails site vs Java EE.

Simply collecting all of your Java libraries, frameworks, dependencies, etc and getting them running in your app server can take days. Minor changes like adding a db column can end up touching nearly every layer.

All these costs do have benefits. Java ORMs generate much more efficient queries than ActiveRecord, have more flexible querying, and better fit into existing schemas; JSP engines can render tens of thousands of pages per second; Java app servers are easily clustered; and much more. But most of that isn't something small or medium web apps use, so why pay the price?

I prefer scripting languages over a pure Java stack simply because I can reload the page and see what's happening with the new code. Yes, you can use JRebel, hook up a debugger and tweak settings to get some hot code replacement, but they've always failed me at one point or another, resulting in hours of fun. The compile-check-fix-compile cycle gets under my skin, especially when you're using frameworks and libraries that take a minute to bootstrap.

The JSTL is not a factor in speeding up development. A lot of people even prefer a Velocity or Freemarker template engine when they are using Java. And I've never worked with MyBatis but have done plenty of projects with Hibernate/JPA and let me tell you: I've often come at a point in a project where I was wondering how much time I had saved by not writing the easy SQL queries and how much time I had lost by trying to work around some random restriction in the Hibernate API. For all the "hate" Django's ORM gets, I've never run into the same obstacles.

With all that said, the Play! framework addresses a lot of these issues and is a lot more fun to work with.

This is one of the specific reasons the Stripes Framework (http://stripesframework.org/display/stripes/Home) was created. The idea behind it is that most Java frameworks require too much configuration and the start-up time (to get rolling with development) isn't short.

Stripes looks to solve both of these problems while making it (actually) fun to do Java development. There's extremely little XML config setup.

There's not a single person I know that's familiar with Struts (1 or 2) and/or Spring MVC (or any other Java framework for that matter) that's tried Stripes, learned it in a day or two, and not really liked it.

Daoud also has a great book, "Stripes: ...and Java Web Development Is Fun Again" that's a great resource for starting out. In addition, the Stripes community is small enough that you can access the code contributors on a daily basis through IRC or the mail lists.

With Stripes-Reload and Stripersist, you can get a CRUD app up and running in under a few minutes--I think that's on par with RoR, isn't it?

IMHO, it's worth looking at.