_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Turbopack: Building faster by building less
maelito wrote 5 hours 22 min ago:
For me, Turbopack resulted in faster builds but also non-recoverable
errors on syntax errors.
baby wrote 7 hours 43 min ago:
Using nextjs with turbopack in a turborepo+bun monorepo is so hard.
Someone need to explain to me how things are supposed to be setup
> Many build systems include explicit dependency graphs that must be
manually populated when evaluating build rules. Explicitly declaring
your dependency graph can theoretically give optimal results, but in
practice it leaves room for errors
Man this is the part I hate with turborepo
aggregator-ios wrote 10 hours 31 min ago:
This is a good write up on the workings. However, in actual use,
Turbopack has severe limitations when compared to Webpack. Iâve been
working on [1] and rely on the jq WASM dependency for the queries. But,
Turbopack cannot handle importing a WASM binary or the glue code for it
directly. The workaround is to have a script copy the binary to the
public directory. But that's not all. jq-wasm has a dependency on the
âfsâ module, even though no fs functions are used. But trying to
resolve this in Turbopack is not possible and 2 days of fighting this
was a waste of time.
Webpack solved this problem with a few lines in the next.config.ts
For now, Iâm back to using Webpack with NextJS 16 with the âWebpack
flag. Hope they allow this for future versions.
There are plenty of complaints on the NextJS subreddit, and here is a
open thread on complaints with Turbopack [2] Looks the alternative is
Rspack?
(HTM) [1]: https://jsonquery.app
(HTM) [2]: https://github.com/vercel/next.js/discussions/77721
tkzed49 wrote 10 hours 52 min ago:
The fact that there's no tangible plan for any plugin support in
Turbopack is actually what made me not choose Next.js.
The answer for people who need basically any build plugin is "use the
webpack mode", and I have zero faith in Vercel maintaining that past
the next major version.
I guess we'll see whether they figure out a story for plugins by then.
razodactyl wrote 9 hours 24 min ago:
Vendor lock-in. Next.js is great until it's not.
lloydatkinson wrote 12 hours 15 min ago:
Not to be confused with Turborepo.
augusteo wrote 12 hours 18 min ago:
The technical approach here is solid. Fine-grained dependency tracking
with automatic invalidation is the right way to do incremental
compilation. The Rust implementation means it can actually handle large
codebases without the JS runtime becoming the bottleneck.
But the skepticism in this thread about ecosystem fragmentation is
valid. Vite won because it worked with the existing ecosystem, not
against it. Turbopack requiring Rust for plugins limits who can extend
it.
That said, if you're already locked into Next.js, this is a clear win.
The question is whether Next.js's market position justifies a separate
build tool or whether this accelerates the trend of frameworks becoming
walled gardens.
I personally love Vite and Remix.
almaight wrote 5 days ago:
This thing can't be replaced by bun on Linux.
chrisldgk wrote 5 days ago:
Is this a quip Iâm not understanding or is there really something
here that bunâs bundled wouldnât be able to do? Because I canât
find anything.
pjjpo wrote 4 days ago:
Not to say it is the quip but I have had buggy builds with bun that
requires sticking to esbuild, I think it was bundling prettier with
many plugins into a single JS file.
I always do that sort of thing in Docker so never considered it
could be a Linux-specific thing, maybe so.
brylie wrote 5 days ago:
I may be out of the loop, but isn't the JS/TS community consolidating
around Vite?
(HTM) [1]: https://vite.dev/
rk06 wrote 5 days ago:
turbopack is tightly coupled with next.js
rest of the JS community can't use turbopack, so they went with vite
brylie wrote 1 hour 19 min ago:
Thanks for the clarification.
gempir wrote 6 hours 20 min ago:
Kind of weird way to put it. Turbopack was not a real product for
years. It was forever stuck in weird beta/alpha stage and only
recently went and became the default for NextJS.
Vite has been stable for years at least 5 years now and is
built-upon because it's fast, stable, reliable and a bit less
complicated than Webpack.
o_m wrote 5 days ago:
Yes, TurboPack is for legacy projects that can't update from Webpack,
but still want some bundle speed improvements.
pjmlp wrote 5 days ago:
Not really, because they only ported into Rust the most used
plugins with "yes but" constraints.
chrisldgk wrote 5 days ago:
Which is mainly NextJS (old and new), since under the hood that
still seems to rely on Webpack.
pjmlp wrote 5 days ago:
Much less indeed, not all Webpack plugins capabilities are supported
and now anyone that wants to make one has to learn Rust, which surely
isn't the same as writing it in JavaScript.
The splitting communities effect always gets left out of these
announcements, or gets positioned as something good.
(DIR) <- back to front page