Has the pendulum begun to swing away from frameworks?
This post is going to talk about using Frameworks (JSF, ASP.NET, Django, Ruby on Rails…) to build web applications and perhaps they have outlived their usefulness in many situations.
I have started to put together a demo server here at deCarta and as part of that I am going to need to write some demos. I know that when I write some MS based demos I will be using ASP.NET since that is was one of the benefits/drawback of MS development – one “blessed” web framework.
It has been a while since I have written some Java web applications and so I thought I would peruse the landscape. I have worked in JSF before but the XML hell that is the configuration files really harshes my mellow. That being said Seam seems to be an interesting framework but there is certainly a steep learning curve and I am still unclear if it runs on Tomcat. I then find Wicket which has no XML config files and everything is done through Java code – which appeals to me. I use an IDE so it can help me avoid doing the mundane and repetitive tasks which are prone to error. Most IDEs have no way to confirm that you don’t have typos in your XML or your XML declares a non-existent class. So Wicket, using nothing but Java code, feels like a step forward… until I look at the amount of code and classes needed just to do a simple form. Feeling undeterred I try to get going and then realize that Wicket documents relies heavily on Maven, and while I have nothing inherently against Maven it is yet another thing I have to learn that I am not in the mood to do now.
Now feeling a bit frustrated I go speak to Geoff and Brent, our web services and JavaScript gurus respectively, to seek words of advice. Turns out they have used Wicket and a bunch of other frameworks and they say, as somewhat devil’s advocates, that frameworks are a waste of time. They now believe that most web apps should be written as Servlets or web services which feed appropriate data to your JavaScript library of choice. I push back a bit and they do concede that for large team projects or repeatable projects a framework makes sense but they also point out that that you spend an inordinate amount of time wrestling with the framework rather than writing code.
And this is the question for the day – has the evolution of web development moved us away from frameworks as the one true way for web developers. All the web languages out there now have their own frameworks, from perl to Ruby to .NET to Java, are they overkill for most projects. Is there where REST and Ajax (and Comet soon enough) have brought us?
When I discovered Struts it was like a ray of light cutting through all the one-off web code I had written. But are we now at a point where the frameworks and the support infrastructure are just too much hassle without enough payoff. I understand sessions are another tricky thing that frameworks help handle but perhaps that is all the frameworks should do. Programming servlets to accept GETs or PUTs and having them spit out XML or JSON is really an order magnitude (WAG ) easier than taking on a framework. It seems some in the Java community are also discussing this issue (look in the middle of the Seam discussion for the grey box which is Matt’s commentary ).
So lazy web what do you think – has the time come to give up on these heavy frameworks and move to something more lightweight – REST services with an AJAX library fronting it? Or is this just a lazy person trying to get out of doing the hard work climbing a learning curve.
For those in the geo community this would like moving from an ESRI ADF or MapGuide to something like OpenLayers + GeoServer’s KML API.
I would really love to get some more data points from the community…
Steve's Little world 
Using no framework at all can be a good choice, at least if you can depend on using Ajax all the way (no surprise the suggestion comes from your ‘javascript gurus’). I think it is actually good to evaluate when you start a project whether you need a framework at all, whether that is for the web part, database mapping or even something like managing dependencies.
The problem – in general – with not using frameworks is that everything starts out simple and all, but you can soon find out you painted yourself in the corner, need to break out by building your own mini framework, and before you know it, you’re building yet another big-ass in-house framework that will be a pain to maintain (not to mention it doesn’t get the hours an average open source project gets). Otoh, if you’re not dependent on a framework, you’ll never run into it’s limitations/ bugs/ etc.
The thing you need to figure out is what you need for your project. The project I’m working on has a strong focus on packaged reusable interface components (the system is a container for logical components, and these logical components package their own UIs); for this, Wicket works really well. I’d have to create a custom framework without it.
In my opinion: the closer you are to developing a ‘regular’ (and Ajax enabled) website, and the better your team is with Javascript, the better your chance is of success without any framework for the web tier.
Final remark: if you’re worried about the amount of code you have to write for a form in Wicket (I really don’t think there’s that much overhead to it personally), it would be interesting to see the kind of code you’ll write when you use HTML and a servlet. Your Servlet will suck, I’m absolutely sure of that, *unless* you’re building that mini framework. Which you’ll probably enhance later on to support localization. And fine grained authorization. And… well you get the point 🙂
Very thoughtful article. I won’t even attempt to discuss the frameworks you bring up, because I’ve never really used them. The few times I write code it’s usually one off, designed to solve a specific task. I mainly work in Notepad2, or vim. I believe in using printf (or equivalent) to bracket and find my bugs. I *don’t* believe that there is ever a killer app, or a killer programming language, or the end all be all way to write code.
The point of my minor rant: I believe you have answered your own question in the stating of it. The process of evolution brings things to life, and puts old things down like a lame horse when the time comes. There was a day when Java was the answer. Java is still cool, but I don’t hear anyone touting it as *the answer* anymore. Sounds like the myriad of frameworks have met the same fate.
I think the question that we often forget to ask is simply, “Do I really need this framework/structure/style for this project? Do I really need everything to be reusable, or is my ego wanting to solve the world’s problems just getting in the way of accomplishing the job I have to do?” These are tough questions, to really answer, because the future is always uncertain. But I prefer simple, modularized, extensible any day to something that tries to solve everything all at once.
Perhaps I took my rant a bit off topic, but it intrigued me to say something at least.
Eelco:
As demonstrated on the Wicket list – you are fast responder. Thanks for the thoughtful reply and I tend to agree with all your points, except for how much code was required to make a simple form. There were quite a few classes needed just to make the form, but again this is probably a trade-off – lots’o’xml or lots-o-classes. The framework needs something to specify all flow and objects.
I guess the interesting point is to figure out where that tipping point is between large/framework and smaller/JSwithServices.
Definitely agreed that projects always become larger and more complicated than originally spec’ed.
Part of what just occurred to me is that I find Library/Code developers less enamored with frameworks and I wonder if that is because they never really create end user applications over and over again for different clients. It seems to me like most of the open-source frameworks have been started by consultants who came up against the frustrations you are talking about.
Thanks for stopping by…
yeah Jeremy – I think some of my points for Eelco apply to the issues you point as well. The hard part is finding the right shade of gray in between black and white.
ASP.NET! Steve, you’ll love this quote from Jon Udell: “I guess I’m extra-sensitive to the .aspx thing now that I work for Microsoft, because I know that to folks outside the Microsoft ecosystem it screams: We don’t get the web.”
Hey Sean –
The funny thing was I sent that same post around on twitter today. I originally sent it to rip on LifeRay who has some of the ugliest URLs ever but that ASP.NET applies here as well. Jon was one of the people who got me to look at REST and simple servlets for doing work on the web.
I personally think you call just about anything a “Framework”. Anytime you write an app, you could strip out some of the specifics and use it for some other project. This is easier said than done for most one-offs But really, how many different was are there to authenticate users, track sessions, serve pages, respond to UI events, etc.. However, I understand that you are really talking about comprehensive, developed frameworks.
Unless you just love re-inventing the wheel, you going to use some reusable (“framework”) components regardless of the rout you go. I like the REST, web handler/servlet, Javascript method. But even this becomes a freamwork of sorts. So you might as well pick your poisoin and go with the method that has the most parts you want, least parts you don’t, and a reasonable learning curve. For the “lazy web” method I would suggest Christopher Schmidt’s Holy App for RIA. If you just want some structure and easy ways to make nice UI then take a look through the major Javascript Libraries (YUI,Ext,MochiKit,Prototype,etc…).
Steven, not intending to be defensive, just venting my opinion 🙂
> I tend to agree with all your points, except for how much code was required to make a simple form
Wicket is more verbose than many alternatives out there, but it is the price to the upside of having no limits in how you nest components, how models work, etc.
What I find unfortunate about how many people use frameworks – including Wicket – is that they often view it is an end point. However, one of the core assumptions on Wicket is that you’ll create custom components that do exactly what you want. Think of creating custom components as building your own DSL (well… kind of). Why not create a form you can instantiate with one line of code? The guy who wrote this: http://javathoughts.capesugarbird.com/2008/01/year-of-wicket.html gets that part. I quote: “The result (of building a custom form…) is that a client can create a very powerful form control using one line of code, e.g. a text field that has an attached label, marks the form as dirty using the onchange event, lays itself out in a pleasing way, can hide itself and its label dynamically (using Ajax), can disable itself based on session properties, and using a common CSS look and feel. Oh, and supports accessibility by using the label tag properly.”
Also, to get back to using no framework at all, I wonder how much code you’ll end up with for the server side form handling by the time you included converting the values to objects, including reporting user facing errors for conversion problems, validations (for the domain but also for things like javascript injection etc), authorizations (is the post by the user allowed in the first place), etc. I’m not saying you have to buy into big-ass frameworks, but I am saying that you’ll likely end up with something of a server-side framework anyway. 🙂
> It seems to me like most of the open-source frameworks have been started by consultants who came up against the frustrations you are talking about.
I can’t speak for other frameworks, but Wicket was started by Jonathan just for his own project at first, without even the slightest intention of making money on it as a consultant at that time.
My involvement came from being an architect/ lead developer on a bunch of rather large web applications (one of these for instance services about a quarter of all Dutch general practitioners, and was and is worked on with a team varying from about 10 to 30 developers).
One of my main problems with other frameworks was that they didn’t promote reuse, which was a problem because we ended up with a lot of code duplication making maintenance a hell, and because we actually had several flavors of the project and we couldn’t reuse panels or even just pages very well across those projects. And as a company that had many development initiatives we would definitively have benefitted from having a set of reusable components that solves a common problem across projects.
Another problem was that it was hard to scale the development effort. It was almost impossible to get (non-coding) designers on the project and the mockups were so different from the end result that there was a lot of wasted effort in going from one to the other. We also couldn’t let people just work on anything finer grained than a page (a search panel for instance), so we had bottlenecks in how to distribute work and because we couldn’t work with self contained components, we were often in each other’s way when working on parts of the application (as some functionality touched multiple pages).
Anyway, that’s a bit about how I ended up going for Wicket; you can read more in Wicket In Action’s first chapter, which is free to download :-).
> I don’t hear anyone touting it as *the answer* anymore. Sounds like the myriad of frameworks have met the same fate.
And that’s a good thing. There are still no silver bullets in software development, so people should always be on the lookout for better ways of doing things and keep in mind that what might work well for project A doesn’t necessarily work well for project B. But I guess I’m not saying anything new here.
> Do I really need everything to be reusable
I believe you should typically strife for that yes, because it lets you avoid code duplication, which is one of the worst things to have in projects if you ask me.