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