However, with JavaScript you have to avoid the old/outdated language constructs, and some warts need to remain, since browsers still need to support old websites. Perhaps in the future we can specify "ECMAScript version" (similar to perl) so old stuff can be thrown away and the VM can optimize without having to worry as much about backwards compatibility.
I'm not entirely sure what you're getting at (perhaps the fact that it mutates the original string, similar to `Array.prototype.splice()`) ... but I can say it's never gotten in my way.
I didn't know about the do BLOCK syntax that's (possibly) coming, that's interesting, thanks for bringing that up.
Regarding your last comment about Ruby and Python. I've been thinking about this for a while and I think a lot of the hate people have towards JavaScript is due to the fact that (being the only "official" web language) lots of people were forced to use it without any other choice, which adds a lot of resentment.
On the other hand, Ruby and Python are deliberate choices of which there are many options. People who choose to use it love it, and people who don't can move onto something else. It's not the same with JavaScript. If you want (or need) to do frontend development, you had to use JavaScript.
I observed this with Lua community in the past. I hardly ever see anything negative about it, but it has its own oddities (such as 1-based indexing, global by default variables) and is in a lot of ways similar to JavaScript being a prototype-based language (the only other one that I know of actually).
Considering how much I like TypeScript, kotlin-js sounds tempting based on your comment, but unfortunately it's a no-go for me the because I use React heavily, and the solutions I've seen for that look less ideal (for me) than using JSX.
You bring up a good point, but as you know, there's a certain amount of intuitive knowledge that gets carried over when learning another programming language (which is why it's much easier to learn additional languages than it was the first one you spent a considerable amount of time with). The problem is, JavaScript does look a whole lot like the languages you mention, it's just that some things behave vastly differently (ie. function scoped variables, behavior of double equals, etc.), which is what causes the confusion and sometimes you don't learn about these things until they bite you at some point.
I wouldn’t consider them business-only as most individuals interacting with the App Store have bank accounts, so that argument breaks down.
I wouldn’t consider them stictly “reader” apps as you can perform many non-passive things in many banking apps (make deposits, iniatiate transfers to and from accounts, pay bills, etc), so that argument doesn’t stick either.
You can’t use the app unless you have a (most of the time) paid account.
editor.fontLigatures has been expanded to allow you to specify stylistic sets, such as "'ss01', 'liga'" (and so on).
I was looking forward to this because I wanted to enable the "ss01" stylistic set for Fira Code, which takes away the downward slope at the end of the "r" character that I don't like, but it doesn't seem to be working for me.
Was anyone else able get this working for Fira Code?
However, with JavaScript you have to avoid the old/outdated language constructs, and some warts need to remain, since browsers still need to support old websites. Perhaps in the future we can specify "ECMAScript version" (similar to perl) so old stuff can be thrown away and the VM can optimize without having to worry as much about backwards compatibility.