3 ms·
This is especially true when it comes to working with JS libraries. Since no two libraries or JS developers have the same set of ideas for how the language's co
by Fellshard 7y ago
This is especially true when it comes to working with JS libraries. Since no two libraries or JS developers have the same set of ideas for how the language's components work and fit together - how objects are intended to be used, standard ordering of arguments, whether to use a functional or an OO style, etc. - your application will be torn between the dozens of wildly different libraries you end up selecting, or worse, by those you have no choice but to select. Every crack in JS will be pulled wide open by that tension, and even TS' attempt at some normalization will not fully erase that.
- hombre_fatal 7y agoSounds like every language I've used, from Python to Java to Rust. JS actually has an improvement to offer here with its async-everything concurrency model taking away one degree of ecosystem fragmentation.
- Fellshard 7y agoNo. In general, there is a sense among Python coders of at least concrete schools of thought for these kinds of abstractions. Java certainly is looser, since it never clung tightly enough to 'pure OO' principles. Rust is young, and - I expect - is still developing its standard idioms and common abstractions, though it has certainly settled on a broad swathe of it already, and holds strong opinions on what good Rust code looks like. If I asked something similar of Javascript, you would see very little commonality between people. It's designed as a Self-y language with functional leanings, and gives far too unopinionated and broad a leeway to nudge its developers in any one direction. Furthermore, early browser APIs for JavaScript - especially when it came to features like window and cookie interaction - pulled the rug out from under every reasonable abstraction the language could have been geared towards, choosing unreasonable over reasonable abstractions. This leaves the language where it is now - incohesive, incoherent, unsound when it comes to stitching multiple parts together, because each developer behind each of those components has a wildly different perception of how the JavaScript world 'ought to work'.