
Parcel – Fast, zero-configuration web application bundler - gilad
https://parceljs.org/
======
vecinu
It should be noted that Parcel was created in house at Adobe and then open
sourced.

I think it's always nice to call out the contributions certain corps are
making to the OSS world.

~~~
devongovett
This is somewhat true. I was working at Adobe while building Parcel in my
spare time at first, mostly to improve build perf of an app at work. After it
launched and we used it internally for a while, Adobe finally started
sponsoring the project.

Now, Parcel 2 has a core team of 9 active members from various companies
including Adobe, Atlassian, and Eventbrite. We also receive funding on Open
Collective which we distribute to a couple independent members of the team who
aren’t already sponsored by a company. Definitely a multi-company effort at
this point! :)

~~~
sverhagen
Just curious how these things go, are there the odd people in these companies
full-time working on a sponsored tool or framework, or is this people on a
team that's using these, finding some time at the end of a sprint to
contribute (like 10% time), or some other model?

~~~
orta
Usually it's one or two people using their spare time to eventually get
something good enough to work on work time occasionally unless it's 100%
aligned with the company goals (e.g. a company like zeit or gatsby)

Parcel is good (and I use it), but it's likely if someone had pitched it
internally I'd bet someone would have said "Webpack is good enough for us". At
least that's how it would have gone at the places I've worked at.

~~~
devongovett
Originally that's how it happened: I was working on a product and frustrated
with build perf, so built parcel in my spare time to scratch that itch.
Eventually convinced the team to adopt it.

Atlassian has 2 full time engineers working on Parcel now though, so they've
made a pretty big investment.

------
zelphirkalt
Except, that it is not really zero configuration and you still have to figure
out some settings for getting source maps to be referenced correctly.

It is blazing fast though and much less a pain to set up than webpack. Every
time I have to touch webpack configurations I think: "Oh no, not that stuff
again ..." and it will take time to get it exactly the way I want or even
requires to load additional helper modules from NPM. Ugh.

~~~
devongovett
Hehe. There's always been some confusion about the term "zero configuration".
To us, it's always meant no config needed to get started (and for the 90%
case), but possible to configure later if needed. :)

~~~
qbaqbaqba
parcelrc would be a nice addition.

