From my experience working with esbuild since it's early days, all I can say is to that there has been a very high bar set by esbuild's speed and ease-of-use. I've used it for all my web apps and services since and i've finally begun to like my front-end build chain, unbelievably.
Turbopack, the successor to Webpack
81–90 of 331 posts
Re: Turbopack, the successor to Webpack
#82Looks 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…
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.
Re: Turbopack, the successor to Webpack
#83Vercel is on a streak. I am curious whether Turbopack elapses Vite like Vite elapsed Webpack over the past 12 months.
If the configuration is a nightmare like webpack then not likely.
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.
Re: Turbopack, the successor to Webpack
#84Really hope this gets a competent library mode. Webpacks library mode never really evolved to meet the needs of things. Vite has a good library mode but it has its own limitations.
Pure rollup is still the best for building libraries, by and large (maybe esbuild now? but I think rollup is more efficient in its output still).
If this has a good, solid library mode that works like rollup with the power of the webpack-like asset graph, it'd actually be amazing for the community as a whole.
Re: Turbopack, the successor to Webpack
#85Looks 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?
Rollup is used by some of these tools. For instance vite uses rollup for production builds.
Re: Turbopack, the successor to Webpack
#86Looks 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?
Yes, e.g. Vite uses Rollup for production builds. Vite uses esbuild for development with plans to make it usable for production builds.
Re: Turbopack, the successor to Webpack
#87Looks 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…
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.
That seems to be the chicken-and-egg problem here: the current problem is endless repetitions of "none of the existing options are good enough, let us build a new option". The call above is "just pick one and everyone work together to make it better", but we're back to "none of the existing options are good enough".
Re: Turbopack, the successor to Webpack
#88Is there any actual proof that Turbopack is 10x faster than Vite at anything? I can't find any benchmark showing it.
Re: Turbopack, the successor to Webpack
#89Earlier quoted context omitted.
Kinda, but not really. There are still lots of parts you'll have to implement yourself if you want to create a CRUD app. The mainly focus on the frontend part with the help from the backend. Combine next.js with https://blitzjs.com/ and you'll have something that looks like rails.
To throw another in the ring, I recently stumbled on https://github.com/t3-oss/create-t3-app . Lots of buzzword tech in there, but the setup looks very interesting. Looks like blitz is tRPC + next auth?
> Looks like blitz is tRPC + next auth?
From what I understand Blitz is their own implementation of tRPC, their own Auth system, Prisma and Typescript support. Blitz is also more of a toolkit that wraps around NextJS currently, but later on Remix, Svelte and Vue.
In future (probably in '23 and post 1.0) some things that may be coming are:
- backend functionality ala NestJS
- form component library
- permissions (rbac) library
- file upload library
- and a bunch of other stuff I'm forgetting right now.
Re: Turbopack, the successor to Webpack
#90Looks 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…
Yeah, it really pains me that Sitecore is doubling down on them as the main FE framework.