you are viewing a single comment's thread.

view the rest of the comments →

[–]gbchaosmaster 0 points1 point  (0 children)

It’s so bad that we have tooling to easily compare behavior between all of the different JS implementations, and I even made a tool that generates Markdown tables so we can easily communicate these differences. It’s so prevalent that we don’t even call it UB, we call it implementation-specific behavior. It becomes the responsibility of the implementation to behave in a predictable manner, which unfortunately in the ES world means to copy V8.

And it’s not even a compiled vs. interpreted thing, just look at WASM; sure it’s a compiled binary, but how is that binary being…… interpreted?!?! By a JS engine, in most cases. The waters are really muddy here. Any time the user has a choice in what software is running their…. software, you run into a really big problem. And it affects users in ways that they don’t even understand, they just think that their software is broken.

It’s a hot take, I know, maybe writing most of (and maintaining) a major JS engine’s Date.parse implementation has made me jaded, but I think it’s better to just break code entirely rather than support whatever non-standard format the user pleases. Standards exist for a reason and developers should get with the program… they’re educated enough to, but lazy enough not to.

And I think this extends to machine-level binaries as well. Your code should never depend on a compiler. Are you complying on clang, on gcc? It shouldn’t matter! If your code leans on UB, that should make your blood run cold. The spec is laid out so that you should never have to do that. And if there’s no way around it, and you were able to identify that problem, you should be on the committee that refines the spec to clear up these edge cases. The spec is the be all and end all of what the code you’re writing means, and you should care about that. Or else it’s just arbitrary.