Are Serverside Web Frameworks Becoming Irrelevant?

We Recommend These Resources

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.