This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes JSP/Servlet against other framework (Wicket, Struts2, SpringMVC/Webflow, Click, JSF) Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "JSP/Servlet against other framework (Wicket, Struts2, SpringMVC/Webflow, Click, JSF)" Watch "JSP/Servlet against other framework (Wicket, Struts2, SpringMVC/Webflow, Click, JSF)" New topic
Author

JSP/Servlet against other framework (Wicket, Struts2, SpringMVC/Webflow, Click, JSF)

Edwin Nathaniel
Greenhorn

Joined: Feb 01, 2010
Posts: 8
Hi all,

I'm very sorry if this question has been asked many times but I can't seem to find a discussion that compares JSP/Servlet against any of those framework (instead I saw JSP vs JSF, JSF vs Wicket, etc).

I'm new to web development. Currently I am using GWT and GWT Servlets (once in a while we do use plain vanilla Servlet) at work (been using it for 2 years). GWT has a different paradigm than the usual way of HTML/JS/Templating solution so I'd like to give the other side of the spectrum a try. I've used Rails just for fun long time ago and I like the simplicity of its approach. Some of the Rails components are quite common: a controller (like Servlet), a view (like JSP), an ORM (JPA/Hibernate).

So here's my question: Why do people invent JSF, Click, Wicket, Struts2, SpringMVC/WebFlow and other Java Web framework while the JSP and Servlet seem to work... (as long as you don't write your JDBC code in JSP). Is it because JSP/Servlet:

1) Hard to test?
2) Hard to maintain?
3) Doesn't work for the Web? (some people say that ASP.NET WebForm "doesn't get it")
4) Have severe limitations?
5) Or something else...

I don't mind wiring things up manually and writing code that other frameworks might've done (say... validation... or other things). I'm trying to keep things simple and explicit. Besides, I'd like to learn how things work...

Thanks,
Ed
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60050
    
  65

To be honest, it's beyond me. I'm not, and never have been, a fan of large monolithic frameworks (and loathe things like JSF with a passion bordering on the pathological).

For me, I can do things quickly and more easily with a smaller set of tools. (Which is why I came up with Front Man -- a simple front controller implementation).

I'm sure you'll get a lot of other replies from all over the spectrum, but for me, the big frameworks just get in the way much more than they help.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Edwin Nathaniel
Greenhorn

Joined: Feb 01, 2010
Posts: 8
Mr. Bibeault,

Thank you for the response. I agree with your thought. Although in my case, I prefer to hone my skill to a specific set of tools rather than say "well this doesn't work, let's build another completely new solution" [that has not been proven...], when the thing that doesn't work is probably not so much of a big issue but just need time to perfect it.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15286
    
    6

Lots of possible answers to this question. Bear answered one perspective. I'll try and answer with the opposite of his perspective (even though I agree with him to a point).

After a while, you find yourself doing the same things over and over....and over again. This is what breeds frameworks; taking common tasks and wrapping them up into some sort of reusable system. Sometimes this is as simple as an API and other times, they become full blown frameworks. And unlike Microsoft Developers who generally think there's one way to do everything, java developers always think we can do it better than the other guy.

What we have at this point is a lot of very similar frameworks in roughly 3 different camps.

Action/Request based: Struts2/SpringMVC/Stripes.

Component based: JSF/Wicket/Tapestry/Click

Full Stack: Grails & Seam

My backstory...I primarily was using Stripes because it was simple enough. And more often than not I found myself using the same set of tools with Stripes; Spring + JPA/Hibernate. So for me, jumping to Grails which is basically Groovy on top of Spring + Hibernate, was a no brainer.

Even though I agree with Bear that simpler is better I think Grails is simple enough and I can develop with it very quickly. Other developers feel the same way about their framework of choice. And still others feel they are most efficient writing pure JSP and Servlets. There are a lot of factors that go into choosing a framework like personal taste, your team, support, etc. So basically, you just have to weigh all those different things and decide what is best for you. Nobody can make that decision for you.

But all boils down to the fact that we have so many choices because we can. Choice is a good thing.


GenRocket - A Test Data Generation Platform
Edwin Nathaniel
Greenhorn

Joined: Feb 01, 2010
Posts: 8
Hi Gregg,

Thank you for your input. How good is JSP/Servlet in terms of libraries? Let's say if JSP/Servlet is compared to a typical Rails (let's take out REST out of the picture or XML based API stuff). A simple web-app (form, auth & auth, validation, a bit of re-use of the view [navigation, header, etc]). It seems to me that Servlet is pretty much the controller, JSP is the view, and JPA is the ORM. Of course what defines Rails is the RAD nature. But I don't mind to set things up manually as long as everything is explicit and I know what's going on...

By the way, I'm sorry if this is sort of out of the topic a little bit but how do you test a JSP/Servlet app (especially the JSP part). Any tips or tricks?

