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

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.