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

111–120 of 225 posts

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

#111

Post by synergy20 »

NerdiOrg wrote: post #91
andrewstuart wrote: post #76

I don’t want server side react. It’s disappointing to me they’ve gone so hard on server side. It feels like Facebook use it server side so they’ve lost interest in being purely client side.

Nobody is forcing you to use all the capabilities. You can still use it for client-side only if you want, but the efficiency of having both is perfect for me personally and our company.

frontend is already complex enough, there are many use cases do not need SSR at all, React used to be SPA first, now is SSR first(just like svelte), which means lots of unnecessary stuff to understand for SPA programmers. I came from vue-svelte-react, now Vue is the only one still does true SPA(SSR is opt-in), so, I am back to Vue and hope it won't change to SSR-first like the rest.

React is owned by Meta which cares more about SSR, similar to Svelte. Vue is not owned by any single company, that seems like a huge huge plus now.

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

#112

Post by tshaddox »

youngtaff wrote: post #83
tshaddox wrote: post #60

Earlier quoted context omitted.

I think you might be using the term “SSR” in a non-standard way. In the context of JavaScript apps, SSR refers to an initial pre-rendering of the HTML of a SPA page on the first browser page load. Subsequent navigations in that same browser tab would render on the client just like an SPA that doesn’t have SSR. You might be talking about what the JavaScript community has started to call “MPA,” which doesn’t seem to ha…

SSR isn’t actually rendering though… it’s generation of markup just like PHP does… sure sometimes it contains data to rehydrate the page just like early .Net components used to The various JS frameworks seem to have taken a concept that was common and tried to rebrand it which just adds more confusion

In React I think it’s pretty fair to call it server-side rendering, to distinguish it from the usual client-side React render which manipulates the DOM. It’s just like that, except it renders to a string that can be returned in an HTML response (or streams: https://react.dev/reference/react-dom/server/renderToString#...).

It might be a little clearer now to call it “pre-rendering,” to distinguish it from React server components which also run on the server but which are quite distinct from SSRing client components.

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

#113

Post by simplotek »

BiteCode_dev wrote: post #41
dmix wrote: post #39

Earlier quoted context omitted.

SPAs, microservices, nosql (Redis), and serverless are all still alive and well, they just aren’t a hammer for all problems like (some) people treated them originally. Nerds getting overexcited about new tech is an old story and it will continue to happen indefinitely as much as we like to smug post about it. IDK about GraphQL since I’ve not used it but I’ve read lots of stuff recently about frameworks/ORMs working t…

That's exactly my point.

> That's exactly my point.

In your own, exactly what point did you tried to make? Complaining that x and y technology users joined the "whoops" crowd when those technologies are in fact well established and proved to be effective if not nearly optimal in some applications, what do you perceive as "whoops"?

Frankly, it didn't seemed you had a point to make other than parroting cliches.

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

#114

Post by [deleted] »

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.

[deleted]

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

#115

Post by moritzwarhier »

Yes, for apps that are not hosted publicly or that are not mainly "websites" – what's wrong with just using react + react-router? So I agree that this is an oversight.

Also, there surely are plenty of non-public web-apps in the B2B segment which run in the browser behind a login or on private networks, where SSR is basically unneeded (also, electron and the like)?

But:

for a public web site or commercial web app, I find the take from the first screenshot pretty nuanced.

It is easy to underestimate the complexity of building your own React SSR- or SSG-framework.

I recently tried out vite-plugin-ssr, which kind of does that, in a way that's agnostic to the frontend framework/library.

Can recommend it for people who want neither SPA without SSR nor one of the established React frameworks.

But for people who want to build a full, public-facing website with SSR (which is kind of a requirement for SEO), with minimal friction, I think the recommendation from the docs is absolutely correct, no?

Plain react for single components in otherwise non-React website, full-stack framework if you build the whole site/app in React.

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

#116

Post by nextaccountic »

synergy20 wrote: post #111
NerdiOrg wrote: post #91

Earlier quoted context omitted.

Nobody is forcing you to use all the capabilities. You can still use it for client-side only if you want, but the efficiency of having both is perfect for me personally and our company.

frontend is already complex enough, there are many use cases do not need SSR at all, React used to be SPA first, now is SSR first(just like svelte), which means lots of unnecessary stuff to understand for SPA programmers. I came from vue-svelte-react, now Vue is the only one still does true SPA(SSR is opt-in), so, I am back to Vue and hope it won't change to SSR-first like the rest. React is owned by Meta which cares…

> now Vue is the only one still does true SPA(SSR is opt-in),

With next.js, SSR is opt-in too

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

#118

Post by kypro »

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…

> What happened to KISS?

Engineers have to over-engineer to look smart.

Back when I first started working as a software engineer no one gave a crap about good code or best practises. Back then it wasn't uncommon for there to be a few dudes maintaining the website of a large household name business with almost no oversight. I remember it being common for someone entirely untechnical to come over to dev desk and ask for some feature, then you'd find the easiest and quickest way to get that thing live.

Skip to today and we have entire engineering teams with hierarchies, specialities, and accountability – and this is true even in smaller companies.

So imagine you're the lead frontend guy at some company... Are you honestly going to say, "well the site's requirements are kinda simple, so we can probably just build it in HTML and vanilla JS"?

There was a period several years ago where frontend guys writing HTML/CSS and some JQuery were lesser regarded than Java and C# devs. It's why I always pitched myself as a backend guy who knew HTML & JS. But then we got Node, React and TypeScript... Now frontends are so complicated that if you want someone with enough experience to understand how any of it works you need to pay them a decent salary for their knowledge.

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

#119

Post by root_axis »

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?

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

#120

Post by lawkwok »

duncan-donuts wrote: post #97
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…

Late last year I listened to talk on nextjs and I was floored by its design. I still can’t get over that the JS community has embraced file system routing and server rendered stuff. I honestly think I’m taking crazy pills because I could have replaced “nextjs” with “PHP” in most places and it would still make sense. I have been in software for about a decade and I think I’m experiencing my first complete cycle of “wh…

It’s funny to think there was a time when using JS vs JQuery was the biggest division among devs. Now just using JS is considered the baseline and React is the new framework that people jump to when it isn’t always necessary.
Post reply on HN