Comment by scotty79
3 months ago
XSLT is much nicer to use if you just create a very simple templating language that compiles to XSLT. Subset of XLST already has a structure of typical templating language. It can even be done with regexps.
Then simplicity becomes a feature. You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. Each template is simple and straightforward to write and read.
And while different date format seems to be a one off thing you'd prefer to deal with as late as possible in the stack, if you think broader, like addressing global audience in their respective languages and cultures, you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture. Then doing just dates and perhaps numbers in the browser is just inconsistent.
If browsers implemented https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange the web would get double digit percent lighter and faster and more accessible to humans and ai.
But that would let you filter out ads orders of magnitude easier. So it won't happen.
Microsoft SharePoint version 2007 and 2010 where all XSLT. Used in just about every serious Intranet 15...20 years ago.
Developers deemed it too complex (or they were just stupid?)
SharePoint 2013 went the CSR (Microsofts "Client-Side-Rendering") path and SharePoint 2016 went the JSON/React path
Maybe with current AI aid XSLT would have had a chance... or we are still just too stupid.
Yes, XML/XSLT is a better technology, so was any Video Casette tape BUT VHS in the early 80s
> 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.
> 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.
There's a huge difference in the level of presentation specific logic you include, though. E.g. between including the publication date of something vs. including the publication date in 4 different ways because it needs to be presented in 4 different ways in different formats and templates. One is about having to ensure a superset of the information required is available, and that superset can often involve very limited overhead (and can even end up being "cheaper" through being able to have fewer, more heavily accessed, cached items), while the other means you need to closely couple it to specific details of the presentation.
> 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.
Web components alone maybe, but combined with a higher level framework that also lets you do server side rendering, we're back to being able to serve up a single format and choose to transform it either on the server side or client side as needed, without the pain of XSL
> Your XSLT could still generate web components if you like.
Yes, but I wouldn't gain anything at all from that other than the pain of dealing with XSLT.
> What XML+XSLT was solving was basically skipped entirely by programmers.
Because XML+XSLT wasn't solving it in a way that was good enough even for people like me who badly wanted to like it. We got it to work, but neve