Rendering pages in javascript just wastes the user's computing resources (and opens them up to nice vulns) and prevents search engines from indexing your content.
All sarcasm aside, plain HTML has plenty of great uses, but just because you don't see a reason for client-side apps does not mean that they don't exist.
This is an aspect of the HTML vs JS rendered page debate I’m still trying to wrap my head around. I understand really large and complex applications need libraries like Angular, Ember, React, and the like to render their pages with JS.
But what is so backwards and old-school about rendering HTML server side and then manipulating the HTML client side with a thin layer of JS and AJAX?
It feels as if the debate is between plain vanilla HTML pages and highly complex JS rendering, without any middle ground and integrating the benefits of both.
EDIT: Thank you for the responses. I’m genuinely trying to understand the pro and cons – of not just each framework – but of the methodologies in general, and your answers help.
Eventually as these side effects pile up, jQuery by itself becomes a mess. You have a ton of checks and complex behaviors after each user event.
Or I can provide some structure on the front end so that I can model my data in a reasonable way and have the DOM respond based on changes to that model. Obviously for stuff thats mostly static, server-side rendering is better. But when you're displaying stuff that includes complex relationships and behaviors, modeling it on the client side becomes an important part of maintainability. This doesn't have to be complicated. Backbone is certainly not complicated. But it is the best option if you want to have complex UI behavior tied to an underlying model and need responsive UI feedback.
Angular has been a breath of fresh air in comparison. It significantly reduces complexity. It's also easy to add to an existing project, even one with server-side templates. At this point, however, I consider the use of jQuery and server templates an antipattern at worst, and a necessary evil for some types of performance optimizations at best.
Just because something can be done as a client-side app doesn't mean that you need to. It might be old fashion, but most of the websites out there would be just fine with forms and links. Javascript can be added later if you think it adds value.
Of cause it doesn't help that I really dislike JavaScript, with it's stupid callbacks and could we just collectively decided to drop the anonymous functions? It's not going to hurt anyone if we agreed to define a function and name it before using it and it would be so much easier to read.
It is old fashioned. It's also backwards when it comes to mobile apps. Phones and tablets have lots of horsepower, but bandwidth is low and more importantly latency is high. I can almost buy that when you expand a menu the whole page reloads if it happens over Google Fiber and your server adds no latency, but when the roundtrip to the server takes 2-3 seconds, I am not using your app.
I will repeat: if you are running a mostly static website, HTML + HTTP is the way to go. There are still plenty of web apps that work just fine that way (basic CRUD mostly). However, there is a category of apps that are much better served by running client side with a well-defined API to the server. This provides you with a true MVC setup and makes for much cleaner code. Trying to put together a JavaScript driven app where you reload pages is something I have experienced quite a bit over the past decade. It's such a pain that it should not be attempted. Angular and friends make single page apps viable and much easier than the jQuery + HTML + Ajax apps.
I don't blame you for disliking JavaScript: it's an odd little language with some really bad parts. Perhaps try one of the other languages that compiles down to JS? I hear CoffeeScript is very nice.
Apps built with Angular or Ember have major issues with SEO. They'll have to resort to using something like PhantomJS to prerender their HTML. This is not a trivial bit of engineering.
http://bensmithett.com/server-rendered-react-components-in-r...
Edit: Very interesting read liked from there ... https://groups.google.com/forum/m/#!msg/reactjs/eUespJPdyas/...
I like as much separation as possible for letting the UI do the formatting and the backend just be an API. I'm not sure how this (not rendering in JS) would handle more complex scenarios such as SPAs.