[ian1321]

The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no small task.

Compare this to server-side rendering where you run some DB queries, generate some HTML based on those results, and send it to the browser to be rendered.

There are some cases where you actually need a rich experience in the browser. In those cases, I would start by seeing if plain old Javascript would work.

In writing this, I definitely feel like a "get off my lawn" guy. But I've just seen too many junior and senior engineers (me included) fall flat on their face trying to use these SPA frameworks.

[scrollaway]

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.

[webmaven]

> 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.

[noisem4ker]

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.

[webmaven]

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

How does it compare to the Java implementations of TAL?

[8n4vidtmkvmk]

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]

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.

[m1el]

> 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

[phist_mcgee]

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.

[tusharpandey13]

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]

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]

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!

[8n4vidtmkvmk]

> Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible.

Whaaat. Async/await/promises is trivial. JS is still single-threaded so you don't have any of those annoying threading issues.

Where it gets a bit wonky is when you apply it to the UI because you have this extra state you need to worry about. After the user clicks something, but before you get the results back from your server. You have a loading or saving state to deal with. But React mostly makes that trivial too.

SPAs get hard because of all the reasons listed in that blog post. They're incredibly hard to optimize properly.

And for that reason, I don't disagree with your first sentence. If all you're doing is worrying about 1 page at a time and shipping some HTML, you're golden.

[tshaddox]

Perhaps you've been luckier than I have in your experience with Rails and Django codebases! I have seen a tremendous amount of "not doing it right" and "architecting things in such a way that it makes it nearly impossible to 'do it right' when adding or changing any behavior."

With any of the popular React server-side rendering frameworks, getting up and running with a basic web site with some pages and HTML content is not significantly harder (and in fact not that different at all) than doing the same in Django or Rails.

[RowanH]

I have to agree. I'm a OG Rails dev looking and constantly compare the productivity of old school SSR sites compared to current complex SPA frameworks. People how tie themselves in knots, the UI interactions are tricky to get right, more places to code, then second guess the frameworks, then try it again. SSR Rails apps just had 3, maybe 4 places to write code - controllers, models, view folders - you can flip back and forth in blinding pace, and get your app up and running really, really quickly. Yes agree there's some places SPA's are really applicable. But watching an app get built that you see no distinct advantage for either end user or dev team makes you wonder.