Live data from Hacker News

Server-side rendering is a better choice for many applications (2020)

timr.co

71–80 of 286 posts

Re: Server-side rendering is a better choice for many applications (2020)

#71
post #31

All this noise around "back to the roots" template rendering seems to ignore the elephant in the room that FE devs DON'T want to work with jinja2, django templates and all this jazz as it is perceived as a devaluation of the role + they need to learn specific syntaxes instead of having a "one size fits all" approach like with js frameworks.

As a frontend dev I can give you a few more reasons why I don't want to go back to writing templates as part of some backend framework:

JavaScript is eventually needed for any non-trivial app. JS without a build system/dependency management is a maintenance nightmare. JS without linting, TypeScript, module syntax and unit tests is a maintenance nightmare.

Reuse of components is much easier and more testable with framework abstractions (compare a react/vue/svelte component to e.g. a laravel blade component).

Strict separation of CSS, HTML and JS means things like class names drift. With a JS build system you can easily introduce tooling to combat this (auto-removal of unused styles, enforcing that all classes are used, linting for CSS code, etc).

I just can't imagine building an app of more than a few thousand lines without a framework and frontend build tooling. I would end up needing to reinvent these tools myself to ensure code quality as the project grows. I'm not saying it's impossible to add these features into, say, a Django or Rails app, just that it's more work for a worse outcome.

Re: Server-side rendering is a better choice for many applications (2020)

#73
post #31

All this noise around "back to the roots" template rendering seems to ignore the elephant in the room that FE devs DON'T want to work with jinja2, django templates and all this jazz as it is perceived as a devaluation of the role + they need to learn specific syntaxes instead of having a "one size fits all" approach like with js frameworks.

This is why I am bullish on React Server Components. With a framework that supports it I can choose where client- or server-rendering is most appropriate but keep organization and expressive benefits of React, TypeScript, and TSX.

Re: Server-side rendering is a better choice for many applications (2020)

#74
I saw the effect of silently forcing hard-core SSR on my team over the last few years. My trick was to not give anyone any say in the matter. I built a product vertical that demonstrates how it is possible to handle not just the happy path, but also the unhappy edge cases.

It is one thing to push an abstract policy/principle. It is another to hand someone a live, working implementation of a policy and request that they keep moving down the indicated path.

I don't think SSR is a Thiel Truth. I think leadership is. If you want to see more SSR in the world around you, you have to build more SSR experiences and teams around them.

Letting a room full of arbitrary developers sit around a conf call and come up with "the tech stack" is how you wind up in a hurricane of bullshit most of the time. At some point someone needs to ask the question "are we here to make money or have fun?" which should quickly highlight your ideal candidates for CTO/dictator.

Re: Server-side rendering is a better choice for many applications (2020)

#75

The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.

The same argument could be used for splitting backend to multiple services, or even micro services. Frontend/backend separation seems pretty arbitrary.

If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. With client-side rendering there's usually expectation of some monolith project using the single framework.

Re: Server-side rendering is a better choice for many applications (2020)

#76
post #31

All this noise around "back to the roots" template rendering seems to ignore the elephant in the room that FE devs DON'T want to work with jinja2, django templates and all this jazz as it is perceived as a devaluation of the role + they need to learn specific syntaxes instead of having a "one size fits all" approach like with js frameworks.

Right on.

Related, the junior FE devs want our web app to be a SPA because they think it’s the only idiomatic way to write reusable components (think a JSX-written React component). Often they’ve never used anything else (so like TFA mentioned, for them it’s not an open choice).

I hate that my job these days has to involve counteracting this notion, probably looking like some weird Luddite in the process, for simply highlighting the same points from TFA.

Re: Server-side rendering is a better choice for many applications (2020)

#77
A good reference in this space is Rich Harris' talk on "transitional" web apps: https://www.youtube.com/watch?v=860d8usGC0o ("Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes")

SvelteKit, in my opinion, did a fantastic job implementing the best of both server-side rendering and client-side hydration and navigation by default (with any amount of route-level mixing and matching you want to do). I was skeptical of client-side navigation in particular, but it really does make my app feel so much snappier.

Re: Server-side rendering is a better choice for many applications (2020)

#78
post #53
post #14

Not really sure why this person is quoting the weird old vampire just to talk about something as banal as server side rendering.

Ad-Hom is generally frowned upon in this establishment.

I mean it's not really as hominem is it? I'm not arguing the point at all. I just mean that invoking a controversial like Thiel for something as reasonable as discussing the merits of server side rendering is a very odd choice.

Re: Server-side rendering is a better choice for many applications (2020)

#79
post #31

All this noise around "back to the roots" template rendering seems to ignore the elephant in the room that FE devs DON'T want to work with jinja2, django templates and all this jazz as it is perceived as a devaluation of the role + they need to learn specific syntaxes instead of having a "one size fits all" approach like with js frameworks.

As a frontend dev I can give you a few more reasons why I don't want to go back to writing templates as part of some backend framework: JavaScript is eventually needed for any non-trivial app. JS without a build system/dependency management is a maintenance nightmare. JS without linting, TypeScript, module syntax and unit tests is a maintenance nightmare. Reuse of components is much easier and more testable with fram…

Many apps with moderate interactivity don’t need thousands of lines of JavaScript. And using a backend framework for templating is not mutually exclusive to using a JS build system for helping transpile files and purge CSS and such.

Re: Server-side rendering is a better choice for many applications (2020)

#80
post #32
post #13

First I’ve heard of this interview question but if anyone is wondering here is a guaranteed way to fail a job interview with Thiel by answering the question thusly: Money has never existed without taxation

He would undoubtably respond with, "What about cryptocurrencies?".

Do you prefer "Money never existed without levy", then?
Post reply on HN