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

61–70 of 106 posts

Re: Next.js 13

#61

Post by Joeri »

pastor_bob wrote: post #46
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

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

Re: Next.js 13

#62

Post by tills13 »

latchkey wrote: post #29
kolanos wrote: post #17

Earlier quoted context omitted.

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

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

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.

Re: Next.js 13

#63

Post by andrewingram »

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

Re: Next.js 13

#64

Post by nightski »

apozem wrote: post #53
AlmostAnyone wrote: post #14

Earlier quoted context omitted.

Sigh? I think the speed improvement is awesome .

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.

Re: Next.js 13

#65

Post by halfmatthalfcat »

nightski wrote: post #25
halfmatthalfcat wrote: post #21

Earlier quoted context omitted.

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.

Re: Next.js 13

#66

Post by randomguy0 »

latchkey wrote: post #51
lghh wrote: post #45

Earlier quoted context omitted.

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.

Re: Next.js 13

#67

Post by MaxLeiter »

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.

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

Re: Next.js 13

#68

Post by chrisco255 »

calvin wrote: post #13
latchkey wrote: post #10

// "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.

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.

Re: Next.js 13

#69

Post by jokethrowaway »

mmis1000 wrote: post #50
kyriakos wrote: post #48

Earlier quoted context omitted.

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

Re: Next.js 13

#70

Post by yboris »

nightski wrote: post #64
apozem wrote: post #53

Earlier quoted context omitted.

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.
Post reply on HN