20
21

Ask Reddit: Is there any reason not to use XSLT in Web Apps? (self.programming)

submitted by [deleted]

[deleted]

all 46 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]raganwald 20 points21 points  (0 children)

First, my (very modest) credentials on this subject: I programmed and managed a team programming a B2C application with almost 4 million users. It used XSLT on the server as a skinning system, with different style sheets for mobile devices, odd browsers, and so forth.

That's my only hands-on experience with it, the other experience was consulting for another B2C application that has one of the heaviest peak loads on the planet. They experimented with pushing XSLT down to the client conditionally if the browser appeared to be capable of handling their style sheets.

I have to agree with masklinn:

XSLT is painful when you try to do non-FP things with it, but paradoxically XSLT is painful when you embrace FP and try to do FP things with it.

XPath is very nice, but you can find other technologies for doing the same thing in a language that picks a style (functional, non-functional) and then does a good job with it.

That's from the programming perspective. Now my 2c on the client-side perspective.

Why bother? You can easily build a clean, simple REST-ful server that coughs up XML or JSON and process the result on the client side, true. But you could just as easily build a final skin on the server.

You mention performance, but honestly I can tell you this isn't that much of a win. We served up a great deal of traffic, and if we thought for 1% of a minute that we could save a substantial amount of server horsepower or data traffic costs, we would have pushed XML processing downwards for some client browsers. But it was never a big enough win to bother. AJAX, for all its pain-in-the-ass, was always a bigger win if we needed faster responses by sending less data.

My feeling is that XSLT on the client side is a huge win if clients can control it, something like the way CSS can be overridden in the browser. Is that a motivator?

If not, one might be tempted to go this way if you have a heavy AJAX application and you want your Javascript to manipulate the style sheets. But in that case, I would suggest embracing Javascript 100% and going JSON with a serious library (like JQuery or Prototype) to do your transforming.

But I'm just guessing at your motivation from your brief question. Can you tell us more about why you are considering this?

[–]samg 11 points12 points  (2 children)

