This is somewhat true. I was working at Adobe while building Parcel in my spare time at first, mostly to improve build perf of an app at work. After it launched and we used it internally for a while, Adobe finally started sponsoring the project.
Now, Parcel 2 has a core team of 9 active members from various companies including Adobe, Atlassian, and Eventbrite. We also receive funding on Open Collective which we distribute to a couple independent members of the team who aren’t already sponsored by a company. Definitely a multi-company effort at this point! :)
Just curious how these things go, are there the odd people in these companies full-time working on a sponsored tool or framework, or is this people on a team that's using these, finding some time at the end of a sprint to contribute (like 10% time), or some other model?
Usually it's one or two people using their spare time to eventually get something good enough to work on work time occasionally unless it's 100% aligned with the company goals (e.g. a company like zeit or gatsby)
Parcel is good (and I use it), but it's likely if someone had pitched it internally I'd bet someone would have said "Webpack is good enough for us". At least that's how it would have gone at the places I've worked at.
Originally that's how it happened: I was working on a product and frustrated with build perf, so built parcel in my spare time to scratch that itch. Eventually convinced the team to adopt it.
Atlassian has 2 full time engineers working on Parcel now though, so they've made a pretty big investment.
wild. didn’t realize that Adobe was behind Parcel.
Love it, but it isn’t all that often that it’s truly zero-conf. regardless, it almost always seems easier than Webpack.
Except, that it is not really zero configuration and you still have to figure out some settings for getting source maps to be referenced correctly.
It is blazing fast though and much less a pain to set up than webpack. Every time I have to touch webpack configurations I think: "Oh no, not that stuff again ..." and it will take time to get it exactly the way I want or even requires to load additional helper modules from NPM. Ugh.
Hehe. There's always been some confusion about the term "zero configuration". To us, it's always meant no config needed to get started (and for the 90% case), but possible to configure later if needed. :)
How did you get sourcemaps working? My limited search of solutions just points to a lot of issues where a maintainer says “could not reproduce the issue” and closes it.
Parcel Bundler is really fun. I would implore people to try it before jumping into too much cynicism because their pursuit for zero configuration has lead to some genius design decisions.
One constant problem with bundlers is how to rewrite the HTML files to match the JS/CSS bundles. You can do all kinds of crap including scripts with regexes, plugins, etc. but what if you could do better?
Put simply, Parcel does better. HTML files themselves can be entries, and they will be compiled such that all of the stylesheets and scripts are compiled, bundled and linked to the HTML file in the output. Now you don’t need to worry about mucking with writing the hash into your HTML.
Parcel isn’t perfect but it makes a great static site gen. Its plugin interface can be slightly cumbersome, but it’s flexible enough that you can abuse it pretty effectively. As an example, I used Parcel to generate some documentation built off of Kaitai Struct KSY files, which are effectively YAML files. I push the KSY data through an HTML template that generates the doc page. It was a lot of fun. You can see it here:
Let's say you want to use CSS Modules, but that's not the default in Parcel. (I don't know if it is, but for sake of discussion, the argument continues). The opinionated default works for some, but not all people. To enable an override, maintainers end up breaking Parcel down into subpackages, and people can pick-and-choose what they want. If that is Parcel's future, what ever did we achieve as opposed to just continuing to use Webpack? In case it's forgotten, this is how you'd enable CSS Modules in webpack:
What could meaningfully be simplified in this configuration? We could get rid of the 'options' object, and spread into the parent object. But then that makes it more difficult for Webpack to statically know if the JSON tree provided is a valid configuration.
I don't see where this leads us. Instead of fragmenting the bundler market, invest in making Webpack better, or move onto to a new problem. There's a limited number of open source contributors out there, and only so much can be built & solved. The end state of a mature Parcel ends up looking basically like Webpack, which sounds like a fragmented, convoluted way of making a questionably impactful contribution to the OSS community.
The trouble I have with Webpack is that everyone has their own snowflake configs, there’s no interoperability, and the config complexity has been bad enough that you could literally have someone working webpack configs fulltime. How many legitimate reasons do you have to have the level of flexibility Webpack provides? How many different TypeScript plugins are necessary? There is a happy medium and Webpack is past it and off the cliff.
To be sure, Webpack is pretty amazing for what it can do, but I consider it harmful for the stated reasons; I do not believe unification on Webpack is helpful because almost literally no two Webpack instances is the same because everyone is repeating basically the same configurations but slightly differently (or radically differently in the pathological end.)
Of course using Parcel doesn’t mean literally no configuration, usually it means standard configuration. All of these softwares work standalone and already do configuration. Need to configure the TypeScript compiler? Use tsconfig! Need multiple tsconfigs? No problem, put them in different folders and you’re good to go.
It’s unlikely you’ll end up with something compromise-free but like dropping to assembler and coding out routines manually the tradeoffs of getting your perfectly ideal output are not necessarily valuable to your fellow devs or your end users. It must be evaluated at some level. For me, Parcel does a good enough job that I trust it to have sane defaults for development and production.
So about your question with CSS modules: you can use .postcssrc as usual, although I do not use (or like, to be honest) CSS modules so I would definitely be the wrong person to comment on how well it is supported.
(Addendum: I anticipate that some will pick up on the duality of saying Webpack configuration is bad but condoning and recommending other configs. To that I would say, it’s all about the details. For one, most of these config files are auto discoverable, whereas for Webpack you gotta know the command invocation. For another, Webpack configs are often executable Javascript whereas most other configs are not used this way. And to be completely honest, the amount of magical configuration you can do in Webpack is hardly ever paralled elsewhere.)
Zero config doesn’t mean non-configurable. You still configure other tools that Parcel runs like Babel, TypeScript, etc. It’s not like create-React-app where if you want to customize anything you cannot (without ejecting). I like to say Parcel has config inference from your actual code, rather than making you declare every minute detail up front. But when you need to change something you can. I wouldn’t call that “opinionated”.
One cool thing about parcel is that you can use es import syntax to "import" stuff from rust modules. It will then automagically do all the wasm interfacing for you during the bundling process. Wow!
You can also import stuff from wasm modules too of course, but I like the magic of "importing rust into JavaScript". It seems like a great way for someone like me, who wants to learn, to use rust into a simple web project without worrying too hard about wasm.
Sure. With Webpack you can find a Medium article that tells you how to install and configure a plugin, run into places where things changed because of major webpack versions and plugin ecosystem evolution, and after enough digging you might get it working.
This sums up my experience with webpack quite nicely. It doesn't help that boilerplates like CRA are so ergonomic in terms of saving startup time in other places as well, because this means I really need to have a good reason to manually fuck with webpack. This combined means every time I finally end up looking at webpack, my knowledge of it is super rusty. I've definitely been side-eyeing parcel for a while
If 9 seconds is "Blazing fast", I wonder how would something like Elm experience of usually building stuff in around 0.2s be named. I think 9s is an embarrassing number, especially when you mostly compile JS to JS.
I expect not to care about implementation details. 9 seconds of work with these rather small inputs is embarrassing regardless of what language the compiler is written in.
Parcel is great, but I would avoid using it again due to the sheer number of dependencies (730 packages!)[1]. Webpack has the same problem[2], depending on 342 packages. Rollup is the best one on this regard, depending only on 3 packages.
We do include a lot more features out of the box than other tools, so this makes sense to some degree. In Parcel 2, we're splitting up the core into lots of small plugin packages so you can only install what you need. The Parcel 2 core is tiny - only a handful of dependencies.
Should a bundler really include all those features though? All I want out of a bundler is to bundle. As soon as it starts doing transforms, we end up with applications that only work with that bundler.
As a user of Parcel, I definitely want it. I wrote my Elm program, found myself wondering what the best tool would be to automate the running of elm make, bundling, not to mention transpiling the small amount of ES6 and sass I had in there as well. Less than five minutes later I have parcel installed with no config and it all just works with parcel start, god bless.
If you just want to bundle JS files, then Parcel probably isn't the tool you want.
If you're building a modern web app, you're likely using more than just JS files. The compilation target is complex, and there's room for more optimizations when the bundler is aware of the app as a whole.
It would be nice to auto-detect needed features and automatically link those packages. Then the guesswork for knowing which packages to include will be minimal.
Parcel has that, partially. If you add a .vue file it adds the Vue packages to package.json, same with Typescript.
Parcel by itself is small, but it could potentially require a lot less packages by default if it did that with other large dependencies: Babel, SVGO, CSS Nano, PurgeCSS/UnCSS, PostHTML, which are not required if you don't use Parcel to bundle JS/SVG/CSS/HTML.
Why would the dev footprint matter? whether it depends on 10 or 10,000 packages, if you managing your project sensibly, `parcel` is a build-only dependency, installing only on your machine, and on CI instances (most of which can take advantage of cached depenency lists already anyway).
Those dependencies, many probably written by unknown authors with 0 stars on github, have complete access to your computer and can execute arbitrary code. Even though it shouldn't affect production, that's still a big problem for your own machine.
To put it another way, would you willingly download and execute 730 programs from unknown authors on your computer?
This is a systemic problem with JS dev in general. I know of zero projects that keep the number of dependencies low enough to enable manual audit. Pretty much everyone out there is blindly installing hundreds, and often thousands, of packages, no matter what setup they choose.
Spitballing...couldn't there be a cloud-based Bundler as a Service? Mind you, there's a risk in letting someone else "see" your code, having 700+ applications of unknown origin isn't any better.
If the host of the BaaS could be trusted, and they constantly vetted all packages, isn't that possibility less risky?
Especially with minified JS, how would you be sure, that you get a minified version of your actual code and not one, which does something else additionally, which you might not want?
Not saying, that running 700+ apps is better, just noting, that bundling as a service might not be a perfect solution either.
I might be missing something here, but that cloud based service would either need to run webpack, roll-up, or parcel on the files you send them, or write a new application from scratch (without dependencies). I guess businesses are gonna business but if you're writing that application anyway why not just release it for devs to run on their own machines and ci servers?
Yes. Same flow/process. The difference is, the service provider vets the packages. Certainly, given the risks, there's a market at the enterprise level. Sec for them is real.
That's a universal dependency problem, and is why you're advised to always run a not-a-throwaway-project with vulnerability monitors. Heck, if you use something like Github, you even get that for free these days.
This is especially true as projects age; i recently ran into yet another bug installing dependencies for a rails app, because of a patch-version change on a small library had a bug that manifested with our otherwise old/legacy stack.
I could see a similar situation for projects stuck on older version of node, lodash or whatever, where some tiny component break everything.
Its always fun when you have a known good build, make a change and trigger an error - only to realize the error is in your build system/dependency graph due to someone else doing testing on a different subset of versions than you need - not due to the change you just did.
That sounds like you forgot to peg your version dependencies, though. No matter the age of your code, proper version pegging in an ecosystem that does not allow version deletions (something npm learned the hard way, but amazingly, something pypi allows to this day) ensures that things don't break until you intentionally bump versions.
Note that there aren't a lot of ecosystems where everyone follows semver rules. Even on the npm registry, patch version bumps can still very much break your code because there's no validation during publication. It's still on you to make sure you have tests set up that run when code or dependencies change, even for something as simple as a patch version bump.
Although specifically to your example of 0.8.0 to 0.8.1: that's exactly the kind of version that semver guarantees is not safe: major version 0 is the "unstable" version, and the minor/patch rules do not apply to it (see https://semver.org/#spec-item-4).
Parcel, webpack and others are build tools very similar to compilers. They take code, process all of it and spit something out, something that would be distributed to the end users.
Sounds dangerous? It should. It is very easy to inject code in a small unknown dependency out of those thousands and effectively recreate the Ken Thompson hack.
Sure, but let's also take the code hosting situation into account: npm now comes with security audits during install, and github now comes with free dependency vulnerability monitoring. While "fewer deps means fewer vectors" is true, the security landscape has changed an unusual amount, and for the better, since that article was written.
This is my primary issue with just about every sizable library in the JS ecosystem. All I need to do is concatenate some files and convert ES6 and now I have 700+ packages in my node_modules folder.
I wish core JS had more functionality built in to alleviate the need for all these tiny packages.
If you don't need to extract CSS that is imported in JS files (which I dislike anyway), you can just use the TypeScript compiler that will work with ES6 modules and transpire into as low as ES3. And it has 0 dependency.
Unfortunately it does not bundle to usable file for browsers, but SystemJS and AMD, and then we are back to RollUp or Parcel or Webpack.
Do you have a breakdown of the impact of those numbers? What functionality differences do you get thanks to those dependencies (more compatibility, smaller bundle size maybe)? What are the concrete downsides of those dependencies (how much space or bandwidth do they take for for devs, are there known security or stability concerns)? It’s hard to make a judgement off of just the dependency numbers.
Maybe you are interested in a real-world comparison, where you'd see that the solutions always pretty much tend to go in the triple digits (# dependencies).
It's the old tradeoff: Configuration (+ installation of multiple plugins, which may all break individually) vs. one system that already just works.
Parcel is great, 99% of the time I'm doing frontend development I just want my build tool to convert Sass/Less/JSX/Babel code to whatever browsers support. It's nice to just source a .sass or .js file and have Parcel figure out the rest.
Has anyone used Parcel and Webpack and still prefers Webpack?
I switched from Parcel to Webpack after lots of bugs and issues. Parcel 1 had lots of tiny things that annoyed me (source maps never worked, it broke a lot when pulling from git), and the team is no longer fixing Parcel 1 issues. However, Parcel 2 literally didn't work for me:
So I switched to webpack. The configuration was miserable, but after I got it working, it seems to be OK. It's actually faster than Parcel, and a lot more stable.
Not to mention that I had a few issues with Parcel trying to be "too smart" for me. It would automatically try to hot reload, but my app wasn't designed for that, so it would break hard rather. The workaround was throwing an Error in the hot reload handler.
I'm hesitant to try parcel, and generally use webpack w/ laravel-mix, even in node projects simply because it's a pretty decent 'starting' point for webpack config, and I can override the config anyway I want when I need to which isn't too often.
Zero configuration is great until your project requires something that doesn’t fit into the parcel model, at which point it’s simply out of the question, but webpack with its myriad configuration options can be bent to your will. I was in that position once, but I can’t recall the details now.
I see this all the time with build systems for various languages and projects (as well as for other classes of tools, frameworks, etc). Most of the time you don’t need the more complex tool. Ride out the simpler tool for as long as you can, and only when your product is mature (the time finding market fit is tremendously valuable—don’t waste it on integrating/building the perfect, most future-proof build system) and successful and you have a backlog of features that really do depend on the more complicated solution do you migrate. Ruthlessly trim that backlog for fade dependencies (most of the time the simpler tool really meets the actual requirements, but proponents of the more complex tool will stock the backlog with items that only appear at first blush to depend on the more complex tool). Consider the one-time cost of moving to the more complex tool and the ongoing increased cost of maintaining the more complex tool (and multiply both by 10) and compare those costs to the value of the items in your backlog, making sure to account for opportunity costs (I.e., what else could my team be working on instead of spending time porting and maintaining the more complex tool?).
A sign of engineering maturity is knowing the right time frame to plan for relative to your project’s lifecycle. Don’t worry about how your solution will scale when your product is hugely successful and you have Google-scale concerns; focus on getting to next week or next year or whatever timeframe is appropriate for your product’s current level of maturity.
Parcel 2 should help with this a lot. It has a much improved plugin system that allows pretty much everything to be extended and overridden, while still keeping things easy to use by default.
As a comment on Parcel, this is kind of a counter productive one. What's the utility of a comment that says "it can't do something, but I don't know what"? If you have the details, those are super valuable to comment with, but if you don't... why comment?
Because "there exist situations that parcel cannot handle because it doesn't allow configuration". That's a useful thing to know. The fact that the OP can't recall what the situation was also provides a useful piece of information; that it's likely something that is not run into often.
From what I read one of the developers wrote on here, Parcel does allow for configuration. It just doesn’t require it.
It’s actually convention over configuration taken to an extreme where it’ll start adding entries to packages.json for you, or wrapping rust code in WASM for you on import.
rollup is a good option if you need more config than parcel allows. It takes about 10 minutes to configure rollup correctly, and it's far more sane than webpack.
Yeah, I actually was very excited to use Parcel until I ran into a tree-shaking bug on my project that broke the generated bundle. I ended up switching to rollup instead, since although you still had to configure it, there were many less times than webpack where things misbehaved for some non-obvious reason.
Still, I dig what the project is going for, and intend to try out Parcel 2 when it becomes stable.
I’ve found that every time I start a project with parcel, I eventually want to change something about the Babel config and end up switching to webpack: once I was familiar with it, configuring webpack wasn’t all that bad
I use Parcel for very small projects but vastly prefer Webpack for my "day job". On large projects it's so useful to have full control over your build pipeline. I've written a few custom loaders and plugins that we use for things like managing legacy code and dealing with oddities of our deployment system. I spent two days learning Webpack a few years ago and that has paid dividends ever since. It really is a beautiful tool but most people just want to start writing code and don't really care about the minutiae.
I tried it in the past (maybe a year ago) and just 2 weeks ago, too. The experience I had was aweful. Pretty much nothing was working. Maybe I am too biased from Parcel and I got disappointed when even simple things such as starting with an HTML file as root module does not work, or when importing CSS does not work, or when using TypeScript does not work.
What I particularly disliked is that it cannot even cope with the standard stuff that I throw at it. CommonJS modules (only the standard...)? You need a plugin. Not only that: I had to specify what modules I wanted to include and what they export. Do you know a way around all these wholes or is your solution always pretty much self-contained?
The one killer feature of rollup (which parcel also gets right) is sensible and usable sourcemaps. Webpack does not deal with using Vue SFCs and TS very well, you end up with 4-5 [almost empty] files in the browser per file on-disk and often the file with the actual source is missing. You have to hunt down the correct file and pray that it is their every time you wish to set a breakpoint. I've burned days in the past trying to figure out a workaround for the unusability of sourcemaps in Webpack. Webpack has tons of knobs and levers to configure sourcemaps, but none that do what I assume most people want (a single sourcemapped file in the browser).
Parcel and Rollup do the right thing 90% of the time (requiring only tweaking the path for the 10% remainder) with a single boolean configuration value.
I used wepback before, and on every project it horrible to configre Webpack. A waste of time for me.
Tried some other packager and ended with Parcel and Rollup. I like Rollup, i can not say why i prefer it over parcel. Both are better, easier, faster then webpack.
You’re right, this is happening to some degree with Parcel. Our aim with Parcel 2 is to open up the plugin system to allow more extensibility while keeping it as simple as possible to use out of the box. This is accomplished through a very well defined plugin system with explicit extension points for each step of the build pipeline (not the Wild West of extensibility like other tools), and a good default configuration that you can extend or override as needed with a simple JSON config format. The result is that you get everything Parcel 1 could do and more out of the box, but you can easily change or extend Parcel 2 with more features specific to your app if you need to.
We’ve been working on Parcel 2 for almost 2 years now (~1 year in design, another in development) and I think it strikes a pretty good balance. I’m excited to see what the community does with it! :)
Can the configuration have strong types (via TypeScript or similar) pretty pretty please? One of my main frustrations with webpack is the undocumented, unpredictable, unspecified config file format that seems to have no rhyme or reason, which you must often change with every new plugin you add.
If you define the types in TS, you can use https://github.com/YousefED/typescript-json-schema to automatically generate a JSON schema from it. That way, configurations can be specified either in an executable JS module or in a JSON file.
JSON is much more static and predictable for configuration. Config through a real programming language was a mistake that many tools made unfortunately. Static configuration has several nice properties including cacheability and simplicity that cannot be guaranteed in a full programming language. Just look at webpack.config.js for an example of the opposite.
All configuration is static. The advantage of using JS (or a language file) is that you run it to generate the appropriate config for that moment and environment.
That need won't ever go away, so not supporting means we're back to users generating their own "static" config files in a separate process. Nothing has been saved, only made more complicated.
That's all totally awesome and cool, right up until the moment you want to add a comment to your configuration. Because you know, it's configuration, and that requires comments.
Quite a few tools went from just JSON configuration files to supporting both .js and .json.
Regarding caching, perhaps I'm mistaken but what's the issue there? Two JSON documents can be equivalent with different bytes so you need to re-parse the configuration file fairly often anyway. So what's the difference with just re-evaluating a .js configuration file and caching the output? If someone wants to put a `if (random() > 0.1)` statement in their config then that's their problem.
You cannot statically cache the results of a .js file - it might include objects or functions that cannot be serialized, and might cause side effects that parcel cannot know about. If we supported .js config files, we would have to intentionally limit what you can return to basically just JSON, so you wouldn’t get much benefit from it and it would be hard to enforce.
While I think this cycle is real, I feel Parcel has done a good job in general being very careful about becoming what they aimed to avoid. Sure, Parcel has some feature creep, but I’d say they have pretty much completely accomplished the goal of removing the need for complicated Webpack configs.
Is it practical? Apparently it’s practical enough that it can compile Monaco Editor, which can either use a fairly hefty Webpack config, or no config at all with Parcel.
While it is a cycle, it isn’t necessarily a bad cycle. With this cycle there is constant innovation to meet changing needs; there is always some new product addressing the shortcomings of the incumbent competitor.
One bad thing about the cycle is we never get to stop dealing with the problem. Because we’re in a cycle of destruction and renewal, applications rot as the infrastructures under them become incompatible.
Where people stopp trying to make “pluggable systems” and “platforms” and instead tried to actually solve problems with finality, and to create procedural interfaces that cover a clear cone of responsibility, the result is mature libraries that stop changing, and become bedrock under applications.
I won’t say it’s “bad” not to strive for that. It is a unique challenge you may or may not wish to tackle.
Bedrock in this sense is small tools that you either build on or you don’t.
What you’re describing is different:
“Abstractions” are by definition unnecessary, they are imaginary things which imperfectly model of some real things underneath. They are contrasted with control systems, which strive to manipulate those things without any metaphor.
“Cruft” is items which you don’t need that are bundled with items you do need. It is contrasted with tools that are easy to just not use at all.
I don’t know what anachronism means in this context.
I’m not saying it’s easy to make tools that are neither abstract, nor bundled with unrelated things. Just that it is a place you can aim for.
I disagree with your notion that abstractions and cruft are inevitable. They’re not inevitable, they are encouraged in the present development climate.
Personally, I take the “run everywhere the same” aspect of web sites very seriously, so I don’t think bleeding edge browser features are an important part of the solution for me.
I also don’t think “build pipelines” are part of the solution.
But I do support you pursuing your vision of finality. Mine is pretty different, you can look up “browser bridge” on NPM if you are interested.
Every widely supported feature was once a bleeding-edge feature.
I'm not sure how you can about finding fundamental enduring solutions to platform gaps that user-space tools solve without adding platform features. That's always going to create a period where some browsers support a feature and some don't, and we've _always_ had to deal with that. It won't be different here.
I mention build pipelines because that's what most bundlers actually are. If they drop the bundling part, they can just focus on that.
I think platforms “mature”, and nothing important happens after that. The web was mature around the time WebGL was widely adopted. Bundles don’t do anything we can’t already do. They just make the web more brittle.
Which means: lovely for you, until something snaps.
For me that’s two cons: lost users, and a more complex data model. And no pros.
I really hope that by separating Web Bundles from signed exchanges that Firefox will get on board. And I really hope that Firefox retains and gains relevance somehow.
That doesn't hold up with browserify => webpack though. Webpack came after Browserify, offered more features, but it was a pain to configure and had no sane defaults. It was still widely adopted and was preferred over the older, much easier to configure browserify, because of its flexibility.
Parcel's been around for well over a(two?) year(s) now and actually instigated a lot of change and refinement in the bundler market. Most now have zero-config options available, either as a result of Parcel coming on the scene, or with inspiration from it.
Thank you for bringing up how new Parcel is. It'll be interesting to see how we as an industry manage ten year old legacy projects built on top of nodejs/js.
You know, when there's a sudden request for a new feature in a project that's been ticking along for five years - and you need to install a development environment to add said feature - but the build system has been abandoned for three years...
This is generally true and I've seen it happening again and again. One of the exceptions (IMHO) that goes a bit the other way is Create React App. That's partially why I like it so much. It has become even simpler to use for the easy usecases. There's tutorials to do many of the complicated things, and you can always eject, but if you don't have convoluted needs it works very smoothly.
How is this different from any build engineer? For some reason we generally accept that client development isn’t trivial except when it’s a web client, then it somehow must always be trivial despite it being the platform that must deal with things like application payload optimizations and work on every device. Meanwhile look how busy the rabbit hole of Xcode config on a complex app can keep an engineer for a single iOS app, and we seem to just accept it because it’s not web, and web = bad.
So, we make fun of a company that is serious enough about their web client to have a fulltime build engineer while we lament how little thought and care seems to be put into so many web clients in the wild. Maybe it turns out
that clients aren’t always trivial and some specialization / division of labor is what it takes to make a good product.
It wasn’t long ago that you could see HNers snicker about fulltime “front-end developers”. I mean, isn’t it just HTML and CSS? How hard could it be? Isn’t the server API the only hard part of building a rich client??
What does he spend his days doing? I wrote a configuration file years ago and I still use it for multiple projects. I only had to update it when upgrading between major versions of webpack.
This may not be a popular opinion, but if you need to dedicate a single FTE to your webpack configuration, something sounds amiss. Alternatively, if that's your engineers only skill (building webpack configs), that also sounds quite suspect.
In most projects, the webpack configs are not edited often, maybe unless you're upgrading a new major version of Webpack itself.
They're not edited often because they're hard to edit. Many times webpack issues just get deferred or ignored because no one has the time to investigate them.
After testing it out on some personal projects, I switched a two year old core project at work from Webpack to Parcel. It took about 5 hours to get it right. The trickiest parts were finding the right alias mappings between TypeScript, our use of `~/` paths, and importing SASS files in TypeScript. This took about an hour. The next 4 hours were figuring out how to map the changes to eslint without Webpack.
It is much simpler to manage so far (though upgrading internal dependencies in general could be an issue over time). It compiles much faster as well. I'm not sure how the default bundle size compares to what we had with Webpack though.
I really dislike the huge, multi-faceted build systems calling themselves bundlers.
An ideal bundler would take a fully working unbundled project, which is easily writable with JS modules now, and just optimize it for production delivery.
The unbundled working app will be easier to develop and debug. Having a working project as input, and working project as output means that you can switch bundlers and aren't tightly coupled to it's transforms.
But most bundlers don't work this way (Rollup is the closest, and that's why I use it). Bundlers are typically entire build systems with compilers, CSS transforms, image optimization, etc... and they happen to bundle somewhere in the build pipeline. In the worst cases it's not possible to run the build but _not_ bundle, if you wanted to run some of the transforms.
This is all kinds of bad for the JS ecosystem. You can't really tell how a module will behave because the bundler is transforming everything. Imports aren't really imports, CSS is concatenated and magically added to the main document. Sometimes libraries publish code to npm that _only_ works with certain bundlers.
Web Bundles[1] is the way out of this. It's a standard bundle format that'll be natively understood by browsers, is unpacked before the network cache, and _only_ a bundling format. If you just want to bundle a working project, any Web Bundle tool will work.
We’ve tried very hard to avoid Parcel specific features actually. When we transform, we use other tools that the user has enabled, eg babel. An application that you build with Parcel does not produce Parcel specific output and there are as of yet no Parcel specific language features. It should be possible to switch to another build tool without much if any work. Definitely not the case with other tools like webpack though, so I can see where this comes from.
Switch to Parcel from Webpack for my latest project. I was actually surprised that it just worked, I didn't even have to write a config file (being used to Webpack this felt like I saved hours of work).
I would like parcel much more if they just emitted ES Modules. I don’t understand the logic of having their own loader in 2020. Same complaint I have with webpack. Just target systemJS for older browsers like rollup does. Leveraging a very efficient existing well tested solution seems wiser to me than reinventing the wheel
I don’t understand why they don’t support that. You can really leverage smaller bundles this way (no bundler runtime for modern browsers for one). You can also leverage type=module in the browser (which parsers more efficiently by default[0]) and use the nomodule attribute for differential loading.
Of course this assumes browser targets, which I feel like is the main target for these tools most of the time.
One could also ask why you'd need parcel if you're already writing modern es module code. If you really need to bundle that (and you kind of don't, es modules allows you to put each requirement in your page html, and get the benefit of browser caching for individual pieces of the pie back, which you lost when you starting bundling and single-line changes to a single small class created entirely new hundreds-of-kbs bundles) use rollup.
If you know you're targeting modern browsers, the need for bundling is slowly disappearing again. And if you're targeting something like electron, there is _really_ no need to bundle because you're distributing the entire filesystem with load times that don't involve network requests.
If companies could, they would just send your browser a binary blob. From a business point of view, exposing your inner workings / modules is a no-go. Same for local apps using Electron, there's a (perceived at least) business need to obfuscate the code into a big ball of mud that is continuously changing with every build so external patches cannot be applied, e.g. Slack doesn't want you to have the ability to read or modify your local Electron client.
We have support for outputting native ES modules in Parcel 2, which is currently in alpha! We can even compile your app to multiple targets to support modern/legacy browsers. :)
I’ve used this with my most recent project 30 Hour Jobs. My goal was the quickest path to launch and this was hilariously easy compared to my old webpack config!
I can imagine at some point you might need more customizability with a tool like webpack - or maybe this will always be sufficient?
I had to switch on a project because I couldn't get IE support working :( A shame (that I have to support IE) because parcel is excellent.
I believe the new version will make it fairly easy to do differential builds - so users with modern browsers don't have to download all the Polyfilla but it still works on IE
I like parcel a lot, but one issue I've always had is that it watches your node_modules folder. The devs kind of pawned it off as a "feature not a bug"[1], but it results in tons of warnings etc related to watching too many files. I've since started using a symbolic link to the actual node_modules folder, but it's still just 1 extra hurdle that would be nice to not have.
We’ve actually rewritten our watcher for Parcel 2 as a cross platform C++ module and it should be much more efficient. :) http://github.com/parcel-bundler/watcher
Haha, Chokidar [0] strikes again! So much time could have been saved by so many devs on Linux if that package had saner defaults. More than one of my package.json .scripts objects have "sysctl fs.inotify.max_user_watches=32768" embedded somewhere...
Has anyone used Parcel as a replacement for create-react-app? I own some tools for generating React projects in an enterprise environment and CRA (specifically react-scripts) has been a huge thorn in my side. Most of these projects are small to medium size and so they don't really warrant custom Webpack configurations. I'd prefer something with react-script's simplicity but without it's absurd restrictions.
Yes. And the create react app documentation actually links to parcel as an alternative. I messed around with webpack, gulp, and others for weeks trying to find a good option that could handle my existing code alongside newer code that would be written in react and that could handle multiple entrypoints. I had a difficult time with most tools until I tried parcel, and it just worked.
Have an entrypoints for a react app? Include that in the build and parcel can bundle and deploy with no configuration. It just knows it's react because of the import react statement. Want to use typescript with react? Just use .ts files.
So my parcel command while developing is something like 'parcel watch src/*.ts. I just put my entrypoints there and my components below that. I've actually been able to just code for a while now without having to fuss with build tools.
We use Parcel in our Microfrontend Framework Piral (https://github.com/smapiot/piral), too. Overall, this was an awesome decision. In the past we used Webpack a lot, but it just does not feel right any more.
I’ve been moving my projects to using es modules natively (supported natively in node 13 and with `<script type="module">` in the browser) and it’s pretty nice. There is no compilation step needed between edit and run. And when its ready for production, rollup is plenty.
I feel like node getting native es modules was the last step that the platforms needed to get up to speed with the bundlers. And the state of HTML, CSS, and JavaScript is good enough to simply use it without any external helpers (until production that is).
There was a period where I started seeing Webpack everywhere, being used by everyone, so I felt obliged to try it. I struggled with the concepts and configuration and eventually realized that I completely failed to figure them out. It was a heavy blow to my developer self confidence. Fortunately I recovered when I discovered Parcel shortly after. "No config" immediately caught me after the frustration. I'm grateful for and still use it.
I love how it even supports Elm out of the box. It's a great feeling to replace your complicated web-of-magic-incantations webpack-config.js with a simple build command that just calls `parcel`.
At the very least, it's nice to default to parcel on a project and then, if needed, adopt webpack once your project matures the point of needing more fiddling.
I was amazed when I could point parcel to a html file that imported a typescript file and it worked. Only downside was that I was importing the script as a module and then half of the typescript imports stopped working. Had to bundle everything as one big typescript file to work around it.
I think they fixed this in Parcel 2 but didn't try yet.
Parcel looks promising, especially to finally free yourself from Webpack's configuration soup, and the compilation time gain looks great. I just wish it has better TypeScript support, it looks like it's still not possible to check types on compile, which is kind of a deal-breaker for me.
oh yikes, the fact that it's closed as "irrelevant" is rather worrisome. how is it irrelevant to ask where the source code is for a project hosted on an open source hosting platform.
one of their top talking points is "Its crust is built with Rust", but without source to verify this it might as well be written in brainfuck.
I gave this a try for one of my experiments, replacing rollup. Wow. It just works and cleans up a bunch of dependencies.
All I need now is some one shot solution for eslint + prettier. Right now that's 7 dependencies, representing almost all the dependencies I add to most of my mini projects.
Seems TS is provided by default (tho it will not do any type-checking, you'll need tsc --noEmit for that).
As for JSX, you need a basic tsconfig that specifies jsx.
I don't know if you're familiar with the expression, but you don't have to be a man to enter a "gentlemen's agreement". You don't even have to be a gentleman for that matter.
Of course, "gentlemen's agreement" is actually what it's called in French as well, and we don't go around thinking it's exclusive to French people because it uses English words (not that we don't do that with other terms…). It's just what it's called, and been called for hundreds of years.
----
Edit: OK this is way off-topic but I can't help but snicker a bit when I see these kinds of comments. The idea that we even genderize words is very arbitrary in the first place, and very inconsistent between languages.
French for example has the word "écrivain" (author) which is very masculine-sounding and as such sounds weird when used for women; but the feminine "écrivaine" sounds atrocious to French speakers. Our canadian friends exported the word "auteure" (feminine of auteur; phonetically identical). It's a whole thing. Apparently we used to use "autrice" which actually rings pretty nice (similar to acteur / actrice == actor / actress).
You'd be hard pressed to see the debate in English around Author / Authoress.
These are potentially legitimately exclusionary though, because it's not completely absurd to think that grammatical rules can influence how friendly we perceive a profession to be to that sex; eg. "fireman" vs. "firefighter", or in french "Femme de ménage" [cleaning lady] vs. "aide ménagere" [cleaning helper].
Point is, there's no reason why most of these words can't be made gender-neutral in the first place. English speakers are lucky to have a mostly gender-neutral language at all. Did you know that in french, Banks, postboxes, cars and churches are feminine, whereas computers, telephones, ovens and monasteries are masculine?
I don't get why it's a good argument to say that something exists for hundreds of years. Thinking about flat earth was also thought for hundreds of years.
> Thinking about flat earth was also thought for hundreds of years
And round even longer :)
I didn't say it's a good argument to keep things that way, I meant to say that the naming itself doesn't mean women are excluded. A gentlemen's agreement is a well-understood term, and if you start saying something gender-neutral such as "gentleperson's agreement", you may sound more inclusive, but you're also less likely to be understood, especially by non-native-speakers.
I can agree with that. I went with the idiom that came to mind and the connotation/image that I have associated with it, not really considering inclusion. Exclusion wasn't a goal, but despite less 'flavor' (with flavor being subjective and not necessary), "Can we agree to" is probably a better choice.
FWIW, I didn't have any problem with the original wording. Then somebody pointed out it's exclusivity and I thought, "Hmmm". Then all the gender contortions made me wince. I almost didn't post because I didn't want to be part of that.
For the record, my post was not an effort for social equity. It was English golfing. I'm sure there are better golfers.
Yes, OP could have just said "can we agree to", and in their case that would have worked fine. But I hope you're not proposing to hard-swap "gentlemen's agreement" for "agreement", because those are two very different things.
Nitpick: If you're referring to the middle ages, nobody there (well, no scholarly person at least) actually thought the earth was flat. That the earth is round was known since antiquity.
The big dispute was about whether the earth was at the centre of the universe; heliocentrism was contradicting the church's doctrine at the time. Somehow this ended up in popular culture as an argument about the earth being flat which it never was.
Now of course, it's entirely possible that earlier cultures, before the Greeks, were under the impression the world was round... or any other shape.
Are they comparable?
Earth is not flat remains static and will for a very long time while languages don't.
Though, change to languages are opposed and pushed for political reasons so it's no surprise to form an argument that relies on age of something to justify it similarly how people need political atmosphere to justify the change instead of solely arguing on the basis of descriptiveness or clarification.
Mentioning gender isn't inherently exclusive, like using "gentleman" to refer to a specific man.
The term "gentlemen's agreement" is exclusive because it's a relic from a time when men were the only people who would conceivably enter into such an agreement. Even if it's "just an expression", it has a lot of assumptions tied up in it, and there are many, many alternate ways to say the same thing these days without those connotations.
If you take it literally (not "just an expression"), then it's an agreement where only men are allowed to participate, and hopefully it's obvious that that's exclusive. Good terminology should ideally be understandable to someone who hasn't seen the term before, so by that metric, "gentlemen's agreement" is just not a good term and doesn't seem worth keeping in the language.
Thank you for posting what I found to be an unbiased and helpful response, alangpierce.
I know it's easy for equality to feel like oppression to people who've never known life without whatever priviledges they may enjoy (race, gender, looks, height, etc.). To combat that, I flip it and see if I feel the same way.
In this case, if "gentlewoman's agreement" were the dominant idiom, I'd probably feel excluded no matter how many women assured me that the phrase wasn't biased.
I still don't understand why everybody is using Webpack when Browserify is easier, simpler, faster, produces smaller builds, can be understood by a normal person. Really, the big shift from Browserify to Webpack happened to fast and without any clear reason.
With that said, it's good that someone is challenging Webpack, as that must happen for the sanity of all.
I think it's always nice to call out the contributions certain corps are making to the OSS world.