Next.js 13 | Hacker News Reader

Next.js 13

nextjs.org

229 pointsjacobwg100 comments

Open articleView on HN

Edit: There's some more discussion about Turbopack at https://news.ycombinator.com/item?id=33333695.

Looks like they launched a webpack alternative called Turbopack today:

> Next.js 13 includes Turbopack, the new Rust-based successor to Webpack.

https://vercel.com/blog/turbopack

https://turbo.build/pack

Sigh another one? I thought Vite was the new thing.

Sigh? I think the speed improvement is awesome.

It is awesome to see so much innovation, but it can be exhausting to keep up.

I'm quite alright with new tooling every six months when the new thing is orders of magnitude faster. If people want to compete to make my job as a frontend dev easier and faster, that is just fine.

Ideally we could learn how to make the existing tools better/faster and create software that can evolve rather than re-writing everything from scratch every six months.

I suspect at some point we hit the limit of the language performance. I can't imagine JavaScript beating Rust when both are written well.

There was many years before people started trying to replace Webpack.

True but webpack itself had a ton of churn and made practically no effort to maintain backwards compatibility causing a ton of work with each major update.

Hmm, I am using it since v2 and I disagree, it was not so bad. I saw a lot of people had overcomplicated configs that could be simplified a lot, I guess those had some problems upgrading... But mine never had much problems (and not just because my needs were simple...), I just removed some options when going to v4 and that's about it.

I think the issue starts when xyz new tool requires you to write code specific to that thing, which is something I avoid as much as possible. IMO they should strive to stay out of the way as much as possible and just bundle/optimize/tree-shake and not worry about extending JS as a language or nodejs as a runtime or doubling as a build tool or a filewatcher or a development server etc etc (see the UNIX philosophy 'do one thing well'), even at the expense of less optimal/fast builds. As soon as you start doing stuff like importing your images into your javascript so your bundler can do compiler tricks, you're painting yourself into the corner.

One recent offering I enjoyed working with was esbuild, as I could use it's CLI as part of my existing build system incrementally instead of planning my whole system around it.

There's a few facets to consider:

1. Does code written a particular way?

2. Does it need to be configured?

3. Does it conflict with other tooling?

4. Does it have limitations that are too restrictive?

5. Does it cause bugs/issues that are difficult to resolve?

The ideal tool just does its thing, doesn't need any code written or configuration, works no matter what other tooling you're using, has no limitations, and will never itself cause a bug.

That might not be realistic to do 100%, but I think it's what all tools should be aiming for.

Spent the last few months migrating to Vite. The Javascript ecosystem is exhausting and exhilarating all at the same time

No telling how many sides the next iteration of the wheel may have but one thing's for certain: That one will be the ultimate version.

Well at least Vite does not lock you in the Next.js eco-system, so it's something ¯\_(ツ)_/¯.

Overall the community is starting to embrace better languages for tooling, primarily Rust with some Go and Zig sprinkled in. Eventually I think we will hit a point where there will be a defacto dev tool that can take a web app and package it however you want, deploy it wherever you want, and do it very quickly. Some would argue those exist now, but until it can be done literally everywhere, painlessly, I would contend we aren't there yet. It's probably more likely something like WASM/WASI takes over before then honestly.

What I hate about javascript fatigue is that there's never enough time for something to mature before it gets replaced. Documentation always covers the basic scenarios and never any edge cases. Sooner or later you end up trying to find a solution in a github issue 20 pages down.

I think webpack is a special exception. It somehow revised the whole 5 major version and still don't get a proper plugin development document at all, not even basic one. You don't even have a flow graph that tells you events happen in which order. Everyone either Google and copy paste random example or reading the source by themselves.

It always amazed me that such a big project can just live without docs.

that's the only thing agile people got from the manifesto

an excuse not to write docs, ever

it's endemic in the majority of companies I've seen in the last 10 years

hopefully tooling (eg. docs.rs mostly automatically generated and pleasant to use) will help in the long term

>On an application with 3,000 modules, Turbopack takes 1.8 seconds to boot up, while Vite takes 11.4 seconds.

How many apps are dealing with 3,000+ modules?

At the pace the javascript ecosystem is going, by next year it will be almost all of them. Create react app for a new default project pulls in 1400 packages, 300 MB in size, just to put a hello world page on a screen. That nobody thinks this is absolutely bonkers drives me absolutely bonkers.

