CGI (Perl) vs JSP

[Nomis52]

I have a uni project comming up soon that involves some sort of database driven website. The group that I'm in for this project have narrowed our options down to either Perl or jsp.We all have experience in java (yet none in jsp) while two of us have experience in CGI using Perl.I haven't looked much into jsp but I'm guessing (hoping?) that there is a cgi.pm equivilent which will do the ground work for us.

Doing some reading around the web I've come across sites listing the advantages of jsp varing from "jsp runs faster than Perl" to "Java programmers are paid more than Perl prgrammers".I wonder if any monks with a foot in both camps could give me a *less* biased view of the two technologies.

IMOHO it would be a lot easier to do this type of thing in Perl than Java and even though I think it would be good to learn to use jsp, an assessed uni project might not be the best time :)

Many thanks,
Nomis52

[perrin]

Here's the deal: JSP pages get compiled into servlets, and have performance equivalent to servlets. They are faster than CGI, but so is molasses. They are NOT faster than mod_perl, and similar options like FastCGI. (Don't believe what the Resin guys say: their benchmark used slow perl code because they didn't know much about performance under mod_perl.) If you're using a database, the quality of the database drivers will have a large effect on the speed of your application. Last time I benchmarked it, DBD::Oracle seemed to be a little faster than Oracle's JDBC stuff, but not much and they may have improved it since then.

With the speed issue gone, you have two things to consider. The first is what it's like to use JSP. In my opinion, it's not so good. JSP uses embedded Java code, which is actually much worse than embedded Perl code because of all the casting and the difficulty of treating Java types generically. I think you'd be much better off with a good templating tool for Java, like FreeMarker, WebMacro, or Velocity. You can read more about why this might be a better choice in "The Problems with JSP". If you want to use a Perl tool that is similar to JSP in terms of embedding code in pages, you can read about the best perl options here.

The other thing you should consider is the experience that your team has. If you are mostly more experienced at Perl than Java, you will definitely write a better site quicker by using Perl. I personally find Perl to be more productive, but someone who had written as much Java as I've written Perl might disagree.

If you do decide to use JSP, do yourself a favor and at least get a decent tag library like the one that the Struts project provides. It basically turns JSP into a templating tool, which is a bit silly since the other templating tools are probably simpler and faster, but it does let you use something decent and put "JSP" on your resume.

[Dog and Pony]

I don't really have that much experience with JSP, but I have played with it upon occassion, since I have a java background among other things.

JSP itself is an easy system to write code and pages in, it works more or less like PHP or a Templating system for perl. You also have the advantages of easily put logic in external classes, and call those as you are used to. For frameworks that add extra functionality, tapestry might be of interest for instance.

On the other hand, I thought that setting up and configuring the system was a real pain in the behind. Java has some real strange quirks about how it is configured. This might be because I missed something, of course, but if I relate to the ease of installing perl (if it isn't already there), this is a nobrainer. That also includes mod_perl and friends.

JSP seemed like a pain also when building the applications, or pages. Lots of Manifest files and such that needs to be properly configured, although I gather that some tools are available to manage this for you. Again, I might have missed something...

While I wholeheartedly support JSP and Java over MS-technologies like VB, ASP and .NET, I don't really see any benefits over using perl. The above "problems" I mentioned are easily overcome, but I think that perl can do everything JSP can do - I won't judge if any of them are "better" though. I think that is a matter of taste.

On a personal level, I would probably build anything small to medium in perl, possibly with additions of PHP, Java or whatever does the job best at the moment. Anything medium to big, I would probably pick java, with additions of perl etc. This is, even though I do understand the OO ways of perl, and realize that almost anything can be done in perl, I feel more comfortable with complex (business) logic in java. I also feel the tools are way better for such for java, something I hope will be better in perl as time passes. :)

In conclusion, perl is most likely your friend in most cases, and should do the trick with less time, just as fast, and less hassle. Only reason to pick JSP would be to learn - I am very much for learning as many different approaches as possible - if nothing else, it probably makes you a better perl coder because it opens your mind to new ways of doing things.

Good luck with the project, in any case! :)

---

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

[jeffa]

JSP is what killed my love for Java. Marketers will tell you that it is faster than CGI, but they tend to look the other way when someone mentions mod_perl.

A company i used to work for replaced all CGI scripts with JSP ("um, have you considered mod_perl instead", "oh well, um, a-hem, um, we need JSP!"), and the site looks the same and runs about the same. Personally, i think that was a big waste of time. Starting from the ground up in JSP would be okay, but i really think a company needs to understand WHY they HAVE to use JSP. The main reason i can think of is that their programmers are really less than average. ;)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

[snapdragon]

I've had a play around with Jsp in the past like Dog and Pony I have some Java experience but I'm mainly a Perl head. IMHO I think Perl has to be the winner for it's ease of development. This is really because of two issues:
1. Java is a fully OO language and you do get all the benefits with that. However the initial developmemt time is longer and for most online transaction processing systems (which it sounds like you have) it's a bit of overkill. Quite simply Perl is a quicker solution (and from my own memories of university I seem to remember that deadlines have a habit of looming unexpectedly ;-). I know the counter point to this is that the OO developmemt makes extension and growth easier. But don't forget Perl allows OO development too so if you wish to go that way it still possible.
2. I've found (often to my own misfortune) that Java - Jsp - Servlets have quite a high lead time in actually setting the environment. Again I'm thinking about that fact that you probably do not have the luxury of time (if you did you could develop a system in both languages and make an informed decision ;-). With this is mind most UNIX systems come with Perl installed and most modules available. Or of you are of the Windows frame of mind there are Perl versions for that too.

