hot take, javascript 

There is no justifiable reason for so many different extensible (yet mutually incompatible) bundlers to exist, given how trivial of a task bundling is, and the fact that they *do* all exist should raise some uncomfortable questions about why

hot take, javascript 

@joepie91 browserify exists and everything else followed, because big tech standard bodies are an anti pattern.
They just cant make good tech.

Bundlers exist because the web sucks.
Imho designing for the need of bundlers is designing for the technical debt and big tech.

We should get rid of all bundlers.
nodejs didnt need them and post web shouldnt need them either.

Post web is in the air already and will manifest any time now 🙂

hot take, javascript 

@serapath Bundlers are necessary because traversing a dependency graph over a high-latency link like the network is fundamentally not viable.

The problem I am talking about is not the existence of bundlers; it's that there are so many, and that most of them bring absolutely nothing to the table that wasn't already possible in their predecessor.

hot take, javascript 

@joepie91
i would call that process "installation"
you do it once - on first page visit
or if not in production, then during "npm install".

a manifest file (even utilized in a web app), such as what `npm shrinkwrap` can produce can massively parallelize this process too.

no bundling needed.

hot take, javascript 

@serapath Generating manifest files is functionally the same thing as bundling. "Bundling" is nothing more than statically traversing the dependency tree and string-concatenating the results with a minimal amount of boilerplate code to make the references work.

I don't know where people are getting this idea that bundling is some kind of highly complex or objectionable or slow process. It's kind of bizarre.

hot take, javascript 

@joepie91

hmm... never considered `npm shrinkwrap` to be a bundler. ...it can work by transitioning package.jsons only technically.
Maybe it actually is implemented processing the sources too, but bundling is often associated with applying code transforms, tree shaking (a.k.a dead code elimination), maybe minifications and generating source maps and so on.

So saying `npm shrinkwrap` is a bundler feels like a stretch imho 🤷‍♀️

...anyway, just needed for first load speedup

hot take, javascript 

@serapath None of those things (code transforms, tree shaking, minifying) are bundling. Source map generation is only a part of bundling insofar it describes the mapping from many files to one JS file.

Calling code transforms 'bundling' is like saying that Make 'compiles' your code. It doesn't. It just invokes the thing that does, if that's what you tell it to do in the process.

(Notably, switching from bundles to manifests also removes exactly zero of those things-that-are-not-bundling from your build stack)

hot take, javascript 

@joepie91
oh alright. i misunderstood you then.

when you said there are so many bundlers, i though of webpack, browserify amd the many newer variants and they do transformation as well.

i am not aware of any "bundler" that just concatenates stuff, so i translated what you said with build+bundle

Follow

hot take, javascript 

@serapath Neither Browserify nor Webpack do code transformation (or at least for Webpack that's true in its initial version). Both just do concatenation.

Both support plugins, which *can* do code transformation, but that happens entirely outside of the bundler.

· · Web · 1 · 0 · 1

hot take, javascript 

@joepie91
i see.
yeah, if you dont apply any code transforms or plugins in browserify thata true, but if there qas NO support for it, it would be kinda useless and a .concat would be enough.

also browserify at least patches the environment with nodejs shims.

still imho we should not need bundlers as all

hot take, javascript 

@serapath Just a .concat wouldn't be enough because it doesn't create a module scope; that's what the small amount of additional wiring is for, but that's also just strings

hot take, javascript 

@joepie91

fair.
anyway, i can see some reason why you would need a builder to e.g. allow ppl to author in typescript ...but many other reasons too, basically to process sources.

But imho that should be part of the runtime and should happen dynamically and deterministically cached ...the web caches stufd so cpupd totally support that.

Bundling should not be necessary imho.

let me downloading missing modules instead of parge bundles containing stuff i already have

Sign in to participate in the conversation
Pixietown

Small server part of the pixie.town infrastructure. Registration is closed.