[scientaster2]

I've given server components with Next.js an honest try in my personal projects, and honestly, the pain of using them far outweighs the benefits.

I MUCH prefer the pattern of getServerSideProps seeding data on-page-load and working with it via context providers. The fact that data loaded in with server components cannot support reactivity of any kind means you have to litter your code with "use client" wrappers that take in their parent data as initial state, then introducing client reactivity on top.

That^ also means that any time you drop into "use client" you drop any SSR benefits anyway. I agree with a lot of this article that the transition feels forced, and I can't help but hope that Vercel commits to supporting pages style routing indefinitely.

Here's an example, the pattern makes it almost impossible to highlight a currently active route in a navbar. Literally a basic building block of web applications: https://github.com/vercel/next.js/issues/43704

[flashgordon]

Oh man as a non fe person this is so overwhelming. I just got the hang of page based routing in nextjs and I still feel like I am walking on eggshells. Frankly all I want is TO render a next/jsx page into a jinja style template that I can render with backend of choice (golang) while leaving some ajax loading on the page when needed. I don't need my entire application to be a single page (don't get me started on understanding routing). May be that's why I can't appreciate consumer apps.

[c-cube]

You could use Go with templates and htmx, no js needed :-)

[flashgordon]

You know I wish I heard about htmx before I started next. Now I feel like another ecosystem to get started on :(

[julianwachholz]

It's hardly an ecosystem, think of it more as a turbocharger for your backend. Your customers won't care if you chose one or the other anyway.

[flashgordon]

IL still have to "migrate" my existing apps no - sure I could use htmx for. Ew projects but I have so many inflight which is where I was wary of the change. Is there an easier way?

[8n4vidtmkvmk]

Fwiw I've been using react on the frontend and php on the backend for like 8 years now. It's a multi page app. It's fast. No issues. If you want to swap php for go it'd be just as easy.

[flashgordon]

Interesting. How do "break down" react to be multipage. With next atleast the folder based layout (and the [id] naming convention) I found helpful. Disclaimer I'm still a react noob.

[erhaetherth]

In webpack, if you use a simple dynamic `import()`, it will compile all the files that it might possibly match. Then in PHP I just pass down the name of the script I want to load plus a bit of server-side data and render it. You can fiddle with the webpack settings about how aggressively it will code split or re-use libs. I recommend throwing all the vendor/3rd party party stuff/rarely changing libs into a single package and set a long TTL. Then the first time a user visits it can download all that junk and from then on they only have to re-download the bits that you change. For me, I might change a few pages a week. For my day job, we deploy once a day, M-Th, so even then if a user visits 100 pages in a day, they only pay for the JS on the first click of the day, and only the parts that have changed for the most part.

[vbello]

Client component still get SSR benefits. They just happen to be included in your JS bundle. This makes sense in the context of your example – you do expect the active route link to change during a client-side navigation.

[fabian2k]

That's kind of a really "meh" thing if you develop web applications and not websites. The static parts aren't that large, and the app kinda useless until the dynamic parts are there. So that doesn't really justify additional effort.

[vbello]

What additional effort?