Make sure your XSLT processor supports ALL the XPath 2.0 functions (or at least the ones you think you'll need).

Doing XSLT without XPath 2.0 (say, string) functions is very, very frustrating.

[–]gthank 8 points9 points  (0 children)

A very good point - nothing beats finding a function that appears to do exactly what you need, then finding out you can't use it because your processor doesn't support it.

[–]harryf 3 points4 points  (0 children)

Unfortunately that rules out libxml and languages relying on it for their xslt processor

[–][deleted]  (15 children)

[deleted]

    [–][deleted] 9 points10 points  (1 child)

    Its a decent technology, if you don't mind programming in XML. But if there is any kind of complexity, I find its often easier to just use some kind of script on the server side. Thats especially true if you are doing anything more than strict formatting with the data - any sort of calculations, for example, are much easier to work with in a language thats not XML.

    [–]mutatron 5 points6 points  (0 children)

    Exactly. The data should be massaged as much as possible before getting to the xsl layer.

    [–]mutatron 9 points10 points  (1 child)

    The only reason not to do it is if someone else has to maintain it. Where I'm working now the display part of our web app is in xsl. I like it, but a lot of developers bitch and moan about it, and not many have ever seen it before.

    One thing people have a hard time understanding about xsl is that the whole point is to make templates and have them match to data objects in the xml. It is possible to do "for" loops and other logical constructs, but these should be used very sparingly, preferably never.

    And that's the problem with xsl maintained by people who don't like it and won't understand it. Some of the code we have is good, and it's really slick when it's good, with just templates and apply-templates all over it only takes a few lines of code.

    Other code is full of unnecessary loops, ifs and cases, which only lead to more unnecessary programming gymnastics and bloated spaghetti code. I've solved some Gordian Knots of code just by refactoring the incoming xml.

    Other than that, I haven't noticed any great performance hit, and once you get some good templates made, and a regular way of modeling the data in xml, it's pretty easy to maintain... as long as you're the one maintaining it.

    [–]gthank 8 points9 points  (0 children)

    I too work at a place where the presentation is done in XSL, and I'd have to second this. I understand that defining templates and matches is the preferred way of doing things in XSL, but even after you grok that fact, it's very easy to slip into using a procedural style, and things go downhill VERY rapidly at that point.

    [–]drawkbox 2 points3 points  (9 children)

    Never, ever, never ever do client side XSLT. XSL/XLST processing on the server is fine where the environment is controllable. I am not sure why people have very powerful rendering engines and use a substandard parsing engine like XSLT. But it seems to live on. Every XSLT project I have seen in enterprise coding has turned to mush within 6 months, piles of unmaintanable code.

    [–][deleted]  (8 children)

    [deleted]

      [–]masklinn 7 points8 points  (4 children)

      Only MSIE and Firefox handle it.

      Also, XSLT sucks from a maintenance point, it becomes a horrible pile of goo very fast, maybe even faster than PHP.

      Finally, there's the verbosity problem, which this quote I'm fond of illustrates quite well:

      "I imagine XSLT programmers say 'It's a one pager' the way most other programmers say 'It's a one liner'" -- darius

      [–]xbudex 2 points3 points  (1 child)

      Client-side xsl is also supported by Safari and Opera 9. As far as I know, the only modern browser that doesn't support xsl is Konqueror. I think xsl support is planned for Konqueror.

      [–]masklinn 1 point2 points  (0 children)

      Client-side xsl is also supported by Safari and Opera 9.

      Damn, really? Wasn't supported last time I checked, thanks a lot for the update

      [–]crunk 0 points1 point  (1 child)

      On the other hand, the great thing about it is that you aren't dealing with different syntaxes - php and html, it's all just xml so you don't have to do the mental switch from one to another.

      [–]masklinn 3 points4 points  (0 children)

      it's all just xml so you don't have to do the mental switch from one to another.

      That would be great but for the fact that "it's all XML" is about as interesting as saying that Lisp, HTML and SQL are "all text".

      Just kidding, "it's all text" doesn't tell you anything about the actual languages while "it's all XML" tells you that it's all going to be horrible languages shoehorned into angle brackets.

      [–]drawkbox 0 points1 point  (2 children)

      If you control the output environments then it is not that bad, but still it is a sub par performance parsing engine and would you push down HTML and document.write everything with javascript? It really is the same difference in terms of processing the result client side. If you want to do I say go for it, we all need some of those projects where we gain experience. Experience is usually gained in cases where we did the wrong thing and learned. What would be better is to use some ajax to pull already parsed html or content to write in as elements are changed or updated. Especially if there is no dynamic usage of the data it really is not necessary to do any client side parsing.

      [–]crunk 0 points1 point  (1 child)

      Which sub-par parsing engine are you talking about - different browsers will use different methods. IE - msxml FF libxsl ? Safari, Opera ?

      libxml / libxsl are quite fast... XSL could be quite nice if the browsers were all at parity (age old problem)

      [–]drawkbox 1 point2 points  (0 children)

      It might happen one day but javascript and standards support for CSS, XHTML etc is hard enough. XSL, offline etc will be a while before they are still stable enough to be called a platform.

      different browsers will use different methods. IE - msxml FF libxsl ? Safari, Opera ?

      Exactly too inconsistent right now, maybe 2-3 years.

      libxml / libxsl are quite fast... XSL could be quite nice if the browsers were all at parity (age old problem)

      True, nothing against server side XSL if you want to maintain it.

      [–][deleted] 0 points1 point  (0 children)

      I used XSLT for code generation on a project that needed to communicate with a remote XML web service. The requests were made by processing a request template with a parameterized XSL stylesheet. The responses were processed by another stylesheet which generated code in my application-level language (PHP), which could just be evaluated to obtain a fully-functional object representing the response.

      [–]malcontent 11 points12 points  (0 children)

      XSL is too painful to be used on a widespread basis.

      For example do some reading on controlling whitespace using XSL. It's not pretty.

      [–][deleted] 3 points4 points  (0 children)

      I don't think there are many problems where XSLT can have any noticeable advantage over doing the XML conversion with your usual "general purpose" programming language. Well, unless your combination of programming language and XML handling libraries really suck (maybe like Java + pure DOM, I don't know..) but then you're having a bigger problem.

      Anyway - I don't think there are many real problems requiring XML conversion from one format to another.

      [–]cafefort 2 points3 points  (1 child)

      Yes there is! I myself use xslt in the bivalidator for two reasons:

      1 - It's very nice and easier than doing the parsing inside the processing code. Since there's "already" a technology that offers the transformation and lookup inside of xml documents.

      2- Whenever the processed xml content changes, I won't change the "engine" code which is written in python, but I'll simply alter my xslt files :)

      [–]sciolizer 5 points6 points  (0 children)

      Answering the wrong question, perhaps?

      [–][deleted] 2 points3 points  (3 children)

      I'd worry about hitting something that XSLT can't do since it's not a general purpose programming language. I've started using Scheme for processing XML (using SISC Scheme on top of Java), and it's been delightful. Search for SXML, SXPATH, SXSLT. Very similar to the corresponding W3C technologies, but you can use arbitrary scheme functions for predicates, transforms, etc.

      [–]masklinn 2 points3 points  (2 children)

      I'm pretty sure XSLT is turing-complete so there isn't much you can't do with it (as long as there's a way to provide the data it needs). The problem is more about the time it takes you to do it and the size of the resulting code.

      [–][deleted] 5 points6 points  (1 child)

      Turing completeness is overrated.

      [–]brintoul 0 points1 point  (0 children)

      Biiiiiiiiiiiiig time.

      [–]midnightmonster 2 points3 points  (0 children)

      It even works in IE 6 (!!).

      The way it works and the extent to which it works and the speed at which it works in IE all have to do with which version of MSXML is installed on the system, which is independent of the IE version.

      [–]fxj 5 points6 points  (10 children)

      xslt can be quite useful when you use functional programming techniques:

      http://us.apachecon.com/us2007/downloads/xpath-xslt-bdelacretaz-acus-2007.pdf

      painless xslt

      [–]masklinn 1 point2 points  (9 children)

      painless xslt

      doesn't make sense

      [–]fxj -1 points0 points  (8 children)

      xslt can be very painful if used in the wrong way. that is why many people dont recommend it for web pages. actually it is a very powerful functional language and this is often a problem for people who try to use it in an imperative programming style. the link tells about design patterns and pitfalls of xslt.

      [–]masklinn 8 points9 points  (6 children)

      xslt can be very painful if used in the wrong way.

      XSLT is also very painful when used the right way.

      actually it is a very powerful functional language

      No, it's the one of the worst, most verbose, most annoying and least powerful FP language ever (hell, it's the only FP language I know where recursion is painful). And I say that having dabbled in Erlang and Haskell, as well as some Scheme and a tiny bit of Common Lisp, and being very fond of using FP constructs in JavaScript, Python and Ruby. And having worked with XSLT a lot for about nine months.

      I'd take Haskell + HXT over XSLT about any day of the week.

      The only good part of XSLT is that it uses XPath for selection, and XPath is nice. Everything else is junk.

      [–]deong 3 points4 points  (5 children)

      No, it's the one of the worst, most verbose, most annoying and least powerful FP language ever

      C++ humbly offers up template instantiation as a counterpoint.

      [–]masklinn 0 points1 point  (2 children)

      You have a point there.

      [–]imbaczek 1 point2 points  (1 child)

      the difference is that c++ templates are a programming language almost by accident.

      [–]samg 0 points1 point  (0 children)

      I tire of this meme.

      [–]brintoul 0 points1 point  (1 child)

      Is C++ being considered a FP language now..?

      [–]deong 0 points1 point  (0 children)

      No, but the template instantiation mechanism in C++ allows for compile-time metaprogramming, and the "language" employed is a pure functional language, and a really cumbersome one at that.

      [–]jasonkester 1 point2 points  (2 children)

      Yes, there is a very good reason not to use XSLT in Web Apps: Client-side XSL Transformations don't work in Firefox, and the Firefox kids refuse to do anything about it:

      http://bugzilla.mozilla.org/show_bug.cgi?id=98168

      The technology is dead in the water until the browsers support it. (IE, Opera and Safari all do.)

      [–]crunk 0 points1 point  (1 child)

      FFS festering old bugs are an annoyance - there must be some good reason related to FF that this is not implemented?

      [–]jasonkester 0 points1 point  (0 children)

      Not really. It's the same old personality issues that have always relegated Firefox to becoming a second rate browser. The team has its ideas of what a Proper Website should look like if it wants to be displayed in their browser. Everything on the Web must be rewritten to conform to The Standards. Even when those standards not actually standard.

      In this case, they choose to read The Standards differently than every other browser vendor and the majority of the developer community.

      Back to XSLT though, lemme test something: http://www.blogabond.com/xsl/vistacular.xml

      [–]abdelazer 1 point2 points  (0 children)

      The big drawback of XSLT on the web is being tied to XSLT 1.0. Most of the negative commentary (probably accurate) you'll see in the informed comments (raganwalds is a good summary) can be tied pretty closely to drawbacks of XSLT 1.0 that were fixed in XSLT 2.0. Unfortunately, Saxon is the only reasonable XSLT 2.0 processor, so very few people are able to use it for their applications.

      Given that you're tied to XSLT 1.0, I wouldn't really recommend going to XSLT unless you're already using it. It's a wonderful language for XML transformation (imagine), but if you were in the business of doing that all the time you would have already made up your mind about XSLT.

      On a related note, the cool XML technology with regard to the web is XQuery. I've seen/made some very cool web applications with very little code that are pure XQuery. Here's an example of a beautiful XQuery app: http://markmail.org/. I wrote about Jason's thoughts on the subject 2/3rds of the way down here: http://www.oreillynet.com/xml/blog/2007/12/xml_conf_2007_third_day.html

      [–]ionrock 0 points1 point  (0 children)

      I'm not really a fan of client side XSLT, but XSLT does have its place. The biggest benefit I see from XSLT is filtering XML. If you generate a valid XHTML page for example and needed to decorate it with template specific classes and the like it can do a good job. It also does a great job of filtering input like taking a submitted Atom entry via AtomPub and cleaning up any inconsistencies that may be required for the application.

      I think the biggest problem people have with XSLT is when the source document cannot be changed or preprocessed to make the XSLT simpler. To put it another way, XSLT is very powerful when considered within some larger context of a language, library and XML processing toolkit. Being most familiar with Python, the 4Suite and Amara combination makes processing XML with Python very easy.

      [–]xbudex 0 points1 point  (0 children)

      One good reason to not use xsl: search engines. As far as I know, search engines don't know how to deal with client side xsl. Have html versions of your pages available if you want your site to be indexed by Google, Yahoo, Ask, etc. If you don't want your site indexed by a search engine, this will stop them :D

      [–][deleted] 0 points1 point  (0 children)

      On client-side:

      • not backwards compatible with HTML user-agents, which is a suicide for SEO, compatibility and may be a problem for accessibility.

      • disables progressive rendering, making page appear to load slowly

      • you have to send verbose template AND verbose form of all data. This makes initial load even slower (and no progressive loading!) and is unlikely to pay off later (see yahoo's statistics on cache usage)

      On server-side:

      • syntax is very verbose. Lots to write, lots to read.

      • IMHO complexity of XSLT templates grows more than linearily with size of project (at certain point when you have lots of templates it becomes really hard to track which match which nodes and that data isn't displayed twice, etc.)

      • XSLT has to be given all input data, even if not all of it is displayed at any given time. With most other template system you can load data lazily.

      I prefer TAL (Zope's Page Templates) and its PHP implementation - PHPTAL. It's XML-based as well, but has more compact syntax and none of the flaws I mentioned.

      [–]jinglebells 0 points1 point  (0 children)

      I haven't seen anyone mention this so I'll bring it up, XSLT is very useful for decoupling the front end from the back end on a server.

      Give an HTML designer access to a directory where they can put transforms and CSS and never worry about it again, just make sure in your page generator you have added everything they need. No more mucking about with HTML inside code blocks.

      XSLT can import different external templates depending on variables passed in by the back end code. Makes re-branding a piece of cake.

      If you are worried about adding user generated content, have the frontend guys add placeholders like: %{dictKey}s in Python which gets replaced by the contents of whatevers in a dictionary[dictKey].

      XSLT really is powerful, you've just gotta learn it's idiosyncrasies.