It should be noted that Parcel was created in house at Adobe and then open sourced.<p>I think it's always nice to call out the contributions certain corps are making to the OSS world.
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.<p>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.
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.<p>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?<p>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.<p>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:<p><a href="https://packets.pangdox.com/packets/loginservice/server/0002.html" rel="nofollow">https://packets.pangdox.com/packets/loginservice/server/0002...</a>
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!<p>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.<p><a href="https://parceljs.org/rust.html" rel="nofollow">https://parceljs.org/rust.html</a>
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.
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.<p>[1]: <a href="http://npm.anvaka.com/#/view/2d/parcel" rel="nofollow">http://npm.anvaka.com/#/view/2d/parcel</a><p>[2]: <a href="http://npm.anvaka.com/#/view/2d/webpack" rel="nofollow">http://npm.anvaka.com/#/view/2d/webpack</a>
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.<p>Has anyone used Parcel and Webpack and still prefers Webpack?
Ah, the classic build tool evolution cycle!<p>1. Become frustrated with complex build tool<p>2. Write a new tool that is dead simple, opinionated (your opinions), convention over configuration, etc<p>3. Post to HN<p>4. Achieve adoption<p>5. As more people use the tool, feature creep ensues<p>6. In order to satisfy diverse use cases, make everything modular and configurable!<p>7. Tool slows and becomes impossible to manage<p>8. GOTO 1.
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.<p>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.
I really dislike the huge, multi-faceted build systems calling themselves bundlers.<p>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.<p>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.<p>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.<p>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.<p>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.<p>[1]: <a href="https://web.dev/web-bundles/" rel="nofollow">https://web.dev/web-bundles/</a>
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).
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<p>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.<p>Of course this assumes browser targets, which I feel like is the main target for these tools most of the time.<p>[0] <a href="https://v8.dev/features/modules" rel="nofollow">https://v8.dev/features/modules</a>
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!<p>I can imagine at some point you might need more customizability with a tool like webpack - or maybe this will always be sufficient?
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.<p>[1]: <a href="https://github.com/parcel-bundler/parcel/issues/1557#issuecomment-397980426" rel="nofollow">https://github.com/parcel-bundler/parcel/issues/1557#issueco...</a>
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.
Parcel has support for React Fast Refresh!! <a href="https://github.com/parcel-bundler/parcel/pull/3654" rel="nofollow">https://github.com/parcel-bundler/parcel/pull/3654</a>
We use Parcel in our Microfrontend Framework Piral (<a href="https://github.com/smapiot/piral" rel="nofollow">https://github.com/smapiot/piral</a>), too. Overall, this was an awesome decision. In the past we used Webpack a lot, but it just does not feel right any more.<p>I've also written a small article comparing different options: <a href="https://blog.bitsrc.io/choosing-the-right-javascript-bundler-in-2020-f9b1eae0d12b" rel="nofollow">https://blog.bitsrc.io/choosing-the-right-javascript-bundler...</a>
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.<p>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).
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.
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`.<p>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.
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.<p>I think they fixed this in Parcel 2 but didn't try yet.
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.
I gave this a try for one of my experiments, replacing rollup. Wow. It just works and cleans up a bunch of dependencies.<p>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.
Parcel is broken on Windows. Since 2018. <a href="https://github.com/parcel-bundler/parcel/issues/1990" rel="nofollow">https://github.com/parcel-bundler/parcel/issues/1990</a>
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.<p>With that said, it's good that someone is challenging Webpack, as that must happen for the sanity of all.