13 ms·

Parcel – Fast, zero-configuration web application bundler

347 points by gilad 7y ago

nbrempel 7y ago
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 7y ago
  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
leeoniya 7y ago
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 7y ago
  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 7y ago
    > 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 7y ago
      To be fair, the "platform for open source" is itself, also not open source.
no_wizard 7y ago
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
- joduplessis 7y ago
  2020...
- TheRealPomax 7y ago
  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.
  - no_wizard 7y ago
    Efficiency with tree shaking is still very important, which is easier to manage with a bundler.
  - Androider 7y ago
    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.
choxi 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.
      - TheRealPomax 7y ago
toastal 7y ago
We should have a gentleman's agreement to stop saying "blazing" + "fast".
- lucisferre 7y ago
  Can we agree to stop using the phrase "gentleman's agreement" while we're at it? It's unnecessarily exclusive and plays up the relatively true stereotypes about the members of HN.
  - scrollaway 7y ago
    I don't know if you're familiar with the expression, but you don't have to be a man to enter a "gentlemen's agreement". You don't even have to be a gentleman for that matter. Of course, "gentlemen's agreement" is actually what it's called in French as well, and we don't go around thinking it's exclusive to French people because it uses English words (not that we don't do that with other terms…). It's just what it's called, and been called for hundreds of years. ---- Edit: OK this is way off-topic but I can't help but snicker a bit when I see these kinds of comments. The idea that we even genderize words is very arbitrary in the first place, and very inconsistent between languages. French for example has the word "écrivain" (author) which is very masculine-sounding and as such sounds weird when used for women; but the feminine "écrivaine" sounds atrocious to French speakers. Our canadian friends exported the word "auteure" (feminine of auteur; phonetically identical). It's a whole thing. Apparently we used to use "autrice" which actually rings pretty nice (similar to acteur / actrice == actor / actress). You'd be hard pressed to see the debate in English around Author / Authoress. These are potentially legitimately exclusionary though, because it's not completely absurd to think that grammatical rules can influence how friendly we perceive a profession to be to that sex; eg. "fireman" vs. "firefighter", or in french "Femme de ménage" [cleaning lady] vs. "aide ménagere" [cleaning helper]. Point is, there's no reason why most of these words can't be made gender-neutral in the first place. English speakers are lucky to have a mostly gender-neutral language at all. Did you know that in french, Banks, postboxes, cars and churches are feminine, whereas computers, telephones, ovens and monasteries are masculine?
    - 7y ago
ausjke 7y ago
great and easy alternatives to webpack, I'm surprised its website appears to be mentioned first time at HN.
- maxfromua 7y ago
  Not the first time https://news.ycombinator.com/from?site=parceljs.org https://news.ycombinator.com/from?site=parceljs.org
  - jjeaff 7y ago
    Considering parcel is listed in the create react app documentation as an alternative to cra, I'm surprised it hasn't received more mentions.
zelphirkalt 7y ago
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.
- protiup 7y ago
  hello
- devongovett 7y ago
  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. :)
  - jcpst 7y ago
    That is the definition for convention over configuration. Zero Config means no configuration, more like what harp.js does.
  - qbaqbaqba 7y ago
    parcelrc would be a nice addition.
    - devongovett 7y ago
      Coming in Parcel 2! :) https://github.com/parcel-bundler/parcel/blob/v2/packages/core/parcel/README.md#parcel-config https://github.com/parcel-bundler/parcel/blob/v2/packages/co...
      - jonilsson 7y ago
        That’s awesome. Been eagerly awaiting this release
frankpf 7y ago
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
- wwright 7y ago
  Do you have a breakdown of the impact of those numbers? What functionality differences do you get thanks to those dependencies (more compatibility, smaller bundle size maybe)? What are the concrete downsides of those dependencies (how much space or bandwidth do they take for for devs, are there known security or stability concerns)? It’s hard to make a judgement off of just the dependency numbers.
