5 ms·

It's absolutely possible, dare I say easy, to do old school SSR wrong. You start with an honest to god html file. Your IDE lints it. You are happy, life is eas

It's absolutely possible, dare I say easy, to do old school SSR wrong. You start with an honest to god html file. Your IDE lints it. You are happy, life is easy. Then you need a second page. So you copy some things over. Then you need a third page, and it becomes apparent that you need a way to share parts of your html pages across multiple files, in a generic way. And kids, that's the story of how I met your templating system. ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. It's easy to get things wrong in that world, because nothing gets things right. There's kludges of course, things that generate html entirely programmatically from their own language, or some weird abstraction. These all suck too. You have to learn new languages, or weird shorthands, or at best new APIs. None of them truly took off either so the tooling is poor. You know what's a language that already has tons of tooling? JavaScript. You know what's a robust API for building HTML that you already know, that is already supported by virtually everything? The DOM. And you know what's a markup language you already know and can intuitively parse without having to learn new things? HTML. Well, guess what.

phist_mcgee 5y ago
To extend your point, I think the linked article suffers from a common trend in web dev editorialism, which is over-generalisation of problems, and reducing the domain into simple binary thinking. A lot of these arguments talk about the dangers of SPAs, but don't talk to the reason why first class interactivity/reactivity exists on the web. It's because for average users, they want to see feedback to their actions immediately. Articles like this talk to SPAs as if they are unnecessary or overused. I disagree, I think SPAs are mostly appropriate for most SaaS, social media, or business tooling. Sure, the poorly implemented version of an SPA is harder to debug than a poorly implemented template generated site, but that's like comparing the complexity of a car built in 2021 to a car built in 1980. And cars from 2021 sell better than cars from 1980. A lot of these articles strike me as opinion pieces decrying the direction of modern web development, and seem to point to the past as a more 'gilded age' of internet browsing. But this was back when users sat at a desk, and scrolled pages using a analog mouse, viewing it on a CRT monitor. Users today want to browse on their phones, want to share and upload, to take live videos, to see when their message was sent, delivered and read. We need SPAs and libraries like React just like we need cars that can do lane assist. It's because it's a feature users want, and on the whole, it is much easier to build using React and SPAs.
- hackerfromthefu 5y ago
  But in the wild, on end user machines, many times the SPAs perform worse/slower than SSR ¯\_(ツ)_/¯ And users don't actually want SPAs, users don't care how it's implemented. But users want performance and reliability, and want their pages to feel natural and work fully with all the features other sites have. Anecdotally SPAs often load slowly, break subtly standard web features, and often are slow to use. Not all SPAs, but a significant amount of them. As someone who's fluent with SSR and SPAs (react/vue), who consults in the enterprise space, I reach for SSR solutions, about 2/3+ of the time as the appropriate architecture. Of course ymmv but you need to be fluent with all the options to be in position to pick the best tool for the job!
webmaven 5y ago
> And kids, that's the story of how I met your templating system. > ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. That's not really true. But fairly incredibly, it seems relatively little attention has been given to the design of HTML templating languages (certainly there are a lot of them, but most seem to have accreted rather than been designed). Anyway, the least weird templating language that was designed that I am aware of is the TAL[0] syntax, which has as it's main constraint that unrendered templates must still be valid HTML. The original motivation for this was to eliminate the terrible workflow problems of round-tripping templates between a web designer and a (backend) developer, but there turned out to be other benefits, like taking care of linting difficulties. It is also rather deliberately not Turing-complete, as that has proved an 'attractive nuisance' that causes more problems than it solves. The TAL syntax is most strongly associated with Python frameworks (I would guess that Chameleon[1] is the most popular implementation), but there are implementations for most prominent languages[2]. > You know what's a robust API for building HTML that you already know, that is already supported by virtually everything? The DOM. How popular is SSR in JS using the DOM directly, rather than a template language of some sort (eg. Handlebars, Jade, Nunjucks)? [0] https://en.m.wikipedia.org/wiki/Template_Attribute_Language https://en.m.wikipedia.org/wiki/Template_Attribute_Language [1] https://chameleon.readthedocs.io/en/latest/index.html https://chameleon.readthedocs.io/en/latest/index.html [2] implementations (sometimes several) exist for JS, Java, C#, Perl, Raku, PHP, Python, XSL, Go, and Common Lisp.
- 8n4vidtmkvmk 5y ago
  TAL looks nasty. If you want conditionals in your HTML, just use conditionals. Don't hamfist it into the HTML syntax. Twig or Pug/Jade are the best ones I've seen. C#'s Razor seemed pretty good too in the brief time I used it.
  - webmaven 5y ago
    If you have some other way of being able to view an unrendered template in a browser and have it display sanely, I'd be very interested to know about it.
