If I can summarize your point: Data-binding can simplify complex pages.
That can be true. I do think most page interactions for most websites don't come close to approaching that level of complexity however. And even then, a helper-function that takes one message and performs multiple assignments can be simpler to write, simpler to understand and simpler to maintain. You still have to explicitly bind the data after all. If you only need to make one update, such as a message post in a chat application, then you're probably not saving a lot from a pure character count perspective.
You're also throwing in a framework requirement, a need to maintain it, spreading your data-binding across the page, adding abstractions, etc.
I'm not sure what you mean by not waiting for a response from the server before updating the app, though I suspect it implies even more complexity (local storage, synchronization, out-of-band management of failures, etc).
From a maintenance stand-point: $(".content").html(response) has had a very long shelf-life. Where you can probably put a 2-year expiration date on any project targeting most of the handful of popular JavaScript MVC frameworks. Trying to predict which one is going to go the distance, not replace major components in that time, and provide a smooth, relatively painless upgrade path is probably futile I'd guess.
Well now you're getting into the framework-or-not debate, which I don't really care to argue. (There are valid arguments on both sides, and it's really a judgement call you have to make for each specific application, but it seems like that's been beaten to death here on HN.) I was specifically replying to your point about having the server generate all HTML changes, which I think is generally a bad idea.
> If you only need to make one update, such as a message post in a chat application, then you're probably not saving a lot from a pure character count perspective.
Either way, the "character count" of the data being sent over the wire shouldn't be an issue, and if it is, that's an edge case and not the general rule. Saving a few bytes on each response is not why JSON is used for data exchange.
> I'm not sure what you mean by not waiting for a response from the server before updating the app, though I suspect it implies even more complexity (local storage, synchronization, out-of-band management of failures, etc).
That's not what I meant at all. If the server is your templating engine, then you can't update the UI until you get a response from the server. So that means, if I click to read the message in my chat application, the UI doesn't acknowledge that it's been read until I get a response from the server, which can be more than a full second in a high-latency environment. In something like React, I can instantly update the UI before the request even finishes.
Having said that, you make web apps seem trivial to develop. In practice (at least in my experience), many (most?) web apps are complex. I've been bitten too many times by projects that seemed "too simple" for a framework. If the web apps you're building really are that simple, then I think your solution is great, but I think most of today's rich web apps aren't simple CRUD applications anymore.
> From a maintenance stand-point: $(".content").html(response) has had a very long shelf-life.
It's also a pain in the ass to maintain. You have to imperatively define changes to your UI based on different events, which makes refactoring difficult and often leads to spaghetti code. There's also the fact that you'd have to keep UI state on the server as well (if this menu is open, change this thing, else change this other thing), which opens a whole new can of worms.
> If I can summarize your point: Data-binding can simplify complex pages.
React actually doesn't do data binding. The reason React is awesome is because it isolates different parts of your app and allows you to define the UI almost declaratively. Rather than keeping track of the current state of your application at all times, changes in state cause React to just (conceptually) re-render components. So your components essentially become pure functions that take state and render a UI. And for event handling and dispatch, check out [Flux](http://facebook.github.io/react/blog/2014/05/06/flux.html) if you haven't already. Even if you don't use React specifically, I think the architecture (treating components like pure functions
Let me know if I'm misunderstanding the architecture you're proposing, because architecture is something I've thought about a lot and am genuinely interested to see how others are structuring their web apps.
The problem is you can't easily send HTML to update many parts of the page. For instance, if you have messages as part of your app, but there are multiple ways to read a message, you have to make sure all of those are updated when you read one. It's WAY easier to just have the client know what to update and do that automatically, rather than having the server send several bits of HTML. There's also the fact that you don't have to wait for a response from the server before updating the app, so you can see the result of reading a message instantly (which becomes really important on high-latency connections like 3G).
So it certainly depends on your use case, but I think letting the client handle templating/HTML generation is a much better default than the server sending bits of HTML. In my experience, the cost of HTML generation in React.js is pretty minimal. And with React allowing server-side rendering, there really aren't that many drawbacks.