Live data from Hacker News

Next.js 13

nextjs.org

41–50 of 106 posts

Re: Next.js 13

#41

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.

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

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

Re: Next.js 13

#42
post #35

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

Re: Next.js 13

#43

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

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

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

Re: Next.js 13

#44

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

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

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.

Re: Next.js 13

#45

// "alt" is now required for improved accessibility I'm all for accessibility, but let us decide when to implement it.

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.

Re: Next.js 13

#46

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?

Re: Next.js 13

#47
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

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.

Re: Next.js 13

#48

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

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

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.

Re: Next.js 13

#49
post #17

Earlier quoted context omitted.

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

Re: Next.js 13

#50

Earlier quoted context omitted.

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

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.

Post reply on HN