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
re: hot take, javascript
@joepie91 the main issue imho is the fact that people wanted to code bundlers in javascript and javascript is an absolutely terrible choice for code that requires allocating and processing large amounts of data
most of the time spent in bundlers is just bound to garbage-collecting since they don't reuse buffers at all (you can't in JS) and have to instead rely on allocating massive buffers for each operation, which is slow
like even a garbage-collected language like go that at least lets you reuse buffers has a dramatic improvement in the time it takes to do things
re: hot take, javascript
@clarfonthey Bundlers have never been slow. You can bundle the frontend code for whole production sites in under like 400ms. The slow part was always all of the shit that people inserted *into* the bundling process (like code analysis, minification, etc.)
re: hot take, javascript
@clarfonthey That's a whole different discussion, though, that isn't really relevant for my original post - which is that bundling is, itself, fundamentally a very simple operation (it's basically somewhat structured string concatenation) and there is no reason for people to reinvent that wheel 10 times.
re: hot take, javascript
@joepie91 this is also fair
the tech industry loves to make products instead of useful code, and so, there's no such thing as just a bundler; it has to do everything else too
re: hot take, javascript
@joepie91 I mean, that's fair. I still think that all the preprocessing is ultimately a good idea, since limiting the required download size is good, but you're right that you get diminishing returns and with processing tools written in javascript you diminish the returns far more rapidly