Ask HN: Why are there so few apps being built with JSP? | Hacker News Reader

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

40 pointsidleworx104 comments

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.

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.

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.

View on HN

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.

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

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.

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.

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.

Check out leiningen! It was made for people who are allergic to configuring the java stack.

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?

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

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.

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

jee stack is a set of specifications, you never "install it" or "set it up"

Agreed on the emotional. I have worked on several JSP sites that are 5 or 10 years old. In every case the JSP code is terrible. In all there was not a clear understanding of the MVC model. Sure there was some MVC handwaving, but for the most part there was a lot of java code doing bits of this and that which should be in the model.

Another problem is the 5 to 15 minute compile, deploy, restart the server cycle.

And the nasty use of XML to integrate the half dozen frameworks which are never consistent from client to client. All of this is a huge blow to productivity.

java stack in ubuntu can be installed mostly via apt-get, ie jdk + netbeans. I guess it depends on which particular jvm framework you're talking about on top of that as to how dicey it gets but for grails it's as simple as installing groovy, grails and the netbeans plugin for dev.

I've had no more issues with configuring a grails stack than configuring a rails or django stack, are you referring to some other kind of java framework here?

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.

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.

Yes, but the question was about jsp, which doesn't require any fancy tricks. :-)

Once upon a time some guy thought it would be a great idea to simply construct SQL queries, make the DB calls and loop over the result sets trying to create somewhat decent output, all in a single JSP. I'm so incredibly happy I never had to work with him again. When you're writing a very simple todo list: be my guest. When you're attempting to create any kind of decent application and do use JSPs like this: you're stupid.

Who said anything about all that?

See my reply here: http://news.ycombinator.com/item?id=1535945

Well, I would never consider jsp for that. But for certain view-layer duties, it works, it's simple and it doesn't require fancy tricks.

Agreed :)

Whoa, no need for the stupid comments. I wouldn't suggest a full fledged app in JSPs, yes thats insane ;-). Although, years ago I wrote blog where I could email my blogs in and I remember that first night I didn't want to set up a war and just wrote a straight JSP...I was only looking and I didnt want to wait. Obviously that is not a long term solution. However, having something that's wrong is better than not having anything done. You do make a good point, I think I will play around with Django, sounds like its faster than compile, war, deploy that java apps take. How much productivity increase do you see over java in terms of development?

I never meant to call anybody on here stupid, but it's how I felt about that guy back then.

It's difficult to quantify the increase in productivity using Django - since I never wrote the same project twice and a lot depends on the Java frameworks you use and the type of apps you write - but I certainly feel more productive and: happier! A lot can be explained by the fact that I'm basically forced to do the whole compile-war-deploy cycle on my current Java project and that Python allows me to write real generic code.

Be sure to first check out the tutorials in the Django docs because setting up a project for the first time can be a bit intimidating. Totally worth it, though ;)

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.

And that's why I thought he was talking about Java webapps in general. I mean, JSTL is pretty useless if that's the way you're going to use JSP. :)

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.

Yeah you are right, lets just forget using jsp without the framework model.

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.

From my experience, I agree with you on Hibernate. MyBatis however turned out to be rather painless. I've also noticed that Play framework and looks really great, just haven't had the chance to play around with it much.

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.

XSDs provide type-checking.

Try Wicket+Guice - no XML at all.

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.

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.

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.

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.

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.

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.

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

Yeah, but 99.9% of what you want to do with web.xml can be summarized in about 2-3 pages of documentations. It's NOT as complicated as you make it sound. The same goes for JSPs and JSTL. You could have a decent understanding of both technologies in an afternoon of reading.

No, but the documentation is horrible. Somebody should create those 2-3 pages of documentation.

Actually the web.xml spec got much worse somewhere in the increasing version numbers of Java Servlets. I rememeber just thinking "WTF" when I realized it was several 100 pages now. It definitely doesn't need to be that long, but I guess they wrote the documentation "enterprise style". It's just off-putting, who cares if the documentation could be simpler? They didn't make it simple, so I don't like it. Especially since the job of a Java developer is essentially digging through the mountain of specifications.

In my companies library there is a book "Handbook Of Java Development" with 1300 pages in small print. I think somebody left it there as a cruel joke.

Thanks for making me feel a bit better. The only way I can get a valid web.xml file is by getting started from a simple copy and then relying on my IDE to warn me when I'm about to make a mistake. Come to think of it: I don't know when I last started a Java web app from scratch. The first thing I do is copy the configuration from an existing project and strip out everything I don't need.

Use netbeans! I haven't had to manually hack a web.xml or build.xml in years. I do lots of Java development without touching XML.

Managing that stuff should be left the IDE, that's the sort of thing that XML was originally meant for, at least.

So they have very good and thorough documentation. Why is that a problem? In my experience, setting up web.xml is a matter of copying the prepackaged one and change a few lines to specify settings about your app.

It is unnecessarily verbose, just as Java itself. It is a problem because it makes finding and digesting the required information difficult. Unfortunately there seems to be only a choice between insufficient documentation (RoR) or too much documentation.

Anyway, if you are fine with Java, more power to you. The question was "why do few people here use Java" not "why nobody should use Java".

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?

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.

I'm curious what your framework of choice is.

Spring, Spring MVC, SiteMesh, JSTL, JSP and iBatis.

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.

Do you like Tapestry?

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.

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 ;)

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.

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.

Ruby deployment has gotten at least an order of magnitude less painful in recent years, particularly with Passenger (http://www.modrails.com/). On a couple servers I run the average memory footprint of a Rails app on Passenger (per instance) is 50-60MB.

heroku.com

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

I have run websites done in Java running on Tomcat plus MySQL plus Wine/Win32 programs and a few other services with 128M Linux servers. Tomcat takes up about 30M to 40M. The 512MB or 2GB are simply misinformation.

Original poster asked about enterprise webapps. Those that I've used are quite huge.

"It seems to me that lots of small to medium webapps..." from the OP doesn't sound like enterprise to me.

If you load lots of data in your app, it will use lots of memory. Doesn't matter what language it's in. It's a poor measurement of Java's memory requirement.

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.

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.

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

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

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

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

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

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.

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.

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

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

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

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.

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.

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

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.

-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

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

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.

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.

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

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)

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.

Django docs rocks on the other side... Better than PHP and jdocs.

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

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.

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?

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.

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.

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

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.

disagree on the documentation point.

Perhaps not the documentation of Java itself, but practically every third-party library I've ever tried to use has been a disaster. At least with Ruby or Python I can just dig into the source code, but with so many FactoryFactory's around...

well, I'll agree to that! Especially the factories :)

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

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.

That is pure denial, not a very professional approach

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.

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

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

It's the competency barrier.

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.

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

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.

Reply on news.ycombinator.com