Is Bun the Next Big Thing After Webpack? | Hacker News Reader

Is Bun the Next Big Thing After Webpack?

betterprogramming.pub

14 pointsanupamchugh13 comments

I don't want to be a naysayer. But the premise of the title is that Webpack is the current big thing. And I read the whole article and don't really understand why Webpack is the current big thing. The whole JavaScript ecosystem seems very disjoint and although I'm not immersed in it, I figured I would have heard of Webpack before or at least seen it on this site if it was so big. I have heard of npm and Babel before, but maybe that's just good marketing (or maybe I just missed a whole generation?).

You’re just out of loop. Webpack is the current big thing. It rose to prominence after grunt and gulp, which were both build automation tools. Webpack supplanted them by being a “one stop shop” for many of the things grunt and gulp were used for. However, as always happens, that convenience spiraled into increasing complexity as people wanted more and more out of their builds.

I would agree with this statement. You may not see Webpack directly because a lot of modern tooling/libraries/frameworks (whatever we're calling them now) have Webpack hidden away in their dependencies and the end consumer gets a hand full of useful cli commands that run magic.

I find it extremely frustrating that the entire build stack for frontend changes every 2 years.

It's really hard to create JavaScript apps that "just work", because you have to factor in that the whole ecosystem and community will be onto something else after 2 years, so you'll have to spend a significant amount of work adjusting your app away from outdated tooling.

Binary lockfile inspectable only by binary tooling sounds like a play to enable undetected supply chain attacks.

I disagree. The current package lock may as well be binary. The performance differences of binary serialization are not to be underestimated. There will be a spec and you can write your own implementation.

The problem is that all existing tooling needs to adapt, from custom package repositories to security scanners. It’s no longer possible to use grep to find out which of your projects’ dependencies use a vulnerable package.

This is a step backwards IMO.

So you pipe through one more thing to get in text form, I don’t think it’s a big problem. I would much prefer a binary format for the perf

It is a problem because it creates a trust vector between the binary vendor and the app developer consuming the binary.

Sure, there is going to be a build-your-own kit, but is everyone going to audit the codebase and the tooling and all dependencies?

It’s a fresh new can of worms and we’re already overstocked.

I really don’t think deserializing the file is that sketchy. It’s really not hard to implement a parser if the format isn’t garbage

There’s already a trust vector between the people shipping all the tiny little pieces of garbage JS, and then on to the binaries that read and handle dependency management, and packaging, and so on-things which, as has been expressed, seem to be in a rolling two-years-or-less handbasket to at least “mess”, if not “hell”.

We’re already to the point where “no one” audits the code base, tooling, or dependencies. Especially the dependencies.

Also the article is from March and mentions a private GitHub but it seems like it has been publicly released per context clues on this commit https://github.com/Jarred-Sumner/bun/pull/205

I don’t know any devs that reach for Webpack over Vite on purpose these days. Bun is amazing though. I hope we get more of the js/ts ecosystem running on something as insanely fast as Bun. First class Typescript and bundler support in a wicked fast runtime… love it!

Reply on news.ycombinator.com