4 ms·

I think a big reason that old-school server-side rendering (i.e., templates) isn't popular anymore is that templating languages are horrible and stuck in 2005.

by notJim 3y ago

I think a big reason that old-school server-side rendering (i.e., templates) isn't popular anymore is that templating languages are horrible and stuck in 2005. An underrated pro of react [1] + typescript is that you get to write your UI logic in regular typescript, and you get real function signatures for all your UI components. This makes it way easier to write reusable components, because you can specify the arguments, and write regular unit tests against them, etc. With most templating languages, there is no defined function signature (with arguments and types specified), so you get to read through the template to figure out what data to pass in. This makes it very hard to make things reusable. And similarly, templating languages are often some bizarre, janky custom language with pipes and stuff. At a previous employer, we actually solved this problem. We implemented a pattern that gave us real typed interfaces for UI components rendered with templates on the server. We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did, although not in the browser. I recently started a side-project in javascript for the first time in years, and was surprised to discover that there is apparently no modern open-source library for rendering server side components, other than rendering react on the server of course. Your options are basically react or using some shitty templating language. I went with react. 1: When I say react, please understand it to mean any of the nice modern frontend libraries, like react, vue (is this still a thing?), svelte, etc.

simonw 3y ago
I find the popularity of JSX-style templating really surprising. <div> <h1>Conditional Display and Looping in JSX</h1> <ul> {this.state.items.map(item => ( item.show ? <li key={item.id}>{item.name}</li> : null ))} </ul> </div> That seems like such an unintuitive way of implementing loops and if statements! I helped design the Django template language, where the above would look like this instead: <div> <h1>Conditional Display and Looping in Django Template</h1> <ul> {% for item in items %} {% if item.show %} <li>{{ item.name }}</li> {% endif %} {% endfor %} </ul> </div> I do like the type signature aspect of it that you're talking about - I've found myself wanting that for Django templates in the past, to the point that I've started figuring out patterns for populating templates using typed Python dataclasses as opposed to anything-goes-dictionaries.
- c-hendricks 3y ago
  Unintuitive? It's just JavaScript, probably indistinguishable from any language that has ternary statements and .map methods.
  - simonw 3y ago
    Yeah, it's unintuitive. I'm not sure how to back that up... just look at it! Weirdest way I've ever seen to implement an if statement in a template.
    - jwells89 3y ago
      What makes it weird for me is the filter/map/etc with an implicit destination, since function chains like that usually get rolled into a variable. It'd get you a compiler warning in Swift or Kotlin ("Result of call to 'map' is unused", etc). Agree that a for loop reads better in this case.
      - jakelazaroff 3y ago
        I suppose that depends on whether you look at it as a templating DSL within a JavaScript expression, or expressions within a templating language. A `for` loop doesn't really make sense from the JS expression viewpoint — `for` loops in JS are statements, and in languages that do treat them as expressions they usually evaluate to the last iteration of the loop. From there, the filter/map makes more sense, since it's an expression that evaluates to an array of template-y stuff. If you see it primarily as a templating langauge, though, the `for` loop makes way more sense — every iteration, it's adding a string to the template.
    - zogrodea 3y ago
      I agree that React's (and maybe other frameworks? I don't know them) conditional rendering syntax is very odd. Like {my_bool && <Component />} instead of (if my_bool then <Component /> else null). Or {my_bool || <Component />} (which is harder to express in most other languages because of Javascript considering truthy/falsy values instead of boolean true/false). I am a fan of the UI-as-code approaches (as opposed to UI-as-markup or server-templating approaches) that React has though because of the other arguments you see in this thread, although the syntax could be better for React specifically. Elm is honestly pretty great in my opinion, and Flutter also has a nice language for describing UI as code. React just has less-than-optimal syntax. I don't have a problem with map, though, except that I would like to extract the mapping function out of the "main view" into its own parameterised function that takes a list of whatever it needs.
lmm 3y ago
I've still found nothing that can match up to what Wicket was doing 10+ years ago. Your are self-contained, and know how to render their own markup. Any "templates" live with the components and are tightly coupled to them. Control flow lives in code and code alone; your markup specifies ids where your code can attach components, but there's no way for your markup to call back into your code, so you avoid spaghetti. It's wonderful.
dpe82 3y ago
I've run into this same issue when developing a DSL for generating language bindings and doing data serialization. Not having compile-time type safety is such a pain. So I'm extending the language to feature statically typed string templates as well. It currently targets (generates) C++, but I'll add other language targets in the future. It's still a work in progress but I just flipped the repository public in case you want to follow along as I work: https://github.com/dpemmons/typedef https://github.com/dpemmons/typedef
yawaramin 3y ago
> templating languages are horrible and stuck in 2005. An underrated pro of react [1] + typescript is that you get to write your UI logic in regular typescript, Yeah exactly, which is why I always recommend DSLs that embed HTML directly in the language. E.g. https://com-lihaoyi.github.io/scalatags/ https://com-lihaoyi.github.io/scalatags/ or (my own) https://github.com/yawaramin/dream-html https://github.com/yawaramin/dream-html They make writing HTML a breeze with the full power of the programming language available. > We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did Dan Abramov is not the original creator of React. That was Jordan Walke: https://www.youtube.com/watch?v=GW0rj4sNH2w https://www.youtube.com/watch?v=GW0rj4sNH2w

