No, JS won because the web won. There's a web browser on almost every computer out there. If you write your software in JS, you can run it just by following a link to a URL. That doesn't have anything to do with JavaScript's absurd module ecosystem.
JS has un unfair monopoly.
Just give us a decent language on FF, Chrome et Edge, and everybody will stop using JS withing 5 years.
I do think however the current trend is OCaml / Haskell influenced languages like Elm, Purescript, Reason, etc. WASM is only going to make them better.
The king is dead, long live the king!
But even without that, then chances that you have exactly the same build than somebody else in cache is very weak unless it's very popular. And to get it popular means a lot of people has to download it, taking the several Mo hit download on first load. And most users will just quit the page before that, thinking it doesn't work.
The solution would be for browsers to stop the madness and decide by community to adopt a new standard with a decent language for the web. Be it Ruby, Lua, Python, at this point I don't care. I'm partial to Python, but I won't fight for it if it means I can get anything with a real stdlib, good builtins, namespaces and a readable syntax.
The same thing happens now with regular browser caching, it's not that big of a deal. People will design run-times targeting webassembly to be lightweight, but if they end up being too heavy, developers will use CDNs the same way they do now with other large front-end dependencies.
> The solution would be for browsers to stop the madness and decide by community to adopt a new standard with a decent language for the web
A subjective and impossible consensus to achieve. The community will never be able to agree, that much is obvious. The answer isn't "pick a language that works today and hope for the best", that is how we got where we are today, rather, we need a solution that gives the community the power to experiment with better solutions that aren't constrained to a single language.
Let's put it this way. Think of your favorite language. Favorite paradigm, whatever. All the shit you hate about JS, picture the exact opposite of that. Now imagine that the web was entirely built around that.
Surprise: now everyone would hate exactly whatever you love. It would've grown all that hair and all those warts you currently despise about JS. It's what the world does.
So when people knock on JS, it's getting much harder to take this stuff seriously. I've been a dev for over a decade and have been down a dozen rabbit holes, from C++ template metaprogramming to .NET nonsense to elisp verbosity to hardcore functional + immutable paradigms. Loved all of them, each in their own way. What we have now with JS is simply incredible from a raw "get shit done" perspective.
It includes special cases for dates, takes O(n log n) time in the number of keys, and has suspicious comments like, "I've managed to break Object.keys through screwy arguments passing. Converting to array solves the problem." There are 15 open issues and 15 open pull requests. A sane language would have this operation built-in.
A better example would be the extremely poor Date object, which has only a couple format functions and can't even be created from a specified format. There's also a bunch of holes when manipulating data, filled by libraries like lodash(although the standard lib has improved significantly in this regard).
>>> {"foo": [1, 2, set([True])]} == {"foo": [1, 2, set([False])]}
False
>>> {"foo": [1, 2, set([True])]} == {"foo": [int('1'), 2, set([bool(1)])]}
True
There are better examples of deficiencies in Javascript's standard library, especially when targeting browsers, but Javascript has made massive strides lately like its native Set and Map datastructures.
For example, Set doesn't come with the classic methods `.intersection()` / `.difference()` / `.union()` / etc. but it's just not a defining moment of my overall experience with Javascript.
We're long past the days where you had to bring your own `Array#map`, but I don't know if all of these commenters are.
irb(main):002:0> {'foo' => [1, 2, [true].to_set]} == {'foo'
=> [1, 2, [false].to_set]}
=> false
irb(main):003:0> {'foo' => [1, 2, [true].to_set]} == {'foo'
=> ['1'.to_i, 2, [true].to_set]}
=> trueOff the top of my head, Haskell has "deriving Eq", and Scheme has "equal?". I'm pretty sure Python uses deep equality for tuples as well. Anyway, it's just one example of something I wanted to do in JS recently and ended up disappointed in the quality of the code I saw to do it.
Sure, you can perhaps override some methods on an object, but given two arbitrary objects (like two dicts in Python), knowing if two are 'equal' is not easy and certainly not built in.
That being said, JS doesn't make implementing this easy or simple at all.
irb(main):001:0> require 'set'
=> true
irb(main):002:0> {'foo' => [1, 2, [true].to_set]} == {'foo'
=> [1, 2, [false].to_set]}
=> false
irb(main):003:0> {'foo' => [1, 2, [true].to_set]} == {'foo'
=> ['1'.to_i, 2, [true].to_set]}
=> trueSee my other comment.
Pick a project. Think of a website you want to make. At no point during that are you going to be stonewalled by "Man, if only I wasn't forced to spend the last 4 hours debugging this weird deep equality issue. I could've gotten so much more done!"
You can take that information and use it however you want. It's the truth. It's up to you to either reject the notion or integrate it into your mindset and abandon the tendency to cling to idealisms. Ivory tower development simply does not happen in reality, and I say this as someone who spent a couple years trying to build an ivory tower Lisp.
I know it's not coming across at all, but I really identify with your mindset and acutely feel your pain. This was a major mental hurdle that I had to force myself to overcome. I'm saying, it's possible, and the only thing you have to do is to choose to do it.
Let go. Realize that it doesn't matter. It's worth the benefits. You can do so much more.
I was afraid that "letting go" would translate into "now I'm part of the problem too." But it turns out the opposite is true. It's very powerful that you have a background that most JS devs lack. Because they often rabbithole themselves into complexity, and you can come along and do something simple that no one else thought to stop and do.
But you can do all of that while still embracing the wider ecosystem. It's not an either-or. You can help bring sanity to what would otherwise be a ball of hair. But the way to be in that position is to jump in and churn churn churn until you've used Vue and React+Redux and understand the concepts and tradeoffs.
I have faced this on the job. About three abstraction layers deep in a Backbone app. It took me two days to trace the exact cause and find a way to implement a better check, that wouldn't make things respond in unexpected ways.
> It's up to you to either reject the notion or integrate it into your mindset and abandon the tendency to cling to idealisms.
JavaScript is terrible. It is not the product of academic research like Smalltalk or Haskell. I can accept it is the only tool available for the job, and continually look at all the solutions for that particular issue, and I will keep doing that.
I can use JavaScript, and I can write it. Usually my code is simpler and faster, because it takes me much longer to write anything, because of how aware I am of the side-effects. My employers in the past have liked the results that has produced.
But I will never enjoy writing it.
It is a language that is difficult in ways that reveal it's sloppy roots, and spill it's implementation details. Much of the time JS feels like working with UB in C, except it is actually detailed to act that strangely, in the spec.
Just an example that has always stuck with me, this is valid JS:
[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()
It's a tool. It's sharp on both sides, which can lead to a lot of blood-letting if you aren't careful. But it is still the best carving tool we have on hand.
Any Turing tar-pit can do incredible things. And when it has a monopoly on its own niche, of course incredible things happen.