6 ms·
This is a really cool hack. > The JSON must contain only pure information without any concern about design or markup. Wellll.. I mean the json has markdown sy
by habitue 6y ago
This is a really cool hack.
> The JSON must contain only pure information without any concern about design or markup.
Wellll.. I mean the json has markdown syntax in it. That's a lot nicer than html tags for markup, but it's still markup.
In case anyone reading hasn't seen it before, browsers have a thing called XSLT built into them that does something similar for XML documents. You serve up your data as XML, add a tag that points to an XSLT document, and the browser will use the transform on your document automatically. If the resulting output is renderable XHTML, it'll display it like a regular webpage.
That being said, I wouldn't recommend doing that, since XSLT is a programming language whose syntax is XML itself. Apparently web standards folks in the early 2000s thought the future was XML all the way down.
- np_tedious 6y agoI had a college course that burned way too much time on XSLT. This was 2008 I think. Needless to say I haven't used it since
- gpnt 6y agoYeah, I thought about using XML/XSLT too, but I think JSON would be more aligned with today's tools. Also, the render could be written in React or Vue, and add all the functionalities of a modern web app, for example, not just HTML.
- habitue 6y agoDefinitely your tooling is better incarnation of the idea, XSLT is kind of an abomination
- gpnt 6y agoYeah, I don't have very fond memories about it.
- crdrost 6y agoI love XSLT in theory. It had the daring to say that the most frequently programmed thing that we do is just translate data structures of one shape into data structures of a slightly different shape, and it said “That is what I shall focus on, doing just that.” And the way that it produced that, by “just start writing your output document and insert XSLT when you finally need to loop or query the input” seemed quite nice too, a sort of PHP dialect which didn't have to “escape” out of the document type and resort to echoing raw text. There is a pure functional programming language waiting to be resurrected from the ashes of XSLT, following Haskell's original idea that a program is a pure function from a stream of inputs to a stream of commands. I just hope that someone removes the XML from it, to save on the pain of my pinkies mashing those greater-than and less-than signs. I like the abstract idea that XML is recursively embeddable, and even the radical suggestion that maybe XSLT should be involved in metaprogramming its own syntax trees, but I am not sure that this is worth it. Maybe if we blur the lines between our code editor and a generic UI, someday?
- fiddlerwoaroof 6y agoJust setup a bijection between XML and s-expressions and XSLT becomes a Lisp.
- jerf 6y agoThe basic problem with XSLT is that it is strictly inferior to equipping any general-purpose programming language with an XPath implementation and just going to town. Let alone giving that programming language an even half-thought-out library designed to help with such a task. Even Go, which is really not amenable to any sort of in-language DSL or syntactic sugar, is nicer to use than XSLT itself. XSLT locks you in a trunk without enough tools to do what you need. I remember using a variant of XSLT Microsoft put out back in the day that let you embed Javascript into it... but then I noticed, why not just do it in Javascript? So I did. And it was soooo much better. There are good ideas in XSLT, but they are so buried in a cascade of bad decisions and limitations and restictions and missing functionality and bizarre ways of doing things (and I mean, I speak Haskell, pure FP doesn't scare me, and they're still bizarre) that the best remedy is just to start over.
- oever 6y ago
- int_19h 6y agoIt depends on which tools you're thinking about. When it comes to web browsers, they can process XML+XSLT (to produce and render HTML output) out of the box. On the other hand, it looks like the hack you're using here to make the JS renderer auto-load is not really valid HTML (as a whole)?
- karlshea 6y agoI think Blizzard used to do this way back on their website.
- ChrisMarshallNY 6y agoThere was a Web-based 3D community/game system that used browser-based XSLT. An employee of mine worked with it a lot. I think it was called "Where," or "There," or something.
- soneil 6y agoWay back when, the WoW armory (web-based character, guild, etc lookup) used to use this. It was incredibly useful for third-party integration - who needs scraping when they serve you the data on a silver platter.
- mark_and_sweep 6y agoXSLT is the only way to do HTML templating on the client without using JS. I think that is valuable.
- mark_and_sweep 6y agoHTML templating with XSLT may be used to save data, too. For example, if you build a social network profile page using XSLT, alice.xml and bob.xml can reference the same profile.xsl stylesheet which converts the XML profile data to the rendered HTML page. Since the profile.xsl stylesheet can be cached, whenever a new profile is visited, only the profile data in XML needs to be transferred. Note that the templating can also be used to save data when rendering a single page. Imagine a Twitter clone that displays a list of tweets. If, hypothetically, 80 characters of Tweet data plus 500 characters of XSL template, produce 250 characters of HTML markup, you only need 3 tweets to start saving data (250x3=750 > 500+3x80=740).
- vincnetas 6y agoXML+XSTL twitter clone in showHN in 3... 2... 1...
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- arpa 6y agoXML+XSLT is vastly, vastly underrated.
- ChrisMarshallNY 6y agoI still have nightmares from learning XSLT. It's very cool, but also, very strange, if you come from a procedural language background. Also, XSLT is really given power by being mixed with XPath (which is procedural). I suspect that if I had known more about FP back when I learned it, I would have had an easier time. I wrote up a really long, painful post about XSLT, way back in the early 'oughts.
- peteretep 6y agoI learned XSLT twice. The first in the very early 2000s when I was creating a large and mostly static website for a magazine with a lot of content, and mostly just hacked it together. It was ok but mostly I was using it as a simple templating language. The second time was about five years ago, as a module in my MSc, by which time I was well-versed in functional programming — this time it was easy to do all sorts of weird and wonderful stuff, including a TAP-outputting assertion library for templates written in XSLT itself and a library for doing depth-first searches over graphs of nodes.
- ebruchez 6y ago> XPath (which is procedural) XPath is not procedural. It is entirely composed of expressions that compose and return results. The closest common language might be SQL.
- ChrisMarshallNY 6y agoFair ‘nuff. I consider it “more proceduralish” than XSLT. It’s really more like an FP language.
- Kimitri 6y agoXSLT is mainly used to transform XML into XML. The resulting document doesn’t have to be XML, though. I remember being assigned a task of parsing and importing a large XML document into a MySQL database. This was supposed to be done on PHP. I kind of felt repulsed by the idea of writing the parser in PHP (it would have been horrible). So, I used XSLT to transform the document into CSV and then just imported it using LOAD DATA. Worked like a charm.
- iamthepieman 6y agoWorking for a government agency that had bought into MarkLogic in 2004, we built an entire analytical site that used XML from the document server, queried via XPath, and rendered it into web pages via XSLT. The web page was defined entirely in the XSLT transform. Worked great and if you were already righting your data queries in XPath, writing the UI in XSLT kinda made sense.
- jdeisenberg 6y agoThere is JSONT (https://goessner.net/articles/jsont/ https://goessner.net/articles/jsont/) and JSONPATH (https://goessner.net/articles/JsonPath/); https://goessner.net/articles/JsonPath/); also JUST (https://www.codeproject.com/Articles/1187172/JUST-JSON-Under-Simple-Transformation https://www.codeproject.com/Articles/1187172/JUST-JSON-Under...)
- ardy42 6y ago> Wellll.. I mean the json has markdown syntax in it. That's a lot nicer than html tags for markup, but it's still markup. Isn't markdown literally just HTML shortcuts for a limited set of common markup cases? IIRC, it's not uncommon to have to insert HTML tagging into markdown to get certain things to work.
- habitue 6y agoMarkdown compiles to html, and if I had to guess, it's probably a superset of html? (Maybe, possibly not all html is valid markdown, I haven't checked) Assuming it's a superset though, the part I was talking about above was the (markdown - html) part, where markdown adds less noisy syntax for bolding, headings, lists etc.
- zelly 6y ago> Apparently web standards folks in the early 2000s thought the future was XML all the way down. It should have been, but just like the masses rejected LISP for its parens, the masses rejected XML for the closing tag. We could have avoided PHP and the zoo of MVC frameworks.
- arpa 6y agoWe could have avoided the bedlam of javascript hacks if browsers had supported XSLT2.
- rabidrat 6y agoI tried programming in XSLT and it was not fun. I'm sure if it took off we'd have the equivalent of Clojure that compiled down to it, but by itself it is not a hacker's language, if you know what I mean.
- mst 6y agoSXML and SXSLT did that in scheme and were really rather good fun.
- recursive 6y agoIf only XML wasn't so damn complicated, it might have had a chance. People love to point at close tags, but there's a long list of more serious problems. External entities, namespaces within namespaces, CDATA, namespaces that confusingly look exactly like URLs, but aren't, parser vulnerabilities.
- int_19h 6y agoThe way XML does namespaces is one of the best things about it - you can host any XML dialect within another, with no name clashes, and without losing the schema identity of embedded parts. Infinite data composability, subject only to the constraints placed by schema authors. And namespaces are URIs, so they can be URLs. The bad smell was mostly coming from all the things inherited from SGML - CDATA, entities etc. Although I would also add that separation into elements and attributes is not a particularly convenient way to model many things; it mixes up differences that should really be orthogonal (ordered/unordered, atomic/composite etc).
- toyg 6y ago> browsers have a thing called XSLT built into them I don't think they actually do anymore, not all of them for sure. > web standards folks in the early 2000s thought the future was XML all the way down Yes. What fools, to think that machine-produced content transmitted from machine to machine and displayed throw other machines would be better handled and more accessible if formatted in machine-friendly ways that were still readable to humans... But it wasn't to be, not just because XSLT was somewhat botched (way too hard, way too many enterprise-looking warts...) and probably insecure, but because people are too lazy to produce readable markup (who wouldn't get tired of reading <prst><artdd><!CDATA[[ all day long...) and to make sure tags appear only where they should and get closed properly. Add the inevitable touch-of-death of enterprise vendors ("let's use xml in such a way you'll only be able to deal with it with our tools!"), and the game was up.