Wille Faler is an experienced software developer, architect and agile coach with experience across a number of different industries as an independent consultant. Wille specializes in backend, integration, and Java technologies, but has more recently found a passion for Scala and text mining/analysis. Wille is a DZone MVB and is not an employee of DZone and has posted 42 posts at DZone. You can read more from them at their website. View Full User Profile

Are Serverside Web Frameworks Becoming Irrelevant?

11.08.2010
| 9117 views |
  • submit to reddit

I have always had a slight dislike for client-side development, html, css and JavaScript have simply not been my cup of tea, I have preferred working with middleware and integration problems. However lately, I’ve noticed three trends that have perked my interest:

  • Javascript frameworks are getting better, higher-level and more insulated from the foibles and differences between individual browsers.
  • With frameworks like Apache CXF, exposing business services is almost effortless, the difference between having say a Java interface only, or a Java interface AND an XML or JSON REST service is minimal.
  • Page based navigation is diminishing in importance and single page webapps are on the rise.


Put these together and one question has to be asked: are serverside web frameworks like Rails, Struts, JSF, Wicket et al losing in importance?
Is there a case for full 100% separation between front-end technologies and back-end services, where front-ends are written in html/css/js only, talking to a REST backend? This would not only achieve the holy grail of a pure UI tier and business tier, but in fact enforce it. You could in fact run your UI tier on a vanilla Apache Httpd instance with no plugins, because there is no Java, Ruby or other serverside language in the frontend code, it would all be browser based technologies. To me, the idea of pure web frontends with only browser technologies is quite an attractive one.

Rethinking the UI - what about SEO and findability?
Assume your frontend is entirely built in web technologies, fetching it’s data from backend RESTful JSON services, if you go overboard, Google won’t be able to find your content, as it’s dynamically loaded by Javascript. So isn’t there still a case for serverside content generation?
Sort of, but not in the way we are used to. In fact, I’d argue that content rendering and dynamic personalized or webapp elements of a page are two entirely different concerns: the latter two you don’t want to have Google index, as they are personal and not applicable to all users. Having them dynamically fetched/generated by Javascript actually helps Google keep its index more relevant as noise is kept out of the index.
When it comes to the common, indexable, searchable content, we still don’t need dynamic generation in the way we do it today, there is another solution: when content is changed or updated, simply generate static html from it and put the files on your webserver. For personalised/app like elements on page, simply put the static page together with those elements in place as you generate it, problem solved!

More valued UI developers, no more moaning backend developers
If you rethink the way web UI’s are done in this way, you achieve a couple of benefits: people can work entirely in technologies that they are comfortable with, Java developers will not have to moan about html and css, and UI developers will not have to try to decipher Java-code in JSP’s, Erb files and what not.

Personally, I think this shift in thinking is entirely viable today, and it’s gotten me interested in seriously exploring web frontend technologies for the first time in a long time. Just a quick browse for frameworks shows that with Mustache.js for front-end templating, Sammy.js for front-end MVC/route definition and JQuery for general JS you already have quite a full featured front-end stack.

References
Published at DZone with permission of Wille Faler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jonathan Fullam replied on Mon, 2010/11/08 - 9:06am

I'm currently working with Google Web Toolkit (GWT) communicating with Alfresco via pure REST and it's going great. Our front end is snappy and very rich while all the backend processing and content is in Alfresco.

Serban Balamaci replied on Mon, 2010/11/08 - 10:19am

Hello.

My bigest issue with these kind of approaches is that it leads to having two separate models of an entity object. One is used to retrieve the data from the database one to be used by the javascript on the client side. Having to make the change from one type of object to the other, also seems to result in creation of aditional methods. This is usually justified by suporters of the client side frameworks, that once you expose your services as an interface callable from javascript, you can use that interface with any other frontend, but I see this aditional code as a big issue for productivity.

In the serverside case, I work only with one type of entity and have generic filter methods that I can use for all type of objects and pass around between my layers with no aditional conversion from one type of object to another. 

Also I encountered the MVP pattern on GWT based frameworks, which everybody has a different implementation or ideea for it. Comming from a Wicket development enviroment, the amount of boilerplate I write for GWT based frameworks seems very big

Andy Leung replied on Mon, 2010/11/08 - 10:39am

You could in fact run your UI tier on a vanilla Apache Httpd instance with no plugins, because there is no Java, Ruby or other serverside language in the frontend code, it would all be browser based technologies.


I don't quite understand how do you achieve that because your Javascript is not able to send Ajax request across domain (another server that the server where the frontend code sits) ?

