
Parcel – A fast, zero configuration web application bundler - KeitIG
https://parceljs.org/
======
TY
Came here to puff about "yet another bundler".

Then read all of the docs in 15 minutes and realized that I might like this.

Then I used it and I know that I'll keep using it, unless there are any
showstoppers.

Great job, Devon!

------
JepZ
Browserify, Webpack, Gulp, Grunt: everything nice and shiny, but the one JS
lib that stands out for me is Rollup.js[1]

Why? Because Rollup.js makes it possible to structure code into modules in a
way that is backwards compatible and future proof. Yeah it takes some getting
used to and it is not yet as simple as it could be, because integrating libs
which are not yet available in the module format, takes some manual
configuration, but once you know how to use it you won't want to got back.

I can highly recommend it, not because it is the hottest tool out there, but
because I think it has a much higher long-term value than most JS libs.

Parcel seems to have a similar functionality but due to the wide range of
other functions it comes with, I think there is a much higher chance that it
will be rendered obsolete in the near future. Rollup.js on the other hand
_focuses_ on the combination of modules to a single bundle which will continue
to be required for the foreseeable future.

[1] [https://rollupjs.org](https://rollupjs.org)

~~~
vladimir-y
Webpack actually does the same (it's module bundler), browserify too (but in a
more limited way). Gulp ant Grunt are not the module bundlers at all, but
simply a task runners - absolutely different things. Btw there is also FuseBox
module bundler, seems also with a focus on performance and configuration
simplicity.

~~~
JepZ
You are right, they are not exactly the same type of programms. Nevertheless,
most of the time they are used for the very same thing: to transform your
development source to format which is best to be delivered to the browser
(bundling).

Actually, I still use Gulp to call Rollup.js as it is more flexible and allows
me to use features which are not the scope of Rollup.js (e.g. automatic
browser reload). My point is, that the exact thing Rollup.js focuses on is
very important for the long-term development of JS: Modularization. Yeah, I
know thats an upcoming part of the JS standard. But with Rollup.js you can use
it today, as it has various adapters for legacy formats and therefore you have
a tool which allows you a smooth transition into the future ;-)

~~~
vladimir-y
Sure, but just don't limit yourself by the Rollup.js only. Again Webpack is a
module bundler (modularization is there), and it was a module bundler before
Rollup.js went public. So you can use all the ES6/7/TypeScript stuff
(including modularization) using Webpack, Rollup, Fuse-box, and other
bundlers, the difference is in the configurability, performance, configuration
syntax, etc. Though yes Rollup provides some specifics, which might be more
suited for the standalone libraries releasing, while Webpack would be better
choice for the complex app development (that is it not supposed to be released
as a library, but deployed somewhere as a complete app).

------
tonysickpony
As a person who is not well-versed in front-end technology, it will be great
if the author(s) could provide more comparison on the website against some
other tools that serve the similar purpose in aspects other than performance.
For instance the by comparing the scope the problem each solves, the ideology
behind each project, or even a side by side configuration file.

------
stupidcar
The eternal cycle of developer tool bullshit:

1\. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily
configurable!"

2\. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need.
No bloated configuration. No huge ecosystem of extensions. Simple,
straightforward and fast."

3\. "SuperTool™ v1.0.0 is great! But our setup really needs it to do something
a bit different, so we've hacked in this extension."

...repeat for a while...

10\. "Introducing SuperTool™ v2.0.0, which now has a more flexible API and
configuration , allowing many former hacks to be done in a straightforward
way."

11\. "SuperTool™ v2.0.0 is great! But our setup really needs it to do
something a bit different, so we've hacked in this extension."

...repeat for a while...

20\. "Introducing SuperTool™ v3.0.0, with a whole new, flexible, pipeline
based API. Everything is a plugin! There's even a plugin to send email!"

21\. "Ugh, SuperTool™ v3.0.0 is overcomplicated, bloated, slow and
unnecessarily configurable!"

22\. "Introducing HyperTool™ v1.0.0, which just does the stuff you really
need. No bloated configuration. No huge ecosystem of extensions. Simple,
straightforward and fast."

~~~
SadWebDeveloper
Welcome to developing in 2016-201X, were you spend 60% of your time
configuring tooling, 35% developing test and 5% developing your app.

~~~
nip
Or stick to something that works for you and keep using the same tool over and
over again.

No one is forcing you to use the latest bundler / tool / programming language.
Let others experiment. You’ll be happy to reap the benefits of their work when
something mature comes out of it.

