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?
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’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:
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.
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?
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/5695https://github.com/parcel-bundler/parcel/issues/5294) . In the end I replaced parcel with webpack, less sexy but it's kind of the standard.
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.
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
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 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).
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.
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. :)
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.
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.
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].
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.
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.
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.
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)
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.
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.
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?
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.
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.
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 ?
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.
And how long before this approach becomes the de facto industry standard?