To Serban, no offense but what you mentioned is not a productivity issue. Simply build a reflection (or any framework) on entity where you need to generate objects in different formats (e.g. XML, JSON) so you don't even have to hardwire your serverside entity into your frontend code, which could lead to productivity issue (such as when you simply change something in entity, you gotta change to whole world).

Just my 2c.

Alexander Smirnov replied on Mon, 2010/11/08 - 2:30pm

I think that any extrimity is irrelevant. Pure server side framework doesn't meet modern client capabilities, there you are absolutely right.

On the other hand, even "single page UI" actually has a couplle of arranged pages. Not only to make content indexable, but to print something ( both Google Maps and Gmail, which seems as pure single-page applications, brings up additional windows to print ), to make content bookmarkable, to divide different functioanlties ( content reader don't need to load CMS administration code, as well editor interface ), to coordinate different representations : for desktop browser, mobile pfone or machine-readable RDF/Linked Data.  Also, because there is no warranty that REST service will be accessed by desired UI ( anyone can make fake request by HTTP ); both client and server side have to have exact same checks and restrictions, that should be aligned across application.

So, it's much better to have framework that coordinates both client and server side, so developer can decide there to put necessary functionality, from pure server-side generated html to client-side only UI.

Otengi Miloskov replied on Mon, 2010/11/08 - 4:30pm

I try to code all the UI in Javascript with Ext-js and the backend using webservices or rest with Java but always I have problems with this approach because the dynamic nature of Javascript on the UI. Lots of bugs, lots of testings. So I prefer something balanced, For example use Spring MVC or Apache Click with JQuery for the dynamic parts of the UI but my logic and almost everything keep in the serverside with Java. I can catch bugs and make less testing with Java and the compiler. I think a real solution to all this is GWT, Programming, compilation and debigging in Java and let the GWT magic do its work with the Javascript. GWT can be a game changer but I think server side frameworks still relevant unless you are a Javascript freak that just want to code everything from serverside to fron UI in javascript.

Jose Maria Arranz replied on Tue, 2010/11/09 - 4:43am

JavaScript libraries like JQuery or Dojo are fantastic for:

* Instant actions with no server roundtrip (mouseovers, clicks with some visibility changes)

* Timed movements and opacity changes

 Excluded them, there is NO other reason to code a content centric web application in client side, and as you can easily understand, these "client" effects (with JQuery, Dojo or similar) usually and easily can be mixed with server-centric frameworks, the server can inject the new HTML code and the new JavaScript actions to be executed in the client. 

 Single Page Interface (SPI) is here around the corner, and soon will become mainstream following the path of Twitter and FaceBook, and SEO continues to be a very strong requisite, and most of page content is dynamic (a simple static page is not enough). Unless you build two web sites, one SPI based and one page based for SEO, the server-centric approach is by far easier for SPI and SEO (and for anything in general).

 More info.

 

Andy Leung replied on Tue, 2010/11/09 - 10:47am in response to: Jose Maria Arranz

I guess you can't say there is no reason at all, how about animations or UI effects? These adds up to the user experience yet it is not limited to community apps only. Other than that I believe it is useful for caching small amount of data that is not frequently updated, it's better than caching on server.

Jose Maria Arranz replied on Tue, 2010/11/09 - 12:16pm in response to: Andy Leung

I'm proposing a mixed of client and server centric approaches, animation and UI effects can be effectively executed with a good JS library, this doesn't imply a full client-centric approach.

Of course you can follow a client-centric approach if you want, but be ready for hard problems with SEO, JavaScript code management (yes GWT is a good alternative), excessive number of AJAX requests, or too many custom client/server bridges, non-deterministic behavior when asynchronous requests are heavily used, client/server code duplication for security and data model management and so on...

 

Andy Leung replied on Tue, 2010/11/09 - 2:18pm

I agree with that, Jose. SEO is definitely one thing but could still get some workaround but I've found that too many sites abusing Ajax without reasons. I believe building browser-base client is not simply just UI, IMHO, it should be an UI agent where it manages information flow (in/out between client and server), security and user experience; it's not just UI, it's simply a full application.

Liezel Jane Jandayan replied on Thu, 2011/08/25 - 6:53am

Dynamic web pages usually consist of a static part (HTML) and a dynamic part, which is code that generates HTML. The code that generates the HTML can do this based on variables in a template, or on code. The text to be generated can come from a database, thereby making it possible to dramatically reduce the number of pages in a site. Consider the example of a real estate agent with 500 houses for sale. In a static web site, the agent would have to create 500 pages in order to make the information available. In a dynamic website, the agent would simply connect the dynamic page to a database table of 500 records.-Jonathan Berkowitz

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.