Next.js 11.1(nextjs.org)
nextjs.org
Next.js 11.1
https://nextjs.org/blog/next-11-1
31 comments
Because they "strongly believe Rust is the future of JS tooling." I'd agree honestly, I like Rust a lot more than Go. But that's a debate for another time.
https://news.ycombinator.com/item?id=28157256
https://news.ycombinator.com/item?id=28157256
My cursory knowledge is Go is best for distributed services and things that heavily involve the network.
Rust is better for memory based operations due to its safety and speed.
Rust is better for memory based operations due to its safety and speed.
But that's just total BS unless they are directly writing rust code.
If you are using tools like swc or esbuild, then you need to evaluate tool itself, not the language it was written in.
If you are using tools like swc or esbuild, then you need to evaluate tool itself, not the language it was written in.
They hired one of the SWC devs, so they are directly writing rust code.
Of course you should care about the language the tool was written in. As another example, 1Password is redoing their mac app in electron. Many are upset about this and concerned it will lead to worse performance. Solely because of the technology being used.
Similarly here, evaluating esbuild vs swc inherently involves comparing their capabilities, benefits, potential etc. A lot of that is informed by the language its written in.
Similarly here, evaluating esbuild vs swc inherently involves comparing their capabilities, benefits, potential etc. A lot of that is informed by the language its written in.
Next.js is getting better every day!
I'm a fan of the improvements made to next/image!
Hm, does the switch to SWC impact babel config support?
With 11.1, SWC support is still experimental (we haven't enabled it by default). In the next release when this becomes stable (and replaces Babel), we will provide more guidance and examples. If you have an existing custom Babel configuration, you'll still be able to de-optimize and "eject" from SWC and continue using Babel. This ensures we don't break existing applications and make it easier to incrementally adopt these new performance improvements.
"these changes in front-end frameworks makes everything slower" everyone starts screaming
"these changes in front-end frameworks makes everything bonkers faster" chirps
kudos to the Next team doing the good work
"these changes in front-end frameworks makes everything bonkers faster" chirps
kudos to the Next team doing the good work
Thank you! We strongly believe Rust is the future of JS tooling[1] and will be investing heavily in this ecosystem. It's been in the works for awhile[2] and I'm happy to start seeing these changes land in Next.js. `npm i next@latest` for perf improvements every time is the goal!
[1]: https://twitter.com/rauchg/status/1417861178290851842
[2]: https://twitter.com/rauchg/status/979525321882984448
[1]: https://twitter.com/rauchg/status/1417861178290851842
[2]: https://twitter.com/rauchg/status/979525321882984448
So is SWC integrated in 11.1? Or is it still _being_ integrated? As in, will I see the performance improvements from SWC by upgrading, or is this just the groundwork for it to be more widely integrated?
Still being integrated - the next release will have a flag you can turn on.
Hadn’t heard of SWC, only esbuild. Why did your team choose SWC/rust over esbuild/go? This: https://mobile.twitter.com/rauchg/status/979525321882984448 ?
Thanks a lot for Next.js and the Vercel platform. Both are great.
Thanks a lot for Next.js and the Vercel platform. Both are great.
We chose SWC over esbuild for a few reasons:
1. SWC is designed to be extensible. We can use it as a crate with no forks! [1]
2. We love the Rust ecosystem. Stellar community & WASM support. Excellent long-term performance prospects (like total control over memory management).
[1]: https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085ceb...
1. SWC is designed to be extensible. We can use it as a crate with no forks! [1]
2. We love the Rust ecosystem. Stellar community & WASM support. Excellent long-term performance prospects (like total control over memory management).
[1]: https://github.com/padmaia/next.js/blob/cf1d081c5b2f55085ceb...
My thoughts exactly. Was surprised this wasn’t on the homepage.
this take is singe-ing but I think it ellucidates a truth that the vast arrayed pissed off scared vocal anti-web-progress retrogressionist amassing un-silent minorities are so pissy about:
we have only just started getting good at the web. the web is still ripe, still, exciting, still heavily heavily optimizable & usable for the cuttingest of cutting edgest computing & computing experiences.
look: the web is often poorly utilized. the folks making money have been doing so at great cost to the user for a long time, on one hand, and the tech itself is still radically underexplored, under tried, under utilized, and most companies use cookie cutter massified software development tools that radically constrain what systems they might produce. they refuse to think.
but some people do think. they have some good thoughts. they reconsider what these platforms might be used to enable, rethink how to assemble experiences from this base matter, from these first toolkits. kudos to everyone still engaged with working the web towards better: we have so much to find out, so much to try, to tune, to evolve along, and we need diverse spirit of all kinds of efforts trying for better. that's why the web keeps winning. because the tool kit can, because the web is low level, because it permits endless platform & architectural engineering atop it's simple & long long long enduring media form.
we have only just started getting good at the web. the web is still ripe, still, exciting, still heavily heavily optimizable & usable for the cuttingest of cutting edgest computing & computing experiences.
look: the web is often poorly utilized. the folks making money have been doing so at great cost to the user for a long time, on one hand, and the tech itself is still radically underexplored, under tried, under utilized, and most companies use cookie cutter massified software development tools that radically constrain what systems they might produce. they refuse to think.
but some people do think. they have some good thoughts. they reconsider what these platforms might be used to enable, rethink how to assemble experiences from this base matter, from these first toolkits. kudos to everyone still engaged with working the web towards better: we have so much to find out, so much to try, to tune, to evolve along, and we need diverse spirit of all kinds of efforts trying for better. that's why the web keeps winning. because the tool kit can, because the web is low level, because it permits endless platform & architectural engineering atop it's simple & long long long enduring media form.
that said 80% of what's described here is a dev experience modernization, if limited real value to the user experience. oops. over jumping my claims a bit.
who gives a crap about esm? you need to have it. bundlers that arent shitty bloated slow beasts? good yes, but to me not a tuallyuch of a difference h my hot reload was under 2s before, usually I didn't even bother & suffered a full 5s progressive recompile. shaving those seconds off is a distraction from architectural redefinition of the core constituating elements of web which is the real ongoing game afoot. value? oh sure, by eliminating inefficiency, but not fundamentally progressive: a way to do more faster.
who gives a crap about esm? you need to have it. bundlers that arent shitty bloated slow beasts? good yes, but to me not a tuallyuch of a difference h my hot reload was under 2s before, usually I didn't even bother & suffered a full 5s progressive recompile. shaving those seconds off is a distraction from architectural redefinition of the core constituating elements of web which is the real ongoing game afoot. value? oh sure, by eliminating inefficiency, but not fundamentally progressive: a way to do more faster.
Noob question but when they say ES Modules support will be integrated does that mean for the server side stuff / serverless functions?
I'm really not a fan of the next/image component at all. It's so unintuitive to use.
Hey, sorry about this. What could we do better?
Maybe this is already fixed in 11.1, but static site generation seemed broken for me with create next app. I had to go in and remove usage of this feature before static build will work.
Are you using `next build`? It should work as expected when `create-next-app`. If not, then would you mind opening up a reproducible issue?
Will do!
The issue is with export, build works https://nextjs.org/docs/advanced-features/static-html-export
The issue is with export, build works https://nextjs.org/docs/advanced-features/static-html-export
Not OP but since you're asking: next/image was unusable last time I tried it. I ended up using next-optimized-images, which didn't feel a lot better but was at least usable for my case. I wanted to compile the images at build time instead.
While I'm at it, next/link also had some bonkers defaults such as the link prefetching on view instead of on hover (neither of which could be disabled, either…).
I hope all that is getting some attention soon. If I can offer some frank feedback: I've had an overall positive experience with the framework, but there have been clear quality issues here and there and I'm always concerned when I see a large feature churn without a high amount of attention being put into existing bugs.
I filed three bugs while porting an app over half a year ago (https://github.com/vercel/next.js/issues/20984, https://github.com/vercel/next.js/issues/21474, https://github.com/vercel/next.js/issues/21461). None of them have even been acknowledged by a dev yet. (That last one was a doozy, too; I'm not actually sure it's a nextjs bug)
While I'm at it, next/link also had some bonkers defaults such as the link prefetching on view instead of on hover (neither of which could be disabled, either…).
I hope all that is getting some attention soon. If I can offer some frank feedback: I've had an overall positive experience with the framework, but there have been clear quality issues here and there and I'm always concerned when I see a large feature churn without a high amount of attention being put into existing bugs.
I filed three bugs while porting an app over half a year ago (https://github.com/vercel/next.js/issues/20984, https://github.com/vercel/next.js/issues/21474, https://github.com/vercel/next.js/issues/21461). None of them have even been acknowledged by a dev yet. (That last one was a doozy, too; I'm not actually sure it's a nextjs bug)
Interested in what’s the issue here, next.js’s image component has been amazing and a breeze for me so far.
I personally would love to see better i18n routing in nextjs. Supporting translated routes while routing to the same page, e.g: /project, /projekt and /projet for en, de and fr
Also with the developer of SWC joining next.js will the non-open-source parts (STC)[1] be released?
[1]: https://stc.dudy.dev/