Parcel – Fast, zero-configuration web application bundler

by gilad • 7 years ago

347 187 7 years ago

nbrempel• 7 years ago

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?

wilsonrocks• 7 years ago

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

leeoniya2• 7 years ago

also https://packem.github.io/

and another build tool that's perf optimized: https://github.com/swc-project/swc

mischnic• 7 years ago

Packem is still only availably as a binary, and they seem very reluctant to release the source code.

(And swc is more similar to Babel than to Webpack/Parcel.)

leeoniya2• 7 years ago

Packem is still only availably as a binary, and they seem very reluctant to release the source code.

https://github.com/packem/packem/issues/4

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.

sorry for linking it :(

no_wizard2• 7 years ago

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.

[0] https://v8.dev/features/modules

joduplessis• 7 years ago

2020...

TheRealPomax9• 7 years ago

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.

no_wizard2• 7 years ago

Efficiency with tree shaking is still very important, which is easier to manage with a bundler.

Androider• 7 years ago

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.

devongovett18• 7 years ago

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. :)

choxi• 7 years ago

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?

oefrha• 7 years ago

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.

TheRealPomax9• 7 years ago

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?

tyre• 7 years ago

Not every project will get there. I’m building a Firefox extension and I just need to turn ES6 and imports into a bundle.

Sometimes that’s all you need

devongovett18• 7 years ago

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.

zamalek2• 7 years ago

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.

weberc2• 7 years ago

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.

fiddlerwoaroof• 7 years ago

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

devongovett18• 7 years ago

Parcel works with normal .babelrc configs the same way as webpack or other tools. Curious what you couldn't change.

preommr• 7 years ago

I use both.

Parcel has some bugs that webpack doesn't since the latter has much better funding and corporate support from Facebook.

TheRealPomax9• 7 years ago

Can you edit in some links to those bug's issues on the parcel repo?

AlexMax• 7 years ago

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.

azangru• 7 years ago

and corporate support from Facebook

Huh? Aren’t you confusing webpack with prepack?

progx2• 7 years ago

Switched to Rollup.

FlorianRappl5• 7 years ago

Can you elaborate why?

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?

ng123• 7 years ago

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.

Jasper_• 7 years ago

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:

https://github.com/parcel-bundler/parcel/issues/3690 https://github.com/parcel-bundler/parcel/issues/3691 https://github.com/parcel-bundler/parcel/issues/3696

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.

https://github.com/magcius/noclip.website/blob/master/webpac...

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.

gremlinsinc• 7 years ago

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.

toastal• 7 years ago

We should have a gentleman's agreement to stop saying "blazing" + "fast".

ksec• 7 years ago

I think Webpack 5 is around the corner, which was suppose to speedup Webpack to blazing fast ( With Caching and Hashing if I remember correctly ) .

Not sure if it is up to the speed of Parcel though.

e12e4• 7 years ago

Doesn't that just mean how quiqly it can burn down your CI pipeline due to a bug introduced deep in the dependcy graph?

mrspeaker• 7 years ago

Agreed. Either we ditch the term, or reach a scientific agreement on how many "blazing fasts" there are to a "regular fast".

ausjke• 7 years ago

great and easy alternatives to webpack, I'm surprised its website appears to be mentioned first time at HN.

maxfromua• 7 years ago

Not the first time https://news.ycombinator.com/from?site=parceljs.org

jjeaff3• 7 years ago

Considering parcel is listed in the create react app documentation as an alternative to cra, I'm surprised it hasn't received more mentions.

zelphirkalt2• 7 years ago

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.

devongovett18• 7 years ago

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. :)

jcpst• 7 years ago

That is the definition for convention over configuration. Zero Config means no configuration, more like what harp.js does.

qbaqbaqba• 7 years ago

parcelrc would be a nice addition.

bikeshaving• 7 years ago

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.

FlorianRappl5• 7 years ago

What's not working for you?

For me sourcemaps is just working (I mainly use Parcel with TypeScript, so Parcel takes TS -> ES6+ -> JS -> Bundle). What's your path?

