Comment by kstrauser

Comment by kstrauser 20 hours ago

Seconded. I spend a whole lot of effort making my early 2000s websites emit compliant XHTML because it seemed like the right thing to do, and the way we were inevitably heading. And then I — and apparently almost everyone else, too, at the same time — realized it was a whole lot of busywork with almost nothing to show for it. The only thing XHTML ever added to the mix was a giant error message if you forget to write "<br/>" instead of "<br>".

Know what? Life's too short to lose time to remembering to close a self-closing tag.

About the time XHTML 1.1 came along, we collectively bailed and went to HTML5, and it was a breath of fresh air.

ndriscoll 19 hours ago

I don't understand this sentiment. Never have. I've doubted myself for years that I'm mistaken that this is how XHTML really fell out of favor despite it being what I recall reading at the time. A modern web developer is writing in javascript or typescript, which is going to make you correctly close your curly braces and parentheses (and so much more with typescript).

Then React introduced faux-XML as JSX except with this huge machinery of a runtime javascript virtual DOM instead of basic template expansion and everyone loves it? And if this react playground I've opened up reflects reality, JSX seems to literally require you to balance opening/closing your tags. The punch-line of the whole joke.

What was the point of this exercise? Why do people use JSX for e.g. blogs when HTML templating is built into the browser and they do nothing dynamic? For many years it's been hard to shake the feeling that it isn't some trick to justify 6 figure salaries for people making web pages that are simple enough that an 8 year old should be up to the task.

That same nagging feeling reassures me about our AI future though. Easy ways to do things have been here the whole time, yet here we are. I don't think companies are as focused on efficiency as they pretend. Clearly social aspects like empire building dominate.

Reply View 4 replies

the_mitsuhiko 7 hours ago

> I don't understand this sentiment. Never have.
It was pretty evident when it happened, particularly because XHTML in some browsers was parsed with a sloppy HTML parser, and in some with an XML parser which was strict. Guess what happened. Tons of invalid XHTML was out there and it made it impossible to parse as XML.

Reply View | 1 reply
- kstrauser 2 hours ago
  
  And some of the sloppy parsers rejected valid XML that the strict parsers accepted.
  Combined with Firefox and MSIE having different combinations of HTTP headers and doctype declarations to specify XHTML mode, it was way too hard to emit one single doc that was viewable on all common browsers. For a while my life involved regularly chasing down random issues that suddenly made our customers' browsers show an error page instead of the content, even when it was actually valid and passed all validators.
  I don't miss this.
  
  Reply View | 0 replies
DaiPlusPlus 17 hours ago

> Why do people use JSX for e.g. blogs when HTML templating is built into the browser and they do nothing dynamic?
...but real HTML templating isn't built-in to HTML[1]. Its absence for these 30 years is as huge a mystery as why there's no combobox input element (combination textbox+drop-down) or <select>'s limitations.
[1] What I mean by this is that JS+DOM still has no simple way of escaping HTML in a string. It's insane.
To elaborate: if you have a some arbitrary strings (unsanitized user input): `headerText` and `firstParagraph` that you want to render to a HTML fragment like `<h2>{headerText}</h2><p>{firstParagraph}</p>` then the only real way of doing this safely is by using the (archaic and verbose) DOM Level 1 methods (document.createElement, textContent = 'text', etc) which somehow always turn what-should-be a 1-liner pure-function in any sane language to a 10-line function with side-effects (...and as it's 2025 then it will probably be async too).
When JS added support for template-literals, I was excited that this might mean an end to the embarrassing problem, but because it didn't ship with HTML-escaping it means it's useless for that purpose - unless you're going to go through the effort to implement a full "tagged template" with a parser function, which I assume would handle the DOM parts.

Reply View | 0 replies
kstrauser 19 hours ago

It could be that we have drastically different ideas of "easy way to do things". To me, XSLT has never remotely resembled an easy way to do things. It seemed like a weird, difficult, almost deliberately obtuse horse designed by committee that technically worked but in a horrifying kind of way, like finding that someone write a C compiler Bash. Wow, it's cool that someone was able to do it at all, but I can't imagine ever wanting to jump on that train.

Reply View | 0 replies