by notJim 3y ago

simonw 3y ago

I find the popularity of JSX-style templating really surprising. <div> <h1>Conditional Display and Looping in JSX</h1> <ul> {this.state.items.map(item => ( item.show ? <li key={item.id}>{item.name}</li> : null ))} </ul> </div> That seems like such an unintuitive way of implementing loops and if statements! I helped design the Django template language, where the above would look like this instead: <div> <h1>Conditional Display and Looping in Django Template</h1> <ul> {% for item in items %} {% if item.show %} <li>{{ item.name }}</li> {% endif %} {% endfor %} </ul> </div> I do like the type signature aspect of it that you're talking about - I've found myself wanting that for Django templates in the past, to the point that I've started figuring out patterns for populating templates using typed Python dataclasses as opposed to anything-goes-dictionaries.

c-hendricks 3y ago
Unintuitive? It's just JavaScript, probably indistinguishable from any language that has ternary statements and .map methods.
- simonw 3y ago
  Yeah, it's unintuitive. I'm not sure how to back that up... just look at it! Weirdest way I've ever seen to implement an if statement in a template.
  - jwells89 3y ago
    What makes it weird for me is the filter/map/etc with an implicit destination, since function chains like that usually get rolled into a variable. It'd get you a compiler warning in Swift or Kotlin ("Result of call to 'map' is unused", etc). Agree that a for loop reads better in this case.
    - jakelazaroff 3y ago
      I suppose that depends on whether you look at it as a templating DSL within a JavaScript expression, or expressions within a templating language. A `for` loop doesn't really make sense from the JS expression viewpoint — `for` loops in JS are statements, and in languages that do treat them as expressions they usually evaluate to the last iteration of the loop. From there, the filter/map makes more sense, since it's an expression that evaluates to an array of template-y stuff. If you see it primarily as a templating langauge, though, the `for` loop makes way more sense — every iteration, it's adding a string to the template.
  - zogrodea 3y ago
    I agree that React's (and maybe other frameworks? I don't know them) conditional rendering syntax is very odd. Like {my_bool && <Component />} instead of (if my_bool then <Component /> else null). Or {my_bool || <Component />} (which is harder to express in most other languages because of Javascript considering truthy/falsy values instead of boolean true/false). I am a fan of the UI-as-code approaches (as opposed to UI-as-markup or server-templating approaches) that React has though because of the other arguments you see in this thread, although the syntax could be better for React specifically. Elm is honestly pretty great in my opinion, and Flutter also has a nice language for describing UI as code. React just has less-than-optimal syntax. I don't have a problem with map, though, except that I would like to extract the mapping function out of the "main view" into its own parameterised function that takes a list of whatever it needs.

lmm 3y ago

I've still found nothing that can match up to what Wicket was doing 10+ years ago. Your are self-contained, and know how to render their own markup. Any "templates" live with the components and are tightly coupled to them. Control flow lives in code and code alone; your markup specifies ids where your code can attach components, but there's no way for your markup to call back into your code, so you avoid spaghetti. It's wonderful.

dpe82 3y ago

I've run into this same issue when developing a DSL for generating language bindings and doing data serialization. Not having compile-time type safety is such a pain. So I'm extending the language to feature statically typed string templates as well. It currently targets (generates) C++, but I'll add other language targets in the future. It's still a work in progress but I just flipped the repository public in case you want to follow along as I work: https://github.com/dpemmons/typedef https://github.com/dpemmons/typedef

yawaramin 3y ago

> templating languages are horrible and stuck in 2005. An underrated pro of react [1] + typescript is that you get to write your UI logic in regular typescript, Yeah exactly, which is why I always recommend DSLs that embed HTML directly in the language. E.g. https://com-lihaoyi.github.io/scalatags/ https://com-lihaoyi.github.io/scalatags/ or (my own) https://github.com/yawaramin/dream-html https://github.com/yawaramin/dream-html They make writing HTML a breeze with the full power of the programming language available. > We were doing this the same year that React came out, and clearly had some of the same thoughts as Dan Abramov did Dan Abramov is not the original creator of React. That was Jordan Walke: https://www.youtube.com/watch?v=GW0rj4sNH2w https://www.youtube.com/watch?v=GW0rj4sNH2w