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.
I feel like people stick fingers in their ears and ignore the ecosystem whenever JS is mentioned. There's a wealth of transpilers and tools that fix all the problems mentioned here (if you even agree they are problems), and yet they are brought up every time.
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.
Yes but if you're using a language that transpiles to Javascript, you might as well use another language all together (for backend programming). Debugging becomes much simpler with a language that doesn't has to turn into something else.
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.
Oh well, at this point we're moving into subjective opinion.
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.
If you write very modular code with good test coverage, the odds of you needing to fire up a debugger are greatly reduced. Regardless of the language you choose.
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 think the real problem is that this has nothing to do with the article on hand.
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.
True, there's a plethora of JS tools someone can use. The problem is that they have to be discovered. And there's no standard. I found out about Browserify 2 days ago and realised all the problems it could have solved for me. Now I have to migrate the code I have to it.
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?
Flow isn't mature enough yet, but even TypeScript eliminates pretty much the entire Wat talk.
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. browserify
1. 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.
Well, observables would just be used as a mechanism to implement a flux-like architecture or decouple various parts of your server-side codebase (making them open to extension). A bit like event emitters, but without the stringly typed event names. I don't think thats evil? [1]
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 :)
I also agree with just about everything here, and thanks for the tip on es6-promise. I'll have to check it out.
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 with generators we still need to yield something or await on something. C# awaits on Tasks, in JS Promises would be a logical choice. You definitely need a value though - you can't await for node style callback functions as they provide no value to yield (or otherwise pass to the runtime) between calling the function with a callback and your callback getting called.
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...
}))
Here is another example (its a bit of an overkill though :)
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.
I prefer straight JS over CoffeeScript/TypeScript/Flow etc...
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.
don't you feel that if you a language's short coming is addressed by adding more of it in the form of duct tapes is problematic? I love javascript when it was doing simple things on the DOM, not trying to recreate the desktop in the browser, making it render across different devices and browsers, making it crawlable by running a headless qtwebkit process to serve pages that google can't see, using a slow and unstable document storage database often advertised with an old javascript engine requiring you to write chains of callbacks for even the simplest operations, all in the back of my mind believing that somehow all this complexity has helped me, why, look around everybody's doing it. This Java/PHP/Apache garbage that has worked well but didn't feel cool or fad enough? Let's kick it.