~~~
devongovett
Coming in Parcel 2! :) [https://github.com/parcel-
bundler/parcel/blob/v2/packages/co...](https://github.com/parcel-
bundler/parcel/blob/v2/packages/core/parcel/README.md#parcel-config)

~~~
jonilsson
That’s awesome. Been eagerly awaiting this release

------
jchw
Parcel Bundler is really fun. I would implore people to try it before jumping
into too much cynicism because their pursuit for zero configuration has lead
to some genius design decisions.

One constant problem with bundlers is how to rewrite the HTML files to match
the JS/CSS bundles. You can do all kinds of crap including scripts with
regexes, plugins, etc. but what if you could do better?

Put simply, Parcel does better. HTML files themselves can be entries, and they
will be compiled such that all of the stylesheets and scripts are compiled,
bundled and linked to the HTML file in the output. Now you don’t need to worry
about mucking with writing the hash into your HTML.

Parcel isn’t perfect but it makes a great static site gen. Its plugin
interface can be slightly cumbersome, but it’s flexible enough that you can
abuse it pretty effectively. As an example, I used Parcel to generate some
documentation built off of Kaitai Struct KSY files, which are effectively YAML
files. I push the KSY data through an HTML template that generates the doc
page. It was a lot of fun. You can see it here:

[https://packets.pangdox.com/packets/loginservice/server/0002...](https://packets.pangdox.com/packets/loginservice/server/0002.html)

~~~
JMTQp8lwXL
Let's say you want to use CSS Modules, but that's not the default in Parcel.
(I don't know if it is, but for sake of discussion, the argument continues).
The opinionated default works for some, but not all people. To enable an
override, maintainers end up breaking Parcel down into subpackages, and people
can pick-and-choose what they want. If that is Parcel's future, what ever did
we achieve as opposed to just continuing to use Webpack? In case it's
forgotten, this is how you'd enable CSS Modules in webpack:

[ 'style-loader', { loader: 'css-loader', options: { modules: true } } ]

What could meaningfully be simplified in this configuration? We could get rid
of the 'options' object, and spread into the parent object. But then that
makes it more difficult for Webpack to statically know if the JSON tree
provided is a valid configuration.

I don't see where this leads us. Instead of fragmenting the bundler market,
invest in making Webpack better, or move onto to a new problem. There's a
limited number of open source contributors out there, and only so much can be
built & solved. The end state of a mature Parcel ends up looking basically
like Webpack, which sounds like a fragmented, convoluted way of making a
questionably impactful contribution to the OSS community.

~~~
jchw
The trouble I have with Webpack is that everyone has their own snowflake
configs, there’s no interoperability, and the config complexity has been bad
enough that you could literally have someone working webpack configs fulltime.
How many legitimate reasons do you have to have the level of flexibility
Webpack provides? How many different TypeScript plugins are necessary? There
is a happy medium and Webpack is past it and off the cliff.

To be sure, Webpack is pretty amazing for what it can do, but I consider it
harmful for the stated reasons; I do not believe unification on Webpack is
helpful because almost literally no two Webpack instances is the same because
everyone is repeating basically the same configurations but slightly
differently (or radically differently in the pathological end.)

Of course using Parcel doesn’t mean literally no configuration, usually it
means _standard_ configuration. All of these softwares work standalone and
already do configuration. Need to configure the TypeScript compiler? Use
tsconfig! Need multiple tsconfigs? No problem, put them in different folders
and you’re good to go.

It’s unlikely you’ll end up with something compromise-free but like dropping
to assembler and coding out routines manually the tradeoffs of getting your
perfectly ideal output are not necessarily valuable to your fellow devs or
your end users. It must be evaluated at some level. For me, Parcel does a good
enough job that I trust it to have sane defaults for development and
production.

So about your question with CSS modules: you can use .postcssrc as usual,
although I do not use (or like, to be honest) CSS modules so I would
definitely be the wrong person to comment on how well it is supported.

(Addendum: I anticipate that some will pick up on the duality of saying
Webpack configuration is bad but condoning and recommending other configs. To
that I would say, it’s all about the details. For one, most of these config
files are auto discoverable, whereas for Webpack you gotta know the command
invocation. For another, Webpack configs are often executable Javascript
whereas most other configs are not used this way. And to be completely honest,
the amount of magical configuration you can do in Webpack is hardly ever
paralled elsewhere.)

------
macawfish
One cool thing about parcel is that you can use es import syntax to "import"
stuff from rust modules. It will then automagically do all the wasm
interfacing for you during the bundling process. Wow!

You can also import stuff from wasm modules too of course, but I like the
magic of "importing rust into JavaScript". It seems like a great way for
someone like me, who wants to learn, to use rust into a simple web project
without worrying too hard about wasm.

[https://parceljs.org/rust.html](https://parceljs.org/rust.html)

~~~
jayflux
You can do that with webpack, that feature is not specific to parcel
[https://github.com/rustwasm/wasm-pack](https://github.com/rustwasm/wasm-pack)

~~~
jchw
Sure. With Webpack you can find a Medium article that tells you how to install
and configure a plugin, run into places where things changed because of major
webpack versions and plugin ecosystem evolution, and after enough digging you
might get it working.

In Parcel you include the rs file. Seriously.

~~~
IceDane
This sums up my experience with webpack quite nicely. It doesn't help that
boilerplates like CRA are so ergonomic in terms of saving startup time in
other places as well, because this means I really need to have a good reason
to manually fuck with webpack. This combined means every time I finally end up
looking at webpack, my knowledge of it is super rusty. I've definitely been
side-eyeing parcel for a while

------
k_bx
If 9 seconds is "Blazing fast", I wonder how would something like Elm
experience of usually building stuff in around 0.2s be named. I think 9s is an
embarrassing number, especially when you mostly compile JS to JS.

~~~
hathym
what do you expect when compiling js with js to js?

~~~
pdimitar
I expect not to care about implementation details. 9 seconds of work with
these rather small inputs is embarrassing regardless of what language the
compiler is written in.

------
frankpf
Parcel is great, but I would avoid using it again due to the sheer number of
dependencies (730 packages!)[1]. Webpack has the same problem[2], depending on
342 packages. Rollup is the best one on this regard, depending only on 3
packages.

[1]:
[http://npm.anvaka.com/#/view/2d/parcel](http://npm.anvaka.com/#/view/2d/parcel)

[2]:
[http://npm.anvaka.com/#/view/2d/webpack](http://npm.anvaka.com/#/view/2d/webpack)

~~~
devongovett
We do include a lot more features out of the box than other tools, so this
makes sense to some degree. In Parcel 2, we're splitting up the core into lots
of small plugin packages so you can only install what you need. The Parcel 2
core is tiny - only a handful of dependencies.

~~~
spankalee
Should a bundler really include all those features though? All I want out of a
bundler is to bundle. As soon as it starts doing transforms, we end up with
applications that only work with that bundler.

~~~
savanaly
As a user of Parcel, I definitely want it. I wrote my Elm program, found
myself wondering what the best tool would be to automate the running of elm
make, bundling, not to mention transpiling the small amount of ES6 and sass I
had in there as well. Less than five minutes later I have parcel installed
with no config and it all just works with parcel start, god bless.

------
choxi
Parcel is great, 99% of the time I'm doing frontend development I just want my
build tool to convert Sass/Less/JSX/Babel code to whatever browsers support.
It's nice to just source a .sass or .js file and have Parcel figure out the
rest.

Has anyone used Parcel and Webpack and still prefers Webpack?

~~~
oefrha
Zero configuration is great until your project requires something that doesn’t
fit into the parcel model, at which point it’s simply out of the question, but
webpack with its myriad configuration options can be bent to your will. I was
in that position once, but I can’t recall the details now.

~~~
TheRealPomax
As a comment on Parcel, this is kind of a counter productive one. What's the
utility of a comment that says "it can't do something, but I don't know what"?
If you have the details, those are super valuable to comment with, but if you
don't... why comment?

~~~
RHSeeger
Because "there exist situations that parcel cannot handle because it doesn't
allow configuration". That's a useful thing to know. The fact that the OP
can't recall what the situation was also provides a useful piece of
information; that it's likely something that is not run into often.

~~~
true_religion
From what I read one of the developers wrote on here, Parcel does allow for
configuration. It just doesn’t require it.

It’s actually convention over configuration taken to an extreme where it’ll
start adding entries to packages.json for you, or wrapping rust code in WASM
for you on import.

------
joshwa
Ah, the classic build tool evolution cycle!

1\. Become frustrated with complex build tool

2\. Write a new tool that is dead simple, opinionated (your opinions),
convention over configuration, etc

3\. Post to HN

4\. Achieve adoption

5\. As more people use the tool, feature creep ensues

6\. In order to satisfy diverse use cases, make everything modular and
configurable!

7\. Tool slows and becomes impossible to manage

8\. GOTO 1.

~~~
devongovett
You’re right, this is happening to some degree with Parcel. Our aim with
Parcel 2 is to open up the plugin system to allow more extensibility while
keeping it as simple as possible to use out of the box. This is accomplished
through a very well defined plugin system with explicit extension points for
each step of the build pipeline (not the Wild West of extensibility like other
tools), and a good default configuration that you can extend or override as
needed with a simple JSON config format. The result is that you get everything
Parcel 1 could do and more out of the box, but you can easily change or extend
Parcel 2 with more features specific to your app if you need to.

We’ve been working on Parcel 2 for almost 2 years now (~1 year in design,
another in development) and I think it strikes a pretty good balance. I’m
excited to see what the community does with it! :)

~~~
ironmagma
Can the configuration have strong types (via TypeScript or similar) pretty
pretty please? One of my main frustrations with webpack is the undocumented,
unpredictable, unspecified config file format that seems to have no rhyme or
reason, which you must often change with every new plugin you add.

~~~
devongovett
Yep! I think we should be able to publish a JSON schema definition that
editors like vscode can use to provide autocomplete etc.

~~~
orf
That’s not strong typing, that’s automated (and not necessarily up to date)
documentation :(

~~~
devongovett
Is there another way to provide strong types for a JSON file?

I believe vscode uses schemas from
[http://schemastore.org/](http://schemastore.org/) for many config files
already.

~~~
ironmagma
If you define the types in TS, you can use
[https://github.com/YousefED/typescript-json-
schema](https://github.com/YousefED/typescript-json-schema) to automatically
generate a JSON schema from it. That way, configurations can be specified
either in an executable JS module or in a JSON file.

~~~
devongovett
Yep, we’ll definitely use a tool like that. We already have types in Flow for
all of Parcel 2, so should be possible to do something similar.

------
kresten
I met a software engineer once and said “what do you do on your team?”

He said “I’m the webpack developer”.

~~~
stefano
What does he spend his days doing? I wrote a configuration file years ago and
I still use it for multiple projects. I only had to update it when upgrading
between major versions of webpack.

~~~
johnghanks
Pretty sure it was a joke.

~~~
kresten
Absolutely not a joke.

------
eatonphil
After testing it out on some personal projects, I switched a two year old core
project at work from Webpack to Parcel. It took about 5 hours to get it right.
The trickiest parts were finding the right alias mappings between TypeScript,
our use of `~/` paths, and importing SASS files in TypeScript. This took about
an hour. The next 4 hours were figuring out how to map the changes to eslint
without Webpack.

It is much simpler to manage so far (though upgrading internal dependencies in
general could be an issue over time). It compiles much faster as well. I'm not
sure how the default bundle size compares to what we had with Webpack though.

------
spankalee
I really dislike the huge, multi-faceted build systems calling themselves
bundlers.

An ideal bundler would take a fully working unbundled project, which is easily
writable with JS modules now, and just optimize it for production delivery.

The unbundled working app will be easier to develop and debug. Having a
working project as input, and working project as output means that you can
switch bundlers and aren't tightly coupled to it's transforms.

But most bundlers don't work this way (Rollup is the closest, and that's why I
use it). Bundlers are typically entire build systems with compilers, CSS
transforms, image optimization, etc... and they happen to bundle somewhere in
the build pipeline. In the worst cases it's not possible to run the build but
_not_ bundle, if you wanted to run some of the transforms.

This is all kinds of bad for the JS ecosystem. You can't really tell how a
module will behave because the bundler is transforming everything. Imports
aren't really imports, CSS is concatenated and magically added to the main
document. Sometimes libraries publish code to npm that _only_ works with
certain bundlers.

Web Bundles[1] is the way out of this. It's a standard bundle format that'll
be natively understood by browsers, is unpacked before the network cache, and
_only_ a bundling format. If you just want to bundle a working project, any
Web Bundle tool will work.

[1]: [https://web.dev/web-bundles/](https://web.dev/web-bundles/)

~~~
devongovett
We’ve tried very hard to avoid Parcel specific features actually. When we
transform, we use other tools that the user has enabled, eg babel. An
application that you build with Parcel does not produce Parcel specific output
and there are as of yet no Parcel specific language features. It should be
possible to switch to another build tool without much if any work. Definitely
not the case with other tools like webpack though, so I can see where this
comes from.

------
XCSme
Switch to Parcel from Webpack for my latest project. I was actually surprised
that it just worked, I didn't even have to write a config file (being used to
Webpack this felt like I saved hours of work).

------
no_wizard
I would like parcel much more if they just emitted ES Modules. I don’t
understand the logic of having their own loader in 2020. Same complaint I have
with webpack. Just target systemJS for older browsers like rollup does.
Leveraging a very efficient existing well tested solution seems wiser to me
than reinventing the wheel

I don’t understand why they don’t support that. You can really leverage
smaller bundles this way (no bundler runtime for modern browsers for one). You
can also leverage type=module in the browser (which parsers more efficiently
by default[0]) and use the nomodule attribute for differential loading.

Of course this assumes browser targets, which I feel like is the main target
for these tools most of the time.

[0] [https://v8.dev/features/modules](https://v8.dev/features/modules)

~~~
TheRealPomax
One could also ask why you'd need parcel if you're already writing modern es
module code. If you really need to bundle that (and you kind of don't, es
modules allows you to put each requirement in your page html, and get the
benefit of browser caching for individual pieces of the pie back, which you
lost when you starting bundling and single-line changes to a single small
class created entirely new hundreds-of-kbs bundles) use rollup.

If you know you're targeting modern browsers, the need for bundling is slowly
disappearing again. And if you're targeting something like electron, there is
_really_ no need to bundle because you're distributing the entire filesystem
with load times that don't involve network requests.

~~~
Androider
If companies could, they would just send your browser a binary blob. From a
business point of view, exposing your inner workings / modules is a no-go.
Same for local apps using Electron, there's a (perceived at least) business
need to obfuscate the code into a big ball of mud that is continuously
changing with every build so external patches cannot be applied, e.g. Slack
doesn't want you to have the ability to read or modify your local Electron
client.

~~~
zelly
They will soon with WASM. I'm pretty sure this is the main reason behind it
being pushed.

------
nbrempel
I’ve used this with my most recent project 30 Hour Jobs. My goal was the
quickest path to launch and this was hilariously easy compared to my old
webpack config!

I can imagine at some point you might need more customizability with a tool
like webpack - or maybe this will always be sufficient?

~~~
wilsonrocks
I had to switch on a project because I couldn't get IE support working :( A
shame (that I have to support IE) because parcel is excellent.

I believe the new version will make it fairly easy to do differential builds -
so users with modern browsers don't have to download all the Polyfilla but it
still works on IE

------
pull_my_finger
I like parcel a lot, but one issue I've always had is that it watches your
node_modules folder. The devs kind of pawned it off as a "feature not a
bug"[1], but it results in tons of warnings etc related to watching too many
files. I've since started using a symbolic link to the actual node_modules
folder, but it's still just 1 extra hurdle that would be nice to not have.

[1]: [https://github.com/parcel-
bundler/parcel/issues/1557#issueco...](https://github.com/parcel-
bundler/parcel/issues/1557#issuecomment-397980426)

~~~
eerrt
After a while, they switched to watching directories instead of files, which
seems to solve the issue you describe of too many watched files.
[https://github.com/parcel-
bundler/parcel/pull/1665](https://github.com/parcel-bundler/parcel/pull/1665)

------
ng12
Has anyone used Parcel as a replacement for create-react-app? I own some tools
for generating React projects in an enterprise environment and CRA
(specifically react-scripts) has been a huge thorn in my side. Most of these
projects are small to medium size and so they don't really warrant custom
Webpack configurations. I'd prefer something with react-script's simplicity
but without it's absurd restrictions.

~~~
jjeaff
Yes. And the create react app documentation actually links to parcel as an
alternative. I messed around with webpack, gulp, and others for weeks trying
to find a good option that could handle my existing code alongside newer code
that would be written in react and that could handle multiple entrypoints. I
had a difficult time with most tools until I tried parcel, and it just worked.

Have an entrypoints for a react app? Include that in the build and parcel can
bundle and deploy with no configuration. It just knows it's react because of
the import react statement. Want to use typescript with react? Just use .ts
files.

So my parcel command while developing is something like 'parcel watch
src/*.ts. I just put my entrypoints there and my components below that. I've
actually been able to just code for a while now without having to fuss with
build tools.

~~~
ng12
Thanks for sharing. What about non-build features like testing and linting? I
think that's the one thing I'd miss from react-scripts.

------
eerrt
Parcel has support for React Fast Refresh!! [https://github.com/parcel-
bundler/parcel/pull/3654](https://github.com/parcel-bundler/parcel/pull/3654)

------
FlorianRappl
We use Parcel in our Microfrontend Framework Piral
([https://github.com/smapiot/piral](https://github.com/smapiot/piral)), too.
Overall, this was an awesome decision. In the past we used Webpack a lot, but
it just does not feel right any more.

I've also written a small article comparing different options:
[https://blog.bitsrc.io/choosing-the-right-javascript-
bundler...](https://blog.bitsrc.io/choosing-the-right-javascript-bundler-
in-2020-f9b1eae0d12b)

------
runarberg
I’ve been moving my projects to using es modules natively (supported natively
in node 13 and with `<script type="module">` in the browser) and it’s pretty
nice. There is no compilation step needed between edit and run. And when its
ready for production, rollup is plenty.

I feel like node getting native es modules was the last step that the
platforms needed to get up to speed with the bundlers. And the state of HTML,
CSS, and JavaScript is good enough to simply use it without any external
helpers (until production that is).

------
zubi
There was a period where I started seeing Webpack everywhere, being used by
everyone, so I felt obliged to try it. I struggled with the concepts and
configuration and eventually realized that I completely failed to figure them
out. It was a heavy blow to my developer self confidence. Fortunately I
recovered when I discovered Parcel shortly after. "No config" immediately
caught me after the frustration. I'm grateful for and still use it.

------
hombre_fatal
I love how it even supports Elm out of the box. It's a great feeling to
replace your complicated web-of-magic-incantations webpack-config.js with a
simple build command that just calls `parcel`.

At the very least, it's nice to default to parcel on a project and then, if
needed, adopt webpack once your project matures the point of needing more
fiddling.

------
0xcoffee
I was amazed when I could point parcel to a html file that imported a
typescript file and it worked. Only downside was that I was importing the
script as a module and then half of the typescript imports stopped working.
Had to bundle everything as one big typescript file to work around it.

I think they fixed this in Parcel 2 but didn't try yet.

------
Zealotux
Parcel looks promising, especially to finally free yourself from Webpack's
configuration soup, and the compilation time gain looks great. I just wish it
has better TypeScript support, it looks like it's still not possible to check
types on compile, which is kind of a deal-breaker for me.

------
leeoniya
also [https://packem.github.io/](https://packem.github.io/)

and another build tool that's perf optimized: [https://github.com/swc-
project/swc](https://github.com/swc-project/swc)

~~~
mischnic
Packem is still only availably as a binary, and they seem very reluctant to
release the source code.

(And swc is more similar to Babel than to Webpack/Parcel.)

~~~
leeoniya
> Packem is still only availably as a binary, and they seem very reluctant to
> release the source code.

[https://github.com/packem/packem/issues/4](https://github.com/packem/packem/issues/4)

oh yikes, the fact that it's closed as "irrelevant" is rather worrisome. how
is it irrelevant to ask where the source code is for a project hosted on an
open source hosting platform.

one of their top talking points is "Its crust is built with Rust", but without
source to verify this it might as well be written in brainfuck.

sorry for linking it :(

~~~
jjeaff
To be fair, the "platform for open source" is itself, also not open source.

------
Waterluvian
I gave this a try for one of my experiments, replacing rollup. Wow. It just
works and cleans up a bunch of dependencies.

All I need now is some one shot solution for eslint + prettier. Right now
that's 7 dependencies, representing almost all the dependencies I add to most
of my mini projects.

------
andraaspar
Parcel is broken on Windows. Since 2018. [https://github.com/parcel-
bundler/parcel/issues/1990](https://github.com/parcel-
bundler/parcel/issues/1990)

------
Waterluvian
How far from zero config do I have to go if I want typescript and jsx? The
result is a single bundle.js?

~~~
PandawanFr
Seems TS is provided by default (tho it will not do any type-checking, you'll
need tsc --noEmit for that). As for JSX, you need a basic tsconfig that
specifies jsx.

src:
[https://parceljs.org/typeScript.html](https://parceljs.org/typeScript.html)

------
a_band
Parcel is one of my favorite open-source projects. Love to see it getting some
attention here.

------
sandGorgon
Is there a Parcel equivalent of create-react-app ?

~~~
swyx
i used to maintain create-react-app-parcel, but lost interest and handed it
off. you might still look into it.

im less interested in replicating the contract of CRA now, and want other
defaults, so i made [https://github.com/sw-
yx/rincewind](https://github.com/sw-yx/rincewind)

~~~
sandGorgon
pretty cool. thanks!

------
nfRfqX5n
is there something better than gulp for older projects that don't use imports?
basically concatting scoped JS

------
ausjke
great and easy alternatives to webpack, I'm surprised its website appears to
be mentioned first time at HN.

~~~
maxfromua
Not the first time
[https://news.ycombinator.com/from?site=parceljs.org](https://news.ycombinator.com/from?site=parceljs.org)

~~~
jjeaff
Considering parcel is listed in the create react app documentation as an
alternative to cra, I'm surprised it hasn't received more mentions.

------
jjordan
How does this compare to webpack?

------
gavreh
Parcel vs Rollup?

------
dblotsky
Just use Make.

Takes just as long to learn, and is transferrable everywhere.

~~~
ricardobeat
These are not task runners. Make alone will give you about 2% of what you'll
need to bundle a modern web app.

~~~
dblotsky
Make can run all the tools like babel, uglify, etc.

------
toastal
We should have a gentleman's agreement to stop saying "blazing" \+ "fast".

~~~
ksec
I think Webpack 5 is around the corner, which was suppose to speedup Webpack
to _blazing fast_ ( With Caching and Hashing if I remember correctly ) .

Not sure if it is up to the speed of Parcel though.

------
bishalb
Does anyone else cringe when they read "blazing fast" X? Seems like "blazing
fast" is thrown around too easily these days.

------
fiatjaf
I still don't understand why everybody is using Webpack when Browserify is
easier, simpler, faster, produces smaller builds, can be understood by a
normal person. Really, the big shift from Browserify to Webpack happened to
fast and without any clear reason.

With that said, it's good that someone is challenging Webpack, as that must
happen for the sanity of all.

