Does anyone use xslt anymore

Because the XML libraries are so horrendous to use from any language. Horrible legacy technology full of bugs nobody was bothered to fix. Havvy on Dec 6, root parent next [—]. JavaScript isn't full of bugs nobody has bothered to fix. It's full of specified behavior that cannot be fixed without breaking backwards compatibility. That said, the issues are well known and actually bypassable.

Whether you should be using it for the problem XSLT tries to solve is another question. Probably not, since there are other templating languages. Unfortuntely running Javascript on the back-end for this purpose is not something most companies do. You're joking, right?

There are JSON libraries for every back end language and ecosystem you could imagine. The first part of the first quote is incorrect. The problem XML solved was bloody hard, though most people nowadays have forgotten what it was. It was to get the world's programmers to stop creating binary file formats, to put an end to the situation where every time you went onto a site, the first thing you had to do was reverse engineer binary files with a hex dump utility.

XML, to its very great credit, solved that problem. Now if you want to start asking whether it solves the problem as well as today's competing technologies like JSON, at that point I will step back and hold my peace. XSLT is one of the most powerful and elegant technologies created in the last 15 years. Those who don't understand it and that's why can't use it, should just do their home work and learn better. My definition of powerful and elegant is lisp XML is just death by overengineering.

That myth has been decisively addressed by Erik Naggum about 12 years ago. And XML is not just another way of writing S-exps. I'll just tell you to search for "naggum xml", there are more than enough copies in circulation, and you'll find a few more postings by other people. It is really at least two languages the XML tags, and the query language that is used inside selectors. However, I know that I could have done their job better if I could have used some structured data, an HTML formatter, and a real programming language.

DennisP on Dec 6, root parent prev next [—]. Tell any lisp programmer he doesn't get first-class functions and has to use nothing but macros, and he'll run screaming in horror. XML and XSLT are analagous to s-exprs and macros, to say they are "just" those things is willful ignorance of a whole boatload of complexity. VMG on Dec 6, root parent next [—]. There is no other way of encoding structured documents these days than XML. Like it or not, XML is the de facto standard for data exchange export from databases, product information software, XML might be overengeneered which, except for a few things I don't agree with , but there is currently no alternative for it.

There's perhaps no general alternative to it that covers all of the things XML tries to do; there are lots of specific alternatives that cover specific things that XML tries to do. The complaint against XML isn't that there is a better general replacement so much that there is a better replacement for each or at least, very many of the applications and that trying to shoehorn all of them into a single solution has costs that outweigh the benefits.

The site in question lists several alternatives, some of which are widely in use especially in cases where XML falls short: brevity, fast to parse, easily readable Most of all, calling it the de facto standard is either dishonest or clueless.

I am working for many years in the publishing business dealing with structured documents, product data etc. I can tell you, that all of my customers are more open XML than any other document formats there exist none as suitable for the job.

You can call me clueless or dishonest, I don't care. I can only share my experience with the topic. You don't have to believe me. Your customers in the field you work in, perhaps, but it's hard to tell that's what you mean when you write data exchange. It's a wide field that is not limited to the publishing business or your customers. The "other" format is of course PDF. Maybe all of this will change when we have more technologies that support formats that can handle mixed content as easily as XML.

Does anyone use Microsoft XPS? It looked rather interesting; like PDF without any interactivity except for links and with special support for publishing color management, job tickets, etc. And internally it is a collection of XML docs and binary data zipped together into a single file; pretty neat, must be easier to use in automated workflows.

I can't answer the question but anyway: None of my customers have ever asked for that. I have not seen a printing house that demands XPS. So I doubt that it plays any role in the market Germany here. Thanks, that's informative. I haven't seen it used much either; the only real use I saw aside from viewing was an XPS printer driver for a Canon inkjet printer. I've also heard that it produced better results than the standard driver, but have no first-hand experience.

Or for that matter in SQL as is the usual practise. Marked up structured text is a different matter, XML still has a use case there. I was a bit unclear. Most of the times the documents I get are hierarchically structured. Yes, JSON could be fine as well.

