News for hackers. Stuff that matters.
Re:You don't need Next.js – Why we migrated from Next to React by TekMol on Wednesday January 01, 2025 @12:54PM (#42567697)
Almost all projects I see that use Next.js or React or Vue or any other heavy frontend framework/library would be better off just using a library to template things on the backend (For example Jinja). Sometimes a bit of client side rendering via EJS also makes sense.

Why use a framework at all?

Re:You don't need Next.js – Why we migrated from Next to React by ericyd on Wednesday January 01, 2025 @01:42PM (#42568079)
Do you feel this way about dashboard apps? The OP is about a dashboard app, and I think they are one example where the benefits of a SPA framework really do make sense. Curious if these fit into the "almost all" criteria you use.
Re:You don't need Next.js – Why we migrated from Next to React by TekMol on Wednesday January 01, 2025 @02:15PM (#42568422)
What makes a dashboard app particularly suited to not just use simple server side and/or client side rendering but a framework?
Re:You don't need Next.js – Why we migrated from Next to React by ericyd on Thursday January 02, 2025 @09:01AM (#42574468)
I think the main thing is that the downsides of SPA frameworks are significantly mitigated in a dashboard app.

Typically dashboards will be accessed on a desktop in an office setting with good internet, so initial load and asset size isn't a huge issue. Then you get benefits like client side routing which feels snappy, and live updating widgets is pretty simple. Of course it's a matter of opinion though.

Re:You don't need Next.js – Why we migrated from Next to React by TekMol on Thursday January 02, 2025 @11:06AM (#42575614)
I doubt that "client side routing" makes a site more snappy.

I think what you mean is that elements shared across pages (the header, the navigation bar etc) do not have to be sent again.

But those are very small anyhow. And you could bring the size down to zero by making them web components. Web components are cached along with the JS that defines them.

Re:You don't need Next.js – Why we migrated from Next to React by ericyd on Friday January 03, 2025 @02:03PM (#42588489)
Ah yes, thank you for the thorough corrections, you knew much more about this topic than me and correctly guessed exactly what I meant.
Re:You don't need Next.js – Why we migrated from Next to React by mzronek on Wednesday January 01, 2025 @02:20PM (#42568472)
Using server-side templating is another layer of complexity on top of your stack, that just glues together your output. These template languages are not easy to learn. Custom code for loops, escaping, template inheritance etc. Sometimes these are also hard to debug. The documentation of Jinja is huge.

Things get worse when you bring Javascript into the mix. You need to create Javascript code with your template engine without any Javascript toolchain.

Hard no to the string concat approach for me.

Re:You don't need Next.js – Why we migrated from Next to React by TekMol on Wednesday January 01, 2025 @02:38PM (#42568620)
How is React easier to learn and debug?
Re:You don't need Next.js – Why we migrated from Next to React by mzronek on Wednesday January 01, 2025 @03:22PM (#42568964)
With Full-Stack React you will use JSX to directly render HTML. Logic is done with Javascript, so you don't need to learn an additional language. There is also no mapping to Javascript and you can use the standard toolchain (for debugging).
Re:You don't need Next.js – Why we migrated from Next to React by TekMol on Thursday January 02, 2025 @03:30AM (#42572742)
How does JSX "directly" render to HTML? Have you compared the codebase of the React to EJS? EJS is much more direct. And the logic is also Javascript.

What do you mean by "no mapping to Javascript"? It is not as if React is part of the Browser API.

Re:You don't need Next.js – Why we migrated from Next to React by mzronek on Thursday January 02, 2025 @03:34AM (#42572757)
How do you get the server-side data to client-side Javascript? For example an array of strings or an object.