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

141–150 of 225 posts

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

#141

Post by nvln »

root_axis wrote: post #119
nvln wrote: post #96

Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 1. There is a significant gap between dev and production environments. (See #2 why this is critical) 2. The production build times are super high 3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard. 4. I occasionally get X is included twice errors that are pai…

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.

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

#142

Post by nvln »

danlugo92 wrote: post #122
nvln wrote: post #96

Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 1. There is a significant gap between dev and production environments. (See #2 why this is critical) 2. The production build times are super high 3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard. 4. I occasionally get X is included twice errors that are pai…

I develop in react and follow KISS and I don't have any problems whatsoever. Some libraries can be a pain in React Native however, but React web has been smooth sailling for me (following KISS and MVVC).

Yes, using just the FE part is still joyful (Svelte, React etc). It's the move towards full-stack (Next, SvelteKit etc) that I'm slightly complaining about. My complaint is also limited to how complex the build process is in combination with other aspects of the fast moving TS/JS ecosystem.

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

#143

Post by claytongulick »

eurasiantiger wrote: post #139
roflyear wrote: post #132

Earlier quoted context omitted.

In my experience it's the poorly implemented abstractions on top of your ORM of choice that make graphql a bad time. It itself is really a great way to do things imo

Yes, exactly. The typical issue is devs not grokking the mental model of GraphQL and instead just creating more and more extra queries, essentially resolving data piece by piece in the frontend instead of leveraging GraphQL types and adding types, fields and field resolvers as needed so that the frontend can do one query to get all the data it needs. No wonder it feels like a clunky extra glue layer if it’s being use…

Some of us learned these lessons in the SOAP/WSDL/XML-RPC days, and learned to embrace the principles of REST to a avoid exactly those issues.

I looked at graphql and saw a return to the horror of DoSomethingBecauseItsMondayAndDueTomorrow() type API methods.

Hundreds or thousands of them that accumulate like cruft over time, and no one can delete anything because you have no idea what it'll break.

I stick with well designed and well planned REST APIs.

It's not a panacea, but it helps.

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

#144

Post by meotimdihia »

deepsun wrote: post #140

I don't understand the fuss about SSR, wasn't that default way of doing websites 10+ years ago, before AJAX? E.g. Apache Struts has all of that Router logic since like 15 years ago, completely server-side.

SSR solves the problem: "the content does not render before your browser download JS."

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

#145

Post by root_axis »

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.

> What part of my comment suggests that I think people are stupid?

This part:

> What happened to KISS?

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

#146

Post by deepsun »

meotimdihia wrote: post #144
deepsun wrote: post #140

I don't understand the fuss about SSR, wasn't that default way of doing websites 10+ years ago, before AJAX? E.g. Apache Struts has all of that Router logic since like 15 years ago, completely server-side.

SSR solves the problem: "the content does not render before your browser download JS."

Sorry what JS? With aforementioned Apache Struts there's no need for JS to render anything.

But if one wishes, JS can be added, of course (e.g. for DHTML stuff). To avoid render blocking there are "defer" and "async" attributes.

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

#147

Post by zarzavat »

Rauchg wrote: post #138
chambers wrote: post #127

Earlier quoted context omitted.

Speaking as an engineering manager, vercel’s approach seems to cater to the last market where overengineering and complexity were status symbols that middle management was happy to pay for. When the headcount was free, there weren’t many questions from upper management why basic UIs required so much heavy lifting by (overly) experienced engineers. In the new market, there will be much more scrutiny on costs and the c…

Interestingly, I have the exact opposite bet: “SPAs were a zero interest rate phenomenon”. Putting the burden of compute on clients, and shipping slower apps for the sake of DX and convenience. Customer-first wins. Looking forward to see how this plays out.

SPAs are faster than SSR because you can choose whether to incur network latency or not.

For example, let’s consider a site with two pages. In the SSR case, if I click the link to page 2, then I have to wait a whole network roundtrip for the page to appear.

In the SPA case you can decide when you want to load the content for page 2: with page 1 (if it’s a small amount of content), if the user scrolls to a certain point, … it’s completely up to you. You can cleverly hide the latency so that when the user does navigate to page 2, it’s instant.

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

#148

Post by seydor »

notfed wrote: post #121
AgentME wrote: post #32

This comment thread is a little funny because every single HN thread outside of this one rants super aggressively about webpages that don't show any content before JS loads, but this thread has managed to collect the opposite group together for once because React's docs have updated to stop actively recommending tools that force that problem to happen.

It's almost as if the community has a diversity of opinions.

my observation is that the community (here) has converging opinions, but the groupthink changes over time. At some point it seemed SPA was all the rage, now there is a reactionary wave

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

#150

Post by CSDude »

All our application lives behind an authentication except login pages. I still cannot grasp how would I use Nextjs in only SPA mode. Not everything needs to be SSR, I don't want to spare resources, just want to deploy it to S3, put cloudfront infront of it, let 404 requests return index.html and I can use the URLs without #.

SSR should not be a must the docs should reflect that. There is no way I'm paying Vercel 20$ per user for our simple use case or I'm hosting a VM to render pages. I don't care about the improvements SSR would bring in the price of cost, deployment complexity, or any other complexity. Affecting React docs like this to push for SSR does not feel safe to me. I'm happy with my Vite based React TS project.

Post reply on HN