Parcel v2


224 points | by jacobwg 6 days ago


  • fishtoaster 6 days ago
    I set up a new project on Parcel*. It was amazing at first for getting going quickly with minimal config, but became increasingly expensive to deal with. Every week or so I'd run into what I'm calling the "webpack tax" where I'd spend twice as long having to figure out how to do something as the price for not using webpack. Every tool out there has a 95% chance of having docs (or at least a blogpost or StackOverflow answer somewhere) showing how to set it up in webpack. Then there's a 50% chance there'll be docs for how to set it up if you're using CRA. And if you're using anything else (eg Parcel), you've got a 30% chance at best to have docs on how to make it work.

    Hopefully this situation improves as more competitors (like Parcel and Esbuild) mature, but at the moment I'd be pretty hesitant to build on anything that's not webpack or webpack based unless you're a lot more confident figuring out build tool setup from first principles than I am.

    * V2, about a year ago, since my options were between the non-production-ready v2 and the explicitly unsupported v1.

    • toastal 6 days ago
      My experience with the “Webpage tax” is every couple of weeks when I upgrade build tooling around one of my Webpack Workspaces, something somewhere silently breaks in the system outputs an exit 0 but with fundamental mistakes. Last week and experimental flag was implicitly enabled with a Webpage version upgrade that broke MiniCSSExtraPlugin (which why at v5 is this still a thing to output CSS as not JS?) and all of a sudden I had no styles. It's in the CHANGELOG for a minor version bump but running NPM/Yarn upgrade gave me a broken build, and trying to tweak my build scripts to find the problem, I got styles outputting but no JavaScript was built. And this has happened on multiple occasions every couple of weeks/months where minor version upgrades to plugins gave me an exit 0 broken build.

      Parcel’s implicit plugin loading with node-gyp and randomly-dowloading-from-the-internet binaries system (rightfully) does not play well with Nix.

      Considering I’m not even leveraging code splitting or many of Webpack’s advanced features, I’m now investigating the cost of switching to something built on esbuild to lessen my Webpack burden and get much better build performance. Honestly makes me miss Tup and Make as front-end tooling exploded with complexity.

      • devongovett 6 days ago
        Note that Parcel’s plugin system is completely different in v2 and the implicit loading is gone.
        • toastal 6 days ago
          That wasn't my experience, but it's been several months since I tested v2. I may have had to specify which plugins to use, but downloading of random binaries was an issues -- albeit this is a larger NPM ecosystem issue assuming read-write capabilities, glibc, x86_64 arch, etc. I've even made some small contributions to Parcel, its blog, and wrote a plugin, but this was before I started using Nix for a lot of things and node-gyp does not like to play well.

          That said, I very much preferred Parcel to Webpack as the JSON5 config was declarative and simpler and the HTML entry point.

          • Vinnl 6 days ago
            Note that Devon Govett, who you replied to, is the main driving force behind Parcel.
            • toastal 6 days ago
              And? I just looked up my old package.json and see the NPM script use `parcel build --no-autoinstall ...` and a pinned version `2.0.0-beta.3.1` which to me says there some genuine autoinstall going on, which is what I meant by "implicit plugin loading", loading/installing some plugins from the ether. Perhaps my wording wasn't clear, but it still was an issue for me.

              Parcel in my experience still came with less issues than Webpack to be clear (and talking about the woes from Webpack was the main reason I commented). Now esbuild is on the front page and we can see some users saying it was a smart switch away from Webpack (

              • Vinnl 6 days ago
                Just thought the additional context could help the conversation :)
                • toastal 6 days ago
                  Also as the esbuild thread alluded, Phoenix (Elixir) and Rails alpha are switching to esbuild because of how many issues were raised in their projects related to things breaking in the Webpack tooling.
      • meowtimemania 6 days ago
        What things are you trying to do that’s not supported with parcel? I think sometimes we make super complex front end build configurations that don’t yield much benefit over something more simple.
        • leloctai 6 days ago
          In my case I actually want it even more simple: not using babel. Parcel silently use babel, which cause problems with other tool in my case and there wasn't any way to turn it off, at least at the time.
          • devongovett 6 days ago
            In v2, there is no transpilation unless you add a browserslist config.
          • FinalBriefing 6 days ago
            This has been my experience, too. Great for getting started quickly on straight-forward projects or prototyping, but even simple projects hit snags.

            If you're certain it covers all of your requirements out of the box, it's a great option.'re probably better off configuring Webpack from the start. I've never hit an issue with Webpack that can't be solved (an likely it has already been solved by someone else).

          • sk55 6 days ago
            This echoes my experience as well.
          • AaronFriel 6 days ago
            > An all new plugin system, which makes Parcel fully extensible. This allows Parcel to scale from small side projects to massive production applications with complex build requirements.

            Everything old is new again! Parcel embarks on the path that Webpack did, and it's only a matter of time before the plugins are doing more and more core work, and Parcel's successor will again rewrite them and bring those in to the core.

            • AnonHP 6 days ago
              This comment by @stupidcar (December 5, 2017) [1] from the first Parceljs post seems pertinent. I’m not pasting the entire comment; visit the link below to read it:

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

              > …


              • repsilat 6 days ago
                I guess the whiggish interpretation is that if each step is an improvement then the cycle represents steady progress, if not arrived at as directly as could be hoped. Maybe a cynic says that the extensions are negative-sum, or the rewrite is (either to adopting teams, or to a fragmented wider community.)

                I'm an optimist, though admittedly entirely ignorant of this project. I think some capacity is sometimes lost when new projects are started with new technologies that don't live up to their predecessors, but that accusations of tool choice being fashion-driven are mostly misplaced. There are real, tangible, frequent improvements, and disruption is probably the price of innovation. And it's a price you can mostly avoid paying if you want to keep using what you're using.

                • duiker101 6 days ago
                  The other day I was playing around with parcel V2 and I ended up having to write a config file for something that I believe was included in v1... The whole point of parcel for me was avoiding config files... I feel like this release is missing the point
                  • FinalBriefing 6 days ago
                    I think they discovered that if a library tries to provide "zero config", users quickly end up needing to configure something, or reconfigure something else.

                    I still don't think that Parcel is right for me given how comfortable I am with Webpack, but I welcome a "simpler config" option. Provide language support, but don't assume I want to use Babel, or PostCSS, or any other build tool.

                • jjeaff 6 days ago
                  I could be wrong, but I don't think webpack ever "just worked" right out of the box to the extent that parceljs does. I was in the middle of all kinds of gulp and webpack configuration when I discovered parcel a few years ago. A single command "parcel watch *.html" just worked. It detected that I was using react, followed the js includes and all the other dependencies and handled hot reloading and typescript and all the included css and sass and everything else. It was magic. It even did yarn add for any new dependency imports that weren't already in the packages.json.

                  My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.

                  • wruza 6 days ago
                    And also go to a vacation at every release, because your config uses plugins that a) can’t keep up, b) can’t help but break previous version compat, and now it’s snafu for few months. And for beginners, good luck finding out the correct set of versions that support what you need simultaneously. One LARGE upside of all-in-one include-all packages is that you can’t find yourself in that sort of a gridlock.
                    • k3liutZu 6 days ago
                      > My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.

                      Uff, really hits the nail on the head from my experience with setting projects in the early webpack days.

                    • dahart 6 days ago
                      > Everything old is new again! Parcel embarks on the path that Webpack did

                      And Webpack embarked on the path that it’s forefathers did.. gulp, babel, browserify, grunt, and others. But that didn’t stop Webpack from improving on what was there.

                      The core thing Parcel does (or at least did when Parcel was started) that is/was a fundamental improvement over Webpack is parse your index.html (or whatever you name it, of course) to figure out what to do. I always thought Webpack was silly for asking a human to re-describe it’s html dependencies. I haven’t used Webpack in the last year, so I’m unaware if Webpack has fixed this shortcoming.

                      • foota 6 days ago
                        At least the core gets better with each new system :-) I joke, but only somewhat.
                        • nextaccountic 6 days ago
                          Who cares? As long as the tools are improving, this shouldn't matter.
                          • tshaddox 6 days ago
                            That sounds...good!
                            • izelnakri 6 days ago
                              controversial comments always make the first page/gets the most attention. I suggest you refrain from them because I found your comment pointless/fake and wrong after using both tools & webpack plugins for many years.
                              • AaronFriel 6 days ago
                                I'm sorry you felt that an observation on the cyclical nature of technology tools was controversial, pointless, fake, and wrong.

                                I think it's pretty impressive if my comment was all of those things.

                                • hsn915 6 days ago
                                  I think anyone who has the misfortune of having to deal with webpack knows the pain very well.
                                  • izelnakri 6 days ago
                                    Webpack is a pain to use I agree, I've never liked webpack. My comment is on the behavior of trying to look smart/funny(meme-y) while lacking actual substance.
                                    • hsn915 6 days ago
                                      When A points out a real problem, and B comments with "old man yelling at cloud". Who's the one exhibiting "problematic" behavior? I think it's B.
                                      • root_axis 6 days ago
                                        A free open source tool exists for you to use if it suits your needs. What exactly is the "real problem" here?
                                        • bryanrasmussen 6 days ago
                                          >A free open source tool exists for you to use if it suits your needs.

                                          I do not believe that webpack suits my needs, it is in my opinion incredibly inferior to Gulp. So Gulp suits my needs.

                                          Nonetheless I have had to basically use nothing but webpack for the last 5-6 years unless I do something for myself! Why is that?

                                          Well it turns out that when I go to work at some place they have set up everything with webpack, why? Well that's what everybody else does, nothing we can do about it now. Hardly anyone in the real world only uses tools because they suit their needs, they use the tools that have been chosen by someone else.

                                          Ok, so then something goes wrong with webpack build, anyone at the place know the depths of webpack and how every different plugin/module is screwed together - nope, we use webpack here but have no webpack experts - so they spend some days fixing things. Or even worse we want something that there is no webpack solution for that we can find - either we need to fix it ourselves with a plugin / module / fork of plugin module we want to extend (after asking fruitlessly on StackOverflow if someone knows) or we have to do a horrible hack to fix it.

                                          I am sure there are some webpack experts out there who take minutes to fix problems they encounter in webpack, but my experience is that a webpack problem any more complex than we don't have a plugin for that file extension seems to require a developer day to fix (not just me as the developer, other developers always seem to take the same amount of time).

                                          now before someone jumps in and cleverly changes my complaints to use Gulp instead of webpack (if you weren't thinking of doing this you can stop reading now) - can you point out to having a similar experience with gulp? Because I can't, and if I wanted to write a gulp plugin (which I have done twice) it was insanely easy because all you have to do is to understand vinyl streams and that's it; everything in Gulp has the same model of how things work - that really speeds up problem solving time.

                                          • hsn915 6 days ago
                                            Choosing tools based on what other people are doing instead of based on understanding your needs is so endemic in the industry it's not even funny. It's not even the juniors that do it. People labeled "senior software engineers" do this.
                                            • root_axis 6 days ago
                                              I'm still not understanding the problem. If webpack doesn't suit your needs then don't use it. If your employer's technical leadership picks technologies based on fashion rather than suitability for the problem that's not a failure of the technology, that same problem surrounds literally every popular technology irrespective of its technical properties.
                                              • hsn915 6 days ago
                                                Are you serious? Here's how you sound to me:

                                                My poop is on the street. If you like it, you can use it. If you don't like, don't use it. What's your problem? If someone shoves my poop down your throat and you don't like it, that's not a failure of my poop. That's a failure of human relationships.

                                                • root_axis 6 days ago
                                                  Your analogy is laughably absurd. Poop on the street is a public health hazard, someone shoving poop down your throat is assault. Comparing such things to free open-source software is borderline trolling.
                                                  • hsn915 5 days ago
                                                    Isn't it great that you can refute any analogy by finding a literal difference between the analogy and thing being explained?
                                                    • root_axis 5 days ago
                                                      Isn't it great that you can defend any bad analogy with a reply that no analogy is perfect? Your analogy makes no sense at all.
                                • dang 6 days ago
                                  Previous thread:

                                  Parcel 2 Beta 3 – improved build performance - - May 2021 (69 comments)

                                  Also related:

                                  Parcel – Fast, zero-configuration web application bundler - - Jan 2020 (201 comments)

                                  Parcel: Fast, zero configuration web application bundler - - July 2018 (91 comments)

                                  Parcel – A fast, zero configuration web application bundler - - Dec 2017 (163 comments)

                                • jeswin 6 days ago
                                  For a while now, I've been using esbuild (swc is an option too) and a few basic shell scripts. I don't miss anything, other than being able to take a break while build happens.
                                  • cetra3 6 days ago
                                    I moved from Parcel (v1) to ViteJS because it felt a bit faster. Is there a performance or other type comparison between Parcel and some of the newer bundlers? (I.e, vite, snowpack, etc..)
                                    • devit 6 days ago
                             has Parcel 2 benchmarks.

                                      The summary is that you should use esbuild (or swc/spack when ready) for new projects and probably switch existing ones as well if feasible.

                                      It's possible that the Parcel 2 version they used is not the released one, so maybe it improved.

                                      • scottlamb 6 days ago
                                        > It's possible that the Parcel 2 version they used is not the released one, so maybe it improved.

                                        I'd guess so because of timing and because the Parcel 2 beta 3 announcement [1] says "10x faster JavaScript compiler written in Rust [...] on top of the SWC compiler". Likely the esbuild folks benchmarked against beta 2 or earlier.


                                        • silasb 6 days ago
                                          Probably should add to the list as well, it's early but has some potential.
                                          • 1_player 6 days ago
                                            Doesn't seem to be open source, only has a macOS binary, you need to request "early access" by joining their Discord... what's their target audience here? Certainly not web developers.
                                            • hsn915 6 days ago
                                              Is there any information other than this home page? like an announcement somewhere, a demo video, or anything similar?
                                            • isthisreality 6 days ago
                                              to be fair, that's without Parcel 2's cache, which surely improves build times considerably
                                              • tuananh 6 days ago
                                                the benchmark looks brutal to other bundler
                                            • hsn915 6 days ago
                                              I really don't understand vite. They use esbuild under the hood for some of the tasks, but they still ultimately use rollup. I tried to use it for a project I'm working on and it was more than 50 times slower than esbuild. (esbuild took half a second, vite took 30 seconds).
                                              • dcre 6 days ago
                                                It uses esbuild for unbundled dev builds and Rollup for bundled production builds.


                                                • rk06 6 days ago
                                                  Vite's main focus is on a fast dev server and provide ultra fast hmr.

                                                  However, it needs source (user code and npm packages) to be in ESM modules, so it uses esbuild for pre bundling npm packages.

                                                  And vite uses roll-up to create a production build with some parts done by esbuild

                                                  • isthisreality 6 days ago
                                                    Vite's goal is a mixture of speed and flexibility. Rollup's plugin system provides the flexibility in exchange for slower build times, but that doesn't affect development speed, because Vite doesn't bundle anything in development (apart from CommonJS dependencies, which are pre-bundled with esbuild).
                                                    • andrew_ 6 days ago
                                                      As other comments have mentioned, they use Roll-up under the hood.
                                                  • herpderperator 6 days ago
                                                    I think is better. It pulls in a much smaller set of packages for a hello-world non-CRA react app. I think it was something like 1.3k lines of yarn.lock for Vite vs 6k lines for Parcel v2. JS projects shouldn't be bloated, even if this would get optimized-out for production.

                                                    In the ideal world, you would use esbuild only, but you still need the other features for development: hot reload, hot module repalcement, and pretty error pages when you cause a RuntimeError.

                                                    • benatkin 6 days ago
                                                      vite uses Rollup, and I think it's probably better too. When I see zero configuration I become less interested in a project, because I like being able to configure things.

                                                      Edit: I found this on Vite's website: "Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build."

                                                      • devongovett 6 days ago
                                                        Parcel 2 does both: it is useful out of the box, and many projects will never need to configure it, but v2 adds a complete plugin system that lets you override and configure everything too. :)
                                                        • benatkin 6 days ago
                                                          Good to hear! I'll give it a look.
                                                        • catlifeonmars 6 days ago
                                                          I don’t think zero configuration is mutually exclusive with full configuration control. Zero config is often just a design exercise in setting reasonable defaults on top of a configurable system.
                                                      • hsn915 6 days ago
                                                        In the real world, you can use esbuild only.

                                                        You actually don't need hot reload or hot module replacement. esbuild is so fast you can just reload the page and it reloads instantly.

                                                        hot reload is really bad with slow bundlers. One of the projects I have to maintain at work has this hot reload feature. Here's how it goes: I edit a sass file, it recompiles in the background for 5 seconds, then reloads 4 or 5 times. Why? Who knows.

                                                        • eyelidlessness 6 days ago
                                                          > You actually don't need hot reload or hot module replacement. esbuild is so fast you can just reload the page and it reloads instantly.

                                                          You don’t actually need any of these tools. But HMR is useful not because build time is slow (even if it often is), but because dev/validation iteration is slow too. TDD can improve some of that, but when you’re iterating on something interactive and want to validate the experience of it (or any number of other circumstances where manual validation provides value), having your setup state preserved can mean the difference between split second validation (with fast tooling) and completely breaking flow.

                                                          • hsn915 6 days ago
                                                            What do you mean by "dev/validation iteration"?
                                                            • snorremd 6 days ago
                                                              Say you're developing a big form with lots of different inputs. When you're iterating on the form you don't want to lose all your form state because you edited some code.

                                                              When you make the change you want to see what that change does to your form in its current state.

                                                              • renke1 6 days ago
                                                                That's very true. I think the most frustrating thing (that I regularly see) is people trying to do a minor fix in a wizard (let's say on the 5th step) and going through every step again just to see if the bug was fixed. Things like HMR can help here.

                                                                That's why things like mock-service-worker or having prefilled Redux stores (or whatever state management you use that allows something similar) are a real time saver.

                                                                Of course fixing the bug based on test is always better, but often you have to fix something visual which is a little bit harder to do with tests.

                                                                • hsn915 6 days ago
                                                                  In those situations I usually just write some throw away code so the application loads up in the desired state
                                                            • alvarlagerlof 6 days ago
                                                              Sounds like you have auto save on.
                                                          • taitems 6 days ago
                                                            I was put onto the incredibly fast esbuild[1] by a colleague and have used it here and there for open source packages. I'd been keen to understand which release of Parcel v2 they benchmarked against as they claim 0.37s to 39.28s on their home page?


                                                            • FinalBriefing 6 days ago
                                                              Those are some really impressive numbers.

                                                              I was really impressed with the speed of Vite, which uses Rollup under the hood. I never had any real complains about Webpack's speed until I tried Vite out. In my experience with Vue apps, the difference between Vite (Rollup) and Webpack was much greater than esbuild's data shows.

                                                              • Xevi 6 days ago
                                                                Vite only uses Rollup for the production build step. During development it uses ESBuild for pre-bundling, and then serves everything as native ESM, that's why it's so fast. They might get rid of Rollup in the future if ESBuild gains more features.
                                                                • akvadrako 6 days ago
                                                                • devongovett 6 days ago
                                                                  I commented elsewhere in this thread but that benchmark is really measuring the performance of Terser, which is used by all of the other tools listed there. Parcel has improved somewhat since that benchmark was last updated but until terser is replaced there’s no competition.
                                                                • willio58 6 days ago
                                                                  My team’s been using parcel for Wordpress dev of all things. The switch to v2 has been interesting.. overall very happy with parcel v2 though, it magically fixed a bunch of issues that we just kind of lived with in v1.
                                                                  • jbverschoor 6 days ago
                                                                    > The zero configuration build tool for the web.JavaScript.CSS.HTML.TypeScript.React.images.SASS.SVG.Vue.libraries.Less.CoffeeScript.Node.Stylus.Pug.Electron.Elm.WebGL.extensions.GraphQL.MDX.XML. Parcel combines a great out-of-the-box development experience with a scalable architecture that can take your project from just getting started to massive production application.

                                                                    Very unclear what it does, until I tried to copy/paste the title. That changing word should just be a list.

                                                                    • Shish2k 6 days ago
                                                                      It’s a web build tool, which does basically the same thing as every other web build tool — it takes a bunch of developer-friendly inputs (multiple files, typescript, JSX, scss, raw images) and turns them into browser-friendly outputs (single-file, vanilla JS, vanilla CSS, optimised images)

                                                                      The selling point for parcel is that it does the above with zero configuration (you point it at your input directory and it automatically figures out which compilers / optimisers to use -- other builders typically require hours of googling for / installing / configuring / debugging plugins)

                                                                    • clmcleod 6 days ago
                                                                      It’s worth noting that Parcel v2 still needs work to support some basic use cases. For instance, it does not correctly build a Sass file that pulls in Bootstrap imports from NPM:

                                                                      We tried switching to Parcel v2 but we had to downgrade back to v1.

                                                                      • russelg 6 days ago
                                                                        I also ran into issues like this while trying to migrate to Parcel 2.
                                                                      • nsonha 6 days ago
                                                                        Used v1 mainly for quick prototyping and playing around with new tech (had rust and fable which I was interested in at the time). Look like they've been removed from official support so at least it's no longer zero config to play with.

                                                                        Having said if this turns out to be a low hassle tool to build library then I might use it. My pain point is the boilerplates involved in building libraries. For apps, I'm pretty happy with nextjs default.

                                                                        • csense 6 days ago
                                                                          So what exactly is Parcel? The website says it has "a new JavaScript compiler written in Rust" but I thought JavaScript was an interpreted language?

                                                                          The JavaScript ecosystem is so dang confusing. I'm glad I'm not a frontend dev who has to deal with that hot mess.

                                                                          • igreulich 6 days ago
                                                                            Calling it a compiler is not great IMO, but it is a js bundler/transpiler.

                                                                            You set it up, and write your js code, and parcel spits out the final, ready to embed in your html file, js and css assets.

                                                                            That's oversimplified, but the basics all the same.

                                                                          • mrgalaxy 6 days ago
                                                                            Anyone here switch from Webpack to Parcel? Or, look into switching and decided not to?

                                                                            I recently upgraded Webpack from 4 to 5 and briefly looked for alternatives, but ultimately just decided to stick with Webpack since it works for us.

                                                                            • hoten 6 days ago
                                                                              I switched from Parcel (v1; had trouble upgrading) to esbuild for my web game, and it's been much simpler. And faster, obviously.

                                                                              If you don't care about having a large plug-in ecosystem, or things like image optimization being handled directly by your bundler (and other stuff, from scanning the linked article), I'd say just go with esbuild

                                                                              • mrgalaxy 6 days ago
                                                                                esbuild definitely caught my eye. I'm now noticing they support CSS and static files, which I guess I didn't realize. Is it easy to setup and configure? Because that is the one part of Webpack I cannot stand.
                                                                                • hsn915 6 days ago
                                                                                  esbuild is not really configuration based like webpack. It takes some config options but you either specify them via the command line or write your own script to build up the config object. (they have a js and go api).

                                                                                  It's so much nicer to use than all the other bundlers.


                                                                                  To clarify, the dev experience is:

                                                                                  - You start with just the basic bundler with simple options you specify on the command line or maybe in a shell script.

                                                                                  - Then you want to do a few more things, so you turn the shell script into a nodejs script (or a Go program).

                                                                                  - You get to make the build script as simple or complex as you want. To your own discretion and to fit your use case.

                                                                                  • hoten 6 days ago
                                                                                    The documentation is top notch. I was able to learn it and switch over to it in about an hour or two for a moderately complex codebase targeting both Node and the web, and using Workers and some code splitting.
                                                                                    • eyelidlessness 6 days ago
                                                                                      ESBuild is very unopinionated and mostly just does the right thing. Some config is available for mundane stuff. The rest it defers to plugins, rather than config. That’s where you have N+1 problems however.
                                                                                  • 1ark 6 days ago
                                                                                    If you and your team know Webpack and the ecosystem of plugins well already, then stick with that. Setting up a new project does not take a lot of time for you I guess. Someone mentioned "webpack tax" when using Parcel, it is real. Parcel is nice, I like it, but you get more control with Webpack.
                                                                                    • devongovett 6 days ago
                                                                                      This was true in Parcel 1, but v2’s plugin system is just as powerful as webpack’s. v2 is all about adding extensibility and control.
                                                                                    • diskzero 6 days ago
                                                                                      I also switched to Parcel. My use case was such that Parcel was a faster and simpler choice. That being said, I am starting to look at esbuild, in the hopes of making builds even simpler.
                                                                                      • mrgalaxy 6 days ago
                                                                                        Parcel definitely looks simpler than Webpack. Of course Webpack tries to advertise itself that way, but it's never the case.
                                                                                      • joshxyz 6 days ago
                                                                                        Moved from webpack to esbuild + postcss. Forced us to reduce our dependencies, and it also improved our iteration speed. Of course that comes with dropping the need for core-js and focusing on evergreen browsers that esbuild targets.
                                                                                        • akdor1154 6 days ago
                                                                                          I switched to Snowpack for a small project (TS+Preact), reasonably straightforward and strong recommendation. Would not consider Parcel, seems like a step backwards in performance.
                                                                                          • SCLeo 6 days ago
                                                                                            I am just using parcel for my small projects because it is simple. It is actually zero configuration. Setting it up takes about 1 minute.
                                                                                          • kabes 6 days ago
                                                                                            So, with most of this discussion leaning towards esbuild/vite because it's simpler and much faster. What are the reasons one would use parcel instead of esbuild?
                                                                                            • jkrubin 6 days ago
                                                                                              I would like to see a comprehensive benchmark of parcel v2 and vite.