Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Next.js 13

nextjs.org

Post reply on HN
Print view View original

91–100 of 106 posts

Re: Next.js 13

#91

Post by neurostimulant »

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.

Re: Next.js 13

#92

Post by pull_my_finger »

nightski wrote: post #9
dsissitka wrote: post #5

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.

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.

Re: Next.js 13

#93

Post by Vinnl »

andrewingram wrote: post #83
Vinnl wrote: post #57

Earlier quoted context omitted.

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!

Re: Next.js 13

#94

Post by javiercr »

neurostimulant wrote: post #91

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 d…

API routes are not supported yet for /app

Re: Next.js 13

#95

Post by Vinnl »

lghh wrote: post #74
randomguy0 wrote: post #66

Earlier quoted context omitted.

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.

Re: Next.js 13

#96

Post by Vinnl »

latchkey wrote: post #59
joshribakoff wrote: post #58

Earlier quoted context omitted.

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 element from their element.

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.

Re: Next.js 13

#97

Post by Vinnl »

chrisco255 wrote: post #68
calvin wrote: post #13

Earlier quoted context omitted.

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

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.

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

Re: Next.js 13

#98

Post by Vinnl »

googlryas wrote: post #72
abujazar wrote: post #49

Earlier quoted context omitted.

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.

Re: Next.js 13

#99

Post by jfoster »

pull_my_finger wrote: post #92
nightski wrote: post #9

Earlier quoted context omitted.

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

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…

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.

Re: Next.js 13

#100

Post by googlryas »

Vinnl wrote: post #98
googlryas wrote: post #72

Earlier quoted context omitted.

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.

Post reply on HN