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. 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).
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?
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.
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.
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.
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.
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.
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.
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
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 bonkers faster" chirps
kudos to the Next team doing the good work