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

141–150 of 286 posts

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

#141

Post by mock-possum »

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.

I’m looking at you, JSX. >_>

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

#143

Post by alexanderchr »

sanderjd wrote: post #28
badestrand wrote: post #20

Earlier quoted context omitted.

This is already here and in use. See Next.js using React.js for example. Server-side rendering out of the box and small next needed pieces are loaded continuously when they are needed.

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 server and may be changed by the user before hydration finishes). Just from the top of my head.

My experience is that most of the time it’s better to make your public facing site fully SSR and then make the actual app fully client side rendered. You usually don’t need that much interactivity for your public site and your app users don’t mind a few seconds startup time. You also usually don’t need SEO for your app because it’s behind authentication anyway.

Exceptions exist of course.

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

#144

Post by mock-possum »

rambambram wrote: post #139
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.

> a clear separation between frontend and backend devs I love the 'CHAMP' stack, which stands for CSS, HTML, Apache, MySQL and PHP. ;) Clear separation between frontend and backend. I'm almost happy that I started webdev in the 90's. This 'ancient' technology is still going strong, with websites and a whole lot of webapps.

So how do you handle any interactivity that’s not a user click? Like say, mousemove, or keypress?

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

#145

Post by pathartl »

vlovich123 wrote: post #3

I think the next major change will be unified hybrid rendering. Render the initial view via SSR for speed, framework automatically injects more and more of the page transparently as user-driven events happen. All of this will be transparent and you only write the app once.

I have been using Blazor for the past year and I've got to say it's pretty incredible. It has some downsides and .NET 8 with Blazor United is going to be a very welcome change, but I can have my cake and eat it too. I finally get to use components, write some client-side stuff in C#, and I don't have to touch a lick of JavaScript or TypeScript. I get how irritating it is for people to beat the "JS IS BAD" drum, but man, it's nice to use proper typing in a language that has some pretty damn good syntax.

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

#148

Post by pookha »

exabrial wrote: post #136

Really being stated is SSR is far simpler (less moving parts, less latency, less things to break, 100% control of environment, etc) and therefore superior, which should make it the first and best choice for nearly all web applications.

Have to disagree with you. Plenty of web applications are using WebGL and have been for years (Cesium\GoogleEarth). I also like my applications to function when they're offline, especially if I'm flying or working without a network. I also might want to use WASM tools and use my local device as something more than just a dumb terminal. All of those use cases would make me prefer to use a more client centric approach and adding in SSR wouldn't add value (unless it's security).

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

#149

Post by DylanSp »

gv83 wrote: 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.

Speaking as a primarily BE dev with a preference for static typing - what I love about React is that TSX makes writing view code much easier. I get type safety to check that I'm passing in all parameters I'm using, type checking + the editor's autocomplete helps with HTML and CSS that I'm not as familiar with, and TSX being a relatively light sugar over Typescript provides more flexibility/power/ease-of-use than any templating language I've worked with. Go templates and ASP.NET .aspx templates (I think those are for Web Forms, specifically?) are much more annoying to work with.

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

#150

Post by lolinder »

BackBlast wrote: post #109
water9 wrote: post #86

Earlier quoted context omitted.

SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a surface that is small.

SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser which will then parse and execute code based on that rendering. You have to be sure your data going into the database doesn't have XSS escapes or your rendering of untrustworthy data doesn't have such XSS escapes. Which is why you shouldn't roll your own SSR unles…

This isn't a difference between SSR and SPA, it's a difference between using a modern framework and rolling your own.

If I get a user-provided string from the server as a JSON property and set it via `.innerHTML =`, I have an XSS vulnerability. If I use React's JSX string interpolation, I don't.

If I get a user-provided string from a database and inject it with a PHP `` tag directly, I have an XSS vulnerability. If I use Laravel with Blade templates [0], I don't.

You're not saved from XSS by virtue of using JavaScript to render your code, you're saved from XSS by using a framework that escapes everything by default. Whether that framework builds the escaped HTML on the client or the server is immaterial.

[0] https://laravel.com/docs/10.x/blade#displaying-data

Post reply on HN