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

151–160 of 225 posts

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

#151

Post by naikus »

ralusek wrote: post #18

There are a myriad of reasons why I prefer SPA to server rendered content for most applications. The main exception is if I have a public facing, unauthenticated application that I need indexed, I'll go for SSR. Off the top of my head, here are benefits to SPA: - I can just serve a few static files from a CDN. Every user gets the same client. - Most requests made by the application are actually smaller. I'm just load…

Totally agree! Plus if you use PWA, you get some benefits of an installable apps (not on all platforms though) but the support is alright on iOS too (more features are supported than before) I built a small demo app with 3 views (each loading lazily when first requested or loading in background using service worker) with view transitions, back button and scroll position retention. (built for mobile devices but works on desktops too) https://stage-starter.netlify.app

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

#152

Post by cxr »

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…

> ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard.

Please say "NPM" (and not "JS") when that's what you're talking about.

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

#153

Post by noisem4ker »

deepsun wrote: post #146
meotimdihia wrote: post #144

Earlier quoted context omitted.

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.

To clarify: it's a CSR problem to solve, not Struts' (which, as you say, is not subject to).

To answer your original question in a pragmatic way: people used to JS tooling, libraries, frameworks obviously want to continue using these, not revert to Struts. Plus, modern tooling facilitates mixing SSR and CSR, and switching between them as needed.

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

#154

Post by pjmlp »

zarzavat wrote: post #147
Rauchg wrote: post #138

Earlier quoted context omitted.

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 poi…

Nope, you do a bit of DHTML to update the only section that matters.

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

#155

Post by pjmlp »

claytongulick wrote: post #143
eurasiantiger wrote: post #139

Earlier quoted context omitted.

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 d…

Did we? Hello gRPC, Web sockets and language specific SDKs for REST APIs, as no one actually uses REST as designed.

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

#156

Post by cooperadymas »

seandoe wrote: post #68
cooperadymas wrote: post #43

Earlier quoted context omitted.

Since when have SPAs figured out maintaining scroll position? That's not my experience at all.

What is going to change the scroll position on a state or "page" change? It's not that they figured it out, it's just the nature of a single page.

Er, lots apparently. Just now I was searching through posts on a Facebook event to find more details. I thought I finally found what I was looking for buried a few months deep and clicked it. It was the wrong item so I clicked back and Facebook scrolled me to the top of the event page again.

This is a common occurrence for me on Facebook on both mobile and desktop. It happens sometimes in Gmail too. I'm certain I could find a half dozen other examples given five minutes to go test.

Meanwhile HN happily preserves scroll position perfectly.

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

#157

Post by eric-burel »

bryik wrote: 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…

next export, the feature that produces a "true" SPA out of a Next.js app, has been under-developed for along time. However the very newest developments in Next 13 seems to fix that, making Next.js truly versatile

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

#158

Post by floydnoel »

dzogchen wrote: post #37

If you want the control and low overhead of Vite but don't want to implement everything a framework gives you, vite-plugin-ssr might be interesting for you. It is basically Next.js as a do-one-thing-well Vite plugin (its slogan). https://vite-plugin-ssr.com/

Thanks for sharing this! Comments like yours are why I love HN comments. Despite all the arguments and negativity, I managed to find a useful comment which is directly applicable to my current needs!

I have been trying out Vite on my latest small project and was wondering if I should enable pre-rendering or perhaps alter the build process. I have markdown files which form some pages, currently they are imported and this causes the *.md files to be fetched when navigating to that page. It's mostly fine but it wouldn't be the best for blog SEO. So thanks again for giving me another option to look at, it may be just the right thing!

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

#159

Post by mmis1000 »

Dylan16807 wrote: post #129
duncan-donuts wrote: post #97

Earlier quoted context omitted.

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…

Well, when I hear people complain about PHP it's not about the routing or the idea of server-side rendering.

The ancient php idea of mix data fetching and rendering instead of wait until everything done for least `TTFB`(Time to first byte) is still hard to do for a lot of js framework today. You generally need to add tons of hack to the framework so you can print your site header before fetch and print the article body completely. (Which a phper will ask you "why you don't just print it?").

React and vue has add limited streaming rendering support recently, but they are still very limited and you need to met some constraint to actually use it.

It's really something `old is new today`.

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

#160

Post by JeremyBanks »

zarzavat wrote: post #147
Rauchg wrote: post #138

Earlier quoted context omitted.

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 poi…

[dead]
Post reply on HN