Apr
02
Sling is a Web Framework
filed under sling rest | posted by Michael Marth
Matt Raible of AppFuse fame has hosted a very entertaining session at the TheServerSide Symposium called "Java Web Framework Smackdown" where proponents of different Java Frameworks took jabs at each other. There were participants for the usual suspects, i.e. JSF, Struts, Rife, GWT, Spring MVC and even Rails. It was quite funny to watch the discussion, but one thing annoyed me: the title of the podium should not have been Web Framework Smackdown, because the presented frameworks are not web frameworks. I would rather call them "application frameworks" because I believe that the term "web framework" should be restricted to frameworks that actually respect and support the way the web is constructed. There are at least two points where the frameworks mentioned above do not do this (as far as I know):
URLs matter
In a RESTful architecture the URLs of a resource should not depend on the technology that generated the output stream. I think it should look exactly as if the generated, say, HTML was actually a static file on a web server. Yet a typical URL looks rather like this:
/detail.jsp?id=123
This URL explicitly depends on the technology that generates the output. So if the technology needs to be changed the URL is likely to change (unless effort is spent on doing some sort of mapping). This is really uncool in the sense of Tim Berners Lees quote "cool URIs don't change". Often one can also find data base keys in URLs. If the keys change, the url will need to change as well. Last, if the returned data is html the the URL should reflect this. So a good web-like URL would look like this:
/detail/123.html
or even better
/detail/myproduct.html
I know that some of the above mentioned frameworks allow for customization of the URLs which can fix some of these problems in some cases. But one should not have to.
State
In a RESTful architecture state should be kept on the client and no state should be kept on the server. Again, think of the web server with static files. However, a Java application framework usually keeps state. In fact, the first thing your browser will see when you point him to a Java framework-based web application is the session cookie that the application framework sends back.
In the case of JSF it is even considered to be a main feature that the components are stateful. While I do think that this can come in handy in some cases it is simply not web-like. HTTP is stateless. A true web framework should not hide or try to cirumvene this basic property. Yet, the application frameworks above all do just that.
Oh, there is one more thing: Apache Sling is a web framework.
Related Posts
2 comments
Both these points are pretty lame. In the case of a framework like Struts while you could have a URL like /detail.jsp this would be avoiding the controller part of Struts and not using it in the (MVC) way it was designed - its not the case of "customizing URLs to fix this". In the case of state, this is down to the user - if they desire their webapp to hold state on the server, then thats up to them, but its not required by the framework and works perfectly well without.
Lastly Sling hasn't yet had a release and therefore too bleeding edge for most people to use. Also it describes itself on its home page as a "web application framework" - perhaps that would be more appropriate for those other frameworks as well!!
Niall,
the URL issue I refer to is not (too much) related to the question if a MVC architecture is used or not. In fact, the same issue arises if your URL ends in ".do": it is implementation dependent.
Last time I looked at Struts the default mapping was .do. Maybe that has changed, but if not then you need to customize the URL if you want to get independence from the implementation.(*)
This is not a Java issue, I just quoted Java because I referred to the TSS Java web framework smackdown. In php or ColdFusion there is the same issue.
Regarding the state issue I quoted JSF because that is explicitly the JSF pitch. When asked what the sweet spot of his framework is the JSF proponent on the podium said "stateful components".
Afaik Struts is different in this respect and probably allows users to work without keeping state on the server. But it seems if you consider the Struts JavaDoc on ActionForm I think it is fair to say that Struts is at least partly encouraging state. As a result Struts applications tend to use it (see e.g. Struts Dialogs)
I do not understand what your comment about Sling being "too bleeding edge" to be used has to do with the discussion. My remarks were about architecture, not about stability. Also, please be aware that I am trying to point out a difference between different approaches. This post is not about "my framework is better than yours". And I am convinced that a framework whose URLs and HTTP interaction with the browser is not distinguishable (from a browser's perspective) from an Apache HTTP server with static files represents a different approach from the approach many frameworks out there take today.
Regarding your comment on Sling's web site: you are right. I came up with the terminology "web framework" and "application framework" (or maybe reinvented it or stole it without knowing) for this post. I try to distiguish two approaches that I consider to be different. But I (we?) need to come up with a better name.
Cheers
Michael
(*) At least when you change the implementation. When MySpace (with all its .cfm URLs) changed its backend to .NET they sure had to configure a lot.