There are a lot of gatcha moments in JS with weird behavior that makes it really easy to shoot yourself in the foot. It does get better as you get more experience but a lot of the oddities probably shouldn’t have existed to begin with. For what it was originally intended for (adding light scripting to websites) it’s fine but it very quickly gets out of hand the more you try to scale it up to larger codebases. TypeScript helps a little bit but the existence (and common usage) of ‘any’ has the potential to completely ruin any type safety guarantees TypeScript is intended to provide.
That’s true but at the same time the fact that JavaScript equality is so broken that they needed a === operator is exactly the problem I’m talking about.
And those examples were low hanging fruit but there are a million other ways JavaScript just makes it easy to write buggy code that doesn’t scale because the JavaScript abstraction hides everything that’s actually going on.
For example, all of the list abstractions (map, filter, reduce, etc.) will copy the array to a new list every time you chain them. Doing something like .filter(condition).map(tonewvalue) will copy the list twice and iterate over each new list separately. In most other languages (Java, C#, Rust, Go, etc.) the list abstractions are done over some sort of iterator or stream before being converted back into a list so that the copy only has to be done once. This makes using list abstractions pretty slow in JavaScript, especially when you have to chain multiple of them.
Another simple but really annoying thing that I’ve seen cause a lot of bugs - Array.sort will convert everything into strings and then sort if you don’t give it a comparison function. Yes, even with a list of numbers. [ -2, -1, 1, 2, 10 ] will become [ -1, -2, 1, 10, 2 ] when you sort it unless you pass in a function. But if you’re looking over code you wrote to check it, seeing a list.sort() won’t necessarily stand out to most people as looking incorrect, but the behavior doesn’t match what most people would assume.
All this is also without even getting started on the million JS frameworks and libraries which make it really easy to have vendor lock-in and version lock-in at the same time because upgrading or switching packages frequently requires a lot of changes unless you’re specifically isolating libraries to be useful (see any UI package x, and then the additional version x-react or x-angular)
That’s fair. I was mostly commenting on my own experiences with JS/TS, I’ve never used PHP so I can’t say if it’s better or worse but a few people I know have said that modern PHP is actually pretty good for personal projects. I’m guessing it would have its own set of nightmares if it was scaled to an enterprise level though.
For example, all of the list abstractions (map, filter, reduce, etc.) will copy the array to a new list every time you chain them.
This methods were added to generator recently. So you can avoid copying the array in memory.
All this is also without even getting started on the million JS frameworks and libraries which make it really easy to have vendor lock-in and version lock-in at the same time
In my opinion, it’s also what make JS good. There a package for almost everything.
To its credit JavaScript has made quite a few improvements to the underlying structure since 2016. JS is one of the most used languages because it is fast to adapt to changing environments along with wide support.
It is not a safe language by any means, it can be easy to fall down holes of unwarranted expectations. Like any language once understanding limitations will open up its power and potential.
Short answer:
Long answer:
There are a lot of gatcha moments in JS with weird behavior that makes it really easy to shoot yourself in the foot. It does get better as you get more experience but a lot of the oddities probably shouldn’t have existed to begin with. For what it was originally intended for (adding light scripting to websites) it’s fine but it very quickly gets out of hand the more you try to scale it up to larger codebases. TypeScript helps a little bit but the existence (and common usage) of ‘any’ has the potential to completely ruin any type safety guarantees TypeScript is intended to provide.
It’s always the type coersion. Just use === and 90% of the “footguns” people complain about go away.
That’s true but at the same time the fact that JavaScript equality is so broken that they needed a
===operator is exactly the problem I’m talking about.And those examples were low hanging fruit but there are a million other ways JavaScript just makes it easy to write buggy code that doesn’t scale because the JavaScript abstraction hides everything that’s actually going on.
For example, all of the list abstractions (map, filter, reduce, etc.) will copy the array to a new list every time you chain them. Doing something like
.filter(condition).map(to new value)will copy the list twice and iterate over each new list separately. In most other languages (Java, C#, Rust, Go, etc.) the list abstractions are done over some sort of iterator or stream before being converted back into a list so that the copy only has to be done once. This makes using list abstractions pretty slow in JavaScript, especially when you have to chain multiple of them.Another simple but really annoying thing that I’ve seen cause a lot of bugs - Array.sort will convert everything into strings and then sort if you don’t give it a comparison function. Yes, even with a list of numbers. [ -2, -1, 1, 2, 10 ] will become [ -1, -2, 1, 10, 2 ] when you sort it unless you pass in a function. But if you’re looking over code you wrote to check it, seeing a
list.sort()won’t necessarily stand out to most people as looking incorrect, but the behavior doesn’t match what most people would assume.All this is also without even getting started on the million JS frameworks and libraries which make it really easy to have vendor lock-in and version lock-in at the same time because upgrading or switching packages frequently requires a lot of changes unless you’re specifically isolating libraries to be useful (see any UI package
x, and then the additional versionx-reactorx-angular)Tldr; Why can’t we have nice things JS?
This is all true, although I don’t think it warrants saying that it’s worse than PHP.
That’s fair. I was mostly commenting on my own experiences with JS/TS, I’ve never used PHP so I can’t say if it’s better or worse but a few people I know have said that modern PHP is actually pretty good for personal projects. I’m guessing it would have its own set of nightmares if it was scaled to an enterprise level though.
This methods were added to generator recently. So you can avoid copying the array in memory.
In my opinion, it’s also what make JS good. There a package for almost everything.
To its credit JavaScript has made quite a few improvements to the underlying structure since 2016. JS is one of the most used languages because it is fast to adapt to changing environments along with wide support.
It is not a safe language by any means, it can be easy to fall down holes of unwarranted expectations. Like any language once understanding limitations will open up its power and potential.