I'm still green in this field but every day I often see people focusing on frameworks instead of simple, proper, and robust design (be it the domain model, the db schema, the table, the business logic or the overall app). It just doesn't feel right...

Thanks,
Ed
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15286
    
    6

How good is JSP/Servlet in terms of libraries? Let's say if JSP/Servlet is compared to a typical Rails (let's take out REST out of the picture or XML based API stuff). A simple web-app (form, auth & auth, validation, a bit of re-use of the view [navigation, header, etc]). It seems to me that Servlet is pretty much the controller, JSP is the view, and JPA is the ORM.


I can't speak for Rails but as far as libraries and JSP/Servlet, there's endless supply. You will be left with the task of wiring everything together. Whereas some frameworks take care of the boilerplate for you.

I often see people focusing on frameworks instead of simple, proper, and robust design


I'm unclear on why you think using a framework means a system is not simple, proper, and robust. Most modern frameworks are designed to adhere to proper design principals and follow established patterns. Some more than others. As I said, it really boils down to your own comfort level. If you think a framework doesn't work for you, simply don't use it.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15286
    
    6

By the way, I'm sorry if this is sort of out of the topic a little bit but how do you test a JSP/Servlet app (especially the JSP part). Any tips or tricks?


A quick google search reveals a lot of different options. If you're asking me personally, however bad this is going to sound, I generally don't. My JSP's (or whatever template I may be working on) has so little code and logic in them, testing them wouldn't amount to much.
Frederic Daoud
author
Ranch Hand

Joined: May 22, 2008
Posts: 71
While I agree with Bear that large monolithic frameworks can get in your way more than they help you, and I certainly share his feelings towards JSF (I hate it with a passion), I wouldn't want to develop a web application with just Servlets and JSPs.

You start out nice and simple, but then, what happens when you need to support file uploading? That isn't a simple issue. Maybe you pull in a library like commons-* and you're all set. Then you need (other common feature) and you pull in (other lightweight library that neatly solves the problem). So really, you are building up your own custom "framework" as a combination of libraries.

Nothing wrong with that. I find that Stripes solves those kinds of common issues without being large and monolithic, and without getting in my way.

Bear, I suspect that you've built up a set of libraries, helper classes, and so on, along the way, so that you can quickly solve these kinds of common issues. I'm sure you don't start from scratch.

So, either way, I'm all for lightweight solutions, but just Servlets and JSPs and nothing else doesn't cut it in my opinion, sooner or later you'll need to add a feature and using a tried-tested-and-true solution will be faster than writing everything from scratch yourself.

My 2 Canadian cents.

Cheers,
Freddy
http://www.stripesbook.com
http://www.fdaoud.com/clickbook
Aleksey Serov
Ranch Hand

Joined: Sep 11, 2009
Posts: 32
Edwin Nathaniel wrote:So here's my question: Why do people invent JSF, Click, Wicket, Struts2, SpringMVC/WebFlow and other Java Web framework while the JSP and Servlet seem to work... (as long as you don't write your JDBC code in JSP).

The problem is that form the very beginning of JSP it became evident that JSP/Servlet does not solve certain problems well. (I did my first jsp file in 1998). Those problems have been named many times.

1) JSP is a just a "template engine". Means - it does substitute Java and HTML code into the generated Servlet class, but checks nothing from the syntax point of view until javac is called.
2) Difficult to read - always have impression that the page is 30% filled with %-s in various combination.
3) No in-language instruments for code reuse. Includes before and after (both in place if you are lucky) filled the rest 30% of the page. As a result the code got huge unpropotionally to the problem solved.
4) No component model at all. (Please continue this list at your will)

About for the last ten years folks tried to address these issues and this way those frameworks came to life. Why it is happening on? Alas - because none solved the problem comprehensively enough. (Of course - each of frameworks did it's step forward and is pretty useful ... for certain classes of applications). So I do not think that in this case "choice is a good thing". And many of them are inadequately complicated. Also many lost in performance compared to plain Servlet (JSP).

A good discussion would start with definition that everybody agrees to. All the frameworks talk a lot about "components" but almost each java web framework means different thing. Some are talking about View components. Other about Action(Controller?) component. Some about Model components and further on in some combination. I have suggested a list of eight principles. of good component model (http://www.hybridserverpages.com/framework.html). Now I check frameworks against that list and see much better what each framework provides. They are really different and none is complete. You may or may not like my definitions, but I bet they are at least better than nothing and may be at least used as a reference point for discussion.

I call my ideal component model "MVC component model" Means that a component is an reusable MVC part of Web presentation layer. Actually I went as far as implementing a framework according to those principles ... but here I have to stop in a fear of being punished for spamming.

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JSP/Servlet against other framework (Wicket, Struts2, SpringMVC/Webflow, Click, JSF)
 
Similar Threads
Struts vs Struts2
Newbie Question: Java EE vs Tomcat+Hibernate+Struts
Struts vs Tapestry
In Search of the Framework
struts2 Vs spring mvc