
Ask HN: Why are there so few apps being built with JSP? - idleworx
It seems to me that lots of small to medium webapps are built either in php or in ruby on rails. I'm wondering why there seem to be only a small minority of webapps (at least not enterprise ones) being built using JSP technology.
Most articles and posts I see on HN seem to be webapps built with other technologies but Java.<p>JSP web apps can be built quickly as well. Eg. you have the JSTL tag library, and orm frameworks such as MyBatis or Hibernate. And there are also other things for simplifying, decoupling and modularizing a webapp like the Tiles framework, Struts, Spring MVC frameworks etc.<p>Now, I know for a fact that there are some other advantages php or rails apps have, particularly the lower price of hosting and possibly smaller memory requirements, but I'm wondering if there are any other reasons that JSP/Servlets/Java based small webapps are such a small minority and why adoption seems to be rather low for small to medium web 2.0 apps.
======
10ren
My opinion. It's partly because teams who do webapps tend to be small, young
and agile. First, prejudices: they prefer new things (Java is old); they
dislike the environment that is Java's home (big enterprise) and the practices
and personalities types that go with it (perfectionistic, professional,
conservative).

Second, real reasons: Java is verbose and statically typed, and therefore it
takes more work to make changes - it is slower to develop in and less
flexible/agile. These things really count when you want to try out an idea;
and when you need to adapt it. There's also a community effect, where all
those early adopters are working with Ruby/Python, that's the platform cool
stuff gets developed for (eg. sinatra, github, haml).

Technically, it's possible to write a sinatra in Java (I have; using
annotations for urls); but who would use it? I actually love Java myself,
including its static typing, and use it in my startup. But when I've played
with Ruby - even as a novice without knowing the tricks - I found it much
quicker to develop in, and the code easier to understand because less
cluttered. It's probably not as reliable; and the code doesn't run as fast;
but these things just don't matter for prototypes and early versions.

~~~
drivebyacct2
What sort of easy changes are people making that verbosity and static typing
would prevent? I get the heebiejeebies trying to imagine that...

~~~
lemming
Exactly - I often read "easy changes" as "I don't have to think about all the
implications of this" which is never good.

Personally I find Java one of the easiest languages to make functionality
changes in just because of the excellent refactoring tools that are available.
People always claim to feel restricted by the language when they use Java. If
they're using emacs or Textmate to edit it then sure, I can see that.
Personally, whenever I'm writing something other than Java I feel desperately
restricted by the tools - editors that don't have semantic knowledge of the
program structure and just treat it all as text seem unbelievably primitive to
me now after years of using IntelliJ.

~~~
davelnewton
Refactoring isn't a functionality change--functionality should stay exactly
the same during refactoring; that's why unit testing makes refactoring easier.

 _Functionality_ changes require expressiveness, something Java lacks, due to
its superfluous ceremony. Functionality changes require an ability to clearly
see where and how things are done, and this is obscured by the extra noise of
Java.

