I spent the day finally adding a modern build system / bundler to my side project, and I chose Parcel. Parcel is really cool! I really wish they'd stop calling it "zero-configuration". It has configuration options (--out-dir, --public-url), there's just no configuration file for them. I really wish they would make one, since it's annoying to have your configuration be hidden in a batch file.
Congrats to the Parcel team! Really great work. Having used Parcel in personal projects for the past year, it really is a great user experience.<p>Despite what people says in the comments, Parcel has its (great) value. The ability to import a rust file directly and have it compiled to a web assembly module for example, is a great piece of engineering and exceeded my expectations for web build tools. Parcel also hits the sweet spot where it's both zero-config, and easy to customize if you find the need.<p>Honestly? Parcel has a better experience than your C++ build tools. Be it CMake, Ninja, or whatever build tools people use in 2018.
I love that Parcel is out, even if yes it is another bundle, because it helps highlight the major problem with bundlers right now: they (but especially WebPack) are a meta-platform over the web unto themselves and they encourage use of features that are not supported by the web platform, in a way that's not easily transformed into what the web platform does currently, or will realistically, support, creating lock-in.<p>Just as we're getting to the point where many of these tools should be optional because we have great modern JS and modules support in browsers, and many projects are already written in supposedly standard modules, many are blocked from actually shipping code that runs un-built on the browser because of bundler features like importing images, CSS, etc.
IMO, the fact that 1726 modules is a “reasonable” number for a web app is a clear indication that there is something seriously wrong with this process.
I hate doing javascript. I have no desire to attempt to understand or mess with JS or build systems past the bare minimum I can manage to get a project working so I can move on with my life.<p>So I tried using this. It was nice while what I was doing fit inside of everything that was default settings and/or what maintainers used. As soon as I stepped outside of that I ran into things like having to hope someone implemented a Parcel plugin for some random transform (an issue that applies to Webpack, too, but Webpack has so many more users that you're guaranteed someone actually did make one that actually works correctly), or: <a href="https://github.com/parcel-bundler/parcel/issues/645" rel="nofollow">https://github.com/parcel-bundler/parcel/issues/645</a>. Having an issue on something as popular as Bootstrap 4 be open for 6+ months is pretty frustrating. I spent several hours flailing at this issue to no avail.<p>I switched to Webpack 4 and had all of my existing build system and some additional niceties working in <45 minutes.
I've used used Parcel for a few projects this year and really enjoyed it for the most part. I've found it's basically effortless for building static projects, but its lack of documentation can be frustrating when errors pop up (e.g. I was stuck on an older version for a while due to some issue with a newer release) and I still haven't quite figured out the best pattern for extracting the hashed bundle names for use in other places.<p>That being said, Webpack 4 (released months ago) shipped with a similar zero config option, so I'll likely go back to it for future projects.
The main complication remaining with Parcel, IMO, is one that mostly derives from the syntax being used: there's no clear way to separate "I want this file to be added to the bundle, and a string URL for it" and "I want the appropriate representation of this file's contents".<p>My line of thought here is helper methods in an empty package namespace, so that they only exist at build time and are stripped out in the result.
I love the idea of Parcel but I've struggled with a number of non-obvious problems when using it on hobby projects.<p>° Sourcemaps not working (wrong files / no source translation)<p>° Randomly losing exports (a module with multiple exports where one of them ends up as an empty object - fix by clearing cache and restarting)<p>° Errors like "module 71b not found"<p>° Hot module reload enabled by default, meaning that all top level code runs again when you reload the code (e.g. here's an extra canvas in your dom)<p>My preferred zero config setup for hobby projects has become <script type="module">[1] and a live reload server[2].<p>If I'm working on a React project then I will always use Create React App when I can[3].<p>When I take something beyond the hobby stage and into maintaining it as an ongoing project, I use TypeScript Quickstart[4]—to abstract the underlying Webpack config and start writing code immediately.<p>I'll only reach for Webpack when I know that I need more flexibility than any of these other tools offer—which isn't very often.<p>[1]: <a href="https://jakearchibald.com/2017/es-modules-in-browsers/" rel="nofollow">https://jakearchibald.com/2017/es-modules-in-browsers/</a><p>[2]: <a href="https://github.com/tapio/live-server" rel="nofollow">https://github.com/tapio/live-server</a><p>[3]: <a href="https://github.com/facebook/create-react-app" rel="nofollow">https://github.com/facebook/create-react-app</a><p>[4]: <a href="https://github.com/danprince/typescript-quickstart" rel="nofollow">https://github.com/danprince/typescript-quickstart</a>
I think the ultimate solution to bundling is to go the way of the CLIs, and Angular CLI in particular, where the framework team configures a sensible default bundle config with a few options exposed via the CLI. The user can then build with a single command and everything just works. The user can eject from the CLI and configure manually if needs be, but most of the time that won’t be necessary.<p>Bundlers probably have a certain minimum complexity that can’t be reduced if they want to be universally applicable, but a lot of that can be hidden for most use cases, particularly if using the same framework.
Just tried it quickly; didn't work. It did something and then I got a blank page. Probably some config missing that it needs but the point is: no zero conf and doesn't work as advertised.
For a recent project (with modest needs), I just used a short makefile[1] and plain ES5. I found the experience refreshing as there is definitely peace of mind in depending on one less black box.<p>There is indeed something uncomfortable about a big node_modules directory or a magic build tool. It's almost like bathophobia, where instead of depths there is 3rd-party javascript code.<p>[1]: <a href="https://github.com/gvalkov/tailon-next/blob/master/frontend/Makefile" rel="nofollow">https://github.com/gvalkov/tailon-next/blob/master/frontend/...</a>
Gulp has/had the right approach. There's only so much flexibility and complexity configuration format can support without becoming strange copy-pasted incantations that can only be reasonably expressed and clearly visualized through code. And they've proven that, eating Grunt's lunch, but then they blew it with never-ending alpha and general stewardship fail.<p>And with regards to Parcel vs Webpack, it's not (at least not yet) even a competition since webpack 4 is basically zero-configuration and is so much more advanced tool at all levels.
I suspect that most services start very lean, and if they become popular people request more and more stuff and it gets added, making the thing more complicated.<p>Webpack is too complicated though, so if this can stay simple, why not.
Seems like a nice alternative to more opinionated language dependent site generators and webapp frameworks built on top of Webpack (ex. Gatsby, Next.js, Nuxt).
Is something really wrong with WebPack? Didn’t we decide that we want more modularity and plugins, instead of “zero configuration” solutions that lock you into a few technologies? What about the next hip new frameworks that release in the future? Will they just be piled into parcel, or will they add a plugin system? This seems like an unsustainable model.
Ah, the neverending cycle.<p>1. The existing tool is way too complicated to configure and slow. Let me introduce a new, zero-configuration, blazing fast tool<p>2. OK so because it's strongly opinionated there are some things it can't do. So we'll allow you to extend it via plugins. You'll have to configure this.<p>3. Due to the increasing popularity, we are making a meta-version that lets you re-plug any element in the entire system with one of your own choosing. You'll have to configure this.<p>4. GOTO 1.
The code looks nice, I hope it has helped you in your life.<p>But frankly, if a JavaScript developer ever really wants to solve the problem... Learn enough C++ to write the equivalent code that compiles 6.5M in 0.1 seconds (assuming a nice HD).
Please God no. We don’t need another bundler.<p>Also. What’s up with the obsessive use of emojis everywhere? Take a look at this issue for example: <a href="https://github.com/parcel-bundler/parcel/issues/144" rel="nofollow">https://github.com/parcel-bundler/parcel/issues/144</a>