Plenty of people think it's bonkers and the informed frontend perspective is to not use CRA anymore: https://www.youtube.com/watch?v=7m14f0ZzMyY

Informed developers don't use CRA anymore.

Awesome release. As an early adopter of Next.js and seeing it evolve over the years, it's been one of the most consistent frameworks that continues to get better and "just works".

Is it perfect. No. But it's very close for most of my use cases.

Turbopack (comes with Next.js 13) seems AMAZING!

> Turbopack updates 10x faster than Vite and 700x faster than Webpack

> Turbopack is an incremental bundler optimized for JavaScript and TypeScript, written in Rust by the creators of Webpack and Next.js at Vercel.

I'm pleased to see cumulative layout shift (re self-hosted fonts) advertised as a feature, this is the right kind of user-centric development, indeed the small details like these go a long way in improving user experience.

  // "alt" is now required for improved accessibility

I'm all for accessibility, but let us decide when to implement it.

You should still be able to use alt="" to indicate that it is "decorative" and not meaningful imagery for a visually-impaired user.

That's like the difference between null and undefined.

If you have no alt attribute, then screen readers read the URL!

Empty strings are the way to go for decorative images

What if I have an app that no screen reader will ever read?

Then write your own component that extends and removes the requirement. Until then, web tooling is better off explicitly acknowledging that accessibility is an explicit goal.

Alt is a required attribute of the <img> tag, so requiring it is just basic validation. C code won't compile if you omit the semicolon after statements, either.

Instead use the ARIA tag role="presentation": https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... to indicate when an element has no semantic meaning and is purely visual.

Which of these tags you should use and what they should contain is entirely context dependant.

That said, the use of empty alt tags is generally discouraged and not even allowed together with the ARIA presentation role in most cases.

This decision of theirs will steer developers towards non-compliant/asemantic code. It's really stupid.

https://html.spec.whatwg.org/multipage/images.html#alt

https://w3c.github.io/aria/#presentation

https://w3c.github.io/aria-practices/#presentation_role

That second link from W3C gives this very example:

https://w3c.github.io/aria/#example-13

"In the following code sample, the containing img and is appropriately labeled by the caption paragraph. In this example the img element can be marked as presentation because the role and the text alternatives are provided by the containing element."

So empty alt tags are not discouraged.

Hence the generally discouraged - as in not recommended in the majority of situations but exceptions exist (such as the one you provided).

As I read that page, role="presentation" is intended to remove the natural semantics of a tag (e.g. have an <h2> be treated as a <div>), rather than to tell the user that there is nothing relevant to them in the given tag?

"presentation" is the default role for an <img> element when the "alt" attribute is an empty string.

> I'm all for accessibility, but let us decide when to implement it.

Which usually means never.

Which just means codebases will be littered with alt="" for no reason.

It's often better to specify alt="" than not at all, because screen readers may use the filename instead if there's no alt attribute.

That's actually a detriment then, if the "fix" for no a11y makes screen readers think they should use no alt text, instead of some possibly meaningful alternate.

The fix for no a11y is to add a11y. In many cases (i.e. the "often" specified by GP), images contain no extra information, in which case you should indicate that by adding alt="". In other cases, you should add an actual description.

I meant the "fix" of people not caring about a11y(which is why I put it in quotes) and just trying to get their code to compile.

If people don't care about a11y, they aren't going to start devoting time to it because a tool puts a slight roadblock in their way - they're just going to try to bypass the tool.

Sure, but it doesn't really matter what you do for those people; their projects will be inaccessible anyway. For the rest of us, it's a useful reminder.

Which is ok too. It is far better than encouraging people to write alt="" or alt="asdf".

See also (naming things): https://twitter.com/secretGeek/status/7269997868

They are encouraging people to write alt text, not encouraging people to write alt="".

That's like saying "Typescript just encourages people to make everything `any` instead of defining types. It's a useless addition over JS." Sure, you _could_, but most actually use the actual tool.

alt="" has a specific and intentional meaning which is _always_ better for accessibility than an unset alt

It's 6 extra characters, you'll survive.

I'd rather spend a literal 6-character burden (alt="") to put an empty string in my little hobby projects than live in a world where non-hobby projects can skip adding alt.

It should be very clear by just looking around on the internet that, when given the choice, accessibility will take a back seat.

