HN Explorer

40 comments

[ 3.3 ms ] story [ 90.4 ms ] thread
edgyquant
I like working with next but some of these changes in 13 kinda suck. Router especially, I inherited a codebase that didn't wrap a lot of functionality so hard changes to the way useRouter works from 12 to 13 means I can't reasonably upgrade anytime soon.
nickisnoble
Annoying that they hyped up this live keynote, and then it was all previous / pre-recorded announcements.

I figured with all the other releases, this keynote would show something really big — maybe they should've saved the databases reveal.

Instead we get "the thing we announced months ago is out of beta".

Vercel, you've been inconsiderate with my time.

leerob
The keynote was the summary of the entire week, which included the intro/outro, visual editing section, and the Next.js section which were new. A lot of folks were just tuning in today, versus the start of the week, but yeah, I can empathize with there being some parts that overlap. We'll be publishing more Next.js content here in the coming weeks around the new features as well.
yeskia
Yeah - "keynote" seemed to imply a big presentation. Not 15 minutes, most of which was literally already released video content. Now confused what is the point of "day 5" if the big reveal is done.
benatkin
> live keynote, and then it was all previous / pre-recorded announcements

Those appear to be mostly equivalent if you're watching it online.

If you don't feel they're almost equivalent, lockdown might have been easier. Personally I find online conferences disappointing and only watch if it's the same sort of content I would watch in a simple video.

0xblinq
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.

davnicwil
> 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?

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

davnicwil
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 :-)

0xblinq
As I replied above, all is neat and great until you have to debug something not working as expected.
steve_adams_86
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.

0xblinq
Until things fail or don’t go as expected and it’s imposible to know what the hell is going wrong. That’s the biggest problem with complexity, not just understanding it from the user point of view.
steve_adams_86
I agree. At the moment that’s what’s going wrong in countless react applications already though, largely due to things a compiler could catch automatically.

I’m not saying it’s perfect, but I expect the case you’re anticipating will be less common (though harder to resolve) than the ones which plague people today (whether they realize it does or not… The lack of awareness is one of the worst parts in my opinion, and why resolving it in the background seems ideal).

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

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

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

the_only_law
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.
0xblinq
Well, then it’s not JavaScript anymore? I love abstractions, but lately all the ones provided by next.js related to the server stuff are pretty leaky, and the compiler looks to me like it’s going to be the most leaky of them.

There’s also that thing about understanding your layer and the layer below to be able to debug. At this point “my layer” is complex enough that I can’t even think on debugging what’s going on with an error in a hook that was inserted by a compiler while SSRing a client side component which toggles a drop-down.

cranglin
I've been using the App Router beta for a few months on a pre-production project. No major complaints and I can see the vision. However, I (understandably) had a big issue with implementing Algolia Instant Search SSR into it. Fingers-crossed that 3rd party libraries launch support for it soon.
kylehotchkiss
A big benefit of the pages folder is the ability to statically generate content on build time and deploy, then getting the performance benefit of being a static site. Does/will the app folder allow for the same static generation capability? Seeing `Is the pages directory going away?` in the release notes to me seems like a hint that the pages directory may be going away.
MalseMattie
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...

reducesuffering
I've been using the app/ dir for a couple months now on a side project and I'm really liking how concisely I can build UI + backend + deployment. Vercel is getting some heat for it's pricing, but Next.js is really pushing forward what's possible for people without fiddling with DevOps, separate frontend deployment, separate backend deployment, etc. Coming from Django with Create React App, Django Rest Framework, on a VPS, is a relative nightmare compared to Next.

For example, in one small file, two functions, you have a reactive UI, styling (Tailwind), backend with database fetching, routing, and deployment handled:

async function getPostsFromDb() {

  return await prisma.posts.findMany();
}

export default async function PostsPage() {

  const posts= await getPostsFromDb();

  return (
    <main className="flex min-h-screen flex-col items-center justify-center">
          {posts.map((post) => {
            return (
              <GradientCard
                key={post.name}
                title={post.name}
              />
            );
          })}
    </main>
  );
}
benatkin
Their pricing seems OK to me, the only issue I have is that you can't tell them just to shut it down if the bill goes past a certain limit.
CharlieDigital
> ...in one small file, two functions, you have a reactive UI, styling (Tailwind), backend with database fetching, routing, and deployment handled

Sounds like a recipe for spaghetti.

Other platforms have been here before (ASP.NET Web Forms comes to mind) and it always ends up bad.

Escapado
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 or a success code)? How does it figure out that the db import will not be bundled into the client? Because it is only used in the function with the "use server" directive? And finally: Can I call "use server" functions in a client component too? In case I want some extra state in there?

Maybe there is someone here who knows more!

sionarancsle
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.
pwnstar4ever
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.
c-hendricks
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.
shitlord
Are you using server side rendering? If so, did you end up writing a custom server, or are you monitoring your website some other way?

My team is developing a server-rendered nextjs app which is deployed on AWS. We haven't really configured it beyond the defaults, but nextjs seems to provide very little visibility into what's happening (e.g., no request logs).

If you could share any tips or lessons learned from operating a production nextjs app, it would be much appreciated.

poisonborz
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.
flashgordon
Sigh. I'm a huge fan of next. But am getting a bit worried. As a backend person, Next made it possible for me to build cool pages easily - especially as a static export to be served by my backend of choice. This whole push towards forcing an entire stack worries me. I personally am not building consumer apps so am ok with server side routing and/or spas and it feels like every new version the disapproving nod on "no outside backbends" is getting stronger. (As a services developer I personally don't find the ROI on the rest of the vercel ecosystem either but I can see why they need to sell the kitchen sink to justify that crazy valuation)
ivanakcheurov
Is “API first” principle obsolete nowadays? How can Server Actions allow other clients to use the same backend? That was the whole point of SPAs, mobile clients communicating only over REST/GraphQL so that you can add more clients/automation/consumers later. To do that properly, the endpoint needs to be secured and documented (Swagger or GraphiQL with autogeneration of client libraries in most languages).