5 ms·

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

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., WebGL (http://www.chromeexperiments.com/webgl/ http://www.chromeexperiments.com/webgl/), Web Audio API (https://chromium.googlecode.com/svn/trunk/samples/audio/samples.html https://chromium.googlecode.com/svn/trunk/samples/audio/samp...), Web Real Time Collaboration (https://togetherjs.com/ https://togetherjs.com/ http://www.webrtc.org/ http://www.webrtc.org/)

carsongross 12y ago
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. This is what I'm trying to accomplish with intercooler.js: http://intercoolerjs.org/ http://intercoolerjs.org/
- charlysisto 12y ago
  I appreciate this effort and will give it a try. 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.
  - pmontra 12y ago
    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.

carsongross 12y ago

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. This is what I'm trying to accomplish with intercooler.js: http://intercoolerjs.org/ http://intercoolerjs.org/

charlysisto 12y ago
I appreciate this effort and will give it a try. 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.
- pmontra 12y ago
  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.