Looks 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…
Agreed. Every time NextJS changes out their build system for speed, its users lose out on all kinds of functionality that they were depending on before. Moving away from Babel to SWC meant we could no longer use SCSS within JSX styled components. We first switched everything to plain CSS, which was a nightmare IMHO. Now slowly switching things to SCSS modules. Now with Turbopack, we lose that too: https://turbo.build…
Turbopack, the successor to Webpack
91–100 of 331 posts
Re: Turbopack, the successor to Webpack
#92This looks great, but I feel like calling this a successor to Webpack in its current state is disingenuous, considering the roadmap literally says: “Currently, migrating to Turbopack from Webpack is not yet possible.” At least the marketing website is snazzy ¯\_(ツ)_/¯
Re: Turbopack, the successor to Webpack
#93Earlier quoted context omitted.
I don’t think any of the current options are good enough that I would want the community to settle on one of them at this point at the expense of any innovation or experimentation.
We’ve been doing JavaScript development for how many years now? And still no bundling options that are good enough? Or at least one that can continue to evolve vs. creating a successor, etc.
The biggest issue in FOSS is folk don't wanna join a "good enough" project and move it. Sometimes the project is contributor hostile (rare?)
And we end up with basically: "I'll build my own moonbase with blackjack and hookers!"
All that starting from scratch costs loads of impossible-to- recover-time.
Re: Turbopack, the successor to Webpack
#94Looks 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…
Re: Turbopack, the successor to Webpack
#95> We're planning Turbopack as the successor to Webpack. In the future, we plan to give Turbopack all the tools needed to support your Webpack app.
> Currently, migrating to Turbopack from Webpack is not yet possible. In the future, we're planning to offer a smooth migration path for all Webpack users to join the Turbopack future.
Re: Turbopack, the successor to Webpack
#96Too much marketing speak I think. > We're planning Turbopack as the successor to Webpack. In the future, we plan to give Turbopack all the tools needed to support your Webpack app. > Currently, migrating to Turbopack from Webpack is not yet possible. In the future, we're planning to offer a smooth migration path for all Webpack users to join the Turbopack future.
Re: Turbopack, the successor to Webpack
#97Earlier quoted context omitted.
I don’t think any of the current options are good enough that I would want the community to settle on one of them at this point at the expense of any innovation or experimentation.
We’ve been doing JavaScript development for how many years now? And still no bundling options that are good enough? Or at least one that can continue to evolve vs. creating a successor, etc.
It’s hard to overstate how game changing this new wave of zero-config, ultrafast rust bundlers are for the day-to-day dev experience.
Re: Turbopack, the successor to Webpack
#98Looks 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…
Is rollup still a thing?
JS is not my main language, true, but damn it's hard to keep up. I think it took me less time to be productive with Typescript than with webpack.
Re: Turbopack, the successor to Webpack
#99Looks 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…
JS has 10x the amount of developers of all other languages combined, that translates to a lot of ideas on how to progress the different avenues of JS land.
Re: Turbopack, the successor to Webpack
#100Looks 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…
Agreed. Every time NextJS changes out their build system for speed, its users lose out on all kinds of functionality that they were depending on before. Moving away from Babel to SWC meant we could no longer use SCSS within JSX styled components. We first switched everything to plain CSS, which was a nightmare IMHO. Now slowly switching things to SCSS modules. Now with Turbopack, we lose that too: https://turbo.build…