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

201–210 of 225 posts

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

#201

Post by Jnr »

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…

You can do what you described with Next.js and latest React easily. In addition, it will also help with SSR where it makes sense for speed and performance.

Building site with Next.js makes it simple to get a good perceived performance, the framework handles it out of the box.

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

#202

Post by robertlagrant »

matijash wrote: post #101
leerob wrote: post #98

Earlier quoted context omitted.

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

I enjoy interviewing people who have full-stack engineer on their resume, as it means I can ask them about anything from HTML tags to CPU microcode, or from relational algebra to networking stacks, and they'll be able to give a good answer.

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

#203

Post by claytongulick »

roflyear wrote: post #186
claytongulick wrote: post #178

Earlier quoted context omitted.

> 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. Most sane REST-like implementations also support this, typically with query string modifiers like a "fields" param or similar. A lot of them also support deep relationships this way too.…

Well, yes, but not really. With GraphQL you can have one user: - Request the users, their IDs, and emails, and their post ids Or: - Request the user, tons of profile information about them, and the posts with all the info about the posts You'd have to implement all this filter stuff for REST - and at this point if you have a bunch of different queries, yeah GraphQL makes sense.

You should really check out modern REST APIs.

Again, as an example, Directus supports doing everything you just said over both REST and GraphQL.

There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever.

You may also want to take a look at HATEOAS and JSON:API and similar.

REST-like APIs have long had feature parity with GraphQL and also superior mechanisms for caching etc...

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

#204

Post by cush »

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…

React replaced class components with functional components and hooks. Class components were awful.

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

#205

Post by cush »

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…

React is still backend agnostic

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

#206

Post by cush »

CSDude wrote: post #150

All our application lives behind an authentication except login pages. I still cannot grasp how would I use Nextjs in only SPA mode. Not everything needs to be SSR, I don't want to spare resources, just want to deploy it to S3, put cloudfront infront of it, let 404 requests return index.html and I can use the URLs without #. SSR should not be a must the docs should reflect that. There is no way I'm paying Vercel 20$…

I never understood where the idea came from that if pages are authenticated, then SSR isn't needed. Maybe because people think the only benefit is SEO. The biggest benefit is performance. SSR is still great to have behind authenticated pages, to improve load times. eg multiple tabs, continuing sessions, etc. There are countless examples of sites that usr SSR + CSR + Auth - Netflix, Github...

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

#208

Post by roflyear »

claytongulick wrote: post #203
roflyear wrote: post #186

Earlier quoted context omitted.

Well, yes, but not really. With GraphQL you can have one user: - Request the users, their IDs, and emails, and their post ids Or: - Request the user, tons of profile information about them, and the posts with all the info about the posts You'd have to implement all this filter stuff for REST - and at this point if you have a bunch of different queries, yeah GraphQL makes sense.

You should really check out modern REST APIs. Again, as an example, Directus supports doing everything you just said over both REST and GraphQL. There are many others that do too, and lots of libraries out there to make it easy to add that capability to your own endpoints in Node or.net or whatever. You may also want to take a look at HATEOAS and JSON:API and similar. REST-like APIs have long had feature parity with…

Yeah just seems like a different interface than GraphQL, but it's basically the same thing as GraphQL. So at this point, is it just "we don't like GraphQL" or something?

I don't see the reason to have to homebrew this for most things when GraphQL has a fairly sane standard.

GraphQL is still over HTTP. You can actually even just use the concepts in the backend (and maybe Directus does??) and hide it from the user, if you think they have some aversion to POSTing JSON for a query.

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

#209

Post by tmpz22 »

freedomben wrote: post #179
klysm wrote: post #42

Earlier quoted context omitted.

The part about this that bothers me is it not being documented well is in vercels financial interest

This is what has made me hesitant to really invest deeply in Next.js. It's just too familiar where some open source project starts. Later it attempts to monetize. Some feature in open source makes it so new monetization thing (usually cloud functionality) isn't needed, so those feature(s) get downplayed, neglected, and eventually deprecated, often with self-fulfilled prophecy/declaration of "nobody is using those" (b…

And they've raised at least $313 MILLION! Where have we seen this story before?

[1]: https://www.crunchbase.com/organization/vercel

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

#210

Post by freedomben »

leerob wrote: post #181
freedomben wrote: post #179

Earlier quoted context omitted.

This is what has made me hesitant to really invest deeply in Next.js. It's just too familiar where some open source project starts. Later it attempts to monetize. Some feature in open source makes it so new monetization thing (usually cloud functionality) isn't needed, so those feature(s) get downplayed, neglected, and eventually deprecated, often with self-fulfilled prophecy/declaration of "nobody is using those" (b…

We've made quite a few improvements to the static export with the new App Router, including support Server Components, Route Handlers, i18n routes, and more. Definitely still being invested in. My comment about documentation debt is that the entire information architecture of the Next.js docs needed some work. It's being fixed and will be stable soon. You can read more about how to use Image Optimization with a stati…

Nice, thanks for the link. Those new docs do look great!

I wanted to note that I'm not asking you to build this, I'm more sharing my use-case in case it's helpful feedback.

What would really be amazing for me is a build-time image processing pipeline. Any images I use for the static site are already present in the repo (none are user-supplied or come from object storage, etc). Since all the image info is present at build/export time, it would be amazing if the image processing were done locally during the build and then the next/Image tags would instead of invoking server-side code, generate the static code necessary to reference the different versions (such as srcset, sizes, etc)[1]. There is at least one open source project to do that, but at least when I last tried it, it was essentially dead on the vine. I searched around but couldn't find any solutions, which was pretty disappointing. I did end up shipping the app and just manually pipelined those images and hacked out the tags instead of using the component, but if I had more than a handful in the site that wouldn't scale too well.

Anyway, thanks for what you've done with next.js! it's really an incredible project and you've been an important part of moving the web forward.

[1]: https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimed...

Post reply on HN