Good zeitgeist. I feel compelled to give my $0.02 as I was quoted in the blog as someone who "frankly feels completely overwhelmed." However, my criticism will be more from a programmer's perspective not so much a "web application developer" perspective.
Re: the chaos/churn in Javascript, forgetting for a minute the buzz-words of Backbone.js, React.js, Ember.js, Gulp, Angular etc. - they seem all to be a fight about MVC, traditional vs. single-page app vs. isomorphic.
I fail to see how improvements in these tools actually push us to create novel projects. While one can nit-pick about React.js rendering performance in its internal "DOM diff" model or Flux's "data flow architecture" in improving code readability, but they are just buzzwords to me like words-play in a post-modern novel or art that arrange concepts in their idiosyncratic way in an arbitrary aesthetic way; although sometimes the rearrangements can be beautiful, they are ultimately shrines to themselves and their creators and subculture.
Subculture because everyone wants something of their own and ignore interoperability. Although the data model are the same whether you're a single-page or isomorphic, there is no community standard to define standards to define your data models a la J2EE annotations or code-generated one's a la Google Protobuf. Same thing with single app controllers, no standard like RESTful web service spec that's universal and interoperable like between .net/Java/Python etc. that can be applied to say, Sail/Backbone/Ember/Angular.
Postmodern because they are always self-referential to the "Ember.js"/"Node.js" way of doing thing - when they all do the same thing which is rendering HTML elements on the web browser in 2014, much like Visual Basic rendering forms on Windows 95 desktop in 1997. Never mind all the touts about performance, architecture, when the users won't care about the diminishing return of shaving off some microseconds of your AMD JS module loading or the beauty of your invisible architecture.
IMHO, instead of a race to the bottom to the most "efficient" and "beautiful" stack to render HTML, I care more about the ideas that push the web as a medium, e.g.,
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 :)
The improvements in these tools aren't supposed to push us to create novel projects. They're supposed to get out of our way. Some do better than others, and some paradigms can be more helpful than others. It makes sense that we have competing ideas and competing frameworks to implement those ideas.
Some projects get a bit flashy and buzzwordy, it's true. Bacon.js [0] always sticks out in my mind as a prototypical example, though I think it's tongue-in-cheek.
I try not to let that flashiness get in the way, though. The fact is, Bacon.js is useful to me, when I try to make beautiful and efficient code to render beautiful and efficient HTML. Their homepage doesn't change that. React's performance is impressive, and may be important to me; ditto with Flux and code readability. And the theories underlying those libraries (DOM diff and unidrectional data flow) are important too, so I know why I should expect them to be better.
Re: the chaos/churn in Javascript, forgetting for a minute the buzz-words of Backbone.js, React.js, Ember.js, Gulp, Angular etc. - they seem all to be a fight about MVC, traditional vs. single-page app vs. isomorphic.
I fail to see how improvements in these tools actually push us to create novel projects. While one can nit-pick about React.js rendering performance in its internal "DOM diff" model or Flux's "data flow architecture" in improving code readability, but they are just buzzwords to me like words-play in a post-modern novel or art that arrange concepts in their idiosyncratic way in an arbitrary aesthetic way; although sometimes the rearrangements can be beautiful, they are ultimately shrines to themselves and their creators and subculture.
Subculture because everyone wants something of their own and ignore interoperability. Although the data model are the same whether you're a single-page or isomorphic, there is no community standard to define standards to define your data models a la J2EE annotations or code-generated one's a la Google Protobuf. Same thing with single app controllers, no standard like RESTful web service spec that's universal and interoperable like between .net/Java/Python etc. that can be applied to say, Sail/Backbone/Ember/Angular.
Postmodern because they are always self-referential to the "Ember.js"/"Node.js" way of doing thing - when they all do the same thing which is rendering HTML elements on the web browser in 2014, much like Visual Basic rendering forms on Windows 95 desktop in 1997. Never mind all the touts about performance, architecture, when the users won't care about the diminishing return of shaving off some microseconds of your AMD JS module loading or the beauty of your invisible architecture.
IMHO, instead of a race to the bottom to the most "efficient" and "beautiful" stack to render HTML, I care more about the ideas that push the web as a medium, e.g.,
WebGL (http://www.chromeexperiments.com/webgl/),
Web Audio API (https://chromium.googlecode.com/svn/trunk/samples/audio/samp...),
Web Real Time Collaboration (https://togetherjs.com/ http://www.webrtc.org/)