I never worked much with JS, but from my experience I find it hard to imagine writing such a big application in JS. It is so easy to do things wrong in JavaScript. Weak types, global namespace, ambiguous and unexpected behaviours.
Weak types: Check out Facebook Flow or TypeScript.
Global namespace: Not true with require/modules.
Ambiguous/unexpected behavior... please explain? You could use any number of libraries to add consistency there. It's incredibly easy to include a JSLint file in your repo and as a git hook to ensure consistent syntax usage. ES6 introduces lots of nice features for writing code, and is usable today with transpilers.
For frontend development, a lot of frameworks and libraries only work consistently with Javascript. I've looked at TypeScript for instance, and it indeed looks nice. But it has a bunch of edge cases with Angular and/or Backbone. You're just piling on complexity with these languages.
But you need to write your frontend SPA with JS. And the isomorphic part, if designed from the ground up adds almost no extra code. So, really it's almost free to render first with Node, if you're starting a fresh SPA. I don't see why you wouldn't want to do it.
And we can all agree the ES5 has some warts, so you may as well transpile. Whether it's ClojureScript, Coffee, Type, or anything else doesn't matter, I just think it's a problem solved. Webpack makes debugging them easy with sourcemaps and live-compilation. In fact you can get hot-reloading[1] in React. So your app re-compiles without reloading.
I'm happy with ES6 + Flow. It's all ES6 syntax anyway, works with all libraries, and is fast to write, good looking, and functional.
Given JS has first-class functions, and many libraries to follow functional patterns. You can write very stable code, with almost no chance of side effects within a given function/context.
I did, on the other hand, have to take over cobbled together jQuery, Backbone and Coffeescript applications.
Yahoo is writing a greenfield application, and they are avoiding exactly those problems by using React. So, literally your pain point is exactly what they are writing about avoiding, and yet you still comment on this article with the same anti-JS nonsense.
On require/modules, that's a freaking mess.
Ambiguous/unexpected behavior... nothing fixes it.
To make matters worse, there's always the promise of some magical library or tool that's going to fix your problems, until you discover that it sucks, or that it is unmaintained, or that it doesn't interoperate with another library and then you're back to search between thousands of pieces of crap that do the same thing.
I remember the days when people were having boners over CoffeeScript. Boy, that was a bad move.
How is it weak?
I don't find require/modules to be too much of a mess.. unless you are using a lot of really large tool-chains with deep dependencies... npm dedupe helps point out problems there.
Breaking your logic into idempotent functional components without side effects as separate files/modules reduces a lot of what can be considered ambiguous or unexpected.
If you work with a functional flow, avoiding OO in JS as much as prudent, you can get a lot done without nearly as much confusion.
For now co/generators/promises get you really far along. In the future await/async will take it farther.
JS ecosystem is confusing. See: https://news.ycombinator.com/item?id=7074307
Utilities should be a part of the language's "battery".
Ambiguous/Unexpected behaviour: I mean I can redirect you to the popular "Wat" talk. Moreover, isn't that the entire premise of "Javascript: The Good Parts" anyway?
Also, it compiles to CommonJS, which means it works well with both node and browserify.
Yes, we need a blessed, "batteries included" stack for JS made of components that play nicely together. Here is a nice list to get started with (IMO, ymmv)
1. TypeScript or Flow
2. React
3. Promises: bluebird, when or p-promise
4. Observables: rxjs or most (they play well with promises)
5. immutable-js for immutable data structures
6. lodash and/or Ramda.js
7. browserify1. Not a problem, though I don't use either, I tend to use very small modules (not necessarily via npm, but require'd in my own project, or outside modules)
2. React, and even the Yahoo flux tools are pretty nice. React by itself is less useful.
3. I'd go with es6-promise here, which complies with the spec. I wrote i-promise as a module to give an ES6 compatible promise library, or native as available.
4. Observables are pretty evil... the whole flux architecture is to avoid direct observations in favor of a unidirectional data flow.. but that's more opinion.
5. completely agreed... immutable data flows work to prevent side effects. Even if you don't use these libraries, avoiding side effects is a big thing.
6. Also agreed, though you can usually get the parts you want without the weird deep dependency chains in lodash.
7. Agreed here, though webpack is interesting, imho it breaks too much with node's approach to includes, and doesn't work as well with reusing code on the server-side (imho).
Other things to look into include csp, streams, events and the gulp build tool.
Or they can also be used in place of asynchronous lists (like "object streams"). I find them handy for various tasks :)
Regarding es6-promise, its too minimal for my taste, and missing my favorite feature (provided by bluebird. when and p-promise): long stack traces on (possibly) unhandled errors, which are quite invaluable on the server side when debugging longer chains of events. p-promise has the additional advantage of being a relatively small library which is pretty awesome :)
[1]: example: flux implemented with rxjs: https://github.com/fdecampredon/react-rxjs-todomvc
I actually have this entire stack running without observables currently, and my goal is to build a variety of applications using it to really sort out the best techniques with it, and then open source it as a platform.
As for #7. I use webpack and love it. It does work wonderfully server side as well, you just have a build step with webpack that strips out anything you don't want for the server, and then have your server run that built file. Not perfect, but works well. It also avoids any need for gulp.
If you're already at the point where you are utilizing compilation, why not implement a compiler-level async/await solution (probably based off of a loop + a state machine, a la regenerator).
Even so, lambdas, observables and some FP constructs such as map/reduce/filter/etc can potentially eliminate the need for imperative style code. There are also some semi-imperative solutions to certain problems that work okay [1]
Another advantage of functional code is that its easy to extend - adding a combinator that implements filtered (typed) catch for promises is a lot easier than implementing a language construct such as `catch (e if e.code == 404)` for generators.
var only = (predicate, handler) => e => {
if (predicate(e)) return handler(e) else throw e;
}
promise.catch(only(e => e.code == 404, e => {
handle...
}))
You assume all libraries in JS is mature, well-supported, and will be there in the next 4 years at least.
I echoed other comments: JS ecosystem is unstable and confusing at the moment.
Case and point: EmberJS. I have to use ember-cli, npm, bower, and broccoli. Some of them overlap.