- TheRealPomax 7y ago
  Why would the dev footprint matter? whether it depends on 10 or 10,000 packages, if you managing your project sensibly, `parcel` is a build-only dependency, installing only on your machine, and on CI instances (most of which can take advantage of cached depenency lists already anyway).
  - qeternity 7y ago
    More dependencies mean greater attack surface as we’ve seen in npm. I agree with your view, but there is a reason to prefer fewer deps even in dev.
    - mycall 7y ago
      Less code, less bugs.
      - e12e 7y ago
        This is especially true as projects age; i recently ran into yet another bug installing dependencies for a rails app, because of a patch-version change on a small library had a bug that manifested with our otherwise old/legacy stack. I could see a similar situation for projects stuck on older version of node, lodash or whatever, where some tiny component break everything. Its always fun when you have a known good build, make a change and trigger an error - only to realize the error is in your build system/dependency graph due to someone else doing testing on a different subset of versions than you need - not due to the change you just did.
eatonphil 7y ago
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.
XCSme 7y ago
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).
FlorianRappl 7y ago
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-in-2020-f9b1eae0d12b https://blog.bitsrc.io/choosing-the-right-javascript-bundler...
pull_my_finger 7y ago
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#issuecomment-397980426 https://github.com/parcel-bundler/parcel/issues/1557#issueco...
- eerrt 7y ago
  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
- devongovett 7y ago
  We’ve actually rewritten our watcher for Parcel 2 as a cross platform C++ module and it should be much more efficient. :) http://github.com/parcel-bundler/watcher http://github.com/parcel-bundler/watcher
- jessaustin 7y ago
  Haha, Chokidar [0] strikes again! So much time could have been saved by so many devs on Linux if that package had saner defaults. More than one of my package.json .scripts objects have "sysctl fs.inotify.max_user_watches=32768" embedded somewhere... [0] https://www.npmjs.com/package/chokidar https://www.npmjs.com/package/chokidar
eerrt 7y ago
Parcel has support for React Fast Refresh!! https://github.com/parcel-bundler/parcel/pull/3654 https://github.com/parcel-bundler/parcel/pull/3654
jjordan 7y ago
How does this compare to webpack?
hombre_fatal 7y ago
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.
macawfish 7y ago
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 7y ago
  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
  - deleted 7y ago
    [deleted]
  - jchw 7y ago
    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 7y ago
      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
Waterluvian 7y ago
How far from zero config do I have to go if I want typescript and jsx? The result is a single bundle.js?
- PandawanFr 7y ago
  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
joshwa 7y ago
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.
- quaunaut 7y ago
  Parcel's been around for well over a(two?) year(s) now and actually instigated a lot of change and refinement in the bundler market. Most now have zero-config options available, either as a result of Parcel coming on the scene, or with inspiration from it.
  - e12e 7y ago
    Thank you for bringing up how new Parcel is. It'll be interesting to see how we as an industry manage ten year old legacy projects built on top of nodejs/js. You know, when there's a sudden request for a new feature in a project that's been ticking along for five years - and you need to install a development environment to add said feature - but the build system has been abandoned for three years...
- devongovett 7y ago
  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! :)
runarberg 7y ago
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).
spankalee 7y ago
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/
- why-oh-why 7y ago
  Web Bundles are absolutely unrelated to Parcel and Webpack. The output of these two can just be wrapped in a Web Bundle or you can make it yourself. It’s like saying a garage is the solution to your moving needs.
- devongovett 7y ago
  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.
- rolltiide 7y ago
  its like when SDKs started calling themselves OSes, that was pretty confusing
kresten 7y ago
I met a software engineer once and said “what do you do on your team?” He said “I’m the webpack developer”.
- bdcravens 7y ago
  Some teams have build engineers.
  - deleted 7y ago
    [deleted]
- stefano 7y ago
  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 7y ago
    Pretty sure it was a joke.
    - kresten 7y ago
      Absolutely not a joke.
- JMTQp8lwXL 7y ago
  This may not be a popular opinion, but if you need to dedicate a single FTE to your webpack configuration, something sounds amiss. Alternatively, if that's your engineers only skill (building webpack configs), that also sounds quite suspect. In most projects, the webpack configs are not edited often, maybe unless you're upgrading a new major version of Webpack itself.
  - ironmagma 7y ago
    They're not edited often because they're hard to edit. Many times webpack issues just get deferred or ignored because no one has the time to investigate them.
