I personally blame the robustness principle[1], which I think explains a lot of the accidental complexity in web programming.
Make it so that if the caller/client works at all then it must work correctly. Force them to handle errors and retry on things that might fail, values that might change, and if the result is something that must be parsed send it back in varying formats so they have to parse it.
IMO the "robustness principle" is a good thing because it realizes that people make mistakes and their goal isn't to make something correct but something that produces the results they want to see. Even if browsers started with XHTML-like strictness with no alternative, that strictness would quickly have eroded during the first browser wars.
I would argue HTML has been way more successful than React and thus XHTML hasn't been proven right.
Delete a byte from a zip file, and it won’t unzip.
I don’t see why HTML should be different…
Why _shouldn’t_ people have to make actually-valid-html? We don’t tolerate “only sort of correct JSON” tightening the acceptable requirements for valid HTML and CSS would likely make using those formats in more places _easier_.
HTML is different because it is parsed by the browser the end user is using when it is using it. If a site completely broke like, f.e. how Mozilla treated bad XHTML sites (instead of showing the site itself you'd get some yellow page with the error) when you got a tiny syntax error then anything with user generated content (forums, blogs, etc) or even just generated could be a potential minefield. Especially as websites started adding code from external sources (be it for ads or for things like youtube embeds or whatever).
Maybe the solution was to not publish sites that are a bracket off.
I think half the problems with JavaScript are because of its weak typing. 1 + {} should be a type error.
It's okay if JS has warts, but denying they exist doesn't help anyone.
> Do anything, even the wrong thing, just work.
It's even worse than PHP and JS were built around it.
Errors should never pass silently unless explicitly silenced.
Which is what "On Error Resume Next" was doing by overwriting the current error handler. Seems to me that it was simply overused. Implicitly ignoring errors is more a C thing.