HackerTrans
TopNewTrendsCommentsPastAskShowJobs

bgwhn

no profile record

comments

bgwhn
·vor 3 Monaten·discuss
> skip some build steps

There was a change in Next 16, not Turbopack, that removed `ESLint` during `next build`: https://nextjs.org/blog/next-16#breaking-changes-and-other-u...

This behavior is the same whether you use Turbopack or webpack. It doesn't make sense for us to couple ourselves with ESLint when there are many viable alternatives. No other popular frameworks run ESLint automatically during builds. This change in Next 16 brought up closer to parity with other frameworks and bundlers.

> typescript validation

There's no change here with Turbopack. We do still run `tsc` automatically to check your types. That's part of `next build` and not Turbopack. However, we may remove this in the future for similar reasons.

There's no good reason for the bundler to call the typechecker. Bundlers strip types. Historically this was done with Babel in webpack. Modern versions of Next.js use SWC for type stripping in both webpack and Turbopack.

> aggressively cache node modules

We aggressively cache everything. We don't have special-casing for `node_modules`. See our blog post about our caching system: https://nextjs.org/blog/turbopack-incremental-computation

Interestingly vite does actually special-case and cache `node_modules`: https://vite.dev/guide/dep-pre-bundling

There are tradeoffs to both approaches, and I think Vite's choice makes sense in the context of their broader minimal-bundling-in-dev design, but it makes less sense for Turbopack (as well as webpack and Rspack) where we produce bundles in dev.
bgwhn
·vor 5 Monaten·discuss
Thank you for sharing your experience with Next.js, even though you eventually ended up moving off.

> Waiting on Turbopack: Our initial local route loads took 10 to 12 seconds under the full weight of the App Router and RSCs.

Out of curiosity, were you on Next 16.0 or 16.1? We shipped file system caching in 16.1 that greatly improves the initial route loads. https://nextjs.org/blog/next-16-1#turbopack-file-system-cach...

> Production memory leaks

If anyone else runs into this, we've got a guide on how to profile your application: https://nextjs.org/docs/app/guides/memory-usage

> The multi-cloud ceiling

Admittedly hosting Next.js can be a bit harder than a SPA if you're using all the features of the framework, but if you're scaling and you don't want to use Vercel, you've got a lot of other options, including those provided by OpenNext. We've got a nice example repository here: https://github.com/leerob/next-self-host
bgwhn
·vor 5 Jahren·discuss
What's more concerning IMO is that despite the fact that I can't find a CLA, their pricing page claims that if you buy their support contract that they'll give you the software under a "Commercial" license: https://min.io/pricing
bgwhn
·vor 5 Jahren·discuss
> Rust could add a `#![forbid(alloc)]` declaration and achieve the same effect.

Isn't that pretty much what `#![no_std]` is for? You can still use an allocator with no_std, but you have to explicitly import it.

https://docs.rust-embedded.org/book/intro/no-std.html