ng12 7y ago
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.
- jdmg94 7y ago
  I think Parcel would be a great option for your use case, shameless plug I have a boilerplate repo you could fork to get started: https://github.com/jdmg94/minimum-parcel-lib https://github.com/jdmg94/minimum-parcel-lib
- ratww 7y ago
  I use Parcel by default in such projects. Out of the box, with the default configuration, it already supports JSX, including hot-module reloading. So yes, it could be a replacement.
- jjeaff 7y ago
  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 7y ago
    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.
dblotsky 7y ago
Just use Make. Takes just as long to learn, and is transferrable everywhere.
- ricardobeat 7y ago
  These are not task runners. Make alone will give you about 2% of what you'll need to bundle a modern web app.
  - dblotsky 7y ago
    Make can run all the tools like babel, uglify, etc.
- rejschaap 7y ago
  Are there any good examples of projects using Make for a web app?
  - dblotsky 7y ago
    Facetious answer: Are there any good examples of projects using Parcel for a web app? ;) Real answer: probably, but a ton of production code is closed-source. But why restrict to web apps? Most influential software projects in the world use Make.
jchw 7y ago
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.html https://packets.pangdox.com/packets/loginservice/server/0002...
- JMTQp8lwXL 7y ago
  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.
vecinu 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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.
nfRfqX5n 7y ago
is there something better than gulp for older projects that don't use imports? basically concatting scoped JS
bishalb 7y ago
Does anyone else cringe when they read "blazing fast" X? Seems like "blazing fast" is thrown around too easily these days.
- deleted 7y ago
  [deleted]
0xcoffee 7y ago
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.
gavreh 7y ago
Parcel vs Rollup?
zubi 7y ago
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.
a_band 7y ago
Parcel is one of my favorite open-source projects. Love to see it getting some attention here.
fiatjaf 7y ago
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.
Waterluvian 7y ago
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.
sandGorgon 7y ago
Is there a Parcel equivalent of create-react-app ?
- swyx 7y ago
  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 7y ago
    pretty cool. thanks!
k_bx 7y ago
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 7y ago
  what do you expect when compiling js with js to js?
  - pdimitar 7y ago
    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.
andraaspar 7y ago
Parcel is broken on Windows. Since 2018. https://github.com/parcel-bundler/parcel/issues/1990 https://github.com/parcel-bundler/parcel/issues/1990
Zealotux 7y ago
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.

347 points by gilad 7y ago

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 7y ago
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

leeoniya 7y ago

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 7y ago
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 7y ago
  > 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 7y ago
    To be fair, the "platform for open source" is itself, also not open source.

no_wizard 7y ago

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

joduplessis 7y ago
2020...
TheRealPomax 7y ago
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.
- no_wizard 7y ago
  Efficiency with tree shaking is still very important, which is easier to manage with a bundler.
- Androider 7y ago
  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.

choxi 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
    - TheRealPomax 7y ago

toastal 7y ago

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

