The older ones among us remember when XML took over the world and everyone was supposed to use strict XHTML. It turned out that the strength of the HTML ecosystem was its fault tolerance. HTML4 was the "sloppy" answer to XHTML. It brought HTML back from a data language to a markup language. Every Markdown parser is similarly fault-tolerant as HTML parsers.

However, CSS and JS are not error-tolerant. A syntax error in a CSS rule causes it to be ignored. An unhandled JavaScript exception is a hard stop. This way, web does not run on tolerance.

▲ re 2 hours ago | parent | next [-]

> HTML4 was the "sloppy" answer to XHTML

I think you mean HTML5, which exhaustively specified how to do parsing in a fault-tolerant, normalizing way. HTML 4 (and 4.01) predated XHTML 1.0, and HTML 4.01 attempted to take things in a stricter direction, introducing a "Strict" DTD that did things like drop the <font> tag, in pursuit of separating structure and presentation.

▲ verandaguy 2 hours ago | parent | prev | next [-]

Funny enough my impression of JS (the kind you'd write in 2007 more than the type you see now, mind you) is that it's remarkably tolerant; many idioms and operations which would cause, in other languages, runtime errors or compile errors, would just get steamrolled over in JS because of just how much built-in flexibility the uber-weak type system (plus liberal use of the prototype pattern in the stdlib) allows for.

- Wanna subtract a string from a number? That's not a type error, that's a `NaN` -- which is just a perfectly-valid IEEE 754 float, after all, and we all float down here.

  - Hell -- arithmetic between arbitrary data types? Chances are you get `[object Object]` (either as a string literal or an *actual* object), which you can still operate on.

- Accessing an object field but you typoed the field name? No worries, that's just `undefined`, and you can always operate on `undefined` values.

Frankly, while I haven't had a frontend focus in about 15 years, I struggle to think of any situation where calling a stdlib function or standard language feature would result in an actual exception rather than just an off behaviour that'll accumulate over time the more of them you stack on eachother. I guess calling an undefined variable is a ReferenceError, but beyond that...

(This comment shouldn't be taken as an endorsement of this school of language design)

	▲	auxiliarymoose an hour ago \| parent [-]
		It is also (nearly) impossible to completely crash a web page. There isn't a main loop that can panic out. No matter where an exception gets thrown, the overall application keeps going and responding to events. Can't access a network resource? API returns an unexpected error? Library crashes? Browser extension breaks something? Doesn't matter. The user can still view and scroll the page, and the rest of it will probably keep working, too.

▲ sebular 2 hours ago | parent | prev | next [-]

Nonsense. Open the console on l any mediocre webpage and you’ll see a stream of JavaScript errors. But it’s still working. One script crashes? Doesn’t matter to any other script. Unhandled exception? Rest of the app is still working fine. Hell, that button may work if you just click it again.

And CSS syntax error causing only that single line of code to be ignored while every other line of code works fine is the very definition of fault tolerance.

What else could you possibly want?

▲

trimethylpurine an hour ago | parent [-]

All that is very good. But as a back end guy dabbling in front end, it would be more welcoming if JS was a little intuitive. I'm very thankful for LLMs now helping with that a bit, but honestly even they seem to fail at JS more so than other languages, at least in my experience so far.

	▲	auxiliarymoose 19 minutes ago \| parent [-]
		Much of the challenge in JS today is due to unnecessary packages, build systems, and workarounds found throughout blogs and forums which were reasonable 5-10 years ago but aren't really needed today. Unfortunately, LLMs tend to output old-fashioned JS. With (almost) everyone using an up-to-date standards-compliant browser, you can sidestep most of the complexity and weirdness by just using the standard library and ES Modules (instead of frameworks, libraries, build systems etc.) and an IDE with good intellisense + inline documentation lookup. MDN documentation is good and up to date overall, but I'm not sure there is a good overview/entry point resource that is up to date as of today... maybe I'll have to write it!

▲ MangoToupe 2 hours ago | parent | prev [-]

> It turned out that the strength of the HTML ecosystem was its fault tolerance.

I don't think this was a "strength" of html so much as a necessity to not break the internet. I certainly preferred the formal nature of xhtml to html 5. But, we're stuck with needing to render obviously formally-broken documents.

	▲	wredcoll 2 hours ago \| parent [-]
		So it's not a strength it's a necessity? I'm not sure these words mean what you think they do...