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
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
@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
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
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