Pure Servlets? Or pure nonsense?

I am shocked that someone is actually proposing to go back to simply servlets for creating web applications. JSP has it’s share of problems (one of the reasons why Wicket was started), though the JSP team fixed some of it’s most urgent problems in the last few years. However, proposing something like:

if ("true".equals(request.getAttribute(P_SUCCESS)))
    "Team picks were saved successfully.");
      "(Reminder:  \"Pick 20\" represents the team you"
      + " think likeliest to win.  \"Pick 1\" is the least likely.)");

as the better alternative is so bad I consider it to be too cruel to serve as an April fool’s day joke. And if those code fragments aren’t ugly enough for you, just imagine what it would look like when you have a couple of forms, statefull components and updating of model objects to do. Brrrr.

But here is the best part (quoted from that article):

Although Web frameworks tend to complicate the overall shape of things, they do solve a variety of smaller problems.

That’s quite the inverted argument when you consider a framework like Wicket. Wicket solves the big problems, and leaves the smaller problems to be solved by it’s users or through specific components. A sample of the big issues Wicket tries to address:

  • The ability to build a larger whole from smaller pieces (Pages from components, behaviors and models), where the smaller pieces are self contained/ encapsulated so that they can easily be designed for reuse in different contexts and have explicit extensions points.
  • Enforced separation of logic and presentation so that it is always clear where to find what. Presentation templates can be managed by designers using their favorite tools and the templates are clean and easily readable at all times. The logic is statically typed to facilitate robustness and so that it is easy to test, navigate and debug using standard IDE facilities.
  • Providing the proper abstractions to let you reason about the problem domain at hand (the user interface). Coming up with proper names and thinking about your entities’ responsibilities is half of the power of object orientation. It’s not just about how you organize your code; it’s also about how you think about and communicate what you’re doing.

In my opinion, Wicket is a ‘think big’ framework. Rather than having been started to solve a number of day-to-day problems, we – and particular Wicket’s founder Jonathan Locke – took a step back and came up with the near-to-ideal programming model for web user interfaces. We created a framework to support good programming practices and team work first. We postponed the optimizations and nitty gritty details like how to deal with Ajax and file uploads etc to when we were ready for it. This is similar to how Java was started – in the first few years bashed for it’s poor performace – and now for instance Terracotta – whos builders have the grand idea of transparantly clustering JVMs, and who are working to fill in the gaps now, after having implemented the rough idea first.

Maybe I’m too harsh on the author of the article, and all he wanted was to let people think outside of a narrow mindset of having to utilize frameworks for every little programming problem they have. If this would be the case, I would agree with the idea behind the article. But as this is not the idea I get, I see the suggestion to get back to plain Servlet programming as yet another example of provincial thinking in the world of ‘enterprise Java’.