Java 5/6 went a fair ways to mitigating this... somewhat. And IDEs can help
reduce extraneous noise (like IntelliJ's <~> for generics). But it's not
eliminated, and it's not enough.

Java still has an impoverished model of abstraction and OO, it forces me to
repeat myself _continually_ (and having an IDE do the grunt work of repetition
doesn't help-- _nothing_ should have to do it), and that both slows me down,
and obfuscates meaning.

The tooling is the only thing that makes Java even remotely palatable.

------
iamelgringo
For me, it's purely emotional.

My last class at Uni 2 years ago was a survey of web dev technologies. We
built sites using ASP.NET, Perl, PHP and JSP. Java and asp.net were tied for
worst experience ever. Setup and configuration of the Java stack was 2/3rds of
the project. And, that's after taking 2 years of Java in school. Setting up a
Java stack on a Ubuntu or a Windows box was equally as painful for me at the
time.

My experience at school as made me loathe to try anything Java related. And,
while I love the idea of the jvm, I have a pretty visceral emotional reaction
to anything java related. I know it's wrong, but I can't even bring myself to
do the installation required to mess around with Clojure or Scala.

I get the same vibe from a number of young developers I come across at Hackers
and Founders SV meetups that have recently graduated from school. Someone
mentions Java at our meetups and everyone at the table groans.

Python and Ruby are essentially lingua franca here in Silicon Valley startup
culture, with C and C++ mixed in for speed. I've settled on Python/Django for
day to day dev work.

In my case, even though Clojure and Scala look really sexy. The thought of
installing a jvm based development environment makes me break out into a cold
sweat. If I'm going to play around with a "sexy" language to learn stuff I'm
going to play with Haskell, Erlang, or O'Caml, just to avoid using the jvm.

~~~
rit
What's the big deal with setting up a "JVM Environment"? Working with Scala
for me involves the latest Scala distro and a copy of VIM. Is there something
in particular that makes it so painful that I"m missing?

~~~
davelnewton
Yes--there's more to setting up a JEE stack then getting a JVM and a language
running.

~~~
prodigal_erik
I sometimes do "yum install tomcat6; sudo rctomcat6 start; emacs foo.jsp" just
to dink around with the odd corners of the servlet API (I'd do it in Eclipse
if it weren't such a pig). You can just ignore a lot of the painful ceremony
that JEE wants to inflict on you.

~~~
davelnewton
Sure, if you don't need it. The bulk of my JEE work is somewhat more complex
than "dinking around with the odd corners of the servlet API".

------
mindcrime
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.

------
roam
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.

~~~
kp212
You can do that with a JSP page, and Tomcat. You can use JSP very much like a
scripting language (no need to hit a servlet, controller, etc), but obviously
it can get a little messy to manage depending how large of app you write.

~~~
tomh
One big problem; if you keep most of the Java code on the servlet side and you
throw an exception, the stack trace will give you the line number of the
offending code.

OTOH, if you do all that heavy lifting in the JSP side, depending on your
choice of server, you get a stack trace...either without a line number, or
with a line number of the JSP which was compiled and turned into a Java
program on the fly.

And we all know what machine-generated Java looks like, right? Like a big
plate of pain with some extra pain on top. Good luck bug-hunting that one.

~~~
eccp
Not entirely true. On Tomcat 5 and 6, the resulting code is _really_ close to
the original, plus lots of out.write().

If the logs show an exception on
org.apache.jsp.mypage_jsp._jspService(mypage_jsp.java:NNNN), you can find the
generated Java class on TOMCAT_HOME/work/Catalina/localhost/myapp and it's
rather straightforward from there.

I do this on a daily basis to maintain a legacy app. Not sexy but, not hard
either.

------
samdk
The biggest problem with Java webapp development, in my opinion, is its
ridiculous obsession with XML. I can't count the number of hours I've wasted
debugging obscure errors only to discover that I had a minor syntax error in
my XML configuration files. In a framework like Rails, 90% of what I have to
specify in those XML config files is assumed by default anyway, and almost all
of the rest is done as Ruby code, which means I get actually intelligent
errors when something is wrong.

Basically, it seems to me like Java web development uses XML as a dynamic
programming language when they're trying to do something Java's not well-
suited for. The issue is that XML has absolutely no type-checking at all, and
so you end up with errors that make absolutely no sense when the only issues
you have are simple typos.

The problem is even worse because you seem to end up having to specify the
same information in so many different places, and having mistakes in just one
of those will prevent anything from working.

I am sure there are ways around this, but the whole point is that if you're
using a framework like Rails, you don't need to deal with _any_ of this. It
all just works, and having wasted months of time on Java web dev, I want to
deal with a system that _just works_ , not a system that requires ten or
twenty kludgey three- and four-letter band-aids to get it to behave
intelligently.

~~~
visural
Try Wicket+Guice - no XML at all.

------
mark_l_watson
Although I use Rails for most web apps that I do now, there was a period from
about 11 years ago to about 5 years ago that JSP was the sweet spot for me. I
would put a lot of embedded Java in JSPs, and as an app matured, I migrated
the code to custom tag libraries (easy to write once you have everything
working in JSPs).

For me part of the lure of JSP apps was that I really liked Tomcat as a
development and deployment platform. For apps that needed a lot of background
processing, I started work threads in servlet init methods, and liked having
everything in one JVM.

I had one app running without restart for several years until my customer's
admins let the server run out of free disk space. I am not at all confident of
a Rails app running for 3 to 4 years with no restarts.

To answer your question: I might still choose JSP for high volume web apps.
For apps with a modest number of users, Rails makes more sense for me.

------
lukev
Actually, there are far more apps being built on various Java stacks than the
alternatives - it's just that the people using them collect a paycheck and go
home at 5 rather than blogging about it. The heavyweight, large business and
government market is almost exclusively Java

Also, lots of people judge Java frameworks based on monstrosities like J2EE,
Struts or Spring. But there are several very nice, truly lightweight Java
frameworks, and even more for alternative JVM languages. The Java stack often
_does_ suck, but it doesn't _have_ to suck.

------
narrator
I am a Java developer in my day to day work but I'll give a few reasons:

1\. The memory footprint of the JVM is significantly larger for a similar app
vs. PHP. Also, it requires a lot of tricky JVM option tweaking to get it to
work in anything less than about 512mb.

2\. The build environment is really heavy weight and complicated. Maven seemed
crazy at first though working with it for a while finally got me used to it.
It's still crazy complicated compared to rails/python.

3\. Lack of code reloading when you hit refresh. JavaRebel fixes this, for a
price.

4\. Java code is really verbose. You have to become an expert at a lot of IDE
features before you can get decent productivity. You absolutely cannot use a
simple text editor or anything less than one of the big 3 IDEs (Eclipse, Net
Beans, Intellij) and get anywhere.

The future is bright though for the JVM. I have started to work more with
Scala/Lift lately and I am really blown away at how fast and powerful it is
compared to traditional Java development.

~~~
democracy
1\. It depends on your app, you can go ahead fine with 256 megs with no crazy
jvm tweaks at all.

2\. It doesn't have to be complicated - it's the developers who make it so.

3\. it depends on your server and configuration. Every server supports class
reloading and jsp recompiling.

4\. You don't have to - eclipse and netbeans are free and very powerful.
Notepad for simple tweaks if you have to.

------
Tichy
Just to set up one of the Java frameworks you list is already a lot of work
and a lot of wrangling of XML.

Without frameworks, it is probably OK if you already have a working web.xml. I
used to just copy my working web.xml and modify it. Good luck if you want to
create a working web.xml from scratch, though. The specification for a proper
web.xml is a PDF with several 100 pages (last time I looked, a couple of years
ago), and to parse it you basically need a scanner for XML specification files
in your brain.

That is only for creating the working web.xml. Specifications for JSP and JSTL
are several hundred pages on top of that.

~~~
aagha
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.

~~~
democracy
it still needs web.xml, doesn't it?

------
arete
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?

~~~
jbail
It doesn't take me days to get a Java web app up and running. It takes me
minutes. In days, my Java web app is done.

I'm a senior engineer who codes for pleasure, so maybe I'm faster than average
--- but if it's taking you days to get your libraries together and minor db
changes touch every layer, you're doing something wrong.

~~~
arete
Recently I started working on a new project using Tapestry 5.1 in GlassFish 3.
That particular combination requires replacing GF's StAX lib with a different
implementation that Tapestry depends on. Then there's the usual issue of
reconciling the 2-3 different logging frameworks that various components
depend on, writing the (albeit minimal XML descriptors for the app, web app,
EJB, configuring resources in the app server admin console, etc.

It's unlikely you can do all that in minutes, so you're probably talking about
copying an existing app template.

Adding a db column requires modifying the entity itself, DTOs, form beans, and
of course the relevant JSP/templates. With Rails conventions you'd only modify
the pages.

~~~
jbail
Do you like Tapestry?

~~~
drivebyacct2
For what it's worth I had a nightmare of a time with it. Especially Tapestry
5.0, 5.1. The documentation is atrocious and out of date. Also, it could have
been a novice mistake that resulted from days of all nighters in a row, but I
had a critical bug that prevented me from delivering that, as a TA later
discovered, was resulting from my form validation occurring once for each form
element on the page rather than executing once for the entire form.

~~~
ollysb
I've just moved over to rails. After 6 years of using poor APIs tapestry 5 was
what finally tipped me over the edge. On the project we used it for we would
actually allow 2 days to get a tapestry page working correctly. Howard
(creator of tapestry) seems to believe that html and http were a mistake and
that he's created the event based solution to hide it away. The result, helped
along by the lack of docs, is that even with what would have been the simplest
of tasks with html and http become an impossible hunt through his dodgy
codebase. Far and away the most painful framework I've ever had the misfortune
to use. Worst part was that is was me that was seduced by the seeming
simplicity of it and chose it in the first place ;)

------
garyrichardson
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.

~~~
Tichy
Actually I am afraid to host a RoR app on my server, which runs several Java
apps. I think the server has only 256MB of RAM (it is old, but cheap), or
maybe 512 - not a lot, in any case.

I am much more worried about memory consumption of RoR. Never really launched
it in production, but wasn't it the case that you have to load balance between
several Mongrels, each consuming > 100MB of RAM?

Java is just unpleasant to use - other than that, it is very fast and memory
consumption is ok.

~~~
WALoeIII
heroku.com

~~~
Tichy
The "demo" version of heroku has only one process, I think, and 5MB storage.
The first professional version is already quite expensive. I pay 10$/month for
my server (split with a friend).

I host several projects on that one server (incubation...).

------
neovive
From my own experience of working with Java/JSP at work and PHP for side
projects (I'm also learning Python), it comes down to developer productivity
-- rapid application development, deployment speed and developer experience.
For most small- to medium-size projects, you can achieve the same results in
Java, PHP, Python, Ruby and even ASP, but the journey towards completion
varies greatly across languages and tools.

IMHO deployment on the Java stack is not as fun. Time spent configuring
Tomcat, Ant, and compiling code adds-up, especially for a basic web app or
prototype. The Java stack also has a larger learning curve for beginners.

However, if you work on "enterprise" applications, especially ERP, finance and
banking, Java is currently the lingua franca.

~~~
jbail
A good IDE can help most of the issues you mention. Eclipse is free and you
can compile Java web apps in it without Ant. I've worked places whose
deployments involved making a WAR file from Eclipse. Configuring Tomcat in
Eclipse takes a few clicks to basically just point to where you have your
Tomcat directory. Compiling from Eclipse requires you to click a green arrow
icon.

------
jefft
IMHO the answer is here in this thread... which would you choose?

a) php b) rails c) Java +
JSP/Servlets/JSTL/Tiles/Struts/Spring/JSF/Play/Wicket/GWT/Stripes/Tapestry/WebObjects

~~~
DanielRibeiro
This is not really accurate.

When using java, you will not use JSP, JSTL, JSF, Play, Wicket, STripes,
Tapestry, etc, all at the same _time_. Unless you are crazy.

The same way, in Ruby, you will not use ERB, Haml, Erector, Markaby, or the
other (at least) 19 template engines out there ([http://www.hokstad.com/mini-
reviews-of-19-ruby-template-engi...](http://www.hokstad.com/mini-reviews-
of-19-ruby-template-engines.html))

But this comparison is not actually fair, because you mixxed template engines
with frameworks. To be fair, you'd have to add Sinatra, Camping, Rails, Merb,
Ramaze, Padrino and Hobo to the Ruby list, and CakePhp, Zend and Symfony (at
least) to the Php list.

It is not which language has the most options of framework/template engines,
but which has the best optins. JSP is one of the worst template engines on
Java land, and this is why it is not used as much (well, there is also the
fact that it has a very bad reputation, and JSF is considered its successor,
but it is worse nonetheless).

~~~
democracy
I upvoted, however the statement "jsp is not used as much" is not true - it is
used on 99.9% java web apps out there

------
jedwhite
Try out Google App Engine's Java support and the Eclipse plug-in, and if
you're after a Java framework check out GWT.

I love Python and work in it almost entirely now, but previously worked with
Java (yes I know the joke about them being the same with the whitespace re-
arranged).

GAE gets rid of most of the configuration and scaling pain. Plus it's free to
get started. There are some limitations, but essentially it makes deploying
Java web apps a snap.

<http://code.google.com/appengine/docs/java/overview.html>

~~~
ravih
GWT is the more heavy weight than JSP. Whole app takes 2 minutes to load in
hosted mode. In my opinion if one has to choose Java then my ideal stack is:
JSP, Spring, Hibernate, Java.

For personal projects: I am a Grails guy. I love it. Dynamic methods on Model
classes, no need of DAO's per say, GSP tags are great.

I have also developed using Python and Django. And loved it. Grails gives me
that only in Groovy/Java which is awesome!

My 2 cents.

------
rryyan
I think Java and its plethora of frameworks makes new developers feel
overwhelmed. Python clearly has Django, Ruby clearly has Rails, Java has...
what? Struts? Spring? Tiles? Servlets? JSPs? Tag libraries? Where do you
start?

To an outsider, it feels like there is a mountain of material to wade through
before you can really get going with a Java webapp; for Python and Ruby, the
perceived barrier to entry is much lower.

~~~
mindcrime
> Python clearly has Django,

To be fair, the picture on Python isn't totally clear either. You can choose
from Django, Pylons (my preference, btw), Turbogears and possibly others...
and you have the choice between SQLAlchemy and the Django ORM, etc. Picking
Python definitely does not alleviate the need to make some evaluations and
decisions.

------
paolomaffei
It takes you 10 periods of time in JSP to do what you can do in PHP in 1
period of time.

~~~
democracy
example of code that takes 10 more lines of code to write in JSP than in PHP,
please?

------
smitjel
You're asking this question on a site that is "startup focused" which means
they aren't going to have a team of 20 developers churning out java byte
code...they're going to be using more modern, dynamic languages like Python
and Ruby because the popular full-stack frameworks that are behind Python and
Ruby are better suited to get ideas off the ground as opposed to the
monolithic JEE stack.

------
tzs
I used to write desktop apps and also do drivers and VxDs for Windows. One of
the things I strongly disliked about that work is that you are working in an
environment where there is a huge amount of infrastructure that you are
intimately dependent upon and that is hidden from you.

Java brings that kind of thing to the server, and I want no part of it.

~~~
lukev
Just to be fair - if this is your criteria, Rails is worse than most Java
stacks.

------
tomjen3
Because it is an abomination - it has less power than most of the other
template frameworks available for Python and Ruby, and the tag libraries
require mountains of XML if you want to write your own.

Now the basic servlet idea is pretty damn nice, and once you have your code
written final deployment isn't that bad.

------
dkberktas
-steep learning curve compared to rails, django, grails, etc \- lots of configuration (I mean a lot, no convention over configuration) \- application servers are not easy, tomcat can be a nightmare in term of rapid deployment/undeploy routines, just think about heroku on the other hand

~~~
democracy
grails is java, right? and if we are talking about "jsp" then jsp recompiling
is a standard in any server out there

------
sethg
One can make a case that when a team of developers uses JSP in the context of
the entire Java EE stack, it gets certain advantages that outweigh the
overhead of developing and maintaining all of JEE’s moving parts. My last
experience with JEE was pretty horrific (portlets! Java Faces! madness!), so I
am not eager to try this again, but at least an argument can be made in favor
of JEE for certain applications.

If you take away the rest of the stack and are just using JSPs... why bother?
I have found a certain comfort zone using Django and I’m not going to switch
to a different framework or language just because it’s _possible_ ; I would
want to know why that alternative gives me a _significant advantage_ over what
I’m doing now.

------
sqrt17
Actually, you can code very nice lightweight apps using an embedded servlet
container like Jetty, a JSP library, and an ORM (MyBatis or Hibernate). Which
is kind of like the idea of a microframework.

I've used it for a demo I've made (some NLP stuff in Java that needed a web
frontend, but where running it under Tomcat would have been like the tail
wagging the dog) and it worked quite well.

I guess that all the people who want a microframework to get small things done
efficiently have moved away from Java at this point, appalled by the whole
J2EE circus. And once you have something as elaborate as the J2EE stack as
it's meant to be, JSPs are not a good fit, because they don't enforce a
separation between presentation and business logic.

------
grandalf
I find javadoc very ugly and annoying to look at. Dumb reason, I know but I
can't get past it.

~~~
hoggle
To be fair - neither ruby/rdoc and rails api documentation are much if any
better in that regard. I like the ruby/rails ecosystem but the javadoc
approach was IMHO really OK as well (I don't talk about some of the parts of
the standard library / the API itself)

~~~
grandalf
I dunno I find rdoc significantly better organized and easier to read.

Maybe it's the lack of a README concept that offers a high level intro to the
library.

edit: maybe it's the font too. I have slogged through javadoc a few times when
I've had to use java for something, but overall it's fairly high friction /
annoying to learn an API via javadoc.

------
nirav
Three reasons I can think of, in order of time to get things done:

1\. Availability, ease of use of Java based hosting provider

2\. Time from writing code to live deployments

3\. Lack of agile frameworks like rails, django or any other php framework
(hot code reload etc.).

------
naos_pl
I moved all my webapp development from java to python+django. What I observed
is: \- I code webapps much faster now \- I produce a lot less lines of codes
\- Testing is so much faster due to uncomparable faster deployment time on
development server \- Templating engine is more clear \- Configuration is
faster, everything in one file, no sucky XMLs! \- Python is easier to read and
so fun to code

Ultimately I feel now that moving from PHP to Java was a step backward, and I
feel like now I made a big step forward by moving to Django.

------
kp212
I know that Fleaflicker which was posted here was a java based app. So they
are out there, but I think more of them are from the 2000-2003 time frame. Has
anyone here gone from the Java Stack to RoR? What would you recommend to
anyone making that transition? I want to make my next project a "learn a new
lang" web project. I fairly strong understanding of the Java MVC(Spring,
Struts 1), and DB transactional frameworks(Spring JDBC, Hibernate) and wonder
what I should be reading for a transition?

------
toastr
Here's why (and I'm flammable):

Because it sucks. Seriously. I don't want another bloated framework like
tiles, struts or even Spring MVC (and yes, I know it's the 'less bloated'
framework).

You know what the best user interface is for Java apps? XML, JSON or Java. You
know what the best framework is for a webapp? Me either, but it better fucking
be html, css and javascript.

It's not rocket science. For fucks sake if I wanted a framework for my front
end I'd use the native language.

------
msencenb
I can't speak for everyone but the reasoning behind my choice of php is 3 fold
1) Ease of set-up 2) I'm simply more comfortable with php 3) Better online
resources / documentation

In the end it came down to picking a language I was comfortable in and could
start moving forward the fastest with.

------
kdonald
If you want to see what Spring MVC brings to the table, checkout the following
showcase:

[http://blog.springsource.com/2010/07/22/spring-
mvc-3-showcas...](http://blog.springsource.com/2010/07/22/spring-
mvc-3-showcase)

------
thenduks
A few major reasons:

\- The verbosity of Java wears on me very quickly.

\- I can't stand working in an IDE.

\- Documentation is abysmal.

\- I'm not familiar with the ecosystem (so I don't know what to use and when
-- What's 'Struts'? What's 'Tiles'?) and there doesn't seem to be a place to
learn.