I'm curious why you think that forcing people to write alt="" is going to improve accessibility?

Because that’s how screen readers know the image is decorative. It literally is/improves accessibility.

Additionally, the developer is more likely to actually write alt text when it's not decorative.

Although I must admit, I've also seen such rules leading to developers writing alt text for decorative images, and I'm not sure if that's much better.

The HTML spec says it is required, even if you don’t think it should be required it is. https://html.spec.whatwg.org/multipage/images.html#alt

NextJS could just create alt="" when rendering the HTML <img> element from their <Image> element.

That could harm the experience for assistive tech users more than no alt tag

I think the compromise would be an optional build parameter that allows this functionality.

Frameworks shouldn't be changing the content you coded on the sly, that's just asking for trouble. Imagine trying to debug that.

Next.js can't determine what the value of the alt tag should be, i.e. whether it should actually be empty. If it would do this, it would actually tell screen reader users that the image is decorative, instead of warning them that there might be information conveyed in the image that the developer forgot to label.

I find the data fetching example extremely confusing…

1. Where does this "use" comes from ? It is not present in the official React API reference : https://reactjs.org/docs/react-api.html

2. It says that the value is not serialized, but what if Page is rendered client side and I want getData to always be executed server side (for example, it may contains secret API key, or make a database call) ?

3. getData is async, so what happens to name if the promise is not yet resolved ?

it's a new "hook", https://vived.io/new-hook-is-coming-to-react-frontend-weekly... https://github.com/reactjs/rfcs/pull/229 contain some discussion

But `use` is still just in the RFC phase, right? How can Next.js already be (committing to) using it?

They’re essentially both in beta, but for something like this, React needs a proving ground - hence it’s being used in Next’s beta functionality

Oh! I'd mis-parsed the heading sizes, didn't realise the "data fetching" heading was underneath the "app/ directory (beta)" heading, and thus that they were both in beta. Thanks!

The next-gen bundler rewrites are getting insane, just as things were consolidating in the other parts of JS. We now have:

- EsBuild

- SWC (also written by someone who works at Vercel)

- TurboPack

- Vite (rollup)

- Parcel

- Rome

I've noticed in the javascript ecosystem there is much less convergence than in other languages. Everyone wants a flag in the ground.

That's a good thing? Keeps things fresh and keeps established "norms" unable to stay complacent.

Actually it tells me that the javascript ecosystem fails to build software that can adapt to change. The culture is to throw everything out and start fresh every time they want to do something different. It's terrible engineering.

Thankfully that's just your opinion. I appreciate all the innovation and experimentation that's happening. Nobody is dictating you or anyone else use these tools.

My opinion based on decades of experience in web development. I've been through this churn dozens of times, it is tiring. The other ecosystems I work with do not work this way and yet they still innovate a lot.

It's not an opinion. It's common sense. Do you think Rust or Swift would exist if LLVM would have stopped its development long ago in favour of <insert new exiting tool>?

Not only in software, if we keep renewing rather than perfecting software, we won't go anywhere.

This will consolidate again, and these tools are not all equal. They cover different parts of the whole thing. There is clearly a desire for faster compilation and bundling, and various groups and people are trying out different approaches now.

Right now you can stay with Webpack or whatever you were using already, or you can try one of the new shiny things if you want to. But if you want to avoid the churn, it's probably time to just wait for a bit until things settle down.

Beauty of nextjs though is that you don't have to worry about it unless you want to go under the hood. My quality of life has improved tremendously since I stopped having to deal with webpack config files, and upgrading to the hottest bundler on the street couldn't be lower on my list of priorities.

Yeah exactly, Next.js is the consolidation. If they can make things faster behind the scenes without my having to make changes, that's great.

Vite is built on esbuild and Rollup, but there’s nothing tying it to either. In theory with the evolving ecosystem, it can swap whatever it wants to use internally and still provide a consistent experience.

It's a bigger ecosystem than all others, and there's no batteries included in web development, so it necessitates the need for tooling to be built from scratch.

everyone believes they can write some JS and call themselves developer

bigger audience, bigger chance to make it big selling crap to developers so more personalities try to build an audience by making OSS

> With Server Components and nested layouts in Next.js, you're able instantly render parts of the page that do not specifically require data, and show a loading state for parts of the page that are fetching data. With this approach, the user does not have to wait for the entire page to load before they can start interacting with it.

