ec changed the topic of #elliottcable to: a π•―π–Šπ–“ 𝖔𝖋 π•―π–Šπ–™π–Šπ–—π–’π–Žπ–“π–Šπ–‰ π•―π–†π–’π–˜π–Šπ–‘π–˜ slash sΝ”ΜžuΝ•Ν™pΝ™Ν“e̜̺rΜΌΜ¦i̼̜oΜ–Μ¬rΜ™Μ™ c̝͉α»₯Μ§Ν˜αΈ·Μ‘Ν™Ε£Ν“Μ€ || #ELLIOTTCABLE is not about ELLIOTTCABLE
<devsnek> i thought apple allowed other browsers now
<devsnek> and that whole only webkit meme was from like 2012
<devsnek> oh nvm still a thing :( https://gc.gy/6234008.png
Sgeo has joined #elliottcable
Sgeo_ has quit [Ping timeout: 268 seconds]
Rurik has joined #elliottcable
Rurik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Rurik has joined #elliottcable
Rurik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ec> wow, my second message never sent eeyeroll
<ec> ljharb: … ooooor B) literally sniffs your browser and simply demands you switch to Chrome, then disables the feature serverside, instead of feature-sniffing
Rurik has joined #elliottcable
<ljharb> ec: lol yes that is certainly a terrible and existing option
Rurik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<ec> fuck, i h8 gulp
<ljharb> yeah gulp sucks
<jfhbrook> we still have grunt somewhere in our build
<jfhbrook> though I think these days it's a thin wrapper around webpack
<jfhbrook> which, I guess? I was never huge on webpack but it at least seems maintained
<jfhbrook> I get sub's take that software can be "done" a la browserify but
<jfhbrook> it's not very satisfying
<ljharb> i don't like webpack but yes, it is maintained
<ljharb> and it's also just a bundler, not a shitty version of Make or `npm run`
<gkatsev> well, it's a bundler that can do like 99% of what npm run could potentially do :P
<ec> why dislike webpack
<ec> I ask because I barely understand it, but it seems very powerful and complex, and it doesn't seem like it's duplicating the purpose of another, lighter tool
<gkatsev> because it's so powerful and complex
<ljharb> it's large and bloated, yes
<gkatsev> then again, with v4 it's significantly better
<ljharb> v4 is slower than v3 for airbnb
<gkatsev> really?
<gkatsev> weird
<ljharb> yep
<ec> I mean, to do what it does, doesn't it need a pretty-holistic view of the codebase?
<ljharb> we've spent tons of time and money trying to make webpack faster
<ljharb> we're exploring alternatives at this point.
<ec> it just feels like a problem that justifies large-and-complex idk
<gkatsev> but it's a lot better for beginners, no more needing to configure it for hours before being able to use it
<ljharb> ec: sure. but that doesn't make it slow.
<ljharb> ec: building a dependency map of airbnb's massive codebase is done by jest's haste-map package in seconds
<ec> oh, missed that bit, you don't like it 'cuz it's slow?
<ljharb> webpack takes much longer
<ljharb> well, i don't like it conceptually because it's monolithic and bloated
<ljharb> in practice it's very very slow for us
<ec> can you imagine a solution to This Particular Problem that *isn't* monolithic?
<ljharb> sure. what browserify does
<ljharb> iow, a bunch of small, single-purpose tools, composed together
<ec> gbh don't grasp the differences between webpack and browserify
<ljharb> (ideally in one works-out-the-gate package)
<ec> tbh*
<ljharb> browserify is more unix-like
<ljharb> small and streamlined, but requires more config
<ec> I mean, not in architecture β€” in features
<ljharb> oh, they all have the same features potentially
<ljharb> webpack has more of them built in, browserify can easily be configured/extended to have the same ones
<ec> webpack seems to solve a different problem than browserify? doesn't it to all sorts of intelligent DCE and other static analysis and optimization?
<ljharb> you can do all those same things with browserify
<ljharb> with browserify, you have to add those pieces yourself, with webpack, you have to figure out how to turn them on
<ec> and what do you mean by "done" w.r.t. browserify
<ec> haven't actively looked at it in years, but it's a component of a bunch of my old projects, so,
<gkatsev> yeah, it's often easier with webpack, partly because either it's already available as a package, or there's a blogpost about it
<jfhbrook> browserify itself only does part of what webpack does, but it's designed to be integrated with a bunch of cli tools to do the same kinds of things you would do with webpack...fundamentally different architecture
<jfhbrook> ec, you'll find it hasn't had a new feature added in a few years, I think
<gkatsev> where-as with browserify you kind of have to figure it out yourself at this moment
<ljharb> right
<ljharb> but it's all identically possible
<ec> welp, fun chat, but back on my head
<jfhbrook> hah
<gkatsev> plus, there's even a commonjs tree plugin at this point for browserify
<gkatsev> *tree shaking
<jfhbrook> our frontend's webpack build takes two minutes
<jfhbrook> which from a iterative development standpoint is really painful
<jfhbrook> frontend swears the new and improved frontend doesn't have this problem, we'll freaking see
<ec> how 2 gulpugh ugh ugh