I've had the same experience with node, but normally there aren't that many problems with V8 or the language itself. Most of the rough corners seem to be in nod

I've had the same experience with node, but normally there aren't that many problems with V8 or the language itself. Most of the rough corners seem to be in node's core libraries. IMO this is what we need: * a better designed standard library. Maybe more like Dart's[1] - we already have Bluebird as the de-facto replacement for callbacks - all we need now are something like Dart's streams to fix the built in quirky streams. * built from the ground up with optional types i.e. TypeScript or Flow (eliminates most of JS's type-related quirks while preserving most of the dynamism and duck typing and being very helpful when the time comes to refactor) Now that typescript has support for type definitions inside node_modules[2] there are no barriers remaining to do this. node + V8 + typescript can provide a development experience that matches Dart (exceeds it in some cases, e.g. REPL) without throwing away the entire existing JS ecosystem in the process. [1]: https://api.dartlang.org/1.12.1/dart-async/dart-async-library.html#classes https://api.dartlang.org/1.12.1/dart-async/dart-async-librar... [2]: https://github.com/DefinitelyTyped/tsd/issues/208 https://github.com/DefinitelyTyped/tsd/issues/208 p.s. [2] can actually detect some situations in which there would be problems when multiple library versions coexist together (e.g. when you pass instances that come from library v3 to a function of library v2, explained in detail at https://news.ycombinator.com/item?id=8213273 https://news.ycombinator.com/item?id=8213273). However if the interfaces are structurally satisfied, the compiler will not complain. As a result I'm pretty sure that its possible to write a tool that detects semver violation based on .d.ts files (similar to what Elm does) or suggest the exact amount of version number increment by comparing the definition files