Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Turbopack, the successor to Webpack

vercel.com

Post reply on HN
Print view View original

211–220 of 331 posts

Re: Turbopack, the successor to Webpack

#211

Post by simooooo »

crummy wrote: post #208
fragile_frogs wrote: post #174

After 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? https://github.com/parcel-bundler/parcel/issues/6310

I think this is the exact thing that caused me to leave parcel for webpack

Re: Turbopack, the successor to Webpack

#212

Post by Aeolun »

qbasic_forever wrote: post #22

Wow remote caching like Bazel is wild to see in a bundler. It's nice to see someone realize that JS bundling is more or less like compiling and linking in the native code world and we just need to accept it and optimize the hell out of it.

Does it make sense to cache something that takes 1.7 seconds though?

Re: Turbopack, the successor to Webpack

#213

Post by Aeolun »

rsanheim wrote: post #60

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…

> Vite

On large applications Vite is fast to build, but loading your application in browser issues thousands of http requests, which is tragically slow.

Esbuild is basically instant to build, and instant to load on the same application. It’s a shame it doesn’t do hot reload.

If Turbopack can give us the best of both worlds, then that’s absolutely an improvement I want.

Re: Turbopack, the successor to Webpack

#214

Post by Aeolun »

josephg wrote: post #110
djbusby wrote: post #93

Earlier quoted context omitted.

By my count its 23 years. 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.

Yeah. I’m consistently surprised and disappointed by how much resistance people have to getting their hands dirty digging through other people’s codebases. It’s fantastically useful, and a remarkable way to learn new approaches and techniques. The world doesn’t need yet another JS bundler. It needs the one js bundler that works well with the wide variety of niche use cases.

I dig through other people’s codebases all day long. I really don’t want to do that in my free time as well. Especially to fix the garbage that they built in the first place.

It’s just not fun. And that’s one of the most important reasons I do this job.

Re: Turbopack, the successor to Webpack

#215

Post by Aeolun »

WorldMaker wrote: post #104
cldellow wrote: post #69

Earlier quoted context omitted.

> special snowflake build toolchains That reminds me, wasn't there a build tool called Snowflake? Oh, it was called Snowpack [1]. And it's no longer being actively maintained. Yeesh. [1]: https://www.snowpack.dev/

My disappointment related to this is that I still think Snowpack's philosophy was the right one for JS present and especially for JS future: don't bundle for development at all because ESM support in today's browsers is great and you can't get better HMR than "nothing bundled"; don't bundle for Production unless you have to (and have performance data to back it up). I know Vite inherited the first part, but I still m…

Have you ever tried to load a development build of a project with 3000 modules in Vite? It’s like a webpack build all over again every time you load the page.

Re: Turbopack, the successor to Webpack

#216

Post by tln »

323 wrote: post #176
tln wrote: post #105

Earlier quoted context omitted.

I'm a little skeptical as well. Vite is fast I just checked a code base that's at ~900 modules, and vite is ready to serve dev requests in well under a second.

That is misleading. Open the browser and request the app and you'll see the first cold load will take many many seconds since Vite didn't load and compile the app yet. If you reload the second time will be much faster since it will serve from it's memory cache.

That does take a few seconds, for me. But I could see how that could get painful on larger apps.

I'm not trying to mislead... but it would be good to know what they are actually measuring.

Re: Turbopack, the successor to Webpack

#217

Post by random_kris »

wruza wrote: post #207
fragile_frogs wrote: post #174

After 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…

https://github.com/t3-oss/create-t3-app + Pnpm monorepo

Re: Turbopack, the successor to Webpack

#219

Post by rsanheim »

fragile_frogs wrote: post #193
rsanheim wrote: post #60

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…

> I just wanna `script/build` or `yarn dev` and not think about it anymore. Parcel might be a good fit for you: https://parceljs.org/

We've already migrated our old webpack rails front end to esbuild as of a couple months ago, and couldn't be happier.
Post reply on HN