But it simply lacks a standard toolchain which XSLT ans its ilk proides. I am not trying to defend XML in any way. I have not found such a toolchain for other formats. But XML does not map well to a database dump. A database is a set of sets of tuples. It is not generically hierarchical. It maps to a set of csv files say, as a transfer medium, but it is designed to be manipulated through relational calculus, which is not easily mapped to xslt.

You are using tools not because they map well to the problem space, but because they are the tools you have, which your customers want, and which you are familiar with, but that does not mean they are actually mapping well to the domain. Actually the XML part is the one that maps best to the problem space. The database part usually Excel sheets or SQL based stores are the ones that are "insufficient".

Just recently I had the chance to do a rewrite. And every piece of output HTML is defined just once in the whole application so it's easy to maintain. With the help of XSLT you can abstract a lot of things. I have to say, I love it. The problem is that it's often misused. Using an XSLT that takes 0. Using it for async transformations - html to pdf, customer message format to your message format. The problem is not that it is misused. The problem is that there is a small subset of problems for which it works passably like many other technologies and a large universe of problems for which it will cause you massive pain.

Compiled XSLT stylesheets must be very efficient; they're automata, like regular expressions. I believe the fundamental pain of xslt was When teaching XSLT, the difference between those who said "its elegant" vs. When I see the pain FP causes in the real world I'm never quite sure whether its nature or nurture. I currently believe its a bit of both but the nature part will always hobble FP adoption - if you find algebraic proofs elegant, you will like FP. If you are "normal" and proving a theorem fills you with terror then you would prefer your programming language to resemble a a cookery recipe.

I also believe all templating, especially for code-generation, requires three brains - understanding the input data-structure, understanding the processing of the template and understanding the behaviour of the output. Each keystroke in your templating language has to be carried out with full understanding of all three parts. Its too much for those if they still struggle with more common two brain programming problems. VMG on Dec 6, parent next [—]. I'm tempted to upload a video of my eye twitching just to prove it.

That seems like the difference between object-based early VB and object-oriented. XSLT is referentially transparent no setf for you but withholds from you most of the goodies that people take for granted in functional or logic programming.

You could see it was written by well-intentioned FP enthusiasts. But Perl was never enterprisey enough, and XmlPerl died a painless death.

I've heard this before, but I don't find it to be true for me anyway. XSLT makes it hard to figure out how to express even moderately complex algorithms e. The FP bit was fine. It's more of a declarative language. Like Prolog. I dont think its really either a functional programming language no first class functions , or a logic programming language like Prolog not implemented via unification. It is a declarative language that is in an independent category.

I really enjoyed proving theorems for analysis - I have an undergrad degree in mathematics - but not so much algebraic proofs. Where does that put me? FP languages are a minority even in the professional mathematics world. I once worked on an embedded system with not a lot of RAM or code space, and we were ripping features out to put new stuff in and rewriting things to make new things fit not a bad practice, re-writing, btw. Because it was standard. Because XML added to anything makes it better, no matter what it is.

Because, well, nobody ever saw that traffic except other computers, but XML! I wanted to kill, kill, kill, but instead I wrote an XML parser kind of that fit into about 1K of code. I think the PM was happy. That group got sold to a company famous for its 60s-era radios and crappy teevees, and I assume everyone is happy there, because I have not heard a word from them, and XML!

I've seen XSLT done well, and I've seen the mess it can be when written by someone with only a passing knowledge. As a consultant I usually have dealt with the latter, and that usually goes hand in hand with a poorly designed XML schema. One space that XSLT can demonstrate its strength is when transforming some horribly serialized interoperability data structure. If the system from which you are receiving data, produces terse XML, you aren't going to solve anything by rewriting the upstream system to produce equally lousy JSON.

If you don't have the ability to fix the upstream service to produce better structured data, XSLT and XPath are wonderful tools to morph it into something more manageable. That transformation process is better written with XSLTs than it is in trying to do the same thing by slurping the data directly into some business object and trying then to work with a bad model.

Don't go down the path of "garbage out, garbage in. I would use a language that has a decent XML parser e. Assuming it was a simple transformation, the python parsing code could be under 10 lines.

