
Parcel: Fast, zero configuration web application bundler - humility
https://github.com/parcel-bundler/parcel
======
merricksb
Discussed 7 months ago:

[https://news.ycombinator.com/item?id=15853149](https://news.ycombinator.com/item?id=15853149)
(435 points/163 comments)

~~~
h1d
I almost feel 6 months apart is qualified for another discussion on this fast
changing ecosystem.

------
Jasper_
I spent the day finally adding a modern build system / bundler to my side
project, and I chose Parcel. Parcel is really cool! I really wish they'd stop
calling it "zero-configuration". It has configuration options (--out-dir,
--public-url), there's just no configuration file for them. I really wish they
would make one, since it's annoying to have your configuration be hidden in a
batch file.

~~~
hazza1
The planned v2 of parcel will have a configuration file.

~~~
chrismorgan
Without investigating, I genuinely can’t tell whether you are joking or not.
It seems plausible, save for the fact that would _completely_ undermine the
primary marketing message.

~~~
jf-
Bear in mind that this is relative to webpack. A few lines practically is zero
compared to a webpack configuration.

~~~
Blaiz0r
Although WebPack 4 has some sane defaults that you can use it zero-config

------
yzmtf2008
Congrats to the Parcel team! Really great work. Having used Parcel in personal
projects for the past year, it really is a great user experience.

Despite what people says in the comments, Parcel has its (great) value. The
ability to import a rust file directly and have it compiled to a web assembly
module for example, is a great piece of engineering and exceeded my
expectations for web build tools. Parcel also hits the sweet spot where it's
both zero-config, and easy to customize if you find the need.

Honestly? Parcel has a better experience than your C++ build tools. Be it
CMake, Ninja, or whatever build tools people use in 2018.

~~~
Nimelrian
> Parcel has a better experience than your C++ build tools. Be it CMake,
> Ninja, or whatever build tools people use in 2018.

I don't think there are many people who'd say that there's any good experience
with using CMake for any slightly complicated project.

------
spankalee
I love that Parcel is out, even if yes it is another bundle, because it helps
highlight the major problem with bundlers right now: they (but especially
WebPack) are a meta-platform over the web unto themselves and they encourage
use of features that are not supported by the web platform, in a way that's
not easily transformed into what the web platform does currently, or will
realistically, support, creating lock-in.

Just as we're getting to the point where many of these tools should be
optional because we have great modern JS and modules support in browsers, and
many projects are already written in supposedly standard modules, many are
blocked from actually shipping code that runs un-built on the browser because
of bundler features like importing images, CSS, etc.

~~~
oweiler
Except we don't have great modules support in the browser.

~~~
spankalee
Chrome, Safari, Firefox and Edge support modules. Firefox is landing
import.meta.url and working on dynamic import() now.

~~~
h1d
Except IE11 will still be around for a while. Till 2020 and 2025 for extended
support.

------
bradknowles
IMO, the fact that 1726 modules is a “reasonable” number for a web app is a
clear indication that there is something seriously wrong with this process.

~~~
yoz-y
I think the JavaScript ecosystem needs something akin to Boost. I do not like
using Boost in C++, however the way their libraries are built and integrated
into standard is awesome.

~~~
alex_suzuki
Wasn't that jQuery?

~~~
yoz-y
Yes, kind of, however jQuery is more geared towards the frontend whereas many
of the packages pulled in now are for backend or general use (your zero-pads
and moment and whatnot)

------
mattbreeden
I hate doing javascript. I have no desire to attempt to understand or mess
with JS or build systems past the bare minimum I can manage to get a project
working so I can move on with my life.

So I tried using this. It was nice while what I was doing fit inside of
everything that was default settings and/or what maintainers used. As soon as
I stepped outside of that I ran into things like having to hope someone
implemented a Parcel plugin for some random transform (an issue that applies
to Webpack, too, but Webpack has so many more users that you're guaranteed
someone actually did make one that actually works correctly), or:
[https://github.com/parcel-
bundler/parcel/issues/645](https://github.com/parcel-
bundler/parcel/issues/645). Having an issue on something as popular as
Bootstrap 4 be open for 6+ months is pretty frustrating. I spent several hours
flailing at this issue to no avail.

I switched to Webpack 4 and had all of my existing build system and some
additional niceties working in <45 minutes.

~~~
vmware505
Actually, if you prefer strickt typed languages, maybe give TypeScript a try.
It is such a beauty, make JavaScript great again. ;)

