• Jay (unregistered)

    Sigh. All these posters with the silly idea that the point of a software development project is to produce working code that satisfies some practical need and which can be understood and maintained by future programmers. But of course the REAL purpose of software development projects is to provide entertainment to the developers, and the best way to do that is to use the most complex and obscure technologies that you can find.

  • Is that a suppository up my ass or are you just happy to see me? (unregistered) in reply to M242
    M242:
    Ha! This is great-- I've been mentioned on TheDailyWTF, that's going to the very top of my resume. I'm the manager of the web team at Skechers, and we've all been having a great time reading the thread and the comments. Thank you, everyone, this is a great way to start a Friday. I would say that both the "wtf this is horrible!" and "no, this is great!" sides of the argument have great, valid points...

    Thanks again, everyone, this is great. It's hilarious to be mentioned on the site.

    And I, in turn, commend you on your grace in accepting this badge of "honor"!

    I (have to) use XSL all the time, mostly for XML->XML purposes, sometimes XML->Flat file, and while I hate coding in it, it does offer the benefit of allowing us the ability to patch changes to our QA/Prod environments with great ease. Just replace the xsl file on the server and you're done! Couldn't be easier!

    As for Sketchers.com, I thought this was the whole idea behind XSLT: translating XML content to HTML presentation. Seems pretty straight-forward.

    Whatevs, Congratulations, man!

  • (cs) in reply to Call Me P
    Call Me P:
    This is eerily familiar to me, having implemented a similar system on a smaller scale in the not-so-distant past. When we told our boss that our system would be receiving XML documents from our data sources and producing a unified XML document for export, he immediately demanded that we use XSL. He claimed that was how our organization always handled XML to XML conversions.

    Unfortunately for us, we had multiple source trees and a need for lots of general purpose computation going on between the inputs and outputs. Rather than try to exploit Turing equivalence or something equally mad, we came up with the best strange compromise we could. We would concatenate all the source trees, do all our business logic beforehand, append the results of every general purpose computation we wanted done, and finally pass it through XSL for the output formatting.

    This is just as WTF-worthy as it sounds, I assure you. We are only lucky that we managed to fulfill the requirements demanded of us in a modular enough way we could hope to maintain going forward.

    TRWTF is that in XML land, that is not a WTF.

  • (cs)

    The Skechers dev apparently missed the extremely laughable conf node...

  • David (unregistered) in reply to M242
    M242:
    Similarly, I saw a pseudo-trolling comment about the enterprisey ERP system returning XML. That's actually very close! We take the XML output from our implementation of Endeca (essentially Solr on steroids) and just slam it to the browser. The amount of server-side code to run the browsing experience on the site (a pseudo controller, if you want to talk MVC pattern) is, basically, one class of about 100 LOC, most of which is web service calls.

    Ha! Score! I was right... kudos, M242 - I would have done exactly the same. Yeah XSL is not as easy to use as it should be, yeah there are compatibility issues, but it's the obvious thing that comes to mind when I have XML and I want HTML.

  • anonymouse (unregistered) in reply to DWalker
    DWalker:
    Xenious:
    Pony:
    Not sixth, seventh, dude.

    Fuck you. It is zero based. Get back on you vb script, looser.

    As opposed to tighter?

    This comment thread just keeps getting better and better :) Thanks! you are all going into my quote file.

  • Randy Snicker (unregistered) in reply to M242
    M242:
    Why not shift as many cycles to the client as we can while still making it a relatively fast experience?
    Dear web designers/developers, this is why people hate you. Instead of being able to use your CPU cycles for something productive or at least pleasant, we "get" to use them for this. Add a couple of advertisers that have the same mindset and you find yourself having paid for a top-of-the-line computer with the effective processing power of a 133MHz Pentium.
  • Theman (unregistered)

    I tried it in Chrome, it renders almost instantly. If browser technology is up to it, I really don't see this as a WTF. It would have been 10 years ago but it seems to have matured significantly.

  • (cs) in reply to Dennis
    Dennis:
    No one cares about your whining.
    Except you, Dennis...
  • (cs) in reply to Paul Neumann
    Paul Neumann:
    Perhaps you are new to the interwebs? Here is a guide you should find most useful: http://goatse.info
    FTFY
  • Soulweaver (unregistered)

    Looks like they aren't very NoScript friendly either.

    http://img844.imageshack.us/img844/2360/skechers.jpg

  • Rupert (unregistered)
    and turned what used to be an extremely slow JSF-based mess

    Just to be clear, JSF can be really fast and allows for very clean / maintainable code. Yes, I've seen people fcking up badly with it, but as this is TDWTF you probably know people can fck up with basically everything.

    Just stay away from the old JSF 1.x, use JSF 2.x, follow some of the best practices and you'll be fine with JSF ;)

  • Josh (unregistered) in reply to M242

    We've adopted Scala for all new code

    I'm astounded that you'd go from this giant turd sandwich to something as nice as Scala.

  • Arkh (unregistered)

    I clicked on the link to sketchers.com. I got this: http://tof.canardpc.com/view/86c6ab8b-9002-4267-b12d-3c17b715578b.jpg I never thought I would see something worse than a flash website when using noscript.

  • Robert Rossney (unregistered)

    I dunno, kids. Maybe I just learned to identify with my torturers. But I've been using XSLT for client-side transformation since 1999. (Those people who keep saying XSLT doesn't work in IE: what the hell are you talking about? XSLT worked in IE back when it was still a W3C working draft.)

    It's hard to learn to think the way XSLT requires you to think. You'll come to the language with crazy notions like that variables can vary, for instance, or that looping is a first-class programming technique. In XSLT, variables get set once and never change, and loops are a last resort. Until you understand why these things are true, you'll sound like a lot of people in this thread.

    But once you start identifying with your torturers, XSLT is pretty hard to argue with. A platform-independent data transform language that's side-effect free? That's enormously powerful. I've built applications with enormous amounts of transformation logic - literally many hundreds of XSLT templates for a single document. I've gone back to those applications after not looking at the code for two years to implement new features. The new features come up disturbingly quickly, and my changes never introduce bugs into existing code. I've never come to an old project and thought, "Oh, God, I wish I hadn't used XSLT here." It's more like "Thank God I can fix this in the XSLT, so that I don't have to figure out what's going on in the C#/Java/JavaScript/VB code I wrote six years ago." (My C# programming style has changed enormously over the last decade. My XSLT style has changed very slightly.)

    Yes, it sucks to work with a language that can't do date arithmetic, use regular expressions, or even convert strings to upper case. (You can convert a string to upper case in XSLT, if you use a fantastically stupid hack.) Yes, it's a little dumb that XSLT is XML (until you start using XSLT to generate XSLT; then it makes a little more sense.) Yes, it's mind-bogglingly stupid that sometimes you have to use recursion to iterate over lists. Yes, using the combination of

    key()
    and
    xsl:key
    to implement maps is just idiotic. Do not get me started on Muenchian grouping.

    It doesn't matter. XSLT solves a problem that really has no better solution. You can avoid the problem entirely in a lot of ways - never representing your data as XML and using JSON and JQuery on the client, for instance - but in a lot of contexts it's absolutely the right tool for the job.

    No, the true WTF in the skechers.com example is this horrible antipattern:

    <prop value='some_value' strValue='some_other_value' key='name'/>

    One of the primary reasons to use XML in the first place is because it gives you simple and reliable way not only of transporting data but of validating that the data you're getting is right. Using this antipattern throws XML Schema out the window. I suppose these guys thought they had a good reason for this - "We control both endpoints, so we'll never need to validate our messages." I've thought that. I've almost always been proven wrong, and I bet these guys were too.

  • New_Fan (unregistered) in reply to M242

    @m242: Massive props + kudos. Next pair of sneakers (well, trainers, I'm British) I'm definitely buying Skechers.

  • Fg (unregistered)

    Despicable technology. I'd not be proud of perpetuating this trash.

  • jsno (unregistered) in reply to Soulweaver
    Soulweaver:
    Looks like they aren't very NoScript friendly either.

    http://img844.imageshack.us/img844/2360/skechers.jpg

    That isn't much different from what I get from all of Gawker Media's sites with NoScript.

  • TR (unregistered)

    The idea of generating HTML through XML-XSLT templates doesn't sound as a WTF to me. I used to work on a PHP app that the same XML-XSLT generation of HTML code. We used the XSLT engine Sablotron as a PHP extension to perform the generation. The difference was that the XSLT transformation was performed on the server (and only the result was sent to the client). At the time (2003) no mature frameworks had emerged yet and it was the best we could find to implement a MVC-like presentation/data/logic separation.

  • Jay (unregistered) in reply to Robert Rossney
    Robert Rossney:
    I dunno, kids. Maybe I just learned to identify with my torturers. But I've been using XSLT for client-side transformation since 1999. (Those people who keep saying XSLT doesn't work in IE: what the hell are you talking about? XSLT worked in IE back when it was still a W3C working draft.) ...

    I want to do an experiment. Tell the employees at some company that they must write all future technical documentation in Pig Latin, or that we are removing all the desks and chairs and employees must work while lying on the floor, or that the water cooler is being replaced with a pig urine dispenser. I theorize that within six months some number of employees will be prepared to argue forcefully that this is the only sensible way to do business.

    I bet I could get a government grant for this experiment.

  • (cs) in reply to Robert Rossney
    Robert Rossney:
    I dunno, kids. Maybe I just learned to identify with my torturers. But I've been using XSLT for client-side transformation since 1999. (Those people who keep saying XSLT doesn't work in IE: what the hell are you talking about? XSLT worked in IE back when it was still a W3C working draft.)

    It's hard to learn to think the way XSLT requires you to think. You'll come to the language with crazy notions like that variables can vary, for instance, or that looping is a first-class programming technique. In XSLT, variables get set once and never change, and loops are a last resort. Until you understand why these things are true, you'll sound like a lot of people in this thread.

    But once you start identifying with your torturers, XSLT is pretty hard to argue with. A platform-independent data transform language that's side-effect free? That's enormously powerful. I've built applications with enormous amounts of transformation logic - literally many hundreds of XSLT templates for a single document. I've gone back to those applications after not looking at the code for two years to implement new features. The new features come up disturbingly quickly, and my changes never introduce bugs into existing code. I've never come to an old project and thought, "Oh, God, I wish I hadn't used XSLT here." It's more like "Thank God I can fix this in the XSLT, so that I don't have to figure out what's going on in the C#/Java/JavaScript/VB code I wrote six years ago." (My C# programming style has changed enormously over the last decade. My XSLT style has changed very slightly.)

    Yes, it sucks to work with a language that can't do date arithmetic, use regular expressions, or even convert strings to upper case. (You can convert a string to upper case in XSLT, if you use a fantastically stupid hack.) Yes, it's a little dumb that XSLT is XML (until you start using XSLT to generate XSLT; then it makes a little more sense.) Yes, it's mind-bogglingly stupid that sometimes you have to use recursion to iterate over lists. Yes, using the combination of

    key()
    and
    xsl:key
    to implement maps is just idiotic. Do not get me started on Muenchian grouping.

    It doesn't matter. XSLT solves a problem that really has no better solution. You can avoid the problem entirely in a lot of ways - never representing your data as XML and using JSON and JQuery on the client, for instance - but in a lot of contexts it's absolutely the right tool for the job.

    No, the true WTF in the skechers.com example is this horrible antipattern:

    <prop value='some_value' strValue='some_other_value' key='name'/>

    One of the primary reasons to use XML in the first place is because it gives you simple and reliable way not only of transporting data but of validating that the data you're getting is right. Using this antipattern throws XML Schema out the window. I suppose these guys thought they had a good reason for this - "We control both endpoints, so we'll never need to validate our messages." I've thought that. I've almost always been proven wrong, and I bet these guys were too.

    XSLT doesn't need defending, but as I already pointed out, with the specific example of the conf node - these guys are doing it wrong. Also, it makes a shitty framework for webdev. A development suite that compiled into xslt would be much less of a wtf.

  • nowayman (unregistered) in reply to jc
    jc:
    Always knew such a thing would be theoretically possible but never found people crazy enough to actually do it. Kudos for this wonderful find :D

    My company does the exact same thing, it's been that way since 2001. XSL 2.0 does make it easier, and there are a lot of neat tricks you can do with it. (http://incrementaldevelopment.com/xsltrick/) Our data layer returns an XSL resultset, so it seemed logical to use XSLT to return HTML. Of course, we did ours server side instead of client side. Might have gone client side if our site was a high load application. It's not.

    That said, it's 2012 and 11 years is a long time to be using such a verbose template system. You have to remember, 2001 was when XML was the 'in' thing and you had to have XML to be cool. Now it's JSON or some other micro-format. In any case, we designed it so that our customers could modify it with relative ease. However, nobody in the world knows XSLT(, or wants to learn it) anymore.

  • HP LaserJet 2000 (unregistered) in reply to M242

    "But here's the great thing about XSLT-- it's cacheable on your browser.... Once you've downloaded the file once, you have the layout for the entire site already cached, and the next page you go to is 2k of XML."

    Am I the only one to call bullsh!t on this idea? The "next page" requires high-res images of each product plus real-time FB updates showing us the losers that 'like' the website. Surely those will be the bottleneck, not the HTML rendering?

    We don't all live right next to your server, you know. Some of us are nearly a thousand ms and > 15 hops away.

  • JS (unregistered) in reply to Randy Snicker
    M242: Why not shift as many cycles to the client as we can while still making it a relatively fast experience?
    Relatively fast for an average machine these days equals slow on my current machine. Just because you've got an extra core available to run rendering code on, doesn't mean everyone has one. If I had an extra core, I'd run something useful on it.
  • eMBee (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    Part of the problem with XSLT is also the skills shortage when it comes to finding people who can use it. With my employers previous system, where the page templates for their web apps were written in XSLT, they couldn't find any web developers that knew it. Fortunately, they found a highly intelligent PHP guy who was prepared to learn XSLT (not me I should add - I'm on the back end dev team).

    We've now switched to JSP for the presentation layer templates, and we can at least hire on the basis that a reasonably competent PHP monkey can be taught JSP and JSTL (with scriptlets disabled to stop them reverting to bad habits).

    huh? i've hired a university student who was only familiar with java. he figured out xslt within a week or two. if you hire people who are not prepared to learn something new then you are doing it wrong.

    greetings, eMBee.

  • got you covered (unregistered) in reply to Shutterbug
    Shutterbug:
    Lester:
    Ridiculously complex for absolutely no good reason.

    Isn't the the absolute definition of 'Enterprise-y'?

    (Disclaimer: I haven't read all 120-ish comments so don't shout at me if somebody else has already pointed this out!)

    I have read them and I can tell you: don't worry, you are safe.

    (Disclaimer: I haven't yet read all the comments after that one, so don't shout at me if somebody else has already pointed this out!)

  • got you covered (unregistered) in reply to derpderp
    derpderp:
    Every person here that thinks XSL is a good idea has clearly never created anything remotely resembling a Web site using XSL. Wanna output some attributes on a tag based on a condition? TOO BAD: THE XSL FILE MUST BE VALID XML. Wanna iterate through a list of invoice items, adding up their subtotals, and then print out a total? TOO BAD: VARIABLES ARE ACTUALLY CONSTANTS. Fuck XSL.
    i am not really a fan of xsl either, but it is not as bad as you make it out.

    try xsl:attribute ( http://www.w3schools.com/xsl/el_attribute.asp (it's klunky, but it can be done) and sum() ( http://www.w3schools.com/xpath/xpath_functions.asp )

    greetings, eMBee.

  • Sole Purpose of Visit (unregistered)

    Four pages, and people are still defending this monstrous insanity?

    The world is going to Hell in a hand-basket.

    Look, by all means, use some sort of functional transform/projection between XML and HTML. Try to avoid injecting, you know, state along the way.

    But once you've got that sussed, all you have to do is to deal with other possible inputs (a moving target in the Enterprisey world).

    To do that, you are not going to want to touch XSLT. You're going to want a proper AST (I'll accept the DOM as a substitute), and you're going to want an actual goddamn programmer.

    And any fool who claims that "it doesn't matter, because clients these days have multi-core machines that can do all the work for us" is ... um ... actually, it doesn't really matter what I think of them, because their clients will answer on my behalf.

    If they depend on this sort of dreck to keep their business running, then they will very soon (and, being clueless, without warning) realise that their business is no longer running.

    Does this remind anybody else of the Mumps wars on this site a couple of years ago?

  • fred (unregistered)

    I tried to view http://www.skechers.com/ with Firefox 7 and it still doesn't display correctly (there's a chunk of JS code sitting in place of where the video's supposed to be. Oh well, IE8 and Chrome 16 both seemed to render the website correctly though. Maybe Firefox was treated in the same manner as the usual developers treated IE.

  • MS (unregistered)

    Well about 10 years ago "we" did the same thing - but the rendering happened deploy-time for static content and server-side for dynamic stuff. Client always got HTML and JS.

    Main point here... thats a long while ago... today just go GWT, Vaadin or something like that

    kkthxbye

  • Mark (unregistered)

    All websites should be built this way. Since I learned the way of the XSLT ninja my development time has fallen through the floor and code quality is way higher (and we get draconian error handling for free, which is a huge omission from HTML).

    This is only a WTF for web monkeys who are too stupid to learn proper coding techniques.

  • Stupid User (unregistered) in reply to herby

    Considering that my bandwith is crappier than my CPU, spending a few cycles to save on bandwidth sounds like a pretty sweet deal to me.

  • J.B. (unregistered)

    Everyone seems to be missing the REAL WTF:

    Your twelve-page résumé could land you a job anywhere

    Twelve page resumes go to the bottom of my hiring pile. 2 page resumes float to the top. While I will eventually hire on skill demonstrated during an interview, the quality of your resume says a lot about you. Usually it means, "terrible communication skills; can't code their way out of a pickle bucket."

    Two pagers, please. Three in a pinch. :-)

  • M.S. (unregistered)

    somehow this seems familiar. I did something exactly like this on a project. The reason was that the project organization guy wanted to have the code based on XSLT templates, which could be reused. However putting the javascript code in (it was an Ajax framework to be more specific) was a major show stopper for a quick progress.

  • krez (unregistered)

    I just get "false". Yet another website that insists I enable JavaScript to look at pictures of sneakers. Harrumph.

  • jmo (unregistered) in reply to M242

    Actually, I found your site through accidental curiosity (my daughter was looking at it and I peeked at the source...whoa - they're sending XML? XSLT? for SHOES? wtf?). Then I found the WTF article.

    Your point exploiting the browser and caching is actually quite relevant:

    here's the great thing about XSLT-- it's cacheable on your browser. Instead of browsing from page to page to page, each time getting 25k+ of html, we can frontload a lot of that by having you download the XSLT. Once you've downloaded the file once, you have the layout for the entire site already cached, and the next page you go to is 2k of XML.

    I'd say your approach is innovative in positive way. Clearly WTF because it's unexpected, not because it's snafu. Appreciate your feedback on this article. I also work on a retail ecommerce site and I often cry when I see what is sent to the client, especially since we're usually seeing it when a UX test fails...

  • TheRealPinkyAndTheBrainFan187 (unregistered) in reply to M242
    M242:
    Ha! This is great-- I've been mentioned on TheDailyWTF, that's going to the very top of my resume. I'm the manager of the web team at Skechers, and we've all been having a great time reading the thread and the comments. Thank you, everyone, this is a great way to start a Friday. I would say that both the "wtf this is horrible!" and "no, this is great!" sides of the argument have great, valid points.

    I browse with NoScript on Firefox. When I go to skechers.com I see one word, all alone at the top left of my browser window: false

    Since I started browsing with NoScript installed I've noticed more and more instances of people failing to "fail beautiful" in the absence of Javascript/Flash, but this is the most egregious example I've yet come across! Congratulations.

    Now you say: "Ah, but you're an outlier, most people have javascript turned on" So I say: "Ah, but I'm a potential customer".

  • milo (unregistered) in reply to geoffrey

    XML is not a technology, it's a syntax.

  • David Walker (unregistered)

    Obviously insane. Couldn't possibly be a useful approach. And I can prove it, too. Just visit their site and you'll see how hopelessly ...

    Whoah! Speed! Responsiveness!

    This may be the fastest site I've visited this month. My only question now is why no-one else is doing this.

Leave a comment on “Sketchy Skechers.com”

Log In or post as a guest

Replying to comment #:

« Return to Article