An alternative direction to head is back to the future: take the web for what it is and try to simplify AJAX interaction, rather than relearn all the hard lessons of client/server programming from the 80's, but in a hobbled browser sandbox.
One of my main problem with javascript frameworks is having to drift away from the original server HTML. Not everybody wants to go the whole way down the Single Page Abbit hole. It's not only a question of speed or SEO.
I think many devs are both backend & front-end craftsmen, and as so build the backend first and then wish to 'grow' their frontend part on that foundation. Or ideally wish they could. Instead they have to fork the project into 1). the Good Ol' server HTML part 2). the API SPA part.
No matter how close angular or react (with jsx) stays to HTML, you still need to rewrite the whole view to comply with it's templating needs. There's no incremental evolution there, and worse : having to duplicate and sync maintenance on both ends, breaks the DRY principle which is fundamentally bad - since you end up with 2 sources of truth.
Pre-rendering the view with react on node (even if your on rails or whatever) may be a solution I don't know yet. Another take I guess would be to render your server html files with a template which complies with their JS counterpart. Yet another take would be to use HTML as the API instead of JSON - which is proven to work quiet well.
Anyways, just to conclude I think devs would feel more confident if they could rely a little more on the servers end while the frontend finds its ways and stabilizes a little.
Exactly. Rewriting views is something I really don't want to do. Example: I'm building pages server side and using AJAX PATCHs to update data on the server. The server responds in JSON with a html attribute contaning the very same HTML Rails partial used to create the page. This spares me from having to build a SPA (which for many reasons is not OK in this project) or two different views, one Ruby and one *.js which would be unbearable (as you wrote).
I looked at intercooler supeficially with the hope it could be a foundation to standardize my AJAX calls (I did something myself but it still fluid). I'm not sure I like the way it puts so much information in the attributes of the DOM elements actions are bound to, but I'll keep reading. I prefer doing those stuff all in JavaScript and minimize the impact of frameworks on the DOM. It's still no time to commit to any of them. Let's wait until the dust settles.
An alternative direction to head is back to the future: take the web for what it is and try to simplify AJAX interaction, rather than relearn all the hard lessons of client/server programming from the 80's, but in a hobbled browser sandbox.
For an even more retro approach, perhaps some things are just better written as desktop apps. I know they're out of vogue at the moment, but I've been having good experiences with writing a JavaFX app lately. Particular points to note:
* I wrote my own online updates engine, that can be used to implement Chrome/Web style silent background updates, but which can also give control to the user over which version of the app they use. Users can downgrade at any time if a new version is buggy or just not as good as the previous version. It's very small, simple and easily integrated. It supports threshold signed updates so it's also suitable for high security apps where a hacked web server could be critical. It's called UpdateFX, check it out.
* JavaFX has a tool that creates native, bundled installers on each platform (dmg, exe/msi and deb). The user does not have to install JVMs or get any Ask Toolbar crap on their system. You remain in total control over JRE upgrades.
* UI is specified with an XML dialect called FXML, it's quite intuitive and anyone who knows HTML can pick it up quickly. But there's also (unlike with the web) a competent visual designer. You can style UI with a dialect of CSS and it's very easy to match the Twitter bootstrap look, native looks can be done too.
* Data binding is easy, the UI is OpenGL/Direct3D hardware accelerated, you can trivially apply effects like drop shadows or blurs and animate them, the API is clean, the entire framework is open source and the developers are responsive.
* Because it's not a web app, support for offline or flaky internet connections is second nature.
If your users can tolerate the initial download then it's a much more pleasant and robust development experience. If your users are the type who can't wait, you might want to stick with the web.
I'm not sure that is true, a lot of apps use web technologies on the inside. The more interesting part is that most seem to choose native not because of the development story but because they need to reach some special API or really want to keep the UI very close to examples from the platform manufacturer. It is actually a problem to go native when you have to develop multiple versions of each application which might totally lose any advantages the native coding experience has over html+js.
I will say, a well done client/server app is much more difficult to implement robustly than a web app. And, horror of horrors, users usually expect you to implement... undo!
Higher expectations are the major issue: undo being the canonical example. The general problem of distributed system data synchronization is another: things tend to demo well enough on a local development instances, and then fall to pieces in the unreliable field. Showing synchronization status, merging changes in a semantically correct way, useful UX affordances around all this, etc. is all very difficult work.
Of course it all depends on the domain and architecture of the app in question, so counter-examples and exceptions are easy enough to find.
You always have the option of simplifying by writing the app in the "web style" where it simply refuses to run if it can't connect to the server (if there even IS a server).
Of course, people might indeed think that's lame and sucky whereas they'd forgive it for a web app. This is one reason I made my app visually look like a web app e.g. no menu bars and a bootstrap/web style button/popup aesthetic. If it looks like a duck, people are more forgiving if it quacks like one sometimes too :)
This is what I'm trying to accomplish with intercooler.js: http://intercoolerjs.org/