7 ms·

Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost ce

• wahern 1y ago
  > Also hard not to feel like this is reaching hard to try and recreate xslt. I was never a fan of XML, but XSLT was (is!) a killer redeeming feature of the ecosystem. And it's still widely supported in browsers! It was such a shame that XML caught on where it sucked--configuration, IPC, etc--but languished where it shined, as a markup language with an amazing transformation capability in XSLT. I think where XSLT fell over was that it's a real DSL, and a declarative, pure, functional DSL at that. People like to talk a big game about DSLs, but inevitably they're simplistic syntactic exercises that don't actually abstract the underlying procedural semantics of popular host languages. When faced with a well-designed DSL that makes difficult tasks trivial... people can't be bothered to learn.
  • marcosdumay 1y ago
    XSLT is just not a good language. Every single attempt of making XML executables (and there were many) failed badly, always for this one good reason.
  • wpm 1y ago
    I regularly work with APIs in shell that return XML and XSLT is a goddamn super power. I adore it.
  • eclipticplane 1y ago
    It's been a long number of years, but XUL (Mozilla/Firefox's UI layer) combined with XSLT was an incredible stack to build entire applications.
  • notpushkin 1y ago
    I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day. I also have a simple playground for XSLT: https://xsltbin.ale.sh/ https://xsltbin.ale.sh/
    • nine_k 1y ago
      XSLT's weaknesses are the extension of its strengths. It's the first homoiconic, purely functional language that enjoyed widespread adoption among "normal" developers, not type theory wonks. But XML's syntax sucks, and so inevitably does XSLT's, because XSLT is just XML. Were it s-expressions, the syntax could suck slightly less. It was (is!) a small price to generate XSLT using XSLT, which makes XSLT very powerful and expressive if you hold it right, almost like a Lisp. This saved me a few times around year 2000 or so.
      • agumonkey 1y ago
        I barely used xslt, but as a fp head I wanted to try, the most confusing part to me were terminology / semantics / decoupling. Seemed like matching templates could be anywhere making difficult to understand the meaning of a script.
        • nine_k 1y ago
          It's sort of similar to regular pattern-matching, but sadly not built for ergonomics :(
          • agumonkey 1y ago
            The node pattern matching was ok, but as far as i can recall, there could be multiple matching patterns scattered in lots of places (a 180deg turn compared to most FP pattern matching that aim for exhaustiveness ?)
            • HelloNurse 1y ago
  • geocar 1y ago
    > but languished where it shined, as a markup language with an amazing transformation capability in XSLT I choose to look at this a little differently. An XML application using XSLT is so much better (faster load times, faster to write, easier to make correct) than a JavaScript application with a JSON api, that XML is basically a secret weapon. I only care enough that it stays in browsers, but otherwise I'd prefer nobody know about it because it means less competition on things that matter (faster load times, faster to write, fewer bugs, etc). And I've got a half-baked JavaScript-based "renderer" I can finish in case some Google VP asshat goes looking for things to delete...
  • echelon 1y ago
    XSLT was cool. XML needs another syntax that isn't so verbose. Sort of like how OWL has XML, Manchester, Functional, and Turtle syntaxes for the same data structures. XSLT needs a Turtle-style syntax. XML in general (the data structure, not the syntax) needs a Turtle-style syntax.
  • Mikhail_Edoshin 1y ago
    XSLT is not bad, but XML, unfortunately, is normally misused, so XSLT is tainted as it has to be a part of that misuse. The true role of XML are grammar-based notations. These occur in two places: when a human gives data to a machine and when a machine produces data for a human. This is where XML is used despite its often mentioned shortcomings; for example, many notations to describe the user interface are based on XML. This is convenient, because user interfaces are created manually. (I am not mentioning text markup, it is well known.) Yet XML was often used as a notation for machine-to-machine exchange. For example, the ONIX book description standard. Here data are moved between two computers, yet for some reason they have to form grammatically correct phrases according to a set of grammar rules. Computers do not need grammar. They do just fine with non-grammatical data, like a set of tables. It is way simpler for them; parsing or generating grammar, even explicit, is pure overhead for data exchange and is only necessary when data enters or leaves the computed pipeline. So, to your examples: configuration in XML is actually fine, but IPC is not. Configuration is written by hand, IPC happens between machines. IPC specification, on the other hand, is also a good fit for XML. That said, XML and thus XSLT has another flaw: it is way too verbose and has no good way to format it. Conciseness was an explicit no-goal but now we can say it was a mistake.
    • connicpu 1y ago
      The XML abuse I've seen at work is truly horrifying. We use protobuf for most of our inter-service IPC, but for one particular team one of their customers demands the use of XML so that it can be run through some XSLT "security" filters, so they have to transform a fairly large protobuf object into XML, run it through said filters, and then convert it back to protobuf :( I weep every time I think about it.
      • taeric 1y ago
        It is probably impossible to find a tech stack that has not seen horrible abuse somewhere. :D Granted, it did seem that XML got more heavily abused than some other options for a while. I am curious if that is just a by product of when it was introduced. That or just the general proliferation of how many front end developers we have. (I hate that I am pushing that to almost be a complaint. I certainly don't mean it that way.)
  • froh 1y ago
    here on HN I dare to out myself as a DSSSL lover, the scheme based predecessor of xslt. I still can't wrap my head around how the neat and clean dsssl syntax, a real programming language, was replaced by an xml notation for the same: for cuntional code and a framework. because semantically, that's what xslt is: a functional language with a framework, geared at transforming xml instances. but that syntax... and of course a much inferior and more obscure language than scheme underneath dsssl.
    • striking 1y ago
      Why not implement a DSSSL-to-XSLT compiler?
  • PaulHoule 1y ago
    The thing most people never got about XSLT is that it is really about production rules -- and production rules (e.g. the major path to "expert systems") are one of the most solidly rejected technologies in software engineering. I didn't understand this until I spent a few years going down a rabbit hole asking questions like "why don't people like production rules?" In the case of templating people expect to make a template with a top-down organization that looks like the output, whereas XSLT really wants you build transformations from the bottom-up. On some level the bottom-up part is clear, particularly if you want to code-generate your rules (towards the end I was writing production rules that write production rules) but what is not clear is how the parts all fit together: you can't visually tell between an XSLT that builds the structure you want vs one that doesn't. I think the most fun I ever had with XSLT was when I used an XSLT engine with user-defined procedures and had them create side effects, such as matching certain patterns in an XML document and making SQL inserts, though that was a long time ago when we were still using terrible XML parsing libraries.
  • stuaxo 1y ago
    Its annoying that support stopped at earlier versions, it grew so much more later.
• austin-cheney 1y ago
  > Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. The article fails to accept that performance and security aren’t addressed by vanity layers. This is a mistake repeated by web technologies when popular demand eventually crushes common sense, because hiring is more important than training/maintenance when the lowest levels of the work force can’t tell the difference and drives all design decisions. If you want better performance or security you have to measure things, not wear a pretty dress and look the other way.
• dominicrose 1y ago
  We don't know what good syntax for templating looks like because HTML is complex enough and many have tried making it more complex with things like Blade for PHP or HTMX for example. For some reason I've always preferred JS to HTML. React components with JSX is a good balance. Not everyone agrees but that's OK.
• moritzwarhier 1y ago
  > Hard not to laugh out loud at "We know what good syntax for templating looks like." We don't. Not even close. Because I'd hazard a good template is almost certainly more of a visual thing than it is a symbolic one. How do you come to this conclusion? It seems to me that what you mean is a general gripe with HTML+CSS, not with how it's generated. And why do you bring up absolute positioning? I hear this take on HN again and again and sure, absolute positioning has its place, and is needed for many things. But when it's used for page/app layout, most of the time I came across this it was an absolute nightmare, falling apart at the slightest content (even text!) or screen size changes. Even print newspaper layout can't work like this, because typography is involved, although it's probably a lot closer to what I imagine you are describing. Maybe I'm misunderstanding you. But when I was doing more CSS-intensive work (I still do a fair bit), developing something on a basis when someone created a layout based on absolute positioning that looked like it was "almost ready", it was a terrible time sink to try to fix it and recreating it using flex, flow et al for layout (I'm not that fond of grid outside of some scenarios, and at the time I didn't use it due to browser support) was always faster because the problems with absolute positioning as the main layout tool were basically unfixable. Maybe there are techniques using calc() and viewport units where it makes sense, but absolute positioning is not suitable for any layout outside of completely static content and viewport dimensions, in my experience.
  • taeric 1y ago
    I've been in the opposite, where people will go through lengths to try and make it so that the defaultish dom layout makes things "fall into place" so that they had a very specific layout of elements. When a fairly simple set of elements with somewhat minimal styling would get what you wanted surprisingly easy. Provided you did a lot of up front calculation on your own. Basically, my assertion used to be to draw out what you have in mind on grid paper. Then start creating the elements. I don't see how that flow could land you with the 100ish divs that you wind up with on something like a single blue sky post. Is it a panacea? No. Of course not. Can a constraint language help? I think so. I'll add that the flex layouts seem like an improvement over what used to be there. Even if I find it rather amusing that we seem to have settled back on tables for layout. :D (I suppose it is more like some of the layout managers from Java days, truthfully.) But, fundamentally, the problem appears to be that the drop to symbolic text is just not something that everyone does the same way. As such, it is very easy to get into a lot of trouble with the number of cooks in the kitchen, as it were.
• chii 1y ago
  > People will go through obscene lengths to recreate what judicious use of absolute positioning can achieve fairly well the web has the requirement that the 'document' look good no matter what device size/dimension, orientation, and/or capability. In regular apps (say, a windows app), you don't have this requirement. In mobile apps, there's a standardized set of sizes. Only on web do we have both!
  • taeric 1y ago
    Not really? People impose the idea that they can make this work. Yet no sites looked good on the Nintendo DS browser, and people were largely ok with that. Few sites look genuinely good on phones. People are largely ok with that.
    • DangitBobby 1y ago
      The Nintendo DS browser was not good enough to use as a daily driver. My phone, on the other hand, I spend more time browsing on that than I do my computer. Some sites aren't great on it, but the vast majority are fine (reader mode will get you through 99% of the rest). I'd argue most sites don't "look good" on any device. It's really not that hard these days to make a site work on mobile, the navbar often is the most challenging part of it.
• jdkoeck 1y ago
  > Hard not to laugh out loud at "We know what good syntax for templating looks like." First of all, it's not very nice to laugh in the face of someone advocating for progress on the web platform, which benefits everyone. Second of all, yes we do now know what good syntax for templating is, it's basically jsx (and I'm saying this as someone who's really not a fan of React). It took the whole web by storm, it's been adapted for all kinds of frameworks, and it's undeniable that all js templating systems converged towards common attributes: templates-as-expressions, composition via nesting and control flow with just javascript (instead of specific template syntax).
  • taeric 1y ago
    I'm laughing because it just hits so hard. Started playing some role playing with friends again recently and we were looking for a template for the character sheets. You know what they have? A PDF. That is their template. Why? Because they design things that way. And it is funny, because I can already feel the ideas that would go into templating this symbolically. Characters have 6 and 20 numeric attributes. But, I can already guess most would consider it a fault to manually place either of those on the page. Yes, the sheet has a limitation on how big your name can be. No, you can't really avoid that. JSX is what happens when you no longer have a design and a dev team. It is great at that, even. But if you have a workflow where a designer makes a template and sends it over to a dev, it no longer really helps. You are much better off making something that can pick at artifacts that are handed off. Instead, we seem to be aiming for an idea that will have to replace learning of everyone involved.
    • rschristian 1y ago
      I don't think you understand what "template" means here, this has absolutely nothing to do with design or end result on the page. At no point would a designer be involved with templating the DOM. It's in contrast to the imperative `document.createElement(...)` & `parent.appendChild(...)` APIs which you otherwise use in vanilla JS.
      • taeric 1y ago
• 9rx 1y ago
  We do know what is good. We may not know what is perfect, but perfect need not be the enemy of good.
  • taeric 1y ago
    What is good, then? Because I'm really not seeing it. Just peek at substack and bluesky to see how the templating ideas in web dev have turned out. (I'm assuming they are decent modern examples. If not, I'm game to see one.)
    • 9rx 1y ago
      That which improves upon previous solutions. I have no idea what substack and bluesky are, but I'll take that to suggest that someone used templating to create a mess. While that is no doubt true — someone can create a mess out of anything — would the same person have avoided the mess if the templating wasn't there? It is just ergonomics, after all, not some fundamentally different idea.
      • taeric 1y ago
        substack and bluesky are just newer sites. I don't even think they are bad. Just I question the volume of markup that they use to layout stuff. Knowing that that is the standard. Do you have examples that are good?
        • 9rx 1y ago
          At the time, this was good: printf("%d", 10); It might not hold up to today's standards, but "good" isn't a constant.
          • taeric 1y ago
            So, no? You don't have any examples by which to demonstrate what a good templating language is? You seem to have gone on a tangent that "good" is a general topic in my question. I meant do we have specifically good examples of templates. Surely if we know what good templating syntax is, we can share examples of it? Even if you can't describe it directly.
• deleted 1y ago
  [deleted]
• tshaddox 1y ago
  I'd also argue that there are only superficial similarities between, say, React and Svelte. Yes, they both have a syntax based heavily on HTML, but they work very differently. React is the only major framework that works by having (mostly) normal JavaScript functions return lazy representations of markup (in the form of JSX). React has no template-level notion of looping or conditional rendering, because you use normal JavaScript for that.