Live data from Hacker News

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

timr.co

191–200 of 286 posts

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

#191
post #178

This article misses the single most important reason to use SSR: single language applications are single build applications. Frontend builds are basically a requirement for any application with a UI. You're always going to have CSS, and some degree of user interaction for even the simplest website, which means JS/TS. One of the most important developments for frontend assets in the past decade is dependency managemen…

> single language applications are single build applications I don't know your background but most teams don't view "single language" as an advantage over other options. People choose a certain language because of internal infrastructure, libraries/ecosystem, performance, and whether it is the best suited for a project etc, rarely because "we use that language for backend so we should also use it for frontend" or vic…

> I don't know your background but most teams don't view "single language" as an advantage over other options.

We view it as a massive advantage, assuming we are on the same page with "single language, plus HTML/CSS/JS"

Our language is C#. Our web "framework" consists of the string interpolation and verbatim operators. Most of our views take the form of:

  var finalHtmlResponse = @$"
    
     {DiyPHPViewEngineRabbitHoleEntrance(httpRequestContext)}
    ";
I actually tried using the cshtml/razor engines because it seemed "more proper" but after 2 days of dependency hell I decided to go back to raw string interpolation. If you are able to build a functional website using static sources and have the barest capability to compose functions and strings, I do not see why this path would provoke any serious anxiety (other than it not being popular).

Imagine being able to directly invoke some utility or other backend method from your HTML view source pipeline. If you write it all in the same language, this becomes feasible. The moment principal rendering is outsourced to the client (or some other language), you are talking about a JSON API + distributed state circus and all the hell that must go along with it.

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

#192

Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality s…

While this is your opinion, a majority of the frontend development experience has borne these solutions out of real problems, not in spite of them. Every take like this reeks of never having built large and interactive frontend projects that involve more than 1 developer.

Sure you can get by on htmx/html/css/tailwind/whatever simplistic thing you can conjure up but those things don't SCALE, which is what these frameworks are built to do.

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

#193
This is one of those vague "it depends on your organization" type answers. I've worked in apps where frontend folks did the JSPs and backend folks did everything else and it wasn't really optimal either. You end up with messy and/or non existing contracts between UI and the backend. Also, in my experience it's easier to handle partial functionality degradation in the client than on the server side which may be important or not at all depending on your app.

So what I'm saying is there's a reason people ran to client side rendering and blindly running the other way for the sake of being a contrarian is equally silly.

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

#194

Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality s…

> This has led to a monoculture where questioning popular frameworks like React is heretical.

If that was the case we wouldn’t have the other problem we have on the front end. A million and 1 different web frameworks.

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

#195

Whether you're doing server rendering or client rendering, you need to separate markup from business logic. Modern architecture fashion tells us that we need to use micro services. So even if I generate markup on the server, I need to talk to micro services using HTTP to get data. So the question is: which technology provides best tools for writing server-side rendering module? My wishes: 1. Strict-typed language. 2.…

> 1. Strict-typed language. 2. Compiler-checked HTML output. 3. Flexible CSS output.

Haskell can do that.

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

#196

Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality s…

Strongly agree. A great example of this hyperengineering is React Router. What should be boring utility code wants to be the opinionated lead singer of your app and introduce breaking changes every few years while the rest of the web has been treating routing like a solved problem for decades.

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

#197

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

I'm sure this is an unpopular opinion here, but I hate this website's UX. Replying to a comment loads a new page, losing the entire context of the thread. There is no UI to indicate if there's a reply to an earlier comment made. The typograph is ugly as sin, and hard to read (too small on desktop, looks bad on mobile, poor contrast). With new pages needed for basic reply/editing capabilities, the site doesn't even accurately track the navigation stack. Sure it loads quickly, but we can load a hello world in a p tag pretty quickly too. HN as a site is a perfect example of how bad a SSR experience can be.

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

#198
You're absolutely correct, which is why we had Rails, Django, Laravel,etc.

Why do we need node.js-based SSR and hydration etc these days? It seems it's just remaking an already solved problem with fancier terms, bottom line is that it's way more complex, what's the point?

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

#199

Modern web development has become a wasteland of over-engineered solutions, and the real issue isn't client-side vs. server-side rendering; it's the industry's obsession with frameworks. Frameworks are not just tools; they're ideologies that developers subscribe to, often blindly. This has led to a monoculture where questioning popular frameworks like React is heretical. Ironically, this 'framework-first' mentality s…

[deleted]

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

#200
post #175

I am surprised that this topic keeps coming back and gets attention. I thought in the year 2023 this is a settled topic. Lots of hype from people who obviously never managed a real website or a real-world software project. On the non-technical side, traditional server/client separation is well understood by everyone and has all the tools any team ever needs, while SSR takes some learning -- it is added cost that does…

[deleted]
Post reply on HN