~~~
nathan_long
> No one is forcing you to use the latest bundler / tool / programming
> language.

Tell me that when you get turned down in a job interview because you don't
know <JS framework of the year>.

~~~
tropshop
Try working on your positioning so that you are not hitched to the <JS
framework of the year>. You will forever be competing with the low end of the
market if you cannot market yourself.

~~~
FLUX-YOU
Your advice basically tells them to get out of JS development because
businesses continually hitch themselves to <JS framework of the year>.

This stuff comes up in interviews. Trying to avoid answering direct questions
about a framework and answering with "Well I can learn it really quickly
because I'm a good vanilla JS Dev" doesn't fly all the time. If you can't
answer direct questions about a framework, they will pass on you if they get
someone who can answer those questions.

It has nothing to do with marketing yourself.

~~~
tropshop
What you described is a hiring problem. Marketing is knowing who your buyer is
and finding creative ways to get their attention.

------
pier25
I think it's super cool.

I've been configuring Webpack projects for almost 2 years now and I'd rather
use Parcel tbh. My only problem is the lack of plugins such as loading .vue
files.

~~~
hanley
+1 for Vue support

~~~
supermdguy
And the over complexity begins...

It would be nice though

------
segphault
With transitive dependencies, the total install footprint for this is 689
packages weighing in at 77MB.

This isn't reducing complexity, it's just taking all the junk you'd normally
have in your bloated boilerplate and putting it directly into the build tool.
I'm not convinced that's a good idea.

~~~
Klonoar
Mmmm, so... sub 100MB for a bundler + compiler + etc?

    
    
      - Xcode, for iOS/Mac Development, is usually around 5GB (and 
      no, even if you remove every single simulator, it's still over 100-200MB).
    
      - Android Studio is roughly the same deal as Xcode.  
    
      - I've not used Windows so I can't say for sure, but I'd be surprised if the various tech there doesn't follow this pattern.
    

77MB is nothing, and if you care about this, you're caring about the wrong
things.

~~~
segphault
689 packages is enormous surface area for a leftpad-like (or worse) failure.
Given that nobody is auditing those packages and many of the people who
maintain them aren't adhering to best security practices[1], I don't think
taking nearly 700 dependencies that you are going to treat like a black box is
a safe or responsible choice.

Xcode and the Android SDK each come from a single vendor who provides an
integrated development stack and presumably vets the contents. Does anybody do
that with these npm packages?

It seems like every time I run the du command in my node_modules folder, I
find some crap that shouldn't be there. Earlier this year, I submitted a PR
that reduced the size of the babel react preset install footprint by about a
third, just by removing a totally unused dependency that nobody noticed. I
don't think the contents of npm packages get nearly enough scrutiny and it
scares the hell out of me.

[1] [https://www.bleepingcomputer.com/news/security/52-percent-
of...](https://www.bleepingcomputer.com/news/security/52-percent-of-all-
javascript-npm-packages-could-have-been-hacked-via-weak-credentials/)

~~~
fatso83
Build tool. Not app code. How is security relevant here?

~~~
segphault
And you don't care if a malicious party compromises the development machine on
which it runs? I can think of a whole lot of really damaging things that
somebody could do running arbitrary JavaScript code with user-level privileges
on thousands of developer workstations.

With various CI setups and some server-side rendering configurations, there
are potentially scenarios where build tooling actually do run in environments
where there are higher risks, though it's not as applicable in this specific
case.

------
stevefan1999
The two coolest things about Parcel for me, are 1) multi-core support, and 2)
a simpler, ES6-esque API. Without these two distinct elements, I think Parcel
is nothing more than a simple Webpack boilerplate which could easily been
generated by yeoman.

I see its potential regarding Parcel’s competitiveness against Webpack, but it
also has worsen the JavaScript fatigue, which is considered a nightmare for
many newcomers webdevs because of huge fragmentation and thus bigotry in the
industry.

------
conatus
Is my career as a Webpack whisperer at an end?

 _cries tears of joy_

;-)

~~~
jameskegel
Go, you're free now.

------
aphexairlines
It would be nice if these bundlers could help publish npm packages that vend
non-JS assets (html, stylesheets, fonts, images) in a way that's easily
consumed by other packages.

For example, if one of the JS modules in a library package says "import
classes from './styles.scss'" and an application package imports that JS
module, the application should somehow end up with the CSS output from
styles.scss without having to configure Sass itself, and without having to
include the entire stylesheet from the library package.

