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

New React docs pretend SPAs don't exist anymore

wasp-lang.dev

Post reply on HN
Print view View original

221–225 of 225 posts

Re: New React docs pretend SPAs don't exist anymore

#221

Post by cush »

psnehanshu wrote: post #212
cush wrote: post #206

Earlier quoted context omitted.

I never understood where the idea came from that if pages are authenticated, then SSR isn't needed. Maybe because people think the only benefit is SEO. The biggest benefit is performance. SSR is still great to have behind authenticated pages, to improve load times. eg multiple tabs, continuing sessions, etc. There are countless examples of sites that usr SSR + CSR + Auth - Netflix, Github...

The only other benifit of Next.js other than SEO is the project architecture that it provides. If you are building web apps that live behind auth, it's a no brainer to use CSR. It's easy to deploy, cheaper to host and serve, not harder than SSR to develop. The cons about performance can be solved using code splitting. Moreover with proper caching, the app loads instantly. Are there new age alternative CRA that provid…

Of course, there are tradeoffs. Code splitting might help a bit for someone with a slow connection, but I wouldn't say it "solves" the problem like truly streaming content does.

Re: New React docs pretend SPAs don't exist anymore

#222

Post by psnehanshu »

cush wrote: post #221
psnehanshu wrote: post #212

Earlier quoted context omitted.

The only other benifit of Next.js other than SEO is the project architecture that it provides. If you are building web apps that live behind auth, it's a no brainer to use CSR. It's easy to deploy, cheaper to host and serve, not harder than SSR to develop. The cons about performance can be solved using code splitting. Moreover with proper caching, the app loads instantly. Are there new age alternative CRA that provid…

Of course, there are tradeoffs. Code splitting might help a bit for someone with a slow connection, but I wouldn't say it "solves" the problem like truly streaming content does.

Yeah, it's like a trade off. You can't have your cake and eat it too. With CSR, you distribute the load of rendering to your clients, which reduces your cost, which in turn allows you to provide better service.

Re: New React docs pretend SPAs don't exist anymore

#223

Post by eurasiantiger »

claytongulick wrote: post #219
roflyear wrote: post #208

Earlier quoted context omitted.

Yeah just seems like a different interface than GraphQL, but it's basically the same thing as GraphQL. So at this point, is it just "we don't like GraphQL" or something? I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard. GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if…

> is it just "we don't like GraphQL" or something? Yes. But not without reason. GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs. You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc... This cost would be worth paying if GraphQL brought new a…

GraphQL enables entity-level caching. That is not possible in REST.

Re: New React docs pretend SPAs don't exist anymore

#224

Post by RunSet »

nvln wrote: post #141
root_axis wrote: post #119

Earlier quoted context omitted.

Have you considered the possibility that people aren't as stupid as you think and that these tools actually solve real problems?

What part of my comment suggests that I think people are stupid? --- Tools can solve important problems "and" increase the complexity to point where they create other problems which makes the trade-off untenable.

It seems to me that they may have inadvertently answered your question.

Q: "What happened to KISS?"

A: "It fell by the wayside when it began to be interpreted as a personal attack."

Re: New React docs pretend SPAs don't exist anymore

#225

Post by roflyear »

claytongulick wrote: post #219
roflyear wrote: post #208

Earlier quoted context omitted.

Yeah just seems like a different interface than GraphQL, but it's basically the same thing as GraphQL. So at this point, is it just "we don't like GraphQL" or something? I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard. GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if…

> is it just "we don't like GraphQL" or something? Yes. But not without reason. GraphQL departs from web standards and semantics in order to solve a problem that doesn't really exist in most APIs. You incur a cost in using it, some of which I've outlined but there are many others, such as working against the browser's native caching capabilities, e-tags, etc... This cost would be worth paying if GraphQL brought new a…

Oh, totally agree the best cases for GraphQL are like 10% or so of the usecases for APIs. I don't think you should use it everywhere.

I also think GraphQL should never be used for updating data, just that it is nice for a segment of problems related to querying data.

Post reply on HN