Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

timr.co

Post reply on HN
Print view View original

161–170 of 286 posts

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

#161

Post by tacker2000 »

vbezhenar wrote: post #85

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

Honest question: have you ever used anything besides JS and related stuff (TS/react)?

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

#162

Post by candiddevmike »

flimsypremise wrote: post #137

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…

> So, given that the frontend build is baked into _any_ application build, if you decide to do template rendering in any language other than JS/TS, you are adding another build to your project. That means you need to configure that build for all environments, configure CI, and support that build going forward. Save yourself the trouble and just render everything server-side in JS.

You had me until the last part which seems to contradict everything you said beforehand as you now have to test everything being rendered server-side. Why render it server-side if it's already in JS and capable of being rendered on the client? Optimize your bundles if you're chasing lighthouse scores.

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

#163

Post by BackBlast »

lolinder wrote: post #158
BackBlast wrote: post #154

Earlier quoted context omitted.

You have to explicitly use .innerHTML. As I said, "do work", not that it is impossible. No SPA frameworks do this by default. The default is $DOMElement.textContent = value, which has no escape potential. Everything rendered by the server has this potential as it must be deserialized by the browser.

> No SPA frameworks do this by default. No, but I've definitely seen bespoke, hand-rolled frontend code do it. You can't select SPA frameworks as representative of frontend rendering but look only at hand-rolled PHP from 2002 for backend rendering. No major SSR framework is XSS-vulnerable by default. Whether you're using Rails, Laravel, Spring, ASP.NET, Phoenix, or whatever , every template engine escapes your string…

> No, but I've definitely seen bespoke, hand-rolled frontend code do it, and that's what you're comparing SPAs to on the server side.

Yes, congratulations, you pointed out that you can hang yourself either way. That wasn't my point and I acknowledged as much in the first post.

One has an unsanitized escape free method and the other does not.

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

#164

Post by sanderjd »

alexanderchr wrote: post #143
sanderjd wrote: post #28

Earlier quoted context omitted.

Nice! Anecdotally this still doesn't seem to be the dominant way that web apps I use are implemented. Is this just taking awhile to get mindshare, or are there some drawbacks keeping most people from using it?

Because it adds a lot of complexity for the small benefit of shorter initial load times. There are many issues, for example you need to make sure that all your front end code runs both in the browser and in node. You need to mark parts of your UI to not server render, you need to be aware of the timing between the site being loaded and hydration being finished (a text input might have some value prefilled from the se…

Very helpful!

Those are basically the same drawbacks as a decade ago.

I guess my question to the folks here saying hybrid is the way to go nowadays is: Have these problems been solved in your view?

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

#165

Post by tacker2000 »

So it seems we are coming full circle again now.

Since the dawn of time, backends running on PHP/Java/Ruby/etc… were used to render pages serverside and send them to the client, maybe even sprinkled with a little JS.

Now that the whole JS stack and ecosystem has grown so big and unwieldy, we search for solutions to the problems we have created.

Added to that, many have huge incentives and lots of skin in the game, and many have only knowledge of JS and nothing more, so we try to reinvent the wheel again.

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

#166

Post by Transpire7487 »

superb-owl wrote: post #63

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

You say this as if it is necessarily good, but I disagree and would even say it's actually a hindrance for many teams. It often adds inefficiences, increases costs and makes planning and collaboration more difficult.

> the fact that you get an API by default with CSR is also nice

The vast majority of applications don't need an API.

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

#167

Post by tiffanyh »

tacker2000 wrote: post #165

So it seems we are coming full circle again now. Since the dawn of time, backends running on PHP/Java/Ruby/etc… were used to render pages serverside and send them to the client, maybe even sprinkled with a little JS. Now that the whole JS stack and ecosystem has grown so big and unwieldy, we search for solutions to the problems we have created. Added to that, many have huge incentives and lots of skin in the game, an…

> ”So it seems we are coming full circle again now.”

This is common in tech.

Decades ago, companies rented time slices on beefy servers. This was called “mainframes”.

Today, it’s called “cloud”.

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

#168

Post by evantbyrne »

greenie_beans wrote: post #119

i don't think this is as contrarian as the writer thinks it is, even in 2020. everyday there is a post on the front page of HN glorifying server-side rendering/html/htmx/hotwire or denigrating react.

Yeah, this seems to be a very popular opinion outside of Node.js circles.

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

#169

Post by umvi »

flimsypremise wrote: post #137

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…

I say save yourself the trouble and just avoid all "modern" web development tooling. Avoid "frontend builds" at all costs (everything except for esbuild is insanely slow anyway). Most websites do not need npm for frontend (or backend). Most web applications are barely "applications" at all but rather mostly-static content with a few forms, tables, and/or menus.

I use vanilla html/css/js for frontend + golang for the backend. Modern JS (esp. modules) are very powerful. ESLint provides pretty good static checks for the frontend, and of course golang is statically typed so you get strong guarantees about your backend. Go builds extremely fast as a small self contained binary that can run on any OS and in a from scratch docker container. Go performance and tooling blows JS out of the water. And go has a powerful built-in templating engine for SSR which allows to to make your JS even leaner. Testing a change requires no more than refreshing the page. Debugging is super easy, barely an inconvenience since there are no build layers between anything encumbering developer velocity. Just add breakpoints directly to chrome devtools in the JS (or in VSCode for the golang) and step through.

Always start vanilla. Most of the time you won't need to be dependent on npm, you'll never break when some random maintainer becomes an activist, people will wonder why your site page loads are so snappy, and you'll live happily ever after.

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

#170

Post by [deleted] »

tacker2000 wrote: post #165

So it seems we are coming full circle again now. Since the dawn of time, backends running on PHP/Java/Ruby/etc… were used to render pages serverside and send them to the client, maybe even sprinkled with a little JS. Now that the whole JS stack and ecosystem has grown so big and unwieldy, we search for solutions to the problems we have created. Added to that, many have huge incentives and lots of skin in the game, an…

[deleted]
Post reply on HN