~~~
worldsayshi
Yes, I would say that typescript is the best way to do JavaScript in 2018. I
just converted a Babel es7 project to typescript. I feel like I ended up with
a simpler build system in addition to type checking and working source maps. I
needed to add a few type declarations to make it build though.

------
jacobsimon
I've used used Parcel for a few projects this year and really enjoyed it for
the most part. I've found it's basically effortless for building static
projects, but its lack of documentation can be frustrating when errors pop up
(e.g. I was stuck on an older version for a while due to some issue with a
newer release) and I still haven't quite figured out the best pattern for
extracting the hashed bundle names for use in other places.

That being said, Webpack 4 (released months ago) shipped with a similar zero
config option, so I'll likely go back to it for future projects.

~~~
oweiler
Webpack's zero config is a joke.

~~~
h1d
I haven't tried Webpack 4 but can you describe what's so bad with its zero
config?

------
crooked-v
The main complication remaining with Parcel, IMO, is one that mostly derives
from the syntax being used: there's no clear way to separate "I want this file
to be added to the bundle, and a string URL for it" and "I want the
appropriate representation of this file's contents".

My line of thought here is helper methods in an empty package namespace, so
that they only exist at build time and are stripped out in the result.

------
codecurve
I love the idea of Parcel but I've struggled with a number of non-obvious
problems when using it on hobby projects.

° Sourcemaps not working (wrong files / no source translation)

° Randomly losing exports (a module with multiple exports where one of them
ends up as an empty object - fix by clearing cache and restarting)

° Errors like "module 71b not found"

