4 ms·

The general direction React (+ Next) is going worries me a bit at times. I might be too conservative, but I want my JS on the frontend and not hot loaded from t

The general direction React (+ Next) is going worries me a bit at times. I might be too conservative, but I want my JS on the frontend and not hot loaded from the server. For this reason I'm much more excited about Vite/Bun/Dino/etc. Also thank god for shit like Preact.

pjmlp 3y ago
What worries me are the partner agreements Vercel is making with several enterprise products, making Next.js the only official frontend stack for their products. With everything else being DIY integration, and lesser tooling.
- joduplessis 3y ago
  I think for me the saving grace is the pervasiveness of the React paradigm. Porting code from React to Preact (obvs), Vue3, Stencil or Solid is easy peasy because the patterns are the same. And thanks god for that. EDIT: Honestly a web components framework with 1-to-1 likeness in API would be first class. I'd jump immediately.
johnfn 3y ago
> I want my JS on the frontend and not hot loaded from the server I'm fascinated by this. Literally, in every other HN thread in existence, you find stadiums of people shouting that they hate slow-loading SPA pages, and that all the work should have been done on the server, as God intended. Only on the release of Next.js 14, of all things, do you find people saying that actually SPAs are great and SSR is a regression!
- BoorishBears 3y ago
  You're falling for the trap Vercel laid by having RSC co-opt the concept of SSR. People are complaining about server components and the machinery to enable them: but those are actually unrelated to SSR. Client components are rendered on the server. - SSR was the sane middleground that worked since Next.js 1.0: You generated some content, and the frontend had all the Javascript and used that content to give a snappier SEO friendly experience. Next then turned around and convinced everyone that this wasn't good enough, and you actually want to try and have the server take chunks out of the Javascript your frontend has so that a bunch of metrics that they inflated the performance of would improve.
  - cyral 3y ago
    What is wrong with that? I agree that Next 1.0-12.0 SSR was great. But, you were always shipping a ton of JS that may never be called for components that don't have any interaction. NextJS 13 now only ships what JS is needed.
    - BoorishBears 3y ago
      The framework is called React. As in Reacts. RSC is a standard that makes it so that, by default, a component will break your build if you try to react to state. It's not until you brand it with a "use client" directive, which doesn't opt out of SSR despite the intentionally deceptive name, does the literal basic tenant of React work again. The RFC literally states libraries should embed this directive to not break builds: that means Vercel managed to fund an effort that breaks the underlying value proposition of a decade old framework by default Absolute insanity.
      - cyral 3y ago
        The part about including "use client" by default is referring to component libraries. e.g. you don't want to import <ReactPagination/> and have it break because it uses useState. When writing your own components you can decide which need to be marked as client and which don't. I don't think NextJS is doing any harm by not magically including "use client" on your own files. I agree that it is confusing to be called "use client". Maybe "use interactive" would have been better, but regardless the "use client" directive is from React so I'm not sure why it's related to a complaint for NextJS.
        BoorishBears 3y ago
        I pointed out that the directive is for libraries, and stated the framework React is built on reactivity. The vast majority of the ecosystem is built on using state. Didn't realize I needed to put this together for you, but that means the vast majority of the ecosystem defaults to breaking your build. _ And frankly, I really have to question your understanding of the topic when you say things like "NextJS is doing any harm by not magically including "use client" on your own files" Vercel drove RSC home for Next.js. Shopify tried it (because eCommerce) the effort petered out, and then Next.js, needing a bullet in the chamber against Remix and Hydrogen went and dragged a half-baked concept antithetical to the underlying technology over the finish line. Next.js is still the only actual implementation of RSC: Remix tried it and wrote it off for very obvious reasons... since Vercel/Next.js got to write the framework side and the implementation, there are a massive number of gaps in the standard.
- joduplessis 3y ago
  > hate slow-loading SPA pages, and that all the work should have been done on the server I'm not disagreeing with this actually - but I've also never been a massive fan on SSR for React. In addition - NextJS goes further in inhibiting React functionality - for instance: useLayoutEffect doesn't work at all.
- hermitwriter 3y ago
  Underrated comment.
- oliwarner 3y ago
  What about SSG MPAs? Literally every other HN thread I see has at least handful of people pushing Astro.
- pjmlp 3y ago
  No, we only want JavaScript for the SPAs, nothing else. SSR has been doing just fine for the last 25 years, now we have to put up with Next.js, due to the ongoing partner agreements Vercel has been doing to push Next.js as the only framework in MACH products.
Scarbutt 3y ago
What does vite/bun/deno has to do with keeping JS on the frontend?
- joduplessis 3y ago
  They focus on the tooling and not pushing a "paradigm" like SRR. Maybe not the best examples I would admit.
  - itsjustjordan 3y ago
    That would be because their goal is tooling and not to be a framework? Bun is the worst example here cause it's literally now a runtime for Javascript! If rewriting all the Node APIs, directly executing TS files etc. isn't pushing a "paradigm" I don't know what is.

