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
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
hmm.. i think browserify uses acorn to parse into an AST, but now that you say it, i'm not 100% sure anymore.
I stipl use browserify for all my projects. never had any need for "newer" stuff and still feel browseries approach as a build+bundle tool was the best and its a shame it never got the support and money the big tech sponsored projects got.
i wosh we wpuld make browserify great again 😁
MBGA