Crazy huge user win.

I am a little nervous how much stuff Next does in the middle, how thoroughly it links front & back end. Streaming a page with chunks missing then streaming sections as they resolve is pretty advanced magic. Amazing DX experience but I also can think back to asp.net & remember huge viewstate blobs & utterly magic middle-layers, and those were powerful too, but impregnible bizarre systems to the developer & that wasnt good.

Next keeps hitting reaply really nice sweet spots & consolidates & tackles so many problems, and my trepidation is small at this point, but this is really redefining the page a lot, & I feel like I really want some deep dives on the technics involved here, want to know the magic is somewhat accessible & coherent, for fellow would be meddlers.

I started my journey with Vue, then Nuxt (of course),then switched to React and last year started to use Nextjs. So far I have no complains (at least no big ones).

With new frameworks poping out (qwik, remix, fresh, etc...), it's getting really interesting and tiresome at the same time.

We're migrating all our platforms to React/Next and we couldn't be happier. Is it perfect? Nothing really is. Next is good enough, the community is engaged, the ecosystem is big, and the industry is basically dominated by react (giving react devs some sort of peace of mind when looking or switching jobs).

Sometimes, you have to pick a piece of tech and roll with it as long as the tech keeps improving and the community improves alongside it. Nextjs is currently doing it.

I'm curious why you decided to migrate from Vue to React.

Next[js] Conf is live right now at https://nextjs.org/conf

Might change later but if you don't want to give them an email address here's a direct link:

https://www.youtube.com/watch?v=NiknNI_0J48

q@q.q works.

+ on the website you can see all the incoming guests

Not knowing anything about the new /app directory support, I'm able to migrate my static landing page in about two hours. The resulting page is definitely smaller and load faster than the previous version. Now I'm consistently getting 100 on page speed insight (mobile) while previously it's hovering around 98-99.

The documentation for the new /app directory support is not complete though. API routes seems to be not documented yet (or is it not implemented yet?) so I haven't ported mine and leave it on the /pages/api directory for now.

API routes are not supported yet for /app

Their tutorial is incredible, everyone should take a lesson from Vercel on this: https://nextjs.org/learn/foundations/from-react-to-nextjs/ge...

Tell me:

1. What I need to know to understand this documentation

2. The before state (plain React.js)

3. The after state (Next.js)

I'm fucking sold, I'm going to use Next.js just based on how well written this documentation is.

I'm totally biased here but I've been super impressed with the documentation culture at Vercel. Definitely a high high priority internally.

Their tutorial is fine, but personally I'd much rather just see a GitHub repo of a project that covers all the basics (eg. a CRUD app).

Why not both: https://github.com/vercel/next.js/tree/canary/examples

Their tutorial yields that and gives you a link to the final product on the first step

> I'm going to use Next.js just based on how well written this documentation is.

I Understand the euphoria, but this is a pretty bad take.

Is it? Give me an example of a poorly documented yet wildly popular and good software tool built in the last 10 years (No Stockholm Syndrome for old tools allowed!).

The opposite would be a more interesting example to argue against the original statement.

I’ve been trying out the pre-release version for the last couple of months, just published a quick brain dump of my thoughts related to the major changes (router, server components, etc) as they stand today.

I’ve already heard from the team about the plan for my last concern, and it seems viable.

https://andrewingram.net/posts/thoughts-on-next-13-react-18-...

Surprisingly, my compile times with Next.js 12.3 have been really really awful. A simple CSS change takes almost 10 seconds to compile and I'd love to know why.

My app isn't complex, it uses Recoil, Tailwind and that's it. Compile times were better in v11 in my experience.

What i am still missing is the possibility to deploy next.js to a serverless platform where files have to be stored in S3 or Google Cloud Storage. Had anybody success to get it working, without loosing ISR functionality?

Where are you struggling? Just `next build && next export` and your static site is compiled to the /out folder which you can subsequently push to S3 or Google Cloud Storage.

No idea what ISR stands for.

Incremental Static Regeneration. Next.js allows you to create or update static pages after you’ve built your site but stores them on the filesystem, which in a serverless environment does not exist.

All these changes look great. I'm especially glad that next/link always renders an <a> now, if I read it right it seems to solve the "create a dummy span around some imported component" issue.

Super excited about Turbopack! Thank you for moving the Web forward so much.

Reply on news.ycombinator.com