lucisferre 7y ago
Can we agree to stop using the phrase "gentleman's agreement" while we're at it? It's unnecessarily exclusive and plays up the relatively true stereotypes about the members of HN.
- scrollaway 7y ago
  I don't know if you're familiar with the expression, but you don't have to be a man to enter a "gentlemen's agreement". You don't even have to be a gentleman for that matter. Of course, "gentlemen's agreement" is actually what it's called in French as well, and we don't go around thinking it's exclusive to French people because it uses English words (not that we don't do that with other terms…). It's just what it's called, and been called for hundreds of years. ---- Edit: OK this is way off-topic but I can't help but snicker a bit when I see these kinds of comments. The idea that we even genderize words is very arbitrary in the first place, and very inconsistent between languages. French for example has the word "écrivain" (author) which is very masculine-sounding and as such sounds weird when used for women; but the feminine "écrivaine" sounds atrocious to French speakers. Our canadian friends exported the word "auteure" (feminine of auteur; phonetically identical). It's a whole thing. Apparently we used to use "autrice" which actually rings pretty nice (similar to acteur / actrice == actor / actress). You'd be hard pressed to see the debate in English around Author / Authoress. These are potentially legitimately exclusionary though, because it's not completely absurd to think that grammatical rules can influence how friendly we perceive a profession to be to that sex; eg. "fireman" vs. "firefighter", or in french "Femme de ménage" [cleaning lady] vs. "aide ménagere" [cleaning helper]. Point is, there's no reason why most of these words can't be made gender-neutral in the first place. English speakers are lucky to have a mostly gender-neutral language at all. Did you know that in french, Banks, postboxes, cars and churches are feminine, whereas computers, telephones, ovens and monasteries are masculine?
  - 7y ago

ausjke 7y ago

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

maxfromua 7y ago
Not the first time https://news.ycombinator.com/from?site=parceljs.org https://news.ycombinator.com/from?site=parceljs.org
- jjeaff 7y ago
  Considering parcel is listed in the create react app documentation as an alternative to cra, I'm surprised it hasn't received more mentions.

zelphirkalt 7y ago

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.

protiup 7y ago
hello
devongovett 7y ago
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. :)
- jcpst 7y ago
  That is the definition for convention over configuration. Zero Config means no configuration, more like what harp.js does.
- qbaqbaqba 7y ago
  parcelrc would be a nice addition.
  - devongovett 7y ago
    Coming in Parcel 2! :) https://github.com/parcel-bundler/parcel/blob/v2/packages/core/parcel/README.md#parcel-config https://github.com/parcel-bundler/parcel/blob/v2/packages/co...
    - jonilsson 7y ago
      That’s awesome. Been eagerly awaiting this release

frankpf 7y ago

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

wwright 7y ago
Do you have a breakdown of the impact of those numbers? What functionality differences do you get thanks to those dependencies (more compatibility, smaller bundle size maybe)? What are the concrete downsides of those dependencies (how much space or bandwidth do they take for for devs, are there known security or stability concerns)? It’s hard to make a judgement off of just the dependency numbers.
TheRealPomax 7y ago
Why would the dev footprint matter? whether it depends on 10 or 10,000 packages, if you managing your project sensibly, `parcel` is a build-only dependency, installing only on your machine, and on CI instances (most of which can take advantage of cached depenency lists already anyway).
- qeternity 7y ago
  More dependencies mean greater attack surface as we’ve seen in npm. I agree with your view, but there is a reason to prefer fewer deps even in dev.
  - mycall 7y ago
    Less code, less bugs.
    - e12e 7y ago
      This is especially true as projects age; i recently ran into yet another bug installing dependencies for a rails app, because of a patch-version change on a small library had a bug that manifested with our otherwise old/legacy stack. I could see a similar situation for projects stuck on older version of node, lodash or whatever, where some tiny component break everything. Its always fun when you have a known good build, make a change and trigger an error - only to realize the error is in your build system/dependency graph due to someone else doing testing on a different subset of versions than you need - not due to the change you just did.

eatonphil 7y ago

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.

XCSme 7y ago

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

FlorianRappl 7y ago

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-in-2020-f9b1eae0d12b https://blog.bitsrc.io/choosing-the-right-javascript-bundler...

pull_my_finger 7y ago

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#issuecomment-397980426 https://github.com/parcel-bundler/parcel/issues/1557#issueco...

eerrt 7y ago
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
devongovett 7y ago
We’ve actually rewritten our watcher for Parcel 2 as a cross platform C++ module and it should be much more efficient. :) http://github.com/parcel-bundler/watcher http://github.com/parcel-bundler/watcher
jessaustin 7y ago
Haha, Chokidar [0] strikes again! So much time could have been saved by so many devs on Linux if that package had saner defaults. More than one of my package.json .scripts objects have "sysctl fs.inotify.max_user_watches=32768" embedded somewhere... [0] https://www.npmjs.com/package/chokidar https://www.npmjs.com/package/chokidar

eerrt 7y ago

Parcel has support for React Fast Refresh!! https://github.com/parcel-bundler/parcel/pull/3654 https://github.com/parcel-bundler/parcel/pull/3654

jjordan 7y ago

