Live data from Hacker News

New React docs pretend SPAs don't exist anymore

wasp-lang.dev

101–110 of 225 posts

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

#101
post #98

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…

There are similarities to PHP – and I think that's a great thing! I like to think of Next.js as the best parts of PHP / Rails with the powerful UI engine of React. Especially with the new App Router, where you can fetch code inside components like `await db.query()` and soon easily insert/update/delete from the same file as well. https://beta.nextjs.org/docs/data-fetching/fundamentals

that's one thing I've been thinking about a lot lately and I think it is confusing for many - that both Next/Nuxt/Remix and Rails have a title of a "full stack" framework while they are pretty different in reality.

Next/Nuxt are coming from the frontend origins and are strongest there, while Rails/Django are coming from the backend and focus on db ORM / data model story via ActiveRecord etc.

I understand the etymology of terminology, but I think we'll probably come up with better names in the future. E.g. Remix briefly called themselves "center-stack" which I found interesting and think makes sense.

I'll keep investigating and probably whip up a blog post about it.

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

#102
post #80

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

Honestly, the signal is just to avoid whatever full-time JS developers are getting into.

Winner!

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

#103

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

Being too eager to dismiss a technology and move on is just as much of a bandwagon-jump as being too eager to adopt it in the first place. The Gartner Hype Cycle[1] has both a 'peak of inflated expectations' and a 'trough of disillusionment'. The thing a lot of tech cynics fail to spot is that both of them are wrong about the long term value of the technology . The 'plateau of productivity' awaits, where graphql, nos…

I have to agree. I ignored tailwindcss for far too long. Pry it from my cold dead fingers.

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

#104
post #80

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

Honestly, the signal is just to avoid whatever full-time JS developers are getting into.

Get ready to have a lot of trouble finding work as a js dev if you’re not into whatever full time js devs are getting into.

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

#105

Earlier quoted context omitted.

Fullstack react frameworks aren't purely SSR - they're isomorphic JS apps, which can render an initial page load serverside, then use clientside routing, suspense, serverside components, and clientside rehydration to progressively update the DOM without a full page refresh. They are basically delivered as SPAs, with an integrated, isomorphic backend-for-frontend service embedded in the origin server. They just don't…

Next.js can also do Gatsby-like static generation, but also update those generated pages if the content changes in the backend. They call it incremental static regeneration (ISR).

Yeah, there’s a ton of overlap between what different tools can do. Gatsby is just more centered on those usecases.

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

#106
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…

Makes you really wonder why they’re doing this to themselves. Use whatever is most suitable. I try to use as less JS as possible.

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

#107
Here's my realm: We have a react based "framework" that in the end is zipped up and delivered as a SCORM package to be embedded in a Learning Management System. We use React Router to manage navigation.

After a quick scan of the Next docs, all references to routing seem to tie back to server side which is a non starter, as the SCORM is standalone HTML/CSS/JS/Media - that we happen to embellish at run time with some api calls.

This is a case where the pure SPA with no server side is the only way to go; seems like a real pain to go against the default state of Next. Am I wrong and am just missing something? Again, been occasionally looking at next and the like over the past while, but never had time to really dig into into it.

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

#108

Here's my realm: We have a react based "framework" that in the end is zipped up and delivered as a SCORM package to be embedded in a Learning Management System. We use React Router to manage navigation. After a quick scan of the Next docs, all references to routing seem to tie back to server side which is a non starter, as the SCORM is standalone HTML/CSS/JS/Media - that we happen to embellish at run time with some a…

Do you have an example of the SCORM? I'd love to see how you've structured it? (What's your LMS that you use?)

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

#109
post #106
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…

Makes you really wonder why they’re doing this to themselves. Use whatever is most suitable. I try to use as less JS as possible.

What do you typically use?

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

#110
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.

This is not unusual for HN. I noticed that the bashing and praising Unix come in similar proportions.

If the publication criticises Unix, it's comment section lokks like Unix fans have the loudest voice. The other day, commenting on other publication, virtues of Unix have been forgotten, and the comment thread praises some alternative.

Post reply on HN