←back to thread

392 points _kush | 2 comments | | HN request time: 0.465s | source
Show context
CiaranMcNulty ◴[] No.44394259[source]
It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats.

I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like `<xsl:include href="mycorp://invoice/1234">`

This may be out-of-date bias but I'm still a little uneasy letting the browser do the locally, just because it used to be a minefield of incompatibility

replies(8): >>44394503 #>>44394794 #>>44395004 #>>44395249 #>>44395303 #>>44396380 #>>44398418 #>>44399777 #
tootie ◴[] No.44399777[source]
I never enjoyed XSLT. It always felt like a square peg for a round hole. I do miss XML though. It had so, so many power features that too few people knew how to use. XSD was incredibly good for domain modeling. It had an include systems for composing files. And nobody really made good use of mixed content, but it was a crazy powerful feature. You embed structured content in unstructured content inside structured content.
replies(1): >>44399829 #
1. int_19h ◴[] No.44399829[source]
The original idea was good: having a purely declarative language running on the client which just does the model -> view transformation, and having the server serve the models. XSLT as an implementation of that idea is pretty bad, but mostly because using XML as the underlying syntax for a PL is very unergonomic. If the initial version of XSLT looked more like XQuery does, I think it would have been a lot more popular.
replies(1): >>44400114 #
2. tootie ◴[] No.44400114[source]
Yeah, the idea makes sense. More sense than CSS which ended requiring years and years of refinement and pre-processors to be usable.