> XSLT is very powerful but also incredibly messy because it has to be expressed in XML.
Being expressed in XML does not help, but the language is just bad with implicit data flowing through and very odd constructs, there are XML template languages which I found much more readable than XSLT e.g. I remember my experience with genshi much more fondly than the years I spent with XLST.
all code generators that are not code end up being like that. and just yesterday there was an article about that magazine reporting the end of programming because of some BASIC code generator. heh.
dbaseIIIplus was the one that actually almost managed this feat.
I could imagine use cases for this for example for REST apis that consume json and then have to transform it generically to some other json for db storage in a document database. The internal storage could change over time with the outside spec staying the same, and such transforms could be used to do the mapping per version.
This particular implementation looks a bit messy though - XSLT is valid XML and Xpath, while this solution uses templating syntax. That's more human readable, but also slightly inconsequent - you wouldn't be able to validate such a template with json schema for example.
Just to use the json-schema example - because the transform uses templating syntax inside strings, I wouldn't be able to write a json-schema to check if a given transform object is valid or not, which can quickly become an issue for growing sizes of transforms.
Oh man I have nightmares of XSLT from an internship I had a few years ago. Thankfully there's an XSLT guru on stack overflow that would answer every question I posted.
I mean, sure, it could do the job, but did anyone ever sit down at a file of XSLT and think "yes, this is the best way this information about transforming this XML could be represented"?
JSON is even less suitable for this. It's horrible to read this stuff, horrible to write.
XSLT was, and still is (imho) a great language - at least after 2.0.
There's a steep learning curve full of false summits, for sure, but once you grasp it, there is always an elegant way of solving a problem using it. Sometimes there's even a fast way!
Use of it in the wild, though, leaves a lot to be desired. The false summits lead people to write bad code, the bad code gives it a bad rep, the bad rep leads people to dislike using it, people's dislike leads to then writing bad code... and so on.
I just don't buy it - sure it can be used to do good things, but it's not about learning curves or "grasping it" - it's about "is this a good way for humans to write and read this transformation", and the answer is clearly no.
XML is not a good form for a transformation language. It's not the quality of the code written in it or anything like that.
Take XSLT and change the syntax, and sure, it might be great. You can't ignore the terrible, terrible choice of making the transformation itself XML. It's completely unreadable and horrific to write.
Conversely, I personally find it very readable, and enjoyable to write; don't forget, when people talk about using the right tool for a job, it's not all about the language and the task - the dynamic between the person and the language is just as important :-)
The vast majority of people find XSLT to be an unreadable mess - and for any non-trivial project that requires collaboration, just because it's possible for one person to like it doesn't make it a good choice.
If most people agree a representation is terrible, it's a bad choice for anything serious, because suddenly only a subset of your team or contributors can work on it effectively.
There is a reason XML isn't used as syntax for programming languages. Anyone claiming that an `if` construct, for example, is well represented by a mess of XML tags has a different brain to me and the vast majority of people I've met.
XSLT was meant to be a general-purpose tool. Having a syntax that the vast majority of people find incredibly hard to work with is clearly a huge problem with the spec.
XSLT is very powerful but also incredibly messy because it has to be expressed in XML.
Doing the same in JSON seems like it would result in the same problem.