> You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers.

That's exactly what we didn't want. The XSL encoded the view. The "page" was a pure semantic representation of the data in XML that wherever possible were direct projections from the models stored and serialied internally in our system, and the XSL generated each of the different views - be it HTML, RSS, Atom, or a condensed/simplified XML view. The latter was necessary largely because the "raw" XML data was more verbose than needed due to the deficiencies of XSL.

It's possible it'd be more pleasant to use XSL your way, but that way wouldn't have solved any issues we had a need to solve.

> you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture.

That would've meant the underlying XML would need to mix view and model considerations, which is exactly what we didn't want.

Today I'd simply use a mix of server-side transformations, CSS, and web components to achieve the same thing rather than try to force XSL to work for something it's so painful to use for.

Sorry, I misspoke. What I had was that contents of the page were served to the browser as XML. The browser automatically requested the appropriate XSLT to convert the XML to XHTML to display it nicely. Basically same thing that you had, except that I didn't need feeds.

What I wanted to say is that I didn't write XSLT by hand. Instead I was writing XHTML files with just few short, convenient markers, and my regexps based "compiler" converted them to various xls nasty tags generating output XSLT that was served.

For example `$name` was converted to `<xsl:value-of select="name" />` and `@R:person` was converted to `<xsl:for-each select="person">` and `@E` was converted to `</xsl:for-each>`

Basically there were 5 tags that were roughly equivalent to

with, for, else, if, end

`with` descended into a child in XML tree if the child was present and displayed enclosed XHTML

`for` displayed copy of the enclosed XHTML for each copy of its argument present in XML, descending into them

`else` displayed enclosed XHTML only if the argument node didn't exist in XML

`if` displayed enclosed XHTML Argument only if the element existed

Neither if nor else descended into the argument node in XML. With and for descended. XSLT was using relative paths everywhere.

`end` marked the end of each respective block.

> That would've meant the underlying XML would need to mix view and model considerations, which is exactly what we didn't want.

The thing is, what you are serving to the browser is always a View-Model. If you serve a Model instead you are just "silently casting" it onto a View-Model because at that moment they are identical. Sooner or later the need will arise to imbue this with some presentation specific information attached on the fly to data from your data layer Model.

I no longer try to use XSLT either, but I think web components are completely orthogonal tool. Your XSLT could still generate web components if you like. You could even "hydrate" generated HTML with React for interactivity.

What XML+XSLT was solving was basically skipped entirely by programmers. Instead of taking care about separating concerns, performance, flexibility they just thrown into the browser a server side generated soup that is only one step away from compiled binary and called it a day.