Was Vercel the original creator of webpack?
The Turbopack project is led by Tobias Koppers, creator of Webpack
Turbopack, the successor to Webpack
121–130 of 331 posts
Re: Turbopack, the successor to Webpack
#122A bit of a bummer that "get started" requires nextjs, and there's no documentation for a frameworkless build (I understand it's labeled as alpha but if you're going for such grandiose announcement an "how to bundle a vanilla/frameworkless app" would have been nice)
Our initial development cycles were dedicated on getting Next working. But we absolutely plan on expanding the to support generic bundling and will include that in the docs.
Re: Turbopack, the successor to Webpack
#123Curious if this will be supported by react-scripts. Or is it Next.js-specific?
It's _currently_ Next specific, but we plan on making it generic and usable in any setup.
Re: Turbopack, the successor to Webpack
#124If I want to write a plugin does it have to be in rust? I like rust but we're not going to add rust tooling to our dev env just for one plugin.
We plan on supporting both. We're still in the alpha phase, and have not designed the plugin API yet.
Re: Turbopack, the successor to Webpack
#125Looks impressive, but proof will be in the actual day to day dev experience and configuration, not the perf. Vite and esbuild are fast enough, and I feel the winner will be more about usability, docs, easy config, etc. That aside, it is just so frustrating and sad that this just continues the fragmentation in the JS build space. It is beyond exhausting at this point. I don't care about vite vs (or with) esbuild vs tu…
Fully agreed.
I would add that esbuild has set the bar very high for documentation and configuration. I come away very impressed every time I need to touch esbuild, which is not usually my expectation when it comes to the JS build-and-bundle ecosystem.
And while vite is still young, it does a good job integrating itself with many different JS stacks. The docs are also great, and the project has incredible momentum.
Between esbuild and vite, I feel pretty set already. Turbopack will need to be that much better. Right now, it doesn’t look like much more than an attempt to expand the turborepo business model. Let’s see where they take it.
Re: Turbopack, the successor to Webpack
#126Is there a place I can find a "current state of the art" on this stuff? Once upon a time a quick-start option would have been. For instance, I may have done Rails+React+Babel+Webpack to get a quick backend JSON-API and a front-end web-app that consumes it. Not for something that "scales to 100 teams", just something for me to spin an app up in quickly. i.e. 0 to 1 is the only thing that matters.
Next.js is pretty much that. Not much configuration needed, and it wires up all the tools for you behind the scenes. If a new tool comes out that's worth it (like potentially Turbopack, although that's by the same company), they'll do the migration for you.
Rails also has a whole model/database thing going on.
Next.js is just front end focused and has always left it up to the user to decide about data persistence.
So to answer the original question, an equivalent would be Next+Database, and there is obvious stand-out answer for what Database should be. I often get stuck deciding what that Something should be when trying to go from 0 to 1.
Re: Turbopack, the successor to Webpack
#127Surprised not to see much mention of plugins and how they will work (unless I missed something?).
Plugins are the big differentiator between Webpack and existing "webpack but faster" tools, and presumably the reason most people still use webpack. What's the plan here?
Re: Turbopack, the successor to Webpack
#128The Turbo memoization framework sounds interesting, but I don't see any code samples for what it looks like for Rust users, or how it compares to other Rust memoization/caching libraries…
Re: Turbopack, the successor to Webpack
#129Earlier quoted context omitted.
Webpack has a reputation that was deserved in early versions. More recently it's not so bad unless you have very specific needs. If all you're doing is building a standard app from things like JS or TS, a CSS processor, and maybe a framework you probably won't need more than half a dozen lines of config that you can paste from Webpack or your framework's docs.
Currently looking at a 1000 line webpack config..........
You're either doing something complicated or you're not using Webpack very well. Most Webpack config I've worked with isn't like that.
Re: Turbopack, the successor to Webpack
#130The Turbo memoization framework sounds interesting, but I don't see any code samples for what it looks like for Rust users, or how it compares to other Rust memoization/caching libraries…
In several places it is mentioned as a Rust library, but I don't see any links to it. Using google search I'm not finding a Rust library named "Turbo". Is the library open source, or available on crates.io / in a public repo somewhere?