Parcel 2 Beta 3 – improved build performance | Hacker News Reader

Parcel 2 Beta 3 – improved build performance

v2.parceljs.org

248 pointsbpierre69 comments

It's so encouraging to see esbuild and swc grow in popularity, along with the lightweight dev build vs full production build approach. I made the switch from Parcel v1 to vitejs recently on some personal projects and seeing how fast it starts up and processes changes still has me feeling excited. I wonder how many other frontend tool would be good fits for being written in rust or go.

And how long before this approach becomes the de facto industry standard?

Hopefully within a year or two.

Most of the devs would use build higher level build tool like vite, create-react-app or custom build pipeline. Thus only small number of devs, who are directly involved in build process, need to make the change.

The biggest upside of Parcel to me is not speed (though that's a nice bonus). What I like the most about it is the fact that literally all I need to use it is run `parcel public/index.html` and it'll figure out the technology I'm using and just work.

Both in React and Elm, it's made the friction of starting a new app much more tolerable, considering now I don't need to bring all the baggage that `crate-react-app` and the likes carry. Thank you!

I used it when I was getting into frontend development, after years in the backend, and loved parcel for this reason. Webpack struck me as lunacy.

Unfortunately nowadays I work with create-react-app or Gatsby because parcel gives me huge bundles, or breaks with tree-shaking on.

Really excited about parcel 2 though, I tried the alpha and it didn't work for me but hopefully this does.

I’m happy to see this. After a breaking change in a Parcel (v1) update caused us some trouble a little while back, we took the opportunity to start trying out Parcel 2. At the time, source maps were broken and the fix went in just after the beta release we were using, but the pace of development since then has been impressive.

The SWC-based transpilation looks like another big improvement. For anyone else who had a similar configuration to us, with some Babel packages installed to support Jest for running tests regardless of what Parcel was doing with the main build process, this also looks interesting, though we haven’t tried it yet:

https://swc.rs/docs/usage-swc-jest/

Edit: We have now tried it, but sadly several tests broke due to parsing problems. The cause remains a mystery so far, because the offending lines are in our application code and not our test files, and that same code does appear to build OK via Parcel. So it appears that SWC itself, at least as Parcel is using it, can parse everything involved, but for some reason to be determined, installing @swc/* packages directly as devDependencies and configuring the Jest transform for the relevant source files to use @swc/jest is not a drop-in replacement for the Jest+Babel combination we were using before. If anyone else has had more luck getting this working, and similarly getting ESLint to work well without needing Babel packages after moving other tools to use SWC, details would be appreciated! Otherwise, it looks like we’ll still need Babel for now to run the testing and linting tools, even if Parcel is using SWC for its builds.

I started prototyping a @parcel/jest preset and a @parcel/register package that would help with this. Basically it would use Parcel for builds when using other tools like testing frameworks. Potentially we could do something for ESLint as well. It's probably a post-2.0 feature, but hopefully that could help simplify this a bit.

I think that would be useful eventually, but unfortunately my experience trying beta 3 this evening has been disastrous, so I’d definitely encourage you to focus on stability and reliability of the main build system first. Right now, it seems the only way to successfully build our code using beta 3 is to have none of the old Babel-related packages and config around any more, but that means we can’t use other essentials like Jest or ESLint that also rely on Babel. So unfortunately it looks like our current choices with Parcel are using Parcel 1 (recently broken in many ways as other comments have noted), Parcel 2 beta 2 (which was mostly working OK for us, though sourcemaps were broken) or Parcel 2 beta 3 (doesn’t look viable at all based on tonight’s experiments). Right now this project is only at prototype-to-MVP stage in a stealth-mode startup, so it’s worth spending some of our time to experiment with different tools and infrastructure if it gets us to a good set-up for the long term, but I hope you get to production-ready before we do! :-)

Would be great if you could open a Github issue describing the problems you ran into when using your existing Babel config. That should still work just as before

I used Parcel 1 for several months on personal projects before getting frustrated and switching back to Webpack. Having spent all those hours getting Parcel to work for me and troubleshooting it, and ultimately failing to adopt it, I'd like to say I learned something. In particular, it clarified my own values about writing software for other people to use.

I think Parcel 1's biggest issue was being really ambitious, and then never reaching maturity, in that it had bugs that weren't fixed. It wasn't maintained. So it had its own file watcher, for example, I believe, which is great in theory, but not when it's buggy and unmaintained. My personal style would be if I'm going to write my own version of something, write it in a really high-quality way, and keep it simple, either in API or implementation. Maybe reuse the same module for Parcel 2 and improve it, keeping the same API, or if I'm going to rewrite it, use the rewritten module in Parcel 1, or something. I wouldn't just write my own library for X, and Y, and Z, and put it out there, get a lot of people using it, and then move on. I love writing my own versions of things and taking on fun and ambitious projects, but I'd rather nobody use the code I write in my spare time, for free, and don't want to maintain, than create a liability for people.

Another issue I ran into is Parcel insisted on running "npm install", which was a feature that you couldn't turn off even if it didn't suit your project structure. This violates a few principles of mine.

It's an attempt to be "magical" in order to reduce the amount of configuration. "Magic" is not a good thing. Think about what makes a magic trick a magic trick: obfuscation. It's magic because you don't know what's happening, but you get one moment of delight out of it. Overall it increases complexity; it's the opposite of making things simple. Rich Hickey talks about how "simplicity" properly means simplicity of behavior, not fewer words on the screen. Keep the tool simple and understandable, and the way you instruct it what to do simple and understandable. If you want something to work well out of the box, by all means, build popular things like TypeScript into the core; have sensible defaults and explain what they are. But configuring a piece of software is a dialogue where you learn what the capabilities of the program are. There's no place for "do what I mean" in good UX.

Also, build tools should not treat development as something that happens from a unix shell, and try to "automate" it by shelling out to this and that. That's error-prone and likely not to be very universal or focused. Imagine if Webpack's core shelled out to "git" or something (to make up a random example). It would be ridiculous.

The biggest way to improve on Webpack IMO would be to make something that is both easy to get started with and easier to understand and customize for professional developers. Keep in mind that Webpack has been mature now for a long time, and it has extensive docs and guides, and tons of plugins, and you can write your own plugins without too much fuss... any alternative that is buggy (until further notice, maybe years from now if ever) and poorly documented (until further notice, ditto), and not inherently simpler or easier to understand or troubleshoot, while also having less of an ecosystem of available plugins, etc. is just not a good substitute.

As a quick counter - I’ve had a lot of success using parcel straight out the box, both for personal projects and internal projects in big tech.

To be fair there are definitely times I’ve run into issues, [there’s still an active issue I encountered ~12 months back with including postcss :,( ], but I find such issues are usually faster to solve than looking up the web pack equivalent.

I expect the utility of usin parcel depends on the complexity of the project.

> Another issue I ran into is Parcel insisted on running "npm install",...

We use Parcel 2 with yarn 2 pnp builds - it never runs "npm install", nor does it ever create a node_modules directory.

Used parcel for quite some time, but switched some time ago to: https://esbuild.github.io/

Wondering how new parcel performs against esbuild?

Hi, I'm kinda new to the web development world, do you have a guide on how to set up esbuild to compile and minimize a project built with typescript and sass?

I wouldn't recommend setting it up yourself. Try Vite instead.

Even as an exercise to understand how it works?

For a beginner, I wouldn't recommend vite just yet. There are still rough edges (like browser load time being unbearably slow): https://github.com/vitejs/vite/issues/3208

If you're starting out, I'd suggest spending more of your time in a higher level of the stack (like writing application code, learning React/etc), rather than spending time deeper down in the plumbing, especially if you're using cutting-edge pieces in the build pipeline.

Could be nice but I'll be avoiding parcel like the plague after being confronted by its complete lack of maintenance of parcel v1 while v2 is in beta, and not the working kind of beta, the broken kind, while the solution to old problems is "use parcel 2" (https://github.com/parcel-bundler/parcel/issues/5695 https://github.com/parcel-bundler/parcel/issues/5294) . In the end I replaced parcel with webpack, less sexy but it's kind of the standard.

Ya, we are having the same problem. V1 has some broken parts, but so does V2 and documentation is sparse.

There's a roadmap section saying explicitly that they're not RC yet:

https://v2.parceljs.org/blog/beta3/#roadmap

So it was expected that they would be breaking stuff on their way. I would rather say "I'll keep an eye on Parcel until it becomes stable".

This information shouldn't be hidden in some document, it should be one of the first things they tell you about in their README and through their versioning (0.1 and 0.2 instead of 1.0 and 2.0).

Sorry about that. It's difficult to maintain effectively two large open source projects like this simultaneously, especially since this is a side project for most of us. We've probably dropped the ball a little, especially since v2 has taken a long time to build. But the good news is we are getting very close. Docs and migration guides are our main priorities next.

You don't have to be sorry, you're providing a high quality open-source product for free. It just is what it is.

Addendum: I manage a very small open-source product (https://www.planimeter.org/grid-sdk/), and when you're creating something that competes with an established incumbent, all you can do is your best and focus on the most impactful features. Individuals like the one above saying things like, "I'll be avoiding parcel like the plague," is really disheartening, but try and focus on their concerns more than the actual words they use.

Frustrated people are a goldmine for feedback that many projects simply do not receive. Take it in stride, know that you have something others do not, and use it to your advantage. It can be hard to separate your feelings from the words used, but there are diamonds there.

Great comment. I think this applies for pretty much all products or projects, especially in their early stages. There will always be people who don’t get it or have different priorities. It’s ok. When I showed people early versions of EnvKey[1], it felt like half loved it and half thought it was completely pointless. /shrug. At the time I found it discouraging, but now I see that getting even a single person to genuinely love what you’ve built is a major accomplishment and a really good sign that you’re on the right track.

If you can find one, you can find ten. If you can find ten, you can find a hundred. And so on.

It’s also extremely important to remember that the opposite of love is not hate, negativity, or criticism. It’s indifference. Harsh critics can become some of your best users/customers/advocates if you’re able to learn from them and win them over.

1 - https://www.envkey.com

That's a healthy attitude, I'll try to remember that one next time I get harsh feedback.

It's tough to separate my ego from my work.

for what its worth i think adobe pays devon to work on tooling (parcel and react aria|spectrum) somewhat full time and he even has a team around him. but no doubt its just extraordinarily hard to do regardless

I am paid to work on react-aria/spectrum. Parcel is a side project.

thats... just incredibly impressive. hats off!

Don't sweat it, in hindsight the tool just isn't for me (though it was great while it suited my needs). I'm affraid one reason for these issues is that parcel tries to do everything at once with as little configuration as possible. When it works: great. When it doesn't: not-so-great.

Sure the out of date dependancies thing could be seen as a problem with post-css plugins that require a newer version, but the unfortunate fact is that in webdev land, everything seems to evolve at a breakneck pace, foregoing backwards compatability. And when some part doesn't match, the buildtool suddenly becomes unusable. (webpack is way less easy to setup, the flipside is you can for example choose your postcss version)

This is why it's dangerous using cutting edge software. All in all if they have a small team I'd also point them to v2 for a fixed problem.

Rather than backport to some beta version.

(Not giving Parcel zero blame in how ready they present themselves).

Both issues you linked are about upgrading to newer versions. For these kind of issues saying use the new version is completely fine. There were no security risk. No bug that something essential isn't working. It literally please update the software so a new version of some dependency is supported. I would have done the same.

> Could be nice but I'll be avoiding parcel like the plague after being confronted by its complete lack of maintenance of parcel v1 while v2 is in beta, and not the

You beat me to it here; it’s a shame. That was my experience, too.

I really like how Go and Rust are enabling a new generation of dev tools. I don't know if it's because they're popular at the moment and the open source ecosystem is growing so lots of people use them, or if it's a more real trend. Still, I think they both have qualities to make this kind of tools easier to make than before.

> ~10x faster without Terser, and ~3x faster when minification is enabled

Any plans to replace Terser with something in Rust?

Indeed. There is currently an SWC minifier project that is in progress. The maintainer of Terser is helping with it, and the Parcel team will likely help with that as well after we ship the stable Parcel 2 release. :)

Great news, but that PR just got merged a few hours ago!

https://github.com/swc-project/swc/pull/1302

I don't know if it's just me but I find migrating from Parcel 1 to 2 exceedingly hard and frustrating. I tried a few times for the previous betas, and just spend 2 more hours trying and still failed.

I'd love to finally benefiting from tree shaking and faster build times but I can't get anything to work. I hope they'll improve for the stable version, because Parcel 1 promise was that it just magically worked, which it did! I'd hate for Parcel 2 to regress on this side.

Hah, I literally spent a day trying to use parcel to optimize a good old fashioned HTML+CSS+JS static site that's not an SPA. Webpack would be a pain to set up and all other bundlers were lacking for such an use case. Parcel 1 worked great on my machine, and then on the server decided to flatten all files to a single folder - effectively breaking the site. I had no clue as to why, probably something related to having low memory, and the reigning response on the issue tracker was 'forget about v1, use Parcel v2'. So I tried installing and running it on my machine but it would get stuck building unless I gave it a '--no-cache' option (took a while to figure that out), and then on the server the thing wouldn't even (npm) install. Each time I tried it failed kind of differently, mostly because of node-gyp, other times because of weird GLIBC. After all that I just gave up, maybe in a month I'll be in the mood to set up the Webpack madness - but it's more likely I'll end up rewriting the whole site as an SPA because the bundler gods demand it be so.

If you decide to do an SPA, I'd recommend Next.js, because even if you use zero of the features and just put everything in a single index.jsx component, it does all the Webpack stuff for you. It also has some other useful stuff like easy support for rendering plain Markdown files into static files at build time, so you can use it as a more capable alternative to tools like Jekyll [1].

[1]: https://nextjs.org/blog/markdown

Just use create-react-app if you don't need any of the features provided by next.js.

https://reactjs.org/docs/create-a-new-react-app.html#recomme...

Yeah, I love next.js. I'm much more willing to go that route than fight Webpack.

I commit the mistake of doing SPA,

ONCE.

But happily revert back. I have a single build.sh script with the proper build steps (them are so simply that make or other thing is excessive).

So, if you already know how do thing step by step, just do that!

I'm not sure if I'm a dinosaur or not, but for "old fashioned" HTML+CSS+JS static builds I've rolled my own Gulp setup that does what I tell it to. It's an investment of a couple days I'm sure, but have yet to just try Webpack to see how well it works for that purpose too, can anyone else comment?

Being stuck in Visual Studio 2019 right now for other reasons, I've been using some of it's "Lib Man" client-side library installers to help reduce the amount of gulp required too. Basically all your vendor/polyfill "lib" can just be brought and managed with a couple of clicks.

I also tried that, but didn't find any pre-made gulpfiles for it and after half an hour of trying to make one I decided it wasn't worth the effort, but it's definitely still a great tool.

half an hour... wow, well if you find something that easy let me know.

If you want to specify your supported browsers and utilize transpiling (babel), maybe do some image minification (svgo), compile using the latest sass module features (dart sass), create separate script bundles for required/deferred JS with revision hashes (rev), dynamically generate test/demo HTML files and test them (backstopjs) ... I can't imagine there is a system out there that can handle even half of those things so easily. I always assumed I would need to tell the system what to do.

If you do decide to go looking around at Gulp again, for myself after reading a few articles on Gulp setups I googled for "github gulpfile.js" to see what others had done as well and that helped.

Well, Parcel touts minification, removing unused code, transpiling, and other goodies. If it worked, it really would have been perfect, I could have set it up in minutes. The half-hour I mentioned for Gulp was only enough to make me realize that it would have taken me way longer than I wanted to spend on this problem just to shave a few hundred kilobytes of an early stage website (my main goal), not how much I wanted to spend to get a specific grocery list of features done.

So is this another independent JS compiler implementation comparable to ES Build?

Yes, Parcel is now using SWC under the hood which is written in Rust (esbuild is written in Go), and is esbuild's main competitor/alternative.

Are they competitors? I thought SWC is a transpiler and ESBuild is a buildtool. I think any tree-shaking or code splitting that Parcel has is being done somewhere else.

True, but how many projects will use either one directly and not as a part of a larger toolkit like vitejs and now parcel?

I use just esbuild for prod compilation. For dev we still use webpack (with webpack-esbuild since it’s much faster than babel).

Is it a good idea to use a completely different compiler toolchain for dev vs prod? I don't know enough about their internals but that seems like a recipe for weird behavior in production.

It's a tradeoff. Given that you have a staging environment that behaves like production, you want dev to be the fastest environment as possible, so that you can iterate quickly to develop features and fix bugs, and validate them later on staging. Of course, the closer you are to prod the better, but when you have to chose for dev between speed vs reliability and the difference is high, speed is better (higher morale, more features deployed, the occasional bugs related to the different environments that were not catched by staging (why? need one more test) can be quickly fixed - most of the time)

esbuild is perfect for adding to a go server app that needs to do some basic bundling. Just add it as a go module dependency, add a few go generate comments to use it to bundle your JS code, and you're done--you don't need nodejs or anything else installed.

esbuild does transpiling too, for example it can pull out typescript annotations or handle JSX transforms. It doesn't support transpiling down to ES5 though like swc. In general both tools are pretty similar, when you get down to it they're just a class of tool to take JS code, produce a AST, and then perform various transformations to the AST and write it back out as JS.

Awesome to see progress on this front making it into tools devs use day-to-day.

Babel compilation is, by far, the slowest part of our full-stack build. That includes turning java source into jvm bytecode.

Obviously, it's great that we get tools that provides such improvements, but somehow I feel that JS should not be that slow. I expect it to be about 3 to 5 times slower than lower-level languages, but when the difference exceeds 10 times, it means that the Babel's code is not written very efficiently. Another thing, is that usually you only need to optimize a few critical places, and that will give the biggest improvement. So I wonder if it is possible to optimize or rewrite some parts of Babel into a faster language, but keep all of its extensibility and ecosystem. Maybe projects like esbuild or swc will provide insights for Babels' team.

Yep, this is true. In fact, we already improved performance by over 25x by optimizing algorithms in JavaScript. As covered in the blog post, this rewrite was motivated by more than just performance and does include algorithmic improvements as well. We figured that while we were rewriting we might as well also use a language with more predictable performance traits. But, your points about extensibility does still stand, and that's something we hope to look into more in the future.

Sucrase is what you're looking for. When converting to ES6+, it's actually almost 2x as fast as esbuild on a single thread (though slower in aggregate).

As they point out, there's a JIT warmup time. Testing against small projects that don't allow this makes JS transpilers look much worse than they actually are in real-world projects.

https://github.com/alangpierce/sucrase

https://github.com/alangpierce/sucrase/blob/main/benchmark/b...

Sucrase is quite fast indeed, but some of the trade-offs make it a very difficult choice. It will silently compile invalid JS, and is not easily extensible, so you’ll end up bringing in more tooling on top of it to support things like css modules or a framework like svelte. I don’t think it will survive for long.

It’s for good reason that the docs end on this note:

> You should think carefully before using Sucrase in production. Sucrase is mostly beneficial in development, and in many cases, Babel or tsc will be more suitable for production builds.

Wow, parcel is already insanely fast (coming from webpack), can't wait to see even more perf improvements.

Amazing job

Some past threads:

Parcel – Fast, zero-configuration web application bundler - https://news.ycombinator.com/item?id=21961963 - Jan 2020 (201 comments)

Parcel: Fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=17547433 - July 2018 (91 comments)

Parcel – A fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=15853149 - Dec 2017 (163 comments)

I'm always happy to hear about performance improvements to JS dev tooling. In recent years significant improvements have already been made, but it's still... slow.

However, I have concerns about using Rust here. Not because it's Rust specifically, but because it means yet another native dependency. I've done my best to eliminate any native code from projects because they would always cause problems sooner or later. Mostly later when coming back to an old project. Are there any plans to optionally ship the compiler as WASM to avoid this?

Why you have concerns with native dependencies, it is just a transpiler and a dev dependencies. How it affect your project?

It affects me and other people working on it. I have to make sure the systems running the dependencies have an appropriate Python and C(++) toolchain installed. If they use Node bindings, they will probably need to be updated for newer versions of Node.

When I come back to the project after some time, the first thing I need to do is update dependencies. I often had colleagues on whose devices some dependency would just refuse to compile for one reason or another.

Sure, this isn't the greatest problem in the Node ecosystem right now, but it's painful enough that I would rather not deal with it.

We will have a WASM build, yes. Mainly for running in the browser or on platforms we don't build for. In our tests so far, it is significantly slower though (e.g. ~30%) so it's a tradeoff.

That's great to hear! I might be willing to take that penalty depending on the size of the project to avoid any future incompatibilities.

Not sure where it's positionned in the build process, so the question might be silly, but : would it be something that a project like, say, 'create-react-app' could choose to integrate instead of / next to whatever they're using ? Or does it preclude using some popular framework / library that reserve it for greenfield projects ?

It's amazing how useful graphs are

This looks very promising. Parcel is currently the slowest part of my build process, compiling to JS and running tests is an order of magnitude faster. Regardless I’ve found Parcel v1 to be very useful and entirely worth the wait time.

Reply on news.ycombinator.com