I think I agree with everything he's saying. There have been arguments against javascript for a long time. If anything though, I think they've diminished over time as the language has improved. I still don't really like it.
But there still isn't a technology that can do what js does. That is, distribute apps in a truly cross-platform, zero-install way. So people will keep using it at least as long as that's true.
I'm still bitter that he kept comments out of the JSON syntax out of a fear they would be used for processing directives. I want to have comments in my config files, so I've been left with having almost-JSON config files, or even weirder hacks like "_comment" properties. (which could also be used processing directives FWIW)
I think the issue with comments runs a bit deeper and is more pervasive than the (sad) fact that plain JSON does not support them. Case in point, I just tried and improved a frequently-used piece of 3rd-party software (written in Python) that I use as a CLI tool. Because I use it frequently I want to pass in parameters on the command line instead of editing a TOML file, so I got myself a TOML parser and wrote a teeny NodeJS script that reads the TOML and returns an object on which I set a property according to the argv value, then serialize it and write out to the TOML file, then run that Python tool which grabs the value from the config. Nice kludge and all BUT, as a matter of course, the code comments in the TOML file that instruct users what the entries are for and so on—those are gone after the update. I fixed that problem by making a copy of the original TOML file.
So long whine short, I believe comments should have some kind of 1st class status in configuration files and tools should ideally offer to preserve them even when settings are updated, and to delete them when e.g. talking to another electronic machine over the telephone network, if you know what I mean. The same really goes for comments in other languages like JS, CSS, HTML: they're quite often just fly-over territory, but sometimes, just sometimes folks, they should be kept, and I don't see a great many tools that readily give me that option.
> But there still isn't a technology that can do what js does. That is, distribute apps in a truly cross-platform, zero-install way.
It's not a technology problem. You could accomplish this with almost anything - the problem is getting enough adoption to be in a majority of devices. Aside from web browsers the only example I know of are the "super apps" like WeChat.
Something like roblox could eventually morph into it. Except the corporate overlords would not be able to help themselves from enshittifying out of usefulness.
Web standards (and email) occupy a unique position that will be hard to replicate. And not for technology reasons.
The difference is that the “_comment” as a processing directive is that the JS value and the raw file reflect the same data, where the comment would be invisible at runtime. In this way “_comment” isn’t a workaround, it’s the reflection of the reason the decision was made in the first place (no difference between value and raw).
Strong disagree. We ended up with a Markdown-like menagerie of parsers and serializers with varying degrees of spec-compliance and non-compliant options. In practice, there are plenty of config files that consist of json-with-comments.
I'm good with banning comments in mostly machine-targeted files. But human edited config files that I work on are mostly json these days, and have been. The "_comment" field is not in any schema. No receiving system will read it, other than to throw for schema-non-compliance. I want to leave a message for other human readers inline. If comments would have killed JSON, then we shouldn't have adopted it for config files, because I guess JSON is killing config files?
But there still isn't a technology that can do what js does. That is, distribute apps in a truly cross-platform, zero-install way. So people will keep using it at least as long as that's true.
I'm still bitter that he kept comments out of the JSON syntax out of a fear they would be used for processing directives. I want to have comments in my config files, so I've been left with having almost-JSON config files, or even weirder hacks like "_comment" properties. (which could also be used processing directives FWIW)