pjmlp 3y ago

What worries me are the partner agreements Vercel is making with several enterprise products, making Next.js the only official frontend stack for their products. With everything else being DIY integration, and lesser tooling.

joduplessis 3y ago
I think for me the saving grace is the pervasiveness of the React paradigm. Porting code from React to Preact (obvs), Vue3, Stencil or Solid is easy peasy because the patterns are the same. And thanks god for that. EDIT: Honestly a web components framework with 1-to-1 likeness in API would be first class. I'd jump immediately.

johnfn 3y ago

> I want my JS on the frontend and not hot loaded from the server I'm fascinated by this. Literally, in every other HN thread in existence, you find stadiums of people shouting that they hate slow-loading SPA pages, and that all the work should have been done on the server, as God intended. Only on the release of Next.js 14, of all things, do you find people saying that actually SPAs are great and SSR is a regression!

BoorishBears 3y ago
You're falling for the trap Vercel laid by having RSC co-opt the concept of SSR. People are complaining about server components and the machinery to enable them: but those are actually unrelated to SSR. Client components are rendered on the server. - SSR was the sane middleground that worked since Next.js 1.0: You generated some content, and the frontend had all the Javascript and used that content to give a snappier SEO friendly experience. Next then turned around and convinced everyone that this wasn't good enough, and you actually want to try and have the server take chunks out of the Javascript your frontend has so that a bunch of metrics that they inflated the performance of would improve.
- cyral 3y ago
  What is wrong with that? I agree that Next 1.0-12.0 SSR was great. But, you were always shipping a ton of JS that may never be called for components that don't have any interaction. NextJS 13 now only ships what JS is needed.
  - BoorishBears 3y ago
    The framework is called React. As in Reacts. RSC is a standard that makes it so that, by default, a component will break your build if you try to react to state. It's not until you brand it with a "use client" directive, which doesn't opt out of SSR despite the intentionally deceptive name, does the literal basic tenant of React work again. The RFC literally states libraries should embed this directive to not break builds: that means Vercel managed to fund an effort that breaks the underlying value proposition of a decade old framework by default Absolute insanity.
    - cyral 3y ago
      The part about including "use client" by default is referring to component libraries. e.g. you don't want to import <ReactPagination/> and have it break because it uses useState. When writing your own components you can decide which need to be marked as client and which don't. I don't think NextJS is doing any harm by not magically including "use client" on your own files. I agree that it is confusing to be called "use client". Maybe "use interactive" would have been better, but regardless the "use client" directive is from React so I'm not sure why it's related to a complaint for NextJS.
      - BoorishBears 3y ago
        I pointed out that the directive is for libraries, and stated the framework React is built on reactivity. The vast majority of the ecosystem is built on using state. Didn't realize I needed to put this together for you, but that means the vast majority of the ecosystem defaults to breaking your build. _ And frankly, I really have to question your understanding of the topic when you say things like "NextJS is doing any harm by not magically including "use client" on your own files" Vercel drove RSC home for Next.js. Shopify tried it (because eCommerce) the effort petered out, and then Next.js, needing a bullet in the chamber against Remix and Hydrogen went and dragged a half-baked concept antithetical to the underlying technology over the finish line. Next.js is still the only actual implementation of RSC: Remix tried it and wrote it off for very obvious reasons... since Vercel/Next.js got to write the framework side and the implementation, there are a massive number of gaps in the standard.
joduplessis 3y ago
> hate slow-loading SPA pages, and that all the work should have been done on the server I'm not disagreeing with this actually - but I've also never been a massive fan on SSR for React. In addition - NextJS goes further in inhibiting React functionality - for instance: useLayoutEffect doesn't work at all.
hermitwriter 3y ago
Underrated comment.
oliwarner 3y ago
What about SSG MPAs? Literally every other HN thread I see has at least handful of people pushing Astro.
pjmlp 3y ago
No, we only want JavaScript for the SPAs, nothing else. SSR has been doing just fine for the last 25 years, now we have to put up with Next.js, due to the ongoing partner agreements Vercel has been doing to push Next.js as the only framework in MACH products.

Scarbutt 3y ago

What does vite/bun/deno has to do with keeping JS on the frontend?

joduplessis 3y ago
They focus on the tooling and not pushing a "paradigm" like SRR. Maybe not the best examples I would admit.
- itsjustjordan 3y ago
  That would be because their goal is tooling and not to be a framework? Bun is the worst example here cause it's literally now a runtime for Javascript! If rewriting all the Node APIs, directly executing TS files etc. isn't pushing a "paradigm" I don't know what is.