Most of what you wrote would be templating. If it got complicated though e. The same pattern could be applied to many other language ecosystems. You just need to make sure you get the best XML parsing library and the best templating language.

You could do the exact same thing using XSLT. I'm sure in some cases XSLT would be better for the job, and in other cases another language. Most of the time it would generally just depend on your environment, available tools and skillset. I can't see it being clearer or easier to maintain under any circumstances. Once your code evolves toward doing anything mildly complicated you'll wish you never made your transformation in xslt. I don't know if you're trolling, but here's how I'd do it in Python import xml.

I'm not sure if you are trolling, but you left out the actual transform. In my experience, XSLT feels optimized towards transforms, which most other languages aren't. I'm getting downvotes here? You are probably getting downloads from the fact that your response did not make any sense. You'll see something in the XML that you think you can change, but now it doesn't validate anymore after you change it using a text editor. If I cannot use a basic text editor, it's not basic text.

If it's not basic text, it's no better than any other binary protocol, albeit a very inefficient one. How do you manage to change C or Python source code? Omit a ";" in C or ":" in Python and it will refuse to compile.

What article are we supposed to look at? It is witty quotes and links, there in no substance is this article, just bashing.

Is it supposed to be an answer to this article that had a lot of discussion on proggit? I wasn't surprised, given the domain. Plan 9 fanboys tend to have a very simplistic view of the world and think that "KISS", "do one thing well" and "just pipe stuff" is the universal solution to all problems. Why are you shocked? Investing in a software stack for a website is non-trivial. If it's working for them then it's throwing money away to change it right now.

The problem with most tools is that they go through the "bright and shiny" stage: "New tool - cool! XSLT exists for inter-organizational data transfer and transformation. Don't use it for any other situation. XML is a good not perfect persistent data storage mechanism where you need the data to outlast the program that created it. Lets not blame a tool that was misused. Sign up to join this community. The best answers are voted up and rise to the top.

Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Why is XSLT so rarely used on the web? Asked 3 years ago. Active 3 years ago. Viewed 6k times. Improve this question. Boann 4 4 bronze badges. George Sovetov George Sovetov 2 2 silver badges 9 9 bronze badges. I kid you not, just last night I heard developers saying how grateful they were that they never had to use XSLT again.

See: stackoverflow. Have you ever tried doing something nontrivial with it? Is 'because it is agony to use' a valid answer..? Add a comment. Active Oldest Votes. But HTML is in itself a perfectly fine format, so why not just use that for the content in the first place and skip the transformation?

CSS has become much more powerful. One of the promises of XSLT was that you could keep the source markup clean and semantic and then transform it into "presentational HTML" which worked cross browser and where you could rearrange elements and so on.

XML has not become the ubiquitous format for data. XSLT is designed for transforming a whole document at a time. But in modern interactive web pages, small snippets of data are downloaded piecemeal all the time and merged into the page. Data is just not so complex. For the majority of use cases, simpler template formats with placeholders and repeaters solve the task fine. XSLT is more much more powerful, but you rarely need that extra power, and it has a steep cost in complexity and uglyness.

Improve this answer. JacquesB JacquesB So again, I do not know how widespread was this "advantage" explained the improved bandwidth would have also hurt it and the fact that most HTML pages are fairly small. SJuan That is a take on the idea to transform semantic markup into verbose presentational HTML that uses tables for layout.

Luckily it is no longer necessary to use tables for layout so that use case is moot. JacquesB I used that couple for that page: programaths. It's not about formatting in tables, but the XML offers me a good abstraction. Of course, I don't care about people cheating.

It is rather a good persistence format for mapping tools. XSLT is difficult to work with, but once you conquer it you will have a very thorough understanding of the DOM and schema.

If you also XPath, then you on your way to learning functional programming and this will expose to new techniques and ways about solving problems. XSLT is pretty much dead because only a few enthusiasts still use it.

However, there is no real alternative for it. If you focus only on a single use case, such as for example rendering of HTML pages from semantic documents, you find better tools. It is used to describe and validate the structure and the content of XML data.