Live data from Hacker News

Next.js 13.4

nextjs.org

21–30 of 42 posts

Re: Next.js 13.4

#21
post #4

It's astonishing how complex this has become. All the server component stuff is great technologically speaking and if you're using React, it's a very welcome thing as this will lead in the long term to less bloated applications for end users. But as a developer I just can't stand all the complexity and the magic going on. And now a React compiler is on its way too. This is just too much.

I actually see the React compiler plans as a net positive. It introduces complexity in the toolchain which seems bad, but should serve to eliminate a lot of development pains they've introduced over the years. If they get it right, I expect that the dev and user experience on the other side could be quite a bit better.

Automatic memoization, signals under the hood, eventually moving away from the VDOM — so much of what people have come to find cumbersome about React can be eliminated by a compilation step doing a lot of these things for us. It's a bit strange that so many React developers don't know when or why to utilize useCallback, useMemo, etc... but maybe it was a mistake to expose those and leave it to developers to know when to use them, given that in a declarative system it can be automatically determined where it would be beneficial or not.

I'd prefer to use something else with a more thoughtful design and implementation, but React is well-entrenched. I don't think we'll stop using it any time soon. I still like it, too. The frontend world has arguably had to deal with much worse problems than the complexity of React, and it's a well-worn path that's typically easy to traverse by now. So, net positive I hope.

Re: Next.js 13.4

#22

Really hyped about this! I can't wait to try it out and watching the CI build as we speak. I am curious however about a few points. From their examples in the blog post it's not clear what kind of payloads can be transfered when using server actions. Do they need to be serializable in a specific way? Can I transfer dates? Can they return something (in case I want to validate a form on the server and return an error o…

They are just POST requests to an under-the-hood generated API endpoint.. I don't understand the use-case of these. Makes form validation and basically any type of reactivity bad.

Re: Next.js 13.4

#23
post #18

Earlier quoted context omitted.

Yes, the app router allows for the same static generation.[0] It is the default rendering strategy, and the page only becomes "dynamic" (rendered at request time) if the page has a "dynamic function". (functions that use URL search params etc.) [0] https://nextjs.org/docs/app/building-your-application/render...

Further, you can statically export your application to HTML, CSS, and JS files and host without a server: https://nextjs.org/docs/app/building-your-application/deploy...

This is one of my favorite ways to build Next.js sites, and adding in Dynamic when needed is Next's superpower. Thanks for noting the the new app/ folder supports it!

Re: Next.js 13.4

#24
post #17

Earlier quoted context omitted.

> now a React compiler is on its way too I googled for this and couldn't find anything. Do you have any links that give more info about this?

There isn't much info out there yet, but this video is a small preview: https://youtu.be/lGEMwh32soc The latest update is mentioned in the March 2023 blog post: https://react.dev/blog/2023/03/22/react-labs-what-we-have-be...

Ah, interesting!

My tldr of this is it'll be a transform of easy to read idiomatic react code using hooks etc into more performant code that avoids unnecessary rerenders by statically analysing where optimisations like memoisation can be injected without changing behavior.

Pretty smart stuff but also, yeah, perhaps a bit of a black hole of complexity. I can immediately imagine issues with debugging or somehow relying on the side effects of spurious rerenders and that breaking things in the real world.

You'd hope code like this does not exist in the wild... and yet exist it does :-)

Re: Next.js 13.4

#25

After running Next.js in production for a few years I never want to touch it again. I haven't used Vercel, but hosting on AWS I had to patch configurations in dirty ways just to get it to run reliably. I suspect they "locked" things like node config behind the abstraction of Next.js to drive users to their platform where issues are "magically" solved.

Counterpoint, we deployed our first nextjs app on AWS last year and it's been very set-and-forget. Even with our hacky https in front of nextjs.

Re: Next.js 13.4

#26
We recently launched a rather complex multi-market B2B booking system for a larger company on it. I was afraid of possible backend limitations and the opinionated structure that often comes with such projects, but it was a complete bliss to be honest. It takes away SO MUCH of the boilerplate with setting up a modern web CRUD project. Community and utils like i18next and NextAuth are top notch as well. Things I might have missed like API middlewares were added in meanwhile. No wonder that it starts to become the standard React framework. Surprised about the negativity here.

Re: Next.js 13.4

#27
post #4

It's astonishing how complex this has become. All the server component stuff is great technologically speaking and if you're using React, it's a very welcome thing as this will lead in the long term to less bloated applications for end users. But as a developer I just can't stand all the complexity and the magic going on. And now a React compiler is on its way too. This is just too much.

> But as a developer I just can't stand all the complexity and the magic going o

It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago.

Re: Next.js 13.4

#28
post #27
post #4

It's astonishing how complex this has become. All the server component stuff is great technologically speaking and if you're using React, it's a very welcome thing as this will lead in the long term to less bloated applications for end users. But as a developer I just can't stand all the complexity and the magic going on. And now a React compiler is on its way too. This is just too much.

> But as a developer I just can't stand all the complexity and the magic going o It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago.

> It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago.

Some of us got into the field because of the curiosity of wanting to know how things worked and weren’t satisfied by vague, high level, abstract versions. I imagine this is why I’m so poor at math and physics though.

Re: Next.js 13.4

#29
post #27

Earlier quoted context omitted.

> But as a developer I just can't stand all the complexity and the magic going o It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago.

> It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago. Some of us got into the field because of the curiosity of wanting to know how things worked and weren’t satisfied by vague, high level, abstract versions. I imagine this is why I’m so poor at math and physics though.

There's nothing wrong with that, but physics and math are also about taking understanding, then building useful abstractions around it to deal with inherent complexity.

I find the "complexity bad and makes me sad" attitude around development to be almost paradoxical - our job is literally to abstract things. If you seek for complete understanding you'll never find it. There's always an abstraction underneath and one to build on top.

Re: Next.js 13.4

#30
post #29

Earlier quoted context omitted.

> It's compilers and abstractions all the way down, I don't get why people want to be able to hold the entire stack in their head at once. That ship sailed - decades ago. Some of us got into the field because of the curiosity of wanting to know how things worked and weren’t satisfied by vague, high level, abstract versions. I imagine this is why I’m so poor at math and physics though.

There's nothing wrong with that, but physics and math are also about taking understanding, then building useful abstractions around it to deal with inherent complexity. I find the "complexity bad and makes me sad" attitude around development to be almost paradoxical - our job is literally to abstract things. If you seek for complete understanding you'll never find it. There's always an abstraction underneath and one…

That’s fair, FWIW, I don’t hate abstractions, and often prefer them (recently had a project I switched form primarily C to primarily Erlang because the abstractions provided allowed an amazing level of expressiveness given my project), but I like having a idea of how my abstractions work and preferably where to look when they fail.
Post reply on HN