- 5y ago
m1el 5y ago
> ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. Hard disagree. Lisp family of languages have tree templates that are easy to lint, test and get right. They also scale as well as- or better than React. See: https://github.com/yokolet/hiccup-samples https://github.com/yokolet/hiccup-samples
- tusharpandey13 5y ago
  It again raises the issue that you need to learn a new language. Most web developers are not going to learn lisp when js is already available.
- phist_mcgee 5y ago
  Lisp has had 50 years to catch on, and unfortunately, it has not had the uptake a lot of its proponents would like. I think part of this is the different mental model you need to build around programming when you use these family of languages.

phist_mcgee 5y ago

To extend your point, I think the linked article suffers from a common trend in web dev editorialism, which is over-generalisation of problems, and reducing the domain into simple binary thinking. A lot of these arguments talk about the dangers of SPAs, but don't talk to the reason why first class interactivity/reactivity exists on the web. It's because for average users, they want to see feedback to their actions immediately. Articles like this talk to SPAs as if they are unnecessary or overused. I disagree, I think SPAs are mostly appropriate for most SaaS, social media, or business tooling. Sure, the poorly implemented version of an SPA is harder to debug than a poorly implemented template generated site, but that's like comparing the complexity of a car built in 2021 to a car built in 1980. And cars from 2021 sell better than cars from 1980. A lot of these articles strike me as opinion pieces decrying the direction of modern web development, and seem to point to the past as a more 'gilded age' of internet browsing. But this was back when users sat at a desk, and scrolled pages using a analog mouse, viewing it on a CRT monitor. Users today want to browse on their phones, want to share and upload, to take live videos, to see when their message was sent, delivered and read. We need SPAs and libraries like React just like we need cars that can do lane assist. It's because it's a feature users want, and on the whole, it is much easier to build using React and SPAs.

hackerfromthefu 5y ago
But in the wild, on end user machines, many times the SPAs perform worse/slower than SSR ¯\_(ツ)_/¯ And users don't actually want SPAs, users don't care how it's implemented. But users want performance and reliability, and want their pages to feel natural and work fully with all the features other sites have. Anecdotally SPAs often load slowly, break subtly standard web features, and often are slow to use. Not all SPAs, but a significant amount of them. As someone who's fluent with SSR and SPAs (react/vue), who consults in the enterprise space, I reach for SSR solutions, about 2/3+ of the time as the appropriate architecture. Of course ymmv but you need to be fluent with all the options to be in position to pick the best tool for the job!

webmaven 5y ago

> And kids, that's the story of how I met your templating system. > ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. That's not really true. But fairly incredibly, it seems relatively little attention has been given to the design of HTML templating languages (certainly there are a lot of them, but most seem to have accreted rather than been designed). Anyway, the least weird templating language that was designed that I am aware of is the TAL[0] syntax, which has as it's main constraint that unrendered templates must still be valid HTML. The original motivation for this was to eliminate the terrible workflow problems of round-tripping templates between a web designer and a (backend) developer, but there turned out to be other benefits, like taking care of linting difficulties. It is also rather deliberately not Turing-complete, as that has proved an 'attractive nuisance' that causes more problems than it solves. The TAL syntax is most strongly associated with Python frameworks (I would guess that Chameleon[1] is the most popular implementation), but there are implementations for most prominent languages[2]. > You know what's a robust API for building HTML that you already know, that is already supported by virtually everything? The DOM. How popular is SSR in JS using the DOM directly, rather than a template language of some sort (eg. Handlebars, Jade, Nunjucks)? [0] https://en.m.wikipedia.org/wiki/Template_Attribute_Language https://en.m.wikipedia.org/wiki/Template_Attribute_Language [1] https://chameleon.readthedocs.io/en/latest/index.html https://chameleon.readthedocs.io/en/latest/index.html [2] implementations (sometimes several) exist for JS, Java, C#, Perl, Raku, PHP, Python, XSL, Go, and Common Lisp.

8n4vidtmkvmk 5y ago
TAL looks nasty. If you want conditionals in your HTML, just use conditionals. Don't hamfist it into the HTML syntax. Twig or Pug/Jade are the best ones I've seen. C#'s Razor seemed pretty good too in the brief time I used it.
- webmaven 5y ago
  If you have some other way of being able to view an unrendered template in a browser and have it display sanely, I'd be very interested to know about it.
5y ago

m1el 5y ago

> ALL of them suck. ALL of them are incredibly hard to lint, test, get right. They scale badly. They're all awful. Hard disagree. Lisp family of languages have tree templates that are easy to lint, test and get right. They also scale as well as- or better than React. See: https://github.com/yokolet/hiccup-samples https://github.com/yokolet/hiccup-samples

tusharpandey13 5y ago
It again raises the issue that you need to learn a new language. Most web developers are not going to learn lisp when js is already available.
phist_mcgee 5y ago
Lisp has had 50 years to catch on, and unfortunately, it has not had the uptake a lot of its proponents would like. I think part of this is the different mental model you need to build around programming when you use these family of languages.