Comment by scrollaway | Hacker News Reader

Comment by scrollaway | Hacker News Reader

Parent Full thread

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.

> 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

[1] 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.

Thymeleaf templates are also valid HTML when not rendered. Of course you still have to put some thought into them to make them believable, by e.g. providing placeholders for elements that would be rendered in cycles.

Yeah, I find Thymeleaf to be nice, especially when coupled with Spring. I'm always happy when we decide to use it instead of bloating everything up with a separate Angular application.

I'm not a Java developer, so I wasn't aware of Thymeleaf.

How does it compare to the Java implementations of TAL?

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.

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.

> 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

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.

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.

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.

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!

Reply on news.ycombinator.com