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

161–170 of 225 posts

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

#161

Post by mmis1000 »

NerdiOrg wrote: post #90

I think the author is mistaken. You can build a PWA, SPA in Next.js and it's even easier than not using it. I feel like the author is just confused that they're not specifically focusing on SPA because whether anyone wants to admit or not, enterprise companies aren't asking for SPA, or mobile apps, they're asking for headless, static websites. It makes sense that React would respond to those market demands.

Yes, it's likely react recommend don't do it because to met feature set everyone expect to 'include by default' from bare `react` package today takes way too much effort.

Routing, styling, layout system, animation, data fetching, form validation, i18n, SSR(server side rendering), SSG(static site generation). More and more are expected today. And react by its default offer non of them. And neither react pick a default set that will work by default if you just add them. (Vue or Angular either promote a default set of these or include them by itself, that's a big different with react.)

And integration of library that do these also takes much more time than it used to be because the feature set grows. (Let alone debug why one of combinations didn't work)

Promoting a working default set (A.k.a frameworks) will likely minimize the hassle people need to fight with to get some react app up on the production.

Really, no employer cares about whether you use a react framework or do everything from scratch. If the website isn't online and do what they need. You simply does nothing.

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

#162

Post by never_inline »

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.

But only few comments contain nuance that I come to this site to read.

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

#163

Post by leerob »

eric-burel wrote: post #157
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

New docs are a work-in-progress here: https://beta.nextjs.org/docs/configuring/static-export

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

#164

Post by fooster »

devwastaken wrote: post #81
lastangryman wrote: post #78

Obligatory "front end is a mess" comment. I taught at a bootcamp for 6 months, it was a great experience but when we moved on to react after vanilla JS the amount of incidental complexity was a huge step up, even with create-react-app. Now they push people towards adding a server side framework at the same time, right off the bat? I think there's a real danger with new engineers entering the industry that they have n…

React is for Facebook problems. Facebook is not concerned with "new engineers" at this time, nor have they ever really. Big tech contributes the least to education and pays little in taxes.

React of course was free.

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

#165

Post by roflyear »

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…

> and no one can delete anything because you have no idea what it'll break.

This is a problem with GraphQL, but you can monitor if anyone is requesting that data.

Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc.

GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful.

It depends if you're in that situation or not, or what parts of your domain are in those situations.

I don't think "GraphQL everywhere" is sane.

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

#166

Post by phendrenad2 »

It sometimes seems like every web framework is run by people who see a minor problem and completely change their project to solve it. Flash back to 2014 when Rails made Turbolinks on by default, and broke everyone's SPAs. Flash back to Angular rewriting in Dart because "it's the future" (it wasn't). Flash back to React replacing the perfectly-fine functional components with hooks (because Vue did it).

And now React is throwing away its backend-agnosticism because they want to hold your hand and make sure you don't fail at SEO and blame React.

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

#167

Post by Dylan16807 »

mmis1000 wrote: post #159
Dylan16807 wrote: post #129

Earlier quoted context omitted.

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

"You can't do this old thing, except barely and with great difficulty" sounds like it's close to the opposite of "old is new" to me?

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

#168

Post by mmis1000 »

phendrenad2 wrote: post #166

It sometimes seems like every web framework is run by people who see a minor problem and completely change their project to solve it. Flash back to 2014 when Rails made Turbolinks on by default, and broke everyone's SPAs. Flash back to Angular rewriting in Dart because "it's the future" (it wasn't). Flash back to React replacing the perfectly-fine functional components with hooks (because Vue did it). And now React i…

> Flash back to React replacing the perfectly-fine functional components with hooks (because Vue did it).

I think the timeline went wrong. React did it first, vue did it latter.

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

#169

Post by fendy3002 »

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…

If we're talking about react framework (NextJs), then it's the KISS part. Everything is kept simple as react components. Single way to define styles / class, and single way to maintain components: react components.

Using MPA with htmx and only use react on occasional necessity seems better or optimized, but it comes with one limitation: sometimes it's hard to replicate the non-react component / styles in react. Using NextJs removes that limitation.

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

#170

Post by meotimdihia »

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.

I have 8 years of PHP experience. Let me explain to you. While you can build a static website with Apache Struts or PHP, you must add javascript if you want to build complex sites anyway, for example: Facebook, Twitter, Tiktok,... In the past, everyone used jQuery, but jQuery and ajax can't build complex sites. You will end up with too many Ajax + dynamic elements + bad practices and can't maintain them if you use jQuery.

Finally, you'll end up using React for easy to maintain. And you'll have to wait to load React + related packages => it is slow for initial render => and SSR solved the problem.

Also, you just need a single team to build a complex application while using React instead of backend + frontend as traditionally.

Post reply on HN