frankpf2• 7 years ago

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.

[1] http://npm.anvaka.com/#/view/2d/parcel

[2] http://npm.anvaka.com/#/view/2d/webpack

wwright• 7 years ago

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.

TheRealPomax9• 7 years ago

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).

qeternity• 7 years ago

More dependencies mean greater attack surface as we’ve seen in npm. I agree with your view, but there is a reason to prefer fewer deps even in dev.

frankpf2• 7 years ago

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?

quantummkv2• 7 years ago

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.

Now here is a very old and fascinating story - https://www.quora.com/What-is-a-coders-worst-nightmare/answe... and it's base, the seminal Ken Thompson Hack - https://wiki.c2.com/?TheKenThompsonHack

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.

devongovett18• 7 years ago

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.

spankalee5• 7 years ago

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.

mycall2• 7 years ago

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.

FlorianRappl5• 7 years ago

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.

I guess Parcel 2 will be better in that regard.

pselbert• 7 years ago

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.

maelito• 7 years ago

My experience with Rollup was cool before I tried to import an image and use React hot reloading...

sntran• 7 years ago

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.

One day...

eatonphil• 7 years ago

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.

XCSme• 7 years ago

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).

FlorianRappl5• 7 years ago

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 also written a small article comparing different options: https://blog.bitsrc.io/choosing-the-right-javascript-bundler...

pull_my_finger• 7 years ago

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.

[1] https://github.com/parcel-bundler/parcel/issues/1557#issueco...

eerrt2• 7 years ago

After a while, they switched to watching directories instead of files, which seems to solve the issue you describe of too many watched files. https://github.com/parcel-bundler/parcel/pull/1665

devongovett18• 7 years ago

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

jessaustin2• 7 years ago

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...

[0] https://www.npmjs.com/package/chokidar

eerrt2• 7 years ago

Parcel has support for React Fast Refresh!! https://github.com/parcel-bundler/parcel/pull/3654

jjordan• 7 years ago

How does this compare to webpack?

hombre_fatal2• 7 years ago

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.

blurbleblurble• 7 years ago

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.

https://parceljs.org/rust.html

jayflux• 7 years ago

You can do that with webpack, that feature is not specific to parcel https://github.com/rustwasm/wasm-pack

jchw4• 7 years ago

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.

In Parcel you include the rs file. Seriously.

Waterluvian2• 7 years ago

How far from zero config do I have to go if I want typescript and jsx? The result is a single bundle.js?

PandawanFr• 7 years ago

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.

src: https://parceljs.org/typeScript.html

joshwa• 7 years ago

Ah, the classic build tool evolution cycle!

1. Become frustrated with complex build tool

2. Write a new tool that is dead simple, opinionated (your opinions), convention over configuration, etc

3. Post to HN

4. Achieve adoption

5. As more people use the tool, feature creep ensues

6. In order to satisfy diverse use cases, make everything modular and configurable!

7. Tool slows and becomes impossible to manage

8. GOTO 1.

quaunaut• 7 years ago

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.

e12e4• 7 years ago

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...

devongovett18• 7 years ago

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! :)

ironmagma3• 7 years ago

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.

franciscop• 7 years ago

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.

AriaMinaei• 7 years ago

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.

jchw4• 7 years ago

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.

LeftHandPath• 7 years ago

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.

erikpukinskis4• 7 years ago

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.

j1elo• 7 years ago

Seems that Prettier.js has been able to hang on step 4 and almost avoid 5 and 6 (so far) :-)

I think that is precisely what makes it so desirable in any project, no more organizational fighting about insubstantial stylistic matters.

I would love that ClangFormat was the same. If you leave the door open to interpretations, interpretations will enter the room.

runarberg• 7 years ago

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).

spankalee5• 7 years ago

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.

[1] https://web.dev/web-bundles/

why-oh-why2• 7 years ago

Web Bundles are absolutely unrelated to Parcel and Webpack. The output of these two can just be wrapped in a Web Bundle or you can make it yourself.