~~~
idleworx
\- I can't stand working in an IDE.

Are you saying this because you mostly work with smaller web apps, or other
reasons? For larger projects I find IDE's (especially Eclipse for JAVA
indispensable).

~~~
thenduks
I work mostly on large web apps but that doesn't have much to do with my
dislike for IDE's.

The reason I don't like them is that I don't want 90% of what it gives me. My
'IDE' is 1 gvim per project and a terminal app with a couple tabs. I can't
think of anything an IDE gives me that I don't a) want or b) already have.

~~~
democracy
That is pure denial, not a very professional approach

------
noodle
i do java at work, and ruby/python/php at home. for me, its simple.

java and its frameworks are too bureaucratic. getting things done requires too
much. in an enterprise environment with lots of developers, this is good. in
an agile, rapid development type of environment with a small handful of
people, this is bad.

the closest thing that i've come across that made me want to consider java
apps development is grails.

------
keefe
My server is in java and I hate jsp's. I prefer rest with json and a thickish
client. imho jsps muddy mvc design.

------
iCrusader
Lack of easy and cheap hosting is one big reason for small to medium web apps.
That is what i think.

------
ww520
It's the competency barrier.

------
drivebyacct2
I actually have come to enjoy java servers/services this summer at my
internship, but there is no way in hell I'll ever do anything with JSP, ever.

~~~
idleworx
Could you expand some more? Why do you 'love' JSP so much after your
internship?

~~~
drivebyacct2
No, I hate JSP. I enjoy writing servers and services in Java. I like the
statically typed nature, I like the language constructs and I like the breadth
of existing examples.

