Cool. How do you provide instantaneous feedback with this system? As in, if the user has a list of items with delete buttons, and you want to remove the item from the list as soon as the user clicks the X? Think about using your browser and having it reload every toolbar and menu every time you clicked on something.

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.

Can you not use AJAX through jQuery to gain this instant feedback? Do I really need to load an additional library to send and receive data to the server and update the UI, when I can already do that through jQuery?

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.

Sure. And if you display a count of the number of items in the list, you can update that with jQuery too. Are there other dependencies? Maybe if the list gets too small there's supposed to be a warning message or something shown? I can check the list size each time with jQuery and display/hide the message if necessary.

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.

Your code is always one new feature request away from needing "just a little more" from your front end. Before you know it, your nice and simple JS has to keep a lot more state than you anticipated. jQuery helps, but I eventually realized that it just helps write apps which do aspect-oriented programming on the DOM — and that is completely unsustainable for any but the most trivial app.

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.

I agree except for "large complex applications need libraries like Angular" That is nonsense. There were plenty of large complex web apps before Angular and they worked fine. This sudden belief that web apps need a front-end framework is insane.

I think one of my main issue with client side apps is "Great, now I have to implement the same validation logic twice, and in two different languages". The frontend needs to validate the data, for the "instant feedback" and the backend needs to validate for security.

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.

Validation in two different languages is solved by defining your models using a framework that supports proper validation. Moreover, you should do that for all application. Don't make me wait for your server to respond to know that I mistyped a credit card number. Validation on the client side and on the server side is a solved problem and if your application has any significant amount of validation code compared to all of your code, your application is way too simple.

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.

That's a pretty horrible idea and a large step backwards. Sure the web started out as a system for reading and sharing text but that being the extent of the web's UI pattern has long since passed. For good reason. The web is our best shot at create an open and non controlled application framework. Rendering text on a server and not using JS isn't even close to a solution for that.

Well, roudtripping to the server and reloading a whole chunk of html to get a sorted view of a table you already have downloaded isn't super smart either?

that's exactly what microsoft is doing with its excel app online,and it's one of the fastest app i've ever seen.

Use React and you get the best of both worlds. React supports server-side rendering.

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.

Interesting ... By "supports server side rendering", do you mean react can bind to a chunk of preexisting HTML in the page to enhance it? Or running react on node and build a page? Got an example at hand?

You'll have to excuse me because I only did a cursory reading of the the following, but it seems to be a decent outline:

http://bensmithett.com/server-rendered-react-components-in-r...

Thanks. Will give that a read.

Edit: Very interesting read liked from there ... https://groups.google.com/forum/m/#!msg/reactjs/eUespJPdyas/...

You can render react HTML components in node js without a headless browser, you cant do that with angular,so you can use react on the server.

Would this be anything like Atom/RSS?

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.

That sounds great, but does it have a framework with corporate backers?

It's called HTML.

I think you're talking about XSLT