I'd ignore the whole speed issue for the moment. The design of your system will impact speed more than language choice at this point (I'm thinking of issues like web page caching, persistent database connections, precompiled SQL statements...).

As for the pay point.... I have to say that in general Java developers are paid more than Perl developers. But the difference is not that big - have a look on some job web sites sometime and compare salaries for development positions requiring similar experience.

I've written a bit more than I intended to (sorry about that) but I've tried to give the best advice I can. I think that Perl would be the way to go (but then you might expect that this being perlmonks and not javamonks). Have a look at this link - it's got a good review on issues of Jsp vs Perl (and other server side langhuages too: PHP etc.) It does not specifically deal with Jsp but it does talk a lot about Servlets (which you would probably call at some point from a Jsp page) and compare preformance issues.

And then make you own mind up (go on choose Perl.... you know you want to...).

[hossman]

For starters, you shouldn' try to compare "Perl CGIs" to "JSPs". What you have to remember is that JSP is just a a templating system for creating Java servlets easily. If you want to compare it to something, compare it to a perl templating system, something like Mason is probably comparable.

I write Java Servlets & JSPs at work, the "CGI.pm" of JSPs are the HttpRequest and HttpResponse classes (and instance of which is magically created for you) which have all of the methods you would expect. The Chief Architect at my company is no bone-head, he did a lot of performance analysis of both Weblogic proxied through Apache & mod_perl, assuming that people wrote "imperfect" JSPs & CGIs (ie: not optimal code) and determined that the performance of JSPs in Weblogic was pretty much the same as mod_perl. He choose to go ahead with Weblogic &JSPs because he thought it would be easier for people with very little programming experience to write JSPs then to write perl scripts. (NOTE: he didn't try any Perl templating systems.)

If everyone on your team has strong Java experience, you might as well stick with that. The meat of your work can be done in support classes that won't be any different from any other Java classes you've written, using JSPs to generate the HTML should be relatively trivial to pick up. Your whole team can probably learn the syntax of JSP tags faster then you can get the remaining guys of your team to learn Perl from scratch.

[cjf]

Use JSP.

Now why would I say that you ask? For a few reasons of course:

• You sound like you know Perl a lot better than JSP, it's always good to learn new things, and to know your options well.
• You'll appreciate Perl so much more after this. I never knew how much I liked Perl before I had to learn Java.
• You asked this question at a Perl Monastery, not just a Perl discussion website, but a Monastery. Your blasphemy will not go unpunished. ;-)

Also, after you're done your project, see my thoughts regarding Sun here

[dash2]

Which you should use is probably 80% down to what your team prefers. If you all are used to Java, then Java will be easier. OTOH, you might all just "feel like" learning something new.

Never mind how much people get paid. Start worrying about that at your age and you will be a wage slave before you are thirty.

With those sage counsels out of the way, I can tell you a bit about JSP equivalents in Perl.

• HTML::Mason is a nifty solution for embedding perl in HTML. I've got direct experience of this. It is powerful and flexible and combines well with mod_perl.
• HTML::Template is a simpler templating solution. It enforces better separation of code from presentation than Mason. OTOH you might not want that if you are not doing something that requires a very prettified front end.
• Other things to look at: Template::ToolKit, EmbPerl ... anyone got any experience with these?

dave hj~

[drewbie]

I primarily use TT in my CGI projects. It's not the fastest system, but it's fast enough and very flexible. I've also used HTML::Template, but switched to TT w/ the next release of my project.

My reason was that I (the programmer) had to do too much work to get the data in the correct format H:T required so the HTML guys could do their thing. With H:T I had to do all kinds of massaging because the syntax is very simple (by design). With TT, I just throw data structures at the template folks and they can use it how they want since TT can parse all kinds of data structures.

Just my $.02.

[Bukowski]

Hi Nomis, I'm sure that none of this is going to be any news to you with the other answers. Yes CGI.pm exists, and I use it almost exclusively for this kind of purpose (web database front ends). You can find all sorts of information on the authors site here.
However this is not all you need for your database. Assuming you are going to need some (real) database interaction (eg postgres, mySQL, oracle) you will need to investigate the DBI (database independent) and DBD (database dependent) modules for easy access to such datasources.
Personally I can't see any point doing this in jsp - the experience is there in perl/CGI and the lesson in database integration will be just as valuable in perl as any other language.

Bukowski - aka Dan ([e-mail])
"Coffee for the mind, Pizza for the body, Sushi for the soul" -Userfriendly

[mortis]

I've used both Perl (HTML::Embperl) and Java (JSPs and Servlets) for some larg-ish e-commerce sites (vwrsp.com - Perl, and merckeurolabs.de - Java).

The first site was 2 developers for 4 months. The second was 7 developers for 6 months (with 30% of the features of the first, though it did have internationalization requirements that the first did not). For development speed and performance, (mod) Perl won. For code readability and management acceptance, Java won.

Of course the experience (pain) of using both HTML::Embperl and JSPs/Servlets was what lead me to start Pas, which has (IMO) most of the best aspects of both approaches.

[perrin]

Rather than write your own templating system, I think it would serve you better to look at the other options like HTML::Template and Template Toolkit. If you prefer in-line perl code, Mason is a good option. Nearly all of the perl templating systems compile the template to normal perl code, so there's nothing really unique that I can see about Pas.

There are also nice systems built on top of some of these, like OpenInteract and Apache::PageKit.

[Tyke]

I suspect that JSP is the best choice when
1. The backend processing is fairly complex... (ie. lots of hairy business logic and not just a database connection)
   and
2. it's implemented using EJB's, so as to share the logic with other (Java-based) systems.

Otherwise CGI::Perl / an appropriate templating system, as suggested by other posters, is more than sufficient; and (IME) has fewer gotchas.