It’s like saying a garage is the solution to your moving needs.

devongovett18• 7 years ago

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.

rolltiide• 7 years ago

its like when SDKs started calling themselves OSes, that was pretty confusing

kresten2• 7 years ago

I met a software engineer once and said “what do you do on your team?”

He said “I’m the webpack developer”.

bdcravens• 7 years ago

Some teams have build engineers.

stefano• 7 years ago

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.

johnghanks• 7 years ago

Pretty sure it was a joke.

JMTQp8lwXL2• 7 years ago

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.

ironmagma3• 7 years ago

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.

hombre_fatal2• 7 years ago

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??

ng123• 7 years ago

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.

jdmg94• 7 years ago

I think Parcel would be a great option for your use case, shameless plug I have a boilerplate repo you could fork to get started: https://github.com/jdmg94/minimum-parcel-lib

ratww2• 7 years ago

I use Parcel by default in such projects.

Out of the box, with the default configuration, it already supports JSX, including hot-module reloading. So yes, it could be a replacement.

jjeaff3• 7 years ago

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.

ng123• 7 years ago

Thanks for sharing. What about non-build features like testing and linting? I think that's the one thing I'd miss from react-scripts.

dblotsky3• 7 years ago

Just use Make.

Takes just as long to learn, and is transferrable everywhere.

ricardobeat• 7 years ago

These are not task runners. Make alone will give you about 2% of what you'll need to bundle a modern web app.

dblotsky3• 7 years ago

Make can run all the tools like babel, uglify, etc.

rejschaap• 7 years ago

Are there any good examples of projects using Make for a web app?

dblotsky3• 7 years ago

Facetious answer: Are there any good examples of projects using Parcel for a web app? ;)

Real answer: probably, but a ton of production code is closed-source.

But why restrict to web apps? Most influential software projects in the world use Make.

jchw4• 7 years ago

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:

https://packets.pangdox.com/packets/loginservice/server/0002...

JMTQp8lwXL2• 7 years ago

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:

[ 'style-loader', { loader: 'css-loader', options: { modules: true } } ]

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.

jchw4• 7 years ago

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.)

devongovett18• 7 years ago

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”.

jessaustin2• 7 years ago

Just try it now, and enjoy how useful it is now. Don't worry about a grim future that may never come to pass.

vecinu• 7 years ago

It should be noted that Parcel was created in house at Adobe and then open sourced.

I think it's always nice to call out the contributions certain corps are making to the OSS world.

devongovett18• 7 years ago

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! :)

sverhagen• 7 years ago

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?

jonilsson2• 7 years ago

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.

nfRfqX5n• 7 years ago

is there something better than gulp for older projects that don't use imports? basically concatting scoped JS

bishalb• 7 years ago

Does anyone else cringe when they read "blazing fast" X? Seems like "blazing fast" is thrown around too easily these days.

0xcoffee• 7 years ago

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.

gavreh• 7 years ago

Parcel vs Rollup?

zubi• 7 years ago

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.

a_band• 7 years ago

Parcel is one of my favorite open-source projects. Love to see it getting some attention here.

fiatjaf• 7 years ago

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.

Waterluvian2• 7 years ago

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.

sandGorgon2• 7 years ago

Is there a Parcel equivalent of create-react-app ?

swyx• 7 years ago

i used to maintain create-react-app-parcel, but lost interest and handed it off. you might still look into it.

im less interested in replicating the contract of CRA now, and want other defaults, so i made https://github.com/sw-yx/rincewind

sandGorgon2• 7 years ago

pretty cool. thanks!

k_bx• 7 years ago

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.

hathym• 7 years ago

what do you expect when compiling js with js to js?

pdimitar• 7 years ago

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.

andraaspar• 7 years ago

Parcel is broken on Windows. Since 2018. https://github.com/parcel-bundler/parcel/issues/1990

Zealotux• 7 years ago

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.

Parcel – Fast, zero-configuration web application bundler

Related Stories