How does this compare to webpack?

hombre_fatal 7y ago

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.

macawfish 7y ago

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 7y ago
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
- deleted 7y ago
  [deleted]
- jchw 7y ago
  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 7y ago
    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

Waterluvian 7y ago

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

PandawanFr 7y ago
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

joshwa 7y ago

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.

quaunaut 7y ago
Parcel's been around for well over a(two?) year(s) now and actually instigated a lot of change and refinement in the bundler market. Most now have zero-config options available, either as a result of Parcel coming on the scene, or with inspiration from it.
- e12e 7y ago
  Thank you for bringing up how new Parcel is. It'll be interesting to see how we as an industry manage ten year old legacy projects built on top of nodejs/js. You know, when there's a sudden request for a new feature in a project that's been ticking along for five years - and you need to install a development environment to add said feature - but the build system has been abandoned for three years...
devongovett 7y ago
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! :)

runarberg 7y ago

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

spankalee 7y ago

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/

why-oh-why 7y ago
Web Bundles are absolutely unrelated to Parcel and Webpack. The output of these two can just be wrapped in a Web Bundle or you can make it yourself. It’s like saying a garage is the solution to your moving needs.
devongovett 7y ago
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.
rolltiide 7y ago
its like when SDKs started calling themselves OSes, that was pretty confusing

kresten 7y ago

I met a software engineer once and said “what do you do on your team?” He said “I’m the webpack developer”.

bdcravens 7y ago
Some teams have build engineers.
- deleted 7y ago
  [deleted]
stefano 7y ago
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 7y ago
  Pretty sure it was a joke.
  - kresten 7y ago
    Absolutely not a joke.
JMTQp8lwXL 7y ago
This may not be a popular opinion, but if you need to dedicate a single FTE to your webpack configuration, something sounds amiss. Alternatively, if that's your engineers only skill (building webpack configs), that also sounds quite suspect. In most projects, the webpack configs are not edited often, maybe unless you're upgrading a new major version of Webpack itself.
- ironmagma 7y ago
  They're not edited often because they're hard to edit. Many times webpack issues just get deferred or ignored because no one has the time to investigate them.

ng12 7y ago

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.

jdmg94 7y ago
I think Parcel would be a great option for your use case, shameless plug I have a boilerplate repo you could fork to get started: https://github.com/jdmg94/minimum-parcel-lib https://github.com/jdmg94/minimum-parcel-lib
ratww 7y ago
I use Parcel by default in such projects. Out of the box, with the default configuration, it already supports JSX, including hot-module reloading. So yes, it could be a replacement.
jjeaff 7y ago
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 7y ago
  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.

dblotsky 7y ago

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

ricardobeat 7y ago
These are not task runners. Make alone will give you about 2% of what you'll need to bundle a modern web app.
- dblotsky 7y ago
  Make can run all the tools like babel, uglify, etc.
rejschaap 7y ago
Are there any good examples of projects using Make for a web app?
- dblotsky 7y ago
  Facetious answer: Are there any good examples of projects using Parcel for a web app? ;) Real answer: probably, but a ton of production code is closed-source. But why restrict to web apps? Most influential software projects in the world use Make.

jchw 7y ago

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.html https://packets.pangdox.com/packets/loginservice/server/0002...

JMTQp8lwXL 7y ago
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.

vecinu 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.

nfRfqX5n 7y ago

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

bishalb 7y ago

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

deleted 7y ago
[deleted]

0xcoffee 7y ago

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.

gavreh 7y ago

Parcel vs Rollup?

zubi 7y ago

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.

a_band 7y ago

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

fiatjaf 7y ago

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.

Waterluvian 7y ago

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.

sandGorgon 7y ago

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

swyx 7y ago
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 7y ago
  pretty cool. thanks!

k_bx 7y ago

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 7y ago
what do you expect when compiling js with js to js?
- pdimitar 7y ago
  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.

andraaspar 7y ago

Parcel is broken on Windows. Since 2018. https://github.com/parcel-bundler/parcel/issues/1990 https://github.com/parcel-bundler/parcel/issues/1990

Zealotux 7y ago

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.