Probably because everyone knows JavaScript, but not everyone use it by choice, giving you a higher than average ratio of people who both dislike and know the language.
This is actually one of the reasons I think every language except for JavaScript sucks for open source web-development. Not that I particularly like JavaScript myself, but everyone knows how to use it. I work for a Danish municipality, we use a lot of open source software, but we’re roughly 10 developers and ops technicians that support 7000 employees and around 300-500 IT systems. As a result we can’t use every tech-stack. This is pretty standard for average sized muniplacities by the way.
We don’t share tech stacks, but we do work together, and as you can imagine that leads to wasted resources. We’re a C# shop our direct neighbour does PHP, because of limited resources, we can’t utilise each others projects. That’s just a silly waste. Good luck convincing anyone to change their overall and often cohesive strategy for tech choices though.
The one technology we can all use, however, is JavaScript and everything build within that ecosystem can be put to good use everywhere. So while the language sucks at a lot of things, it’s also the only universal web language that we’ve got.
> We don’t share tech stacks, but we do work together, and as you can imagine that leads to wasted resources. We’re a C# shop our direct neighbour does PHP, because of limited resources, we can’t utilise each others projects. That’s just a silly waste. Good luck convincing anyone to change their overall and often cohesive strategy for tech choices though.
One suggestion, if you don't mind. When I did work for the DoD as a contractor, because of small business rules in government contracting we were pretty much forced to work with at least 10 other companies and all of them had their own preferences for tech stacks, their own expertise, etc. So we tried to go down the road of using things like thirft or avro so regardless of what language / stack you used, as long as you could interface with those on the same network (since we're talking about inter-service communication here) it was still pretty quick.
It's not ideal but sometimes you gotta work with what you have. Sometimes you can find unique ways to bridge gaps across platforms to re-use work. One time a group we worked with tried to use a web app with multiple iframes as the communication bridge between stacks. It _worked_ but it was pretty hacky and slow.
We do have some solutions, if it’s meant to be run as a SaaS or it’s got a major supplier doing updates and support, then we can use whatever.
The problem comes when we want to contribute or run things ourselves, in which case I’m not sure stuff like avro would help us, because we genuinely can’t keep X server technology secure or even updated with our available resources. I mean, I’m sure our Azure and ADFS technician could learn how to operate a JBOSS server on red hat, but he doesn’t have the time to do that and do his regular job. He might not even be interested in doing it, being one of the most talented Microsoft technicians I’ve ever met, he might simply move to a place that let him work with what he enjoys. Those aren’t great engineering arguments for not running JBOSS, I know, but that doesn’t mean it’s not part of managing an IT team.
Python has UnboundLocalError. Javascript will use undefined, which may not surface as an issue until later down the line. It’s the combination of features that makes JS behaviour so surprising to people.
Im talking about accessing variables in parent scopes. In python you have to explicitly declare the var as nonlocal, but in JS it just works. Now, I'm well aware that this was an active design decision made by both communities, and the "Pythonic" way wouldn't be to use `nonlocal` at all probably, but instead use a class or similar. However, I still consider its presence a wart of the language. (likely only because I am so much more familiar with JS!)
Silly micro example to explain what I'm talking about:
JS:
const countUpFromN = (n) => () => n++
Py:
def countUpFromN(n):
def add():
nonlocal n
n += 1
return n-1
return add
Keep in mind that you only need nonlocal to write, reads will work fine. So you can use a variable a bunch in some scope, then suddenly have things break when you try to simply write to it.
Actually, I think an interesting exercise for evaluating a language could be determining "how much code change do small semantic changes require". For instance, if we were to start with passing a generator (in the "generates a value" sense of the word, not the other one), and try to convert it to passing a counter, how would that look?
JS:
foo(x => () => x)
bar(x => () => x++)
Py:
foo(lambda x: lambda: x)
def countUpFromN(n):
def add():
nonlocal n
n += 1
return n-1
return add
bar(countUpFromN)
Fairly damning to python IMO. I'd be interested to see examples of where small changes in Python require large changes in JS.
The whole page, beside being really outdated, feels to be written by multiple people, each of them disliking different aspects of different languages, thus really inconsistent.
C# doesn't claim to have powerful type inference a la. Haskell, so there's no reason to expect it to extract type information from usage of parameters inside generic functions. If you need functionality inside the body, you gotta declare that functionality in the type constraints.
Simple -- because basically everyone is forced to use JS. If 10% of the people who use JS complain about it, and 20% of the people who use Perl complain about it, there are still more people complaining about JS.
WASM is interesting, but the market vastly favors JS. JS is simpler than WASM and transpiling, and any performance advantages WASM offers are relevant for edge case applications. A typical web-app will perform just fine with bloated JS these days.
Not to mention “nonlocal”...