~~~
JepZ
Actually, you can do that with rollup.js and riot.js. Components written with
riot.js contain all their HTMl, CSS and JS (preprocessors can be used too).
Rollup.js can import those components like normal js modules and at runtime
riot.js injects the HTMl and CSS.

The only downside is that you either deliver one large bundle with mixed
HTML/CSS/JS content to the browser or have to use some complicated
configuration the split at least the CSS to a seperate file.

------
newsbinator
I've been using [http://brunch.io](http://brunch.io) and enjoying it. Far less
configuration than Webpack.

~~~
Blaiz0r
I love brunch but I can't find a community for it, what do you do when you
need support on a plugin or help understanding something?

I have a few github issues open that haven't been touched in months!

[https://github.com/brunch/brunch/issues/1752](https://github.com/brunch/brunch/issues/1752)

~~~
newsbinator
100% agree that support is a major problem. I had to figure it all out for
myself, through trial and error.

------
seekbeak
I had my eye on [http://fuse-box.org/](http://fuse-box.org/) for a while, and
tried a few sample projects with it. It has a lot of the same promises as
Parcel appears to have. Multicore is exciting for me, which Fusebox doesn't
have. So... many... choices...

------
plurby
It would be great if the author taken any of the HNPWA project and replaced
WebPack with Parcel so you can compare the setup and actual configuration
needed. WebPack is currently a standard and the community is great so I'm not
seeing this replacing it in any way.

------
chickenfries
I have no problem with ditching webpack for another tool if it's faster and of
similar or better quality. Is anyone using this in production and want to
share their experiences?

------
spondyl
Should main.css be included in the index.html example?

This just confused me for some reason but it's more me focusing on the wrong
thing, haha

~~~
BlakePetersen
It's injected into the main.js file which is added via index.js to the page

------
thelarkinn
From the webpack team to Devon:

Thank you so much for this work! Not only are we happy to see a real contender
in the bundling space, but also look forward to not only work together, but
also learn from parcel in ways we can help make webpack more flexible and easy
to use for those who want "zero configuration".

Welcome to the bundler family!

Sean webpack team

------
superasn
Really happy that besides being fast they made a priority to keep the
configuration simple.

I love webpack to death but there are just so many parts that I keep getting
confused, esp with things like "!" in in require, always copy-pasting the same
boilerplate code over and over to for sass, es6, etc. I know it may be more
flexible but sometimes you just want things to work and can't be bothered with
too many details. Laravel did this with elixir where it wrote a wrapper just
to do it (which lets you just get on with your work without having to learn
another tool). This too seems to be focused on that. Great job!

------
pbreit
Didn't see any info that would give me an impression of the possibility if
this getting any traction which I think would be even more important than any
specific benefits.

------
cvburgess
This looks awesome!

After reading the docs though I couldn't find any mention of tree-shaking or
other things that would shrink the final bundle size. Any word on that front?

~~~
lewisl9029
This is what I was wondering as well.

Especially since Webpack's tree-shaking doesn't _really_ work for a lot of
third party libraries:

[https://github.com/webpack/webpack/issues/1750](https://github.com/webpack/webpack/issues/1750)

I imagine Rollup might do a bit better on that front since its the bundler
that popularized tree-shaking in the first place. Can anyone with experience
with Rollup comment on this?

------
doublerebel
Looks like a well-thought-out approach to a clientside JS bundler.

Is this officially backed by one of the author's employers or any other
organization? I've seen too many projects (including major parts of bundlers
browserify, gulp) die early when a sole author is forced to move on. Beyond
the technical advantages, if I knew a company had already invested resources
it would give me a solid business reason to switch.

------
bovermyer
I am not the target audience for this.

However, my first reaction was "yet another build tool, huh?"

My next thought was "...I must be getting old."

~~~
ardi93
Wait for another 6 months, and we may have "yet another build tool" again

------
pedalpete
Is anybody running a project with webpack that has a 20s rebuild time?

Or if somebody has switched from webpack to parcel, can they give an idea of
the performance improvement?

We've got a moderate sized app, and webpack rebuild (typescript, server-side
react, client side js bundle, css export) is less than 3 seconds.

~~~
cygned
We have a React app with roughly 100k LOC and a lot of SASS that takes about 4
minutes now to create the bundle on my MacBook Pro 2017.

~~~
joekrill
That's probably the _initial_ build, though, right? If you've already got dev-
server running and it has to rebuild, it shouldn't have to rebuild the entire
bundle again.

~~~
milesokeefe
Also every time you add/remove a file or make similar breaking changes.

------
dandare
> Bundle all your assets

Can someone ELI5 what is bundling and what problem does it solve?

~~~
sthatipamala
Sure. Programmers usually group logically-related functions/classes/components
into smaller files.

The logic for web "applications" these days can be complicated and involve
loading hundreds of such files. If loaded individually, this requires a lot of
HTTP requests and results in a slow page load time.

Bundling is similar to a static linker in that it produces a single binary out
of all its dependencies. This can be loaded with a single HTTP request,
cached, zipped, whatever.

------
statueq
When one deploys something like this in production, how do you interact with
an internal API? Surrendering control of my url routing always causes problems
for me.

------
thrownaway954
how does this handle existing 3rd party jquery plugins? The single biggest
problem and configuration nightmare I always face is bundling something like
CKeditor.

------
maxpert
So far from comments I have collected following bundling tools:

\- Webpack

\- Rollup

\- Fuse-Box

\- Brunch

\- Browserify

------
kriss9
React and node bundling and compilation ?

------
gyrgtyn
Which bundler does this use?

~~~
davidnagli
It is a bundler...

------
xchaotic
Explain to me why do we web app need bundlers?

~~~
GijsjanB
I long for the day I can use browser native import to retrieve all my modules
and deps, but at this point it doesn't resolve node_modules and that makes it
unusable to me and the reason I am using a bundler.

------
j4ship
why are we not just using bash scripts ???

-you can log output -perfectly capable of handling your unique build style -no setup (pretty much) -just call the command lines of other tools like (less.c, yui-compressor.jar ... etc) for compliation tasks

talk about over engineering. The thing is that the reason we dont have 1 to
rule them all now is because no one has ever objectively argued why one is
better than the other.

If we could just get command line equilvalents for things like ember-cli that
didnt require npm then we would be good. Npm is the thing holing us back , we
dont need it to do command line processing. Its a bloated middle man. Please
command line tool gods , offer your tool outside of the javascript eco system.
Build it in java and export to jar or c and allow us to worry about the
stitching

Question , what is the thing npm/grunt/gulp gives us that cannot be done with
bash, if all the tools we used were command line executables?

~~~
jhurliman
I think you may be confusing npm with something else? npm is a package
manager, and it does run as a command line tool. Similar to how apt-get is the
command-line frontend for a package ecosystem. npm also includes npx, which
allows you to directly run any command line utility in the npm ecosystem
without installing the package first.

Try running `npx ember-cli` directly in your terminal.

~~~
j4ship
all you say is correct but im not confused. node and npm is require to run
many command line tools (grunt, gulp ...etc). I think this is an unnecessary
overhead if we could get these tools to just be built as standalone command
line tools and then we can just use bash. Im asking for a particular feature
that comes from this environment that I dont have in bash? Why do I need this
environment.

I have a sense that webpack is the same, its a bloated environment. I dont
need an all in one solution for a build process. Just give me the tools, ill
use bash and call it a day. So Im just asking, is there something Im missing?
What is the feature from these environments that I can directly preform by
calling a script from bash? Why cant we just pull that script out into a
command line tool and then devs can use it to their liking, pipe its output to
a folder, cat that file to soemthing else, call another tool to minify the
results, move all the contents to the dist folder.

Node just doesnt seem to give me any more power as a dev (build wise), why is
it so important to the space.

Hats off to frontend engineers, the space has evolved to something respectable
but I feel like over engineering is a pursuit of community. Its like they keep
making new tools, to encapsulate more features and then post on HN and say
"Look at this cool new way to do things that fixes that problem you really
didnt have".

No ones webpack was bottlenecking their work, im guessing you can choose what
to build and when so you dont have to do a full build every time. No one is
going to choose a build system because of its blazing speed. I would rather
not have people work on these problems that dont really need to be solved.

~~~
manigandham
Node is a runtime, npm is a package manager. Together they let you download
code (js or otherwise) and run it.

This is the same as Java (JVM), .NET (CLR), and plenty of other languages. You
can compile to a native assembly if you like (similar to C++ or Go) but it's
not necessary when you have fast runtimes and JIT compilation.

Everything you listed for functionality is possible today - while also letting
people write and ship code to multiple platforms quickly.

