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

261–270 of 286 posts

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

#261

Post by dools »

abecedarius wrote: post #103
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

OK, my model of Thiel would say: are you offering me a thesis from bestselling author David Graeber, or is this a view that actually very few people hold which you're disguising as a popular one for some reason? (i.e. he'd reject this as boringly conventional before it got to the level of does it make sense? I've only read a little bit of Thiel, like 2-3 blog posts worth.)

Disguising as popular? Also I know Graeber talks about this in his book Debt but I haven’t read it because I hate his bullshit jobs work so much.

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

#262

Post by debo_ »

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 appreciate how the tree of responses to this comment are of the form:

> I agree/disagree with the article's premise because of this thing I absolutely know is true.

> You are totally wrong.

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

#264

Post by dools »

Karellen wrote: post #89
nvm0n2 wrote: post #32

Earlier quoted context omitted.

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.

They could be considered a transaction tax and/or payment processing fee. But they are not the reason people would be willing to accept a token in exchange for some real resource like labour, because unless you’re already using that token you are not obliged to pay for anything using that token.

Demand for that token is thus entirely speculative and could evaporate at any time. Since there is no issuing authority that guarantees to accept the token in order to exonerate some obligation we have in common the last person holding the token simply loses the game.

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

#265

Post by ninepoints »

pc86 wrote: post #236
ninepoints wrote: post #226

Earlier quoted context omitted.

Please indicate where I suggested as such.

This reply comes off as needlessly rude, but I'll give you the benefit of the doubt that it's just intent not coming across well via text. In the context of the comment to which you're replying[0] I'm not sure how else to take your comment. OK, you don't like HN's UX, that's either a comment on SSR and on topic for the thread, or completely unrelated. > HN as a site is a perfect example of how bad a SSR experience ca…

My point is that this site is not a good example to use for showing SSR in a good light. Logically, this doesn't mean the converse of the statement is implied (that if this site didn't use SSR, it would be good).

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

#266

Post by james2doyle »

RedShift1 wrote: post #185

I come from the php heyday of SSR apps (now I write vuejs with graphql backend apps) where I used just plain php files that render a Smarty template. Is that still the goto solution or are there better alternatives?

I honestly miss these days. I'm currently using Next 13 with the app directory and server components, calling a headless CMS with graphql, generating types from introspection, all to statically render HTML in a proprietary build system that takes 6 minutes to deploy. Only to find you need to build a whole "preview" workflow because you can't see your drafts with SSG - which means you need a server anyway...

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

#267

Post by spacecadet »

spacecadet wrote: post #91

Heres mine: Longevity tech... who benefits from living forever? The wealthy... What does living longer even mean? Does it mean I live 10 years longer in pain? I see longevity tech as code for ensuring the poor are here in the event we stop reproducing, or our decisions prevent us from being able to... and before you black and white nerds jump on me, Im not talking about biotech and healthcare!

Down votes. Robber barons!

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

#268

Post by traverseda »

la_fayette wrote: post #246
traverseda wrote: post #216

Earlier quoted context omitted.

I've never heard the term SSG before. Apparently stands for "static site generating" and is a `next.js` thing. No, hacker news is not a static site. It just makes use of caching HTML on unchanged pages, and as I understand it that cache is often bypassed for logged in users. This is why sometimes when hackernews is overloaded you can still view the site in private browsing, since you're not logged in it hits the cach…

Ok, it seems I mixed up the acronyms, I thought SSG stands for server-side generated. What I actually mean is, that there is a difference between SSR with react, which requires some kind of rehydration on the client, in contrast to a website generated by, e.g., PHP on the server, which doesn't require this. The PHP website doesn't require the client to rehydrate and produces less load on the client. With the disadvan…

Server side rendering has meant basically just generating HTML and serving it for a long time.

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

#269

Post by umvi »

flimsypremise wrote: post #257
umvi wrote: post #253

Earlier quoted context omitted.

> If you're using JS modules and ESLint, you are using a frontend build Browsers natively support JS modules with no frontend builds needed ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... ). You just need to specify `type="module"` in your ` ` tag

I mean, you could do that, but as someone who has been doing this for a very long time, I would not recommend it. If your application is very simple and has very few dependencies it might work, though I think you'll have a lot of trouble managing your dependencies across multiple environments. You wouldn't distribute a C application without a Makefile, and you shouldn't distribute or deploy a frontend application wit…

> You wouldn't distribute a C application without a Makefile

And yet, SQLite does just that. They distribute as a single .c file. I wrote a moderately successful lcov replacement in python that I distribute as a single .py file so people can directly run it without needing pip (if desired). There's a time and a place for needing build systems, but as a minimalist I default to vanilla + no build system and that serves me very well the vast majority of the time.

> and you shouldn't distribute or deploy a frontend application without the equivalent dependency management and build orchestration

Why not? That's the other thing. What are all these dependencies you are talking about that need "managing"? Most web apps I've written have needed 1 dependency (bootstrap CSS). Maybe PIXI or ThreeJS if making something graphical. Include it in the html, boom done, no npm needed.

Take a look at this guy's blog and tell me that he needs to abandon vanilla and start using a frontend build system: https://ciechanow.ski/gps/

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

#270

Post by water9 »

zmxz wrote: post #95
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 nothing to do with roles being sent and what a user can see. It's as related as Jupiter is to a brick.

It has to do with the size of the attack surface. in order for things to be client side driven gui elements need to be loaded for different role types. Those elements are often exposed If not directly then by showing which APIs are used to Authorize access to admin areas. That’s the whole point of rendering on the client. To load some Little div you might have an API call that when access by different role types will respond differently. With Server side rendering you never see the different API points for each role type As they get their own.
Post reply on HN