5 ms·
Main strengths: * The ecosystem is pretty strong and constantly evolving. Lots of companies and individuals are putting a serious amount of work into making hi
by spion 7y ago
Main strengths:
* The ecosystem is pretty strong and constantly evolving. Lots of companies and individuals are putting a serious amount of work into making high-quality tooling and libraries. (Although with that also comes a lot of lower quality stuff and its sometimes hard to tell)
* The language isn't owned by any single company and is well specified
* TypeScript provides a powerful and flexible type system with advanced dependant-types like features. Lets you gradually evolve from a messy JS prototype to well-organized code with fairly strict type checking
* Fastest dynamic language. The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads)
* wasm support in the runtime a promising escape hatch to the integration with other languages should that become needed. (Similarly not owned by a single company and well-specified)
* sharing code and types between client and server, including interfaces, validation and data models.
* particularly well suited to handling heterogeneous structured data due to how cheap it is to define new object types (even in typescript)
* Async-IO-first (in fact, async-only IO for the most part)
Main weaknesses:
* Poor standard library with an anemic set of classes, anemic set of implementable protocols/interfaces (more stuff like Symbol.asyncIterable needed) and lacking convenience functions. E.g. see https://api.dart.dev/stable/2.7.1/dart-async/Stream-class.html https://api.dart.dev/stable/2.7.1/dart-async/Stream-class.ht... and compare with... well nothing in the language! The official node streams have a terrible API.
* Combining lack of both protocols and standard library leads to pretty bad userspace library fragmentation. (What is the go-to stream library?)
* Restricted data sharing between threads (only SharedArrayBuffer) makes it quite limited for multi-threaded problems.
* (mainly TypeScript) - Insufficient reflection capabilities
* Rigid (non-configurable) node_modules resolution algorithm accepted as standard limits flexibility when organizing projects
Mythical weaknesses that don't matter that much:
* Implicit conversions - largely irrelevant since TypeScript
* DOM/Browser related weirdness - often attributed to the language but actually problems with browser APIs
- gargarplex 7y ago> The performance is also quite comparable to statically typed GCed languages. (For example, you can probably get to 50%-90% of Java performance on most single-threaded workloads) Citation needed, please. I disagree with this. I recently was able to achieve a massive speedup in a Node application through writing a native C++ module... and implementing Garbage Collection is required for N-API.
- spion 7y agohttps://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- gargarplex 7y agoExcellent source; thanks! It’s probably worth clarifying that Node is ⅓ the speed of Java in some of these cases and that the Node implementations use both fixed size typed arrays as well as worker threads, features that aren’t common practice in most Node programs.
- spion 7y agoI wanted to illustrate the fairly "wide dynamic range" available. A lot of typed, GCed languages require significant effort to write highly optimized code anyway, and the optimized code rarely looks like the idiomatic one. But even with idiomatic code the performance is quite good - the JITs are very high quality.
- gargarplex 7y agoI didn't downvote you – in fact, I upvoted you. But I should also make the point that worker threads do not support importing native Node modules that were built directly on the V8 API. For example, most popular sqlite libraries (better-sqlite3, sqlite3) are not usable with worker threads. I'm mulling contributing N-API support to the libraries... but I haven't even done any research or planning work yet.
- spion 7y agoFor those situations where the GC becomes a performance (or more likely memory usage) problem, it seems reasonable that the built-in WASM support of most engines will be able to provide an adequate performance (its already getting quite close): https://www.usenix.org/conference/atc19/presentation/jangda https://www.usenix.org/conference/atc19/presentation/jangda
- deleted 7y ago[deleted]
- bogdanu 7y ago> (mainly TypeScript) - Insufficient reflection capabilities You can always use the compiler api to extract type information. Sure, a bit tricky but doable. The compiler api exposes a lot of awesome things, I'm suprised there aren't that many tools that use it.