4 ms·

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. Frank

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 3y ago
You could use Go with templates and htmx, no js needed :-)
- flashgordon 3y ago
  You know I wish I heard about htmx before I started next. Now I feel like another ecosystem to get started on :(
  - deleted 3y ago
    [deleted]
  - julianwachholz 3y ago
    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 3y ago
      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 3y ago
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 3y ago
  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 3y ago
    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.

c-cube 3y ago

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

flashgordon 3y ago
You know I wish I heard about htmx before I started next. Now I feel like another ecosystem to get started on :(
- deleted 3y ago
  [deleted]
- julianwachholz 3y ago
  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 3y ago
    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 3y ago

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 3y ago
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 3y ago
  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.