Ah, so this is why Vercel hired Tobias. Makes sense, and it could only gain traction with a company like Vercel behind it. Webpack is legacy now, supplanted by Rollup/Vite, ESBuild, et al. The only folks I know still using webpack are stuck with it (e.g. Next users)
Turbopack, the successor to Webpack
201–210 of 331 posts
Re: Turbopack, the successor to Webpack
#202Bummer that we have to wait for Svelte support, but seems worth it. Hope to see it bundled with Svelte Kit soon! https://turbo.build/pack/docs/features/frameworks#vue-and-sv...
Vite's momentum is too much to stop right now imho
Re: Turbopack, the successor to Webpack
#203Literally 1 day after my team migrates our build to Vite :')
you made the right choice.
Re: Turbopack, the successor to Webpack
#204I think the name isn't a great choice, given the already established Turbo ecosystem for Rails/Hotwire. Perhaps Rails can create a gem that makes migrating from one version to the next easier, a Version Compatibility Enhancement Library, calling it VerCEL for short.
When I built the Q Platform originally, I put so much work into it, but showing it to people I mostly got one piece of feedback without them even looking: "it's called Q... and there is a library for promises called Q that is way more popular. Rename yours." I tried to explain that it was a completely different field, and that this was a web development framework. And that we had started ours way before this library…
Here is the thread! See for yourself what happened
Re: Turbopack, the successor to Webpack
#205After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…
I kind of don't understand pure bundlers for the individual dev level; I feel that they are made for other ecosystem authors to package into a "meta-framework", such as NextJS (which used to use webpack). The devs at Vite said something similar, that although they provide a great developer experience with no/low configuration, they're really meant for other ecosystem authors.
Re: Turbopack, the successor to Webpack
#206From 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.
Yeah, as someone who focuses primarily on back-end but occasionally finds the need to dive into front-end, esbuild has virtually eliminated the pain I had with front-end bundling/packaging when I was using Webpack. At least it has in my situation, which involves mostly standard needs and very little customization.
esbuild shines even brighter when you do need to customize. The API is outstanding. Docs are excellent. I've been able to do most things myself, without hunting for plugins and examples.
Re: Turbopack, the successor to Webpack
#207After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…
Parcel felt really fast, zero-conf and “opinionated” in a good way. But I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command, with modules shared across sides. This frontend/backend separation is too alien to my idea of development (coming from desktop programming), and it feels like some artificial border.
Thankfully, Node and browsers slowly converge, so isomorphic code is less and less of an issue.
Btw, how does HN develop solo-dev apps? Do you switch between two projects? Run two separate webpack configs simultaneously? How do you share code/typedefs/dtos between them? Do you use or want to use backend HMR? Backend webpack-like import extensions?
got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works
When I finally built my perfect set of webpack configs, I deleted them after a couple of months. This complexity is “fun” to set up, but maintaining it is not something I want not working as a “devops” full time. Achievement unlocked, so to the trash it goes.
Re: Turbopack, the successor to Webpack
#208After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…
Parcel seemed to fail when I had multiple entrypoints into my app that shared code. Is this such an unusual scenario?
Re: Turbopack, the successor to Webpack
#209After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the bro…
Parcel felt really fast, zero-conf and “opinionated” in a good way. But I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command, with modules shared across sides. This frontend/backend separation is too alien to my idea of development (coming from desktop programming), and it feels like some artificial border. Thankfully, No…
I use Next.js, which does both front and backend in one command. It may not be powerful enough if you need truly large API’s, but for anything I build it’s more than enough.
Re: Turbopack, the successor to Webpack
#210From 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.
Same here!