11 thoughts on “Pure Servlets? Or pure nonsense?

  1. DAR says:

    +1, Eelco. I read that same article, and the first thing that popped into my head was “WTF?!?!?!? This guy can’t be serious! He REALLY thinks it’s a good idea to code like this – in this day and age?”

    Don’t get me wrong, I’m a big fan of not using big, bloated frameworks – even if they are the industry standard (e.g., EJB, Struts, etc.). But only if using something else instead of that standard will make me more productive. Going back to servlets and printlns will definitely NOT make a more productive web developer.

    BTW, best comment response I saw to this was something like: And how are you supposed to do AJAX using this technique?!?!?

  2. Dev Brown says:

    I can’t agree more. That guy is basically wanting to go back to 1997. Having taken over a project where the previous developer followed this paradigm, it was absolute hell maintaining and not extensible. It was also hard to get rid of because it was so brittle. If you pulled a thread here, something broke over there… Eventually, we migrated it to Struts, later JSF and most recently OpenLaszlo. We’re getting ready to move it over to Flex since they changed their licensing model. Besides the richness of the interface, both Laszlo and Flex offer a much cleaner separation of view from model and controller than we ever had with Struts and JSF but to follow what the author of the article suggests and use servlets instead? ARE YOU CRAZY ;-)

  3. Steve says:

    Like most of the above people I also don’t like bloated frameworks. But that doesn’t mean don’t use any framework. Heck, the jdk is loaded with them :-). I don’t actually believe the concept of no framework really exists. When one develops an application they are really building a framework or context from which to build the app, and the app itself. Getting as much of that framework as you can get from others (rather than building yourself) without muddying your app just saves you time and maintenance. I think the original author is substituting a dislike for the frameworks he has tried with a statement that using frameworks is a bad idea.

    Heck obviously servlet is a framework itself so he would have to be claiming that servlet is the best way possible to express web apps. I’m not a web app expert but I think it leaves a lot on the table for others to do from my limited experience so more abstraction (without saying which) seems like it would be a good thing.

  4. Robbert says:

    Maybe the guy just didn’t find the right framework yet, considering he talks about JSF I can’t really blame him for wanting to go pure.

    Thats why I prefer wicket afterall, because it codes pure.

  5. alfons99 says:

    Wicked times! After a couple of years of Plone and Zope, I had a look at JSP, Twisted, Aquarium, Cheetah, RoR etc etc and what happend in our company is this:

    People start from scratch. One of our developers started a project using urllib2 (python) for doing his own 50lines webserver. I think it’s nuts. But nothing to argue there. Times ARE very confusing and the (or “our” since we participate in writing them) frameworks didn’t seem to answer our needs.

    Plain crazy.

  6. hilt2 says:

    Some web frameworks seem to be in fact really ineffective. I have compared Struts 1.2.7 with a small DOM-based Servlets-Only framework and it was 25 to 70 % more effective (less code) than Struts.

  7. nitinpai says:

    The use of pure servlets or frameworks is purely dependent on the task you want to accomplish. In my opinion one need to follow resources that show which framework should be the best approach for the particular situation and not blindly go for a framework since it is hot property currently

  8. @hitl2,

    Indeed, sadly some frameworks sometimes make you think you’re worse off than just staying on the metal. The funny thing in that article is though, that the author first rants against frameworks of any size, and then happily goes on proposing his own framework. A framework that is limited, and so you can expect that by the time people will use it, they’ll build another mini framework around it to get the job done. Not much gain in that imho.


    Sure, never go blindly on anything. However, there is really very little to defend about using bare Servlets, unless it is for very specific tasks like generating a report etc.

  9. Orden says:

    Pure servlet is extreme but I clearly share the ideas about the framework problem. The more interesting is the ideas used by the contradictors. I think many should try to think out of the box and the author of “Pure servlet” is more interesting than many. Some dogmas should be challenged:

    – JSP for designers and Java for coders. I don’t think so. Often designers don’t go behind photoshop and DreamWeaver and the developers are in charge of copping with cross-browsing, HTML, JS and java. So why splitting the files anymore. Artists will not commit sources in you source management system ;)

    – Separation from View to Model. Views are in JSP ? But there is also a bunch of java
    files in charge of supporting the interface like form beans. The interface logic is business logic or view definition ?

    – I often ear that separation from X form Y is a good thing. It’s hard to have the big picture and you have to know many file format, code in XML etc… You have 4 files for the simple Hello world page. Just think that heavy client programmers had 1 language to know!

    – Many abstractions we created are leaky like JSF and abstraction from HTTP and HTML leads to poor performance (the key factor for user acceptance IMHO). We need to learn all the layers insides to cope with them. The promises of simplicity are betrayed.

    I have other things but I have to go back to my JSF debugging …. :)

  10. A few examples of good separation of concerns: using CSS, using different classes to represent different things, using markup for static layout code and a programming language for dynamic stuff. A big part of programming is creating order out of chaos, and separation concerns can be a big help in that.

    Scripting in JSPs is fine for smaller sites, but as soon as things get more complicated, it is good to be able to factor out reusable code, break your problem up in smaller, independent pieces so that you can distribute work over more people, etc. Scripting in JSPs doesn’t encourage such things, and makes other things, like refactoring, much harder because you’re basically only working with text, not statically typed code like you do with Java.

    Look, if you think you don’t need separation of concerns and scripting in JSPs works fine, that’s cool, go ahead and have fun. My experience with that is that initially you work fast and you feel you’re being very lean and all, but that you end up wasting a lot of time in the longer run (say 6 months down the road, and when you make changes to your team), and end up with a system that gets more brittle and harder to change when it grows. A few years ago when using Struts etc, even small change requests caused plenty of panic – and for a good reason, because it usually meant a shit load of new bugs – whereas refactorings, even big ones, nowadays are a piece of cake and rarely cause any big problems.

Comments are closed.


Get every new post delivered to your Inbox.

%d bloggers like this: