Live data from Hacker News

New React docs pretend SPAs don't exist anymore

wasp-lang.dev

21–30 of 225 posts

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

#21

Starting a "new react project" should be basically creating an HTML file, and adding a script tag linking to React the JS library. Why are these developers always trying to obfuscate everything with tons and tons of layers of indirection all the time? You don't need to "bundle" anything and certainly not use some server just to add Javascript to a page (unless it's a matter of CSP of course) and you should certainly…

Because it's slow. Hard to do treeshaking if everything is in random dependencies that need to be downloaded at runtime. You also get a flash of white if you don't pre-render your sites.

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

#22
I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not managed. That's true of any application.

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

#23

I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…

Bored software engineers just want to keep making changes rather than moving to a new problem space.

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

#24

I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…

the biggest problem with SPAs is none of the devs making them seem to remember how nice it was to open different pages of a site in different tabs. it's all horribly phone/tablet centric. middle-clicking doesn't even pop links in new tabs because they break basic browser features. you're lucky if you can even tell what's a real link and what's just going to rearrange your current page.

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

#25

I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…

Typically with SSR, only the initial load is server rendered. Subsequent navigations are client rendered.

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

#27
post #24

I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…

the biggest problem with SPAs is none of the devs making them seem to remember how nice it was to open different pages of a site in different tabs. it's all horribly phone/tablet centric. middle-clicking doesn't even pop links in new tabs because they break basic browser features. you're lucky if you can even tell what's a real link and what's just going to rearrange your current page.

And even big sites built by well paid engineers that should know better (I’m looking at you Microsoft Azure!) have these issues! Sometimes middle click works. Sometimes it doesn’t. Sometimes right click open in new tab works. It’s so damned annoying.

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

#28

I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…

> Little things like maintaining scroll position in the page's navigation bar […] are only achievable with a SPA-based approach.

That’s not true. I wrote non-SPA web applications in the mid-aughts that maintained scroll position throughout server roundtrips, using JavaScript and storing the current scroll position in hidden fields upon submit. Even multiple scroll positions for nested panes. It also adjusted the saved scroll positions correctly when new elements were added to or removed from the page during the server roundtrip. This was encapsulated in a server-side HTML rendering framework.

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

#29
I'm still waiting for preact.js + htmx.org mashup. It probably exists somewhere, maybe https://docs.astro.build/en/concepts/islands/ or something.

I just want a quick way to throw some react hooks or web components into a dom element using a library that is less than 1,000 lines of code.

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

#30
post #10

I don't think that's a fair characterization of the "Start a New React Project" page [0]. Next.js is the first option listed and is described as a way to "create React apps of any size—from a mostly static blog to a complex dynamic application." This reads to me like "Next.js can do SPAs (like CRA) plus static sites and SSR". Next.js' site even says "The core of Next.js has been designed to enable starting as a stati…

"The core of Next.js has been designed to enable starting as a static site" is a little contradicted by the fact static export is considered an 'advanced feature' though. That said, I'm not sure why running `next export` is considered 'advanced'.

I'd say this is documentation organization "debt" – there's a bunch of "advanced" features that aren't that advanced. We're aware and fixing with the new docs -> https://beta.nextjs.org/
Post reply on HN