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

81–90 of 286 posts

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

#81

Post by philote »

mg wrote: post #50
ransackdev wrote: post #43

Earlier quoted context omitted.

I’ve rolled my own mvc framework before, In php even! This was years ago when CakePHP was the new hotness and Laravel didn’t exist. Take it from someone who had your mentality and set off to make a tiny and no bs mvc that just gets the job done, the amount of work these frameworks are doing for you (backend frameworks) that you don’t consider, is why you should run a framework. You don’t want to deal with processing…

You don’t want to deal with ... Well, I do all that and it works just fine for me. All my projects are 100% my own code down to the core. No frameworks, nothing. There might be some traces of jquery in there from when browsers were more unreliable. I don't even use that these days. To get to know those frameworks, I built some projects with Symfony, Laravel, Django and some others. But it didn't stick. They are too a…

Django is a super heavy framework that includes most anything you'd ever want. There's a ton to learn. Have you tried lighter-weight ones like Flask? I much prefer a lightweight web framework with an easy-to-use ORM/ODM.

Also, even though you don't use frameworks, I assume you use various libraries to handle web requests and such, right?

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

#82

Post by ransackdev »

pragmar wrote: post #69
ransackdev wrote: post #54

Earlier quoted context omitted.

How’s your vulnerability reporting process and how much experience do you have interpreting complicated pen tester bug reports about some buffer overflow zero day in your homebrew query string parser? Huge difference between working fine, and working right. The security implications of rolling your own, is why I say “you don’t want to…” Also, none of that code has anything to do with the product you’re actually tryin…

In the aughts, when everyone was rolling their own framework, security and maintenance were a nightmare. It's undeniable. We traded one problem for another, however, and we've gone too far. I think the question at hand is which is more secure/maintainable: 10kb of custom utilities or 100mb of mystery-meat modules that, let's face it, will never be reviewed. It's not a simple answer.

Smaller file sizes or less LOC is not inherently safer than larger sizes or more LOC. if you’re building web apps, you’re more than likely reaching for a handful of packages, and so are millions of other people, and so are multi billion dollar companies, companies with staff who’s job it is to do supply chain security, PCI compliance auditing, security assessments, who hire pen testing firms, and some even write browsers and can sway the direction of our entire industry and the internet as a whole. Countless static code analysis is ran on the millions of CI jobs a day on builds that pull in the package, etc. If you’re using popular and maintained open source packages, people are looking at them. Shy away from no name packages with no usage unless you personally look at the code. That’s my take on it. I tend to trust the open source community to all be working towards the shared goal of well crafted and secure code for the world to use and benefit from

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

#83

Post by em-bee »

collaborative wrote: post #36

> It's cheaper > You will need a backend anyway. It'll need to expose data to users. Exposing it as HTML is no harder than doing it via JSON or GraphQL Sure, if your "app" is just buttons and UI that interacts with a backend DB, I agree. However, many PWAs and native apps do lots of heavy lifting on the client side, and loading the backend with that is not cheap at all!

exactly, exposing the backend with HTML is harder, if that is supposed to mean the complete interface which includes CSS and javascript. without interface it would just be XML, at which point JSON would be the better choice.

even more, many backends can be simple CRUD. i reuse my backend for all websites and haven't had to do any custom backend coding in years. so my current backend cost is zero, because i can do it all in the frontend.

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

#84

Post by fauigerzigerk »

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.

Maybe you're right that people find it easier to think that way, but it seems rather illogical to me.

The very first step in creating this separation is to define an API that is implemented and operated by backend devs and used by frontend devs. Once you have done that, you have achieved all the clarity that is necessary or possible.

Whether or not some parts of the frontend are executed on the server-side shouldn't matter for the question of who has responsibility for what.

Perhaps it's more about the ease of hiring for different skillsets. If frontend is synonymous with client-side and backend is synonymous with server-side, it makes life easier for HR and recruiters.

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

#85

Post by vbezhenar »

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. Compiler-checked HTML output. 3. Flexible CSS output.

So one should be able to write reusable components and easily write required markup.

IMO best tool nowadays is TypeScript + React.

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

#86

Post by water9 »

nvm0n2 wrote: post #26

> What important truth do very few people agree with you on? Seems like answering with SSR would fail a Thiel interview for two reasons: 1. It's not important (in the grand scheme of things) 2. It's not a view that very few people hold. SSR was the standard way to do things for a couple of decades up until frameworks like React, and React itself now implements SSR, doesn't it? Thiel uses this question to try and dete…

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.

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

#87

Post by pjc50 »

dools wrote: 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

Render unto Caesar on the server.

(Mandatory HN joke explanation: https://en.wikipedia.org/wiki/Render_unto_Caesar plus a pun on the original thread title)

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

#89

Post by Karellen »

nvm0n2 wrote: post #32
dools wrote: 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?".

What about network/transaction/gas fees?

They're charged by the entity that issues the currency (the network/the miners), for the act of using the currency, which I think could reasonably be classified as a form of tax.

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

#90

Post by philote »

collaborative wrote: post #36

> It's cheaper > You will need a backend anyway. It'll need to expose data to users. Exposing it as HTML is no harder than doing it via JSON or GraphQL Sure, if your "app" is just buttons and UI that interacts with a backend DB, I agree. However, many PWAs and native apps do lots of heavy lifting on the client side, and loading the backend with that is not cheap at all!

Yeah, I don't get how it'd be cheaper at all. Yes you need a backend anyway, but unless you're not paying for usage and have spare CPU cycles and bandwidth available, it's not cheaper. It's cheaper to send your frontend html+js and let the browser cache it so it's only sent once, and let the frontend pull only the data it needs to render the html. The backend isn't having to process a template, or resend similar html constantly to the frontend since most of that likely cannot be cached.
Post reply on HN