° Hot module reload enabled by default, meaning that all top level code runs
again when you reload the code (e.g. here's an extra canvas in your dom)

My preferred zero config setup for hobby projects has become <script
type="module">[1] and a live reload server[2].

If I'm working on a React project then I will always use Create React App when
I can[3].

When I take something beyond the hobby stage and into maintaining it as an
ongoing project, I use TypeScript Quickstart[4]—to abstract the underlying
Webpack config and start writing code immediately.

I'll only reach for Webpack when I know that I need more flexibility than any
of these other tools offer—which isn't very often.

[1]: [https://jakearchibald.com/2017/es-modules-in-
browsers/](https://jakearchibald.com/2017/es-modules-in-browsers/)

[2]: [https://github.com/tapio/live-server](https://github.com/tapio/live-
server)

[3]: [https://github.com/facebook/create-react-
app](https://github.com/facebook/create-react-app)

[4]: [https://github.com/danprince/typescript-
quickstart](https://github.com/danprince/typescript-quickstart)

------
jf-
I think the ultimate solution to bundling is to go the way of the CLIs, and
Angular CLI in particular, where the framework team configures a sensible
default bundle config with a few options exposed via the CLI. The user can
then build with a single command and everything just works. The user can eject
from the CLI and configure manually if needs be, but most of the time that
won’t be necessary.

Bundlers probably have a certain minimum complexity that can’t be reduced if
they want to be universally applicable, but a lot of that can be hidden for
most use cases, particularly if using the same framework.

~~~
awesomepeter
Yup, just FYI Angulars CLI is based on Embers. Just putting it out there
because the oldest thriving framework which put out a lot of great ideas often
gets forgotten in these discussions :)

~~~
jf-
Was not aware, thanks for mentioning it!

------
jillesvangurp
Just tried it quickly; didn't work. It did something and then I got a blank
page. Probably some config missing that it needs but the point is: no zero
conf and doesn't work as advertised.

~~~
h1d
What's the point of posting a problem without actually describing it?

People who haven't tried can't even tell if you just screwed it up or there's
actually a problem.

~~~
jillesvangurp
Was just pointing out that the tool did not work as advertised (i.e. without
configuration). As in parcel index.html does not produce a working app for me.
There's nothing to screw up here. Either that works or it doesn't. In my case,
it doesn't. It fails to self configure as advertised and it fails to tell me
what broke and why (or even that it broke). But it is quite obviously not
producing a working application for me.

I imagine this relates to a whole range of broken assumptions it makes about
where files actually are in my project, how things are configured on my
system, etc. Normally you'd fix that by configuring these things. Since it
doesn't provide a whole lot of documentation or guidance other than this thing
needing no configuration because it is so smart, I decided against pursuing
this thing any further and uninstalled parcel.

------
gvalkov
For a recent project (with modest needs), I just used a short makefile[1] and
plain ES5. I found the experience refreshing as there is definitely peace of
mind in depending on one less black box.

There is indeed something uncomfortable about a big node_modules directory or
a magic build tool. It's almost like bathophobia, where instead of depths
there is 3rd-party javascript code.

[1]: [https://github.com/gvalkov/tailon-
next/blob/master/frontend/...](https://github.com/gvalkov/tailon-
next/blob/master/frontend/Makefile)

------
synthmeat
Gulp has/had the right approach. There's only so much flexibility and
complexity configuration format can support without becoming strange copy-
pasted incantations that can only be reasonably expressed and clearly
visualized through code. And they've proven that, eating Grunt's lunch, but
then they blew it with never-ending alpha and general stewardship fail.

And with regards to Parcel vs Webpack, it's not (at least not yet) even a
competition since webpack 4 is basically zero-configuration and is so much
more advanced tool at all levels.

~~~
spiritcat
Just other day was trying to remember why everyone switched from gulp to
webpack. There was some reason for it right? Or was it just that gulp/plugins
were unstable.

Do remember looking into it for small side project but ended up just using npm
scripts, maybe that's part of it.

------
minpur2
This looks cool, Quick question if anyone is using Parcel with Angular. How
well is this working for you when compared to webpack?

~~~
voltagex_
Might be worth raising an issue for some docs on this.
[https://github.com/parcel-
bundler/parcel/issues?utf8=%E2%9C%...](https://github.com/parcel-
bundler/parcel/issues?utf8=%E2%9C%93&q=is%3Aissue+angular)

------
nkkollaw
I suspect that most services start very lean, and if they become popular
people request more and more stuff and it gets added, making the thing more
complicated.

Webpack is too complicated though, so if this can stay simple, why not.

------
deltron3030
Seems like a nice alternative to more opinionated language dependent site
generators and webapp frameworks built on top of Webpack (ex. Gatsby, Next.js,
Nuxt).

------
ivanfon
Is something really wrong with WebPack? Didn’t we decide that we want more
modularity and plugins, instead of “zero configuration” solutions that lock
you into a few technologies? What about the next hip new frameworks that
release in the future? Will they just be piled into parcel, or will they add a
plugin system? This seems like an unsustainable model.

~~~
thatswrong0
Caching and parallelization are my complaints with WebPack. WebPack doesn't
cache that well out of the box, and plugins like HardSource seem to have
errors often enough that they're kind of annoying. WebPack also doesn't have
parallelization built in, so you need something like HappyPack. Maybe I was
doing something stupid, but I wasn't able to get HappyPack and HardSource to
work together nicely.

~~~
ksec
>Caching and parallelization are my complaints with WebPack

I thought those were fixed in v4?

~~~
thatswrong0
They made it faster, but per the V4 announcement _:

PS: we haven’t implemented Multicore, or Persistent Caching yet (slated for
version 5). This means that there is still lots of room for improvement!!!!

It _is_ coming, which I'm excited about.

_ [https://medium.com/webpack/webpack-4-released-
today-6cdb9947...](https://medium.com/webpack/webpack-4-released-
today-6cdb994702d4)

------
joshwa
Ah, the neverending cycle.

1\. The existing tool is way too complicated to configure and slow. Let me
introduce a new, zero-configuration, blazing fast tool

2\. OK so because it's strongly opinionated there are some things it can't do.
So we'll allow you to extend it via plugins. You'll have to configure this.

3\. Due to the increasing popularity, we are making a meta-version that lets
you re-plug any element in the entire system with one of your own choosing.
You'll have to configure this.

4\. GOTO 1.

~~~
yzmtf2008
I think this is a great exaggeration of the "javascript build tools are hard
to config" meme, and it honestly is obsolete. Maybe the meme was relevant two
years ago, but every since (1) create-react-app and (2) webpack 3, the
configuration story has greatly improved.

With Webpack 4 and Parcel especially, these tool are both _zero config_ and
_configurable_. Your point 1 and 3 are actually not mutually exclusive, and
repeating the meme just sounds like you're perhaps out of the loop for a bit.

While the Javascript developer experience truly was horrible a few years back,
it has dramatically become better. Try it, and you might be pleasantly
surprised :)

~~~
Soinou
I'll be speaking for Webpack, since it's the only one I use for the few
internal applications at work, and I've never really used Parcel yet.

Configuring Webpack is still pretty bad. If the zero config works for you,
great. But if you need to configure it yourself, it's really verbose, it's
really complicated, and the documentation is a bit thin.

SplitChunks in Webpack are like black magic, they work but you don't have any
idea how, and when they don't work, you still have no idea how. And you don't
know if it's because you didn't configure them properly, because you don't
know what is configuring them properly, because the documentation on them is
so bad.

Maybe I'm just bad at configuring Webpack, but I still don't understand how
many things in Webpack work, and it's given me a lot of headaches, even with
the "zero config" Webpack 4.

------
cjhanks
The code looks nice, I hope it has helped you in your life.

But frankly, if a JavaScript developer ever really wants to solve the
problem... Learn enough C++ to write the equivalent code that compiles 6.5M in
0.1 seconds (assuming a nice HD).

~~~
nemothekid
C++ doesn't even compile 6.5M of C++ in .1 seconds.

~~~
cjhanks
If you do absolutely zero instruction optimization or re-ordering. Literally
mapping the BNF grammar to a syntax tree capable of simple syntactic
reduction... I would be surprised if it did not lag behind disk read speeds.

Traversing that tree to remove unambiguous dead branches seems pretty clear.
Perhaps if you get into a tricky manipulation between strings and syntax you
could add a little runtime...

~~~
yzmtf2008
If you do absolutely zero instruction optimization or re-ordering, JavaScript
takes 0 seconds to compile, and you can use almost-complete feature set of
ES6. /s

Come on man, that's beyond the point. Just because JavaScript needs to be
compiled, doesn't mean it has a worse experience than compiling C++.

~~~
cjhanks
Instruction optimization is procedure of measuring expected CPU latency given
the expected current state to identify which instruction set transition is
optimal for the CPU. It would not be applicable to JavaScript unless I missed
something.

Instruction ordering is largely bound to instruction pipelining and the
estimation of CPU instruction transitioning to reduce latency. Given that V8
uses some degree of virtual indirection... I don't think that's possible in
JavaScript.

------
simplecomplex
Please God no. We don’t need another bundler.

Also. What’s up with the obsessive use of emojis everywhere? Take a look at
this issue for example: [https://github.com/parcel-
bundler/parcel/issues/144](https://github.com/parcel-
bundler/parcel/issues/144)

~~~
voltagex_
I work in a beige organisation where we're not allowed to use emojis in
tickets (they wouldn't render correctly on our PCs anyway). I can't wait to
work somewhere else that allows it - I have to spend 8 hours a day at work,
may as well enjoy myself a little bit.

~~~
mirko22
I work somewhere where i can use emojis and fight for not using them cos they
are distracting and don’t add value. If you red scientific paper full of
emojis would you take it seriously?

