from Hacker News

Parcel – A fast, zero configuration web application bundler

by KeitIG on 12/5/17, 5:05 PM with 163 comments

  • by TY on 12/5/17, 8:35 PM

    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!

  • by JepZ on 12/5/17, 11:17 PM

    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

  • by tonysickpony on 12/6/17, 12:46 AM

    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.

  • by stupidcar on 12/5/17, 6:02 PM

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

  • by pier25 on 12/5/17, 7:17 PM

    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.

  • by segphault on 12/5/17, 7:43 PM

    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.

  • by stevefan1999 on 12/5/17, 6:21 PM

    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.

  • by conatus on 12/5/17, 6:05 PM

    Is my career as a Webpack whisperer at an end?

    cries tears of joy

    ;-)

  • by aphexairlines on 12/5/17, 11:25 PM

    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.

  • by newsbinator on 12/5/17, 7:34 PM

    I've been using http://brunch.io and enjoying it. Far less configuration than Webpack.

  • by seekbeak on 12/5/17, 8:31 PM

    I had my eye on 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...

  • by plurby on 12/6/17, 12:04 AM

    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.

  • by chickenfries on 12/5/17, 7:58 PM

    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?

  • by spondyl on 12/5/17, 6:10 PM

    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

  • by thelarkinn on 12/8/17, 3:18 AM

    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

  • by superasn on 12/5/17, 8:00 PM

    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!

  • by pbreit on 12/5/17, 5:46 PM

    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.

  • by cvburgess on 12/6/17, 12:57 AM

    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?

  • by doublerebel on 12/5/17, 11:17 PM

    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.

  • by bovermyer on 12/5/17, 7:04 PM

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

  • by pedalpete on 12/5/17, 9:09 PM

    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.

  • by dandare on 12/5/17, 11:03 PM

    > Bundle all your assets

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

  • by statueq on 12/6/17, 5:44 AM

    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.

  • by thrownaway954 on 12/5/17, 6:43 PM

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

  • by maxpert on 12/6/17, 3:58 AM

    So far from comments I have collected following bundling tools:

    - Webpack

    - Rollup

    - Fuse-Box

    - Brunch

    - Browserify

  • by kriss9 on 12/6/17, 2:19 AM

    React and node bundling and compilation ?

  • by gyrgtyn on 12/6/17, 1:59 AM

    Which bundler does this use?

  • by xchaotic on 12/5/17, 9:27 PM

    Explain to me why do we web app need bundlers?

  • by j4ship on 12/5/17, 6:33 PM

    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?