1. The existing tool is way too complicated to configure and slow. Let me introduce a new, zero-configuration, blazing fast tool
2. OK so because it's strongly opinionated there are some things it can't do. So we'll allow you to extend it via plugins. You'll have to configure this.
3. Due to the increasing popularity, we are making a meta-version that lets you re-plug any element in the entire system with one of your own choosing. You'll have to configure this.
Iterating without improvement is just making a different wheel, if you know what I mean.
It gives the impression of progress without actually making progress.
This is also why I got tired being a programmer after doing it for many years. First version is always super nice. Then you add features, and refactor. Doing this is slower and slower the bigger your software gets. At the end, your software is filled with complexity and you want to rewrite it from scratch. So you do, and you are back with a nice version. Until again, more features need to be added.
Now, does this example above mean the developer is innovating? Are we getting somewhere? No. At the end, his product is going to be replaced by other products that does the job better - until they also meet the same fate.
> No. At the end, his product is going to be replaced by other products that does the job better - until they also meet the same fate.
Yes, this is the very definition of innovation. Just because what you're working on is going to be replaced, doesn't mean it's not innovative. Of course it's going to be replaced, that's the whole purpose. Hopefully we get better and smarter along the way. Sometimes something that seems trivial to you as an engineer is mind blowing to a layman with domain expertise that goes on to leverage your software to help make the company more money in ways no one was expecting (or maybe save money). In other words, innovating.
I think this is a great exaggeration of the "javascript build tools are hard to config" meme, and it honestly is obsolete. Maybe the meme was relevant two years ago, but every since (1) create-react-app and (2) webpack 3, the configuration story has greatly improved.
With Webpack 4 and Parcel especially, these tool are both zero config and configurable. Your point 1 and 3 are actually not mutually exclusive, and repeating the meme just sounds like you're perhaps out of the loop for a bit.
While the Javascript developer experience truly was horrible a few years back, it has dramatically become better. Try it, and you might be pleasantly surprised :)
I'll be speaking for Webpack, since it's the only one I use for the few internal applications at work, and I've never really used Parcel yet.
Configuring Webpack is still pretty bad. If the zero config works for you, great. But if you need to configure it yourself, it's really verbose, it's really complicated, and the documentation is a bit thin.
SplitChunks in Webpack are like black magic, they work but you don't have any idea how, and when they don't work, you still have no idea how. And you don't know if it's because you didn't configure them properly, because you don't know what is configuring them properly, because the documentation on them is so bad.
Maybe I'm just bad at configuring Webpack, but I still don't understand how many things in Webpack work, and it's given me a lot of headaches, even with the "zero config" Webpack 4.
Have you ever looked at what CRA does? Just do an `eject`. It layers and layers and layers of configuration. The moment you need something not covered by CRA you'll be stuck with the insanity that is webpack config. [1]
webpack 3 did nothing to solve the configuration problems. Heck, just half a year ago one of the core devs of webpack argued that there could be no defaults in webpack and that webpack config is horrendous "because it's javascript" [2] [3]
webpack 4 addresses just some of the long-standing problems with webpack configuration leaving the actual config as insane and inscrutable as ever. And the only reason it exists is probably due to the public outcry of the larger community and tools like Parcel somewhat stealing the thunder.
Parcel is probably the best thing to happen to JS bundlers in recent years, but it's still not without its problems.
Hey, I looked at ejecting as early as September 2016, but why let that stop you from saying “you’re wrong on so many levels” :)
Looking at JavaScript build tools today and ridiculing it makes as much sense as ridiculing the width of car lanes (from width of wagons) or ridiculing the width of rockets (width of railroads).
Create-react-app works just fine with the 80% case you wanted so badly for webpack team to implement. (Not to mention there are easy ways to make incremental changes without ejecting.) But why let that stop you from writing a rant about webpck’s lack of default either :)
You can look at it today, it will be mostly the same: hacks, inscrutable configuration, custom overrides for stupid things etc. etc. etc.
I just looked at it a minute ago.
As for the rest you are equally wrong in anything from assuming that webpack 3 made configuration easier to assuming that configuration became easier just because CRA hides all this complexity from us.
You don't need to deal with the configuration for 80% of the use cases. If you need something custom, it's a good investment to learn the tool you are depending, and I don't think it's inscrutable: https://webpack.js.org/concepts/
You don't have to. Just don't use those plug-ins? If you do need that functionality, it makes sense to "fight the build tool" a bit (or just go through the docs, they really aren't as bad as you say).
I personally always found a solution with Webpack. I find this amazing for a tool which is so young and written in a language without static types.
I try to avoid using webpack, because it looks over overcomplicated. So I would prefer a tool like this. Do stuff automatically and dig deeper if you need some custom option. Nice job! Well done!
The code looks nice, I hope it has helped you in your life.
But frankly, if a JavaScript developer ever really wants to solve the problem... Learn enough C++ to write the equivalent code that compiles 6.5M in 0.1 seconds (assuming a nice HD).
If you do absolutely zero instruction optimization or re-ordering. Literally mapping the BNF grammar to a syntax tree capable of simple syntactic reduction... I would be surprised if it did not lag behind disk read speeds.
Traversing that tree to remove unambiguous dead branches seems pretty clear. Perhaps if you get into a tricky manipulation between strings and syntax you could add a little runtime...
If you do absolutely zero instruction optimization or re-ordering, JavaScript takes 0 seconds to compile, and you can use almost-complete feature set of ES6. /s
Come on man, that's beyond the point. Just because JavaScript needs to be compiled, doesn't mean it has a worse experience than compiling C++.
Instruction optimization is procedure of measuring expected CPU latency given the expected current state to identify which instruction set transition is optimal for the CPU. It would not be applicable to JavaScript unless I missed something.
Instruction ordering is largely bound to instruction pipelining and the estimation of CPU instruction transitioning to reduce latency. Given that V8 uses some degree of virtual indirection... I don't think that's possible in JavaScript.
Oh no! One language has a build process and toolchain... We should clearly throw everything else out and just use this one hammer for everything! /s
Believe it or not, some people have problems in domains with contexts that have nothing to do with yours and the things they come up with are equally valid solutions.
It is not a question of C++ being better than JavaScript or vice-versa in some esoteric sense.
Compiling code from C++ to WASM is counter-productive if the native JavaScript is fine. It's just that native languages seem to perform quite a bit better in the domains of graph construction, graph optimization, and even basic string manipulation.
> Compiling code from C++ to WASM is counter-productive
When did WASM come into the picture? I use Parcel because my time is valuable and I don't want to master the arcane arts of modern JS build toolchains but I still NEED to benefit from them if I'm to run a successful business and make sure my investors get their money back and a language I can deliver plain text over HTTP/S that runs performantly across billions of devices that I can modify on the fly is beyond valuable.
> native languages
C++ isn't going to help me deliver my product to my customers in any measurable way that influences the outcome of our relationship. JavaScript, frankly, does - the less time my organization spends writing code, the less we have to charge for things to make up for that margin impact.
You brought up C++ & WASM in a post where it made absolutely NO contextual sense so you could shit on someones work and I'm the one with comprehension issues? Grow up.
This is fine argument. Although I work primarily in JS, I don’t think that this is the tool for any job. There are lot of nice tools in JS out there. While using single tool written in JS it might be not looks slow, but when you must use multiple of them in day to day work it start be a problem.
To sum up: I don’t think JS was designed to build such tools. Although it is very nice language to write in, it is not so efficient in runtime.
So it is 3 times faster than Webpack, ATM it does not seem worth to be switching to this.
Also the Parcel comparison seems wrong (maybe they are using too old version of Parcel?), see Parcels own benchmarks https://github.com/parcel-bundler/parcel#benchmarks
Clearly a lot of people have put good work into this project, and have decided it adds value to their workflow and your first reaction is to sling mud. Maybe try reddit.
I work in a beige organisation where we're not allowed to use emojis in tickets (they wouldn't render correctly on our PCs anyway). I can't wait to work somewhere else that allows it - I have to spend 8 hours a day at work, may as well enjoy myself a little bit.
I work somewhere where i can use emojis and fight for not using them cos they are distracting and don’t add value. If you red scientific paper full of emojis would you take it seriously?
IMO, the fact that 1726 modules is a “reasonable” number for a web app is a clear indication that there is something seriously wrong with this process.
I think the JavaScript ecosystem needs something akin to Boost. I do not like using Boost in C++, however the way their libraries are built and integrated into standard is awesome.
Yes, kind of, however jQuery is more geared towards the frontend whereas many of the packages pulled in now are for backend or general use (your zero-pads and moment and whatnot)
Yeah, I agree. "Tiny modules" is a thing in JS i.e there are people, influential developers, that champion the existence of modules like "left-pad", "is-positive-zero", etc. The idea is that "npm is the stdlib" but its not a very good one when your node_modules folder is always 1000+ large.
This is one of a few tiring patterns in the JS ecosystem. The other is "you should be using grunt", "should be using gulp", "nooo just use NPM scripts". Ok so now our package manager is a task runner too despite the insistence on "tiny modules that do one thing well coz Unix!"
Now we have webpack. That isn't tiny but is. Its not a build tool. It's a build platform. How do you extend it? Yep. Tiny modules. In the configuration. Zero conf? Maybe for a 0 dependency tiny module. Then when they introduce a major version that breaks pretty much every plugin, the response? "That is what we call a fixed mindset. We want a growth mindset".
I wouldn't mind if the package management solution was built with tiny, one-big-lib in mind. I wouldn't mind if the ecosystem didn't contradict itself so much. Its just tiring.
That's the result of JS lacking anything resembling a standard library. Just look at how long it took just for Object.entries to make its way into the language.
This is both an education issue and a std lib issue. There is no need for packages such as "is-number" or "is-odd" when the language already provides the facilities it check if a value is a number or is even/odd, yet these packages are downloaded a thousand times a a day because they are dependencies in this or that popular package.
For some the first reflex is to add a dependency instead of spending 5 minutes thinking of simple solutions for their use case. But the latter isn't restricted to the node ecosystem.
The avalanche of useless modules profits mainly to NPM, a for profit organisation operating a closed source package repository which imposed itself on the node project in dubious ways. Even nodejs creator regrets it.
Another factor contributing to this being the norm is the fact that web applications are always under pressure to count the bytes over the wire so there's a tendency to break things up into smaller chunks. Otherwise people would be moaning about large files.
I've used used Parcel for a few projects this year and really enjoyed it for the most part. I've found it's basically effortless for building static projects, but its lack of documentation can be frustrating when errors pop up (e.g. I was stuck on an older version for a while due to some issue with a newer release) and I still haven't quite figured out the best pattern for extracting the hashed bundle names for use in other places.
That being said, Webpack 4 (released months ago) shipped with a similar zero config option, so I'll likely go back to it for future projects.
Is something really wrong with WebPack? Didn’t we decide that we want more modularity and plugins, instead of “zero configuration” solutions that lock you into a few technologies? What about the next hip new frameworks that release in the future? Will they just be piled into parcel, or will they add a plugin system? This seems like an unsustainable model.
Caching and parallelization are my complaints with WebPack. WebPack doesn't cache that well out of the box, and plugins like HardSource seem to have errors often enough that they're kind of annoying. WebPack also doesn't have parallelization built in, so you need something like HappyPack. Maybe I was doing something stupid, but I wasn't able to get HappyPack and HardSource to work together nicely.
PS: we haven’t implemented Multicore, or Persistent Caching yet (slated for version 5). This means that there is still lots of room for improvement!!!!
Congrats to the Parcel team! Really great work. Having used Parcel in personal projects for the past year, it really is a great user experience.
Despite what people says in the comments, Parcel has its (great) value. The ability to import a rust file directly and have it compiled to a web assembly module for example, is a great piece of engineering and exceeded my expectations for web build tools. Parcel also hits the sweet spot where it's both zero-config, and easy to customize if you find the need.
Honestly? Parcel has a better experience than your C++ build tools. Be it CMake, Ninja, or whatever build tools people use in 2018.
Gulp has/had the right approach. There's only so much flexibility and complexity configuration format can support without becoming strange copy-pasted incantations that can only be reasonably expressed and clearly visualized through code. And they've proven that, eating Grunt's lunch, but then they blew it with never-ending alpha and general stewardship fail.
And with regards to Parcel vs Webpack, it's not (at least not yet) even a competition since webpack 4 is basically zero-configuration and is so much more advanced tool at all levels.
Just other day was trying to remember why everyone switched from gulp to webpack. There was some reason for it right? Or was it just that gulp/plugins were unstable.
Do remember looking into it for small side project but ended up just using npm scripts, maybe that's part of it.
I love that Parcel is out, even if yes it is another bundle, because it helps highlight the major problem with bundlers right now: they (but especially WebPack) are a meta-platform over the web unto themselves and they encourage use of features that are not supported by the web platform, in a way that's not easily transformed into what the web platform does currently, or will realistically, support, creating lock-in.
Just as we're getting to the point where many of these tools should be optional because we have great modern JS and modules support in browsers, and many projects are already written in supposedly standard modules, many are blocked from actually shipping code that runs un-built on the browser because of bundler features like importing images, CSS, etc.
I hate doing javascript. I have no desire to attempt to understand or mess with JS or build systems past the bare minimum I can manage to get a project working so I can move on with my life.
So I tried using this. It was nice while what I was doing fit inside of everything that was default settings and/or what maintainers used. As soon as I stepped outside of that I ran into things like having to hope someone implemented a Parcel plugin for some random transform (an issue that applies to Webpack, too, but Webpack has so many more users that you're guaranteed someone actually did make one that actually works correctly), or: https://github.com/parcel-bundler/parcel/issues/645. Having an issue on something as popular as Bootstrap 4 be open for 6+ months is pretty frustrating. I spent several hours flailing at this issue to no avail.
I switched to Webpack 4 and had all of my existing build system and some additional niceties working in <45 minutes.
Yes, I would say that typescript is the best way to do JavaScript in 2018. I just converted a Babel es7 project to typescript. I feel like I ended up with a simpler build system in addition to type checking and working source maps. I needed to add a few type declarations to make it build though.
> Are you comparing that as a new web pack user or you're already used to it with a bias of your "hate" toward new JS stuff?
A new user. Most of the time I spent was reading docs.
> Perhaps your problem will be solved as parcel takes more time for third parties to fill those small niches.
Oh yes, probably. That's basically what the advantage of Webpack was. There was more 3rd party stuff and it actually worked. Though really I'd want more first party support, otherwise I'm losing the 'zero configuration' sale that got me to try to use it in the first place.
The main complication remaining with Parcel, IMO, is one that mostly derives from the syntax being used: there's no clear way to separate "I want this file to be added to the bundle, and a string URL for it" and "I want the appropriate representation of this file's contents".
My line of thought here is helper methods in an empty package namespace, so that they only exist at build time and are stripped out in the result.
I spent the day finally adding a modern build system / bundler to my side project, and I chose Parcel. Parcel is really cool! I really wish they'd stop calling it "zero-configuration". It has configuration options (--out-dir, --public-url), there's just no configuration file for them. I really wish they would make one, since it's annoying to have your configuration be hidden in a batch file.
Yeah, In my experience Parcel is nice, but Meteor does a better job at offering a zero-config build system than parcel. Because it also provides the node server (which may of course be seen as a drawback to some) it allows to do stuff like multiple bundles for multiple browsers, exact code splitting using dynamic imports etc. with actual zero-config.
Without investigating, I genuinely can’t tell whether you are joking or not. It seems plausible, save for the fact that would completely undermine the primary marketing message.
Seems like a nice alternative to more opinionated language dependent site generators and webapp frameworks built on top of Webpack (ex. Gatsby, Next.js, Nuxt).
I suspect that most services start very lean, and if they become popular people request more and more stuff and it gets added, making the thing more complicated.
Webpack is too complicated though, so if this can stay simple, why not.
Just tried it quickly; didn't work. It did something and then I got a blank page. Probably some config missing that it needs but the point is: no zero conf and doesn't work as advertised.
Was just pointing out that the tool did not work as advertised (i.e. without configuration). As in parcel index.html does not produce a working app for me. There's nothing to screw up here. Either that works or it doesn't. In my case, it doesn't. It fails to self configure as advertised and it fails to tell me what broke and why (or even that it broke). But it is quite obviously not producing a working application for me.
I imagine this relates to a whole range of broken assumptions it makes about where files actually are in my project, how things are configured on my system, etc. Normally you'd fix that by configuring these things. Since it doesn't provide a whole lot of documentation or guidance other than this thing needing no configuration because it is so smart, I decided against pursuing this thing any further and uninstalled parcel.
I think the ultimate solution to bundling is to go the way of the CLIs, and Angular CLI in particular, where the framework team configures a sensible default bundle config with a few options exposed via the CLI. The user can then build with a single command and everything just works. The user can eject from the CLI and configure manually if needs be, but most of the time that won’t be necessary.
Bundlers probably have a certain minimum complexity that can’t be reduced if they want to be universally applicable, but a lot of that can be hidden for most use cases, particularly if using the same framework.
Yup, just FYI Angulars CLI is based on Embers. Just putting it out there because the oldest thriving framework which put out a lot of great ideas often gets forgotten in these discussions :)
What is WebPack and SystemJS? I am being tongue in cheek but I totally agree. See all this bundling stuff? Nothing is more boring and lifeless to me personally and Angular CLI has shielded me from all of it. Really great project.
The only real problem I am having is lazy loading and dynamic component's. I am being forced really to add routes to lazy load some heavy components but I would really like not to have to deal with that. I believe there is a way to use SystemJS to load dynamic components at runtime but there is scant information and have no interest to pursue it. A small price to pay.
I love the idea of Parcel but I've struggled with a number of non-obvious problems when using it on hobby projects.
° Sourcemaps not working (wrong files / no source translation)
° Randomly losing exports (a module with multiple exports where one of them ends up as an empty object - fix by clearing cache and restarting)
° Errors like "module 71b not found"
° Hot module reload enabled by default, meaning that all top level code runs again when you reload the code (e.g. here's an extra canvas in your dom)
My preferred zero config setup for hobby projects has become <script type="module">[1] and a live reload server[2].
If I'm working on a React project then I will always use Create React App when I can[3].
When I take something beyond the hobby stage and into maintaining it as an ongoing project, I use TypeScript Quickstart[4]—to abstract the underlying Webpack config and start writing code immediately.
I'll only reach for Webpack when I know that I need more flexibility than any of these other tools offer—which isn't very often.
For a recent project (with modest needs), I just used a short makefile[1] and plain ES5. I found the experience refreshing as there is definitely peace of mind in depending on one less black box.
There is indeed something uncomfortable about a big node_modules directory or a magic build tool. It's almost like bathophobia, where instead of depths there is 3rd-party javascript code.
97 comments
[ 4.2 ms ] story [ 278 ms ] thread1. The existing tool is way too complicated to configure and slow. Let me introduce a new, zero-configuration, blazing fast tool
2. OK so because it's strongly opinionated there are some things it can't do. So we'll allow you to extend it via plugins. You'll have to configure this.
3. Due to the increasing popularity, we are making a meta-version that lets you re-plug any element in the entire system with one of your own choosing. You'll have to configure this.
4. GOTO 1.
sounds like progress / innovation to me?
It gives the impression of progress without actually making progress.
This is also why I got tired being a programmer after doing it for many years. First version is always super nice. Then you add features, and refactor. Doing this is slower and slower the bigger your software gets. At the end, your software is filled with complexity and you want to rewrite it from scratch. So you do, and you are back with a nice version. Until again, more features need to be added.
Now, does this example above mean the developer is innovating? Are we getting somewhere? No. At the end, his product is going to be replaced by other products that does the job better - until they also meet the same fate.
Yes, this is the very definition of innovation. Just because what you're working on is going to be replaced, doesn't mean it's not innovative. Of course it's going to be replaced, that's the whole purpose. Hopefully we get better and smarter along the way. Sometimes something that seems trivial to you as an engineer is mind blowing to a layman with domain expertise that goes on to leverage your software to help make the company more money in ways no one was expecting (or maybe save money). In other words, innovating.
With Webpack 4 and Parcel especially, these tool are both zero config and configurable. Your point 1 and 3 are actually not mutually exclusive, and repeating the meme just sounds like you're perhaps out of the loop for a bit.
While the Javascript developer experience truly was horrible a few years back, it has dramatically become better. Try it, and you might be pleasantly surprised :)
Configuring Webpack is still pretty bad. If the zero config works for you, great. But if you need to configure it yourself, it's really verbose, it's really complicated, and the documentation is a bit thin.
SplitChunks in Webpack are like black magic, they work but you don't have any idea how, and when they don't work, you still have no idea how. And you don't know if it's because you didn't configure them properly, because you don't know what is configuring them properly, because the documentation on them is so bad.
Maybe I'm just bad at configuring Webpack, but I still don't understand how many things in Webpack work, and it's given me a lot of headaches, even with the "zero config" Webpack 4.
Have you ever looked at what CRA does? Just do an `eject`. It layers and layers and layers of configuration. The moment you need something not covered by CRA you'll be stuck with the insanity that is webpack config. [1]
webpack 3 did nothing to solve the configuration problems. Heck, just half a year ago one of the core devs of webpack argued that there could be no defaults in webpack and that webpack config is horrendous "because it's javascript" [2] [3]
webpack 4 addresses just some of the long-standing problems with webpack configuration leaving the actual config as insane and inscrutable as ever. And the only reason it exists is probably due to the public outcry of the larger community and tools like Parcel somewhat stealing the thunder.
Parcel is probably the best thing to happen to JS bundlers in recent years, but it's still not without its problems.
[1] I did: https://twitter.com/dmitriid/status/908677755046449154
[2] Webpack team arguing there can't be defaults in October 2017: https://twitter.com/dmitriid/status/920542261020160000
[3] And continues pretending config issues are because of Javascript: https://twitter.com/dmitriid/status/920714918625775618
Looking at JavaScript build tools today and ridiculing it makes as much sense as ridiculing the width of car lanes (from width of wagons) or ridiculing the width of rockets (width of railroads).
Create-react-app works just fine with the 80% case you wanted so badly for webpack team to implement. (Not to mention there are easy ways to make incremental changes without ejecting.) But why let that stop you from writing a rant about webpck’s lack of default either :)
I just looked at it a minute ago.
As for the rest you are equally wrong in anything from assuming that webpack 3 made configuration easier to assuming that configuration became easier just because CRA hides all this complexity from us.
There's only so many hours in the day. There are better things in life than to fight a build tool.
I personally always found a solution with Webpack. I find this amazing for a tool which is so young and written in a language without static types.
But frankly, if a JavaScript developer ever really wants to solve the problem... Learn enough C++ to write the equivalent code that compiles 6.5M in 0.1 seconds (assuming a nice HD).
Traversing that tree to remove unambiguous dead branches seems pretty clear. Perhaps if you get into a tricky manipulation between strings and syntax you could add a little runtime...
Come on man, that's beyond the point. Just because JavaScript needs to be compiled, doesn't mean it has a worse experience than compiling C++.
Instruction ordering is largely bound to instruction pipelining and the estimation of CPU instruction transitioning to reduce latency. Given that V8 uses some degree of virtual indirection... I don't think that's possible in JavaScript.
Believe it or not, some people have problems in domains with contexts that have nothing to do with yours and the things they come up with are equally valid solutions.
Compiling code from C++ to WASM is counter-productive if the native JavaScript is fine. It's just that native languages seem to perform quite a bit better in the domains of graph construction, graph optimization, and even basic string manipulation.
When did WASM come into the picture? I use Parcel because my time is valuable and I don't want to master the arcane arts of modern JS build toolchains but I still NEED to benefit from them if I'm to run a successful business and make sure my investors get their money back and a language I can deliver plain text over HTTP/S that runs performantly across billions of devices that I can modify on the fly is beyond valuable.
> native languages
C++ isn't going to help me deliver my product to my customers in any measurable way that influences the outcome of our relationship. JavaScript, frankly, does - the less time my organization spends writing code, the less we have to charge for things to make up for that margin impact.
Fastpack is a binary JS bundler written in OCaml:
http://fastpack.io/
It’s new and missing some features (http://fastpack.io/docs/get-started.html ), but already faster than Webpack / Parcel. It also supports Webpack loaders.
Also. What’s up with the obsessive use of emojis everywhere? Take a look at this issue for example: https://github.com/parcel-bundler/parcel/issues/144
Just like your comment.
Clearly a lot of people have put good work into this project, and have decided it adds value to their workflow and your first reaction is to sling mud. Maybe try reddit.
This is one of a few tiring patterns in the JS ecosystem. The other is "you should be using grunt", "should be using gulp", "nooo just use NPM scripts". Ok so now our package manager is a task runner too despite the insistence on "tiny modules that do one thing well coz Unix!"
Now we have webpack. That isn't tiny but is. Its not a build tool. It's a build platform. How do you extend it? Yep. Tiny modules. In the configuration. Zero conf? Maybe for a 0 dependency tiny module. Then when they introduce a major version that breaks pretty much every plugin, the response? "That is what we call a fixed mindset. We want a growth mindset".
I wouldn't mind if the package management solution was built with tiny, one-big-lib in mind. I wouldn't mind if the ecosystem didn't contradict itself so much. Its just tiring.
For some the first reflex is to add a dependency instead of spending 5 minutes thinking of simple solutions for their use case. But the latter isn't restricted to the node ecosystem.
The avalanche of useless modules profits mainly to NPM, a for profit organisation operating a closed source package repository which imposed itself on the node project in dubious ways. Even nodejs creator regrets it.
That being said, Webpack 4 (released months ago) shipped with a similar zero config option, so I'll likely go back to it for future projects.
https://parceljs.org/plugins.html
I thought those were fixed in v4?
PS: we haven’t implemented Multicore, or Persistent Caching yet (slated for version 5). This means that there is still lots of room for improvement!!!!
It _is_ coming, which I'm excited about.
https://medium.com/webpack/webpack-4-released-today-6cdb9947...
Despite what people says in the comments, Parcel has its (great) value. The ability to import a rust file directly and have it compiled to a web assembly module for example, is a great piece of engineering and exceeded my expectations for web build tools. Parcel also hits the sweet spot where it's both zero-config, and easy to customize if you find the need.
Honestly? Parcel has a better experience than your C++ build tools. Be it CMake, Ninja, or whatever build tools people use in 2018.
I don't think there are many people who'd say that there's any good experience with using CMake for any slightly complicated project.
And with regards to Parcel vs Webpack, it's not (at least not yet) even a competition since webpack 4 is basically zero-configuration and is so much more advanced tool at all levels.
Do remember looking into it for small side project but ended up just using npm scripts, maybe that's part of it.
Just as we're getting to the point where many of these tools should be optional because we have great modern JS and modules support in browsers, and many projects are already written in supposedly standard modules, many are blocked from actually shipping code that runs un-built on the browser because of bundler features like importing images, CSS, etc.
So I tried using this. It was nice while what I was doing fit inside of everything that was default settings and/or what maintainers used. As soon as I stepped outside of that I ran into things like having to hope someone implemented a Parcel plugin for some random transform (an issue that applies to Webpack, too, but Webpack has so many more users that you're guaranteed someone actually did make one that actually works correctly), or: https://github.com/parcel-bundler/parcel/issues/645. Having an issue on something as popular as Bootstrap 4 be open for 6+ months is pretty frustrating. I spent several hours flailing at this issue to no avail.
I switched to Webpack 4 and had all of my existing build system and some additional niceties working in <45 minutes.
It was never great, not even good.
Perhaps your problem will be solved as parcel takes more time for third parties to fill those small niches.
A new user. Most of the time I spent was reading docs.
> Perhaps your problem will be solved as parcel takes more time for third parties to fill those small niches.
Oh yes, probably. That's basically what the advantage of Webpack was. There was more 3rd party stuff and it actually worked. Though really I'd want more first party support, otherwise I'm losing the 'zero configuration' sale that got me to try to use it in the first place.
My line of thought here is helper methods in an empty package namespace, so that they only exist at build time and are stripped out in the result.
I think really the value proposition here is “very little if any setup needed” and making so there was no setup possible may have gone too far.
Webpack is too complicated though, so if this can stay simple, why not.
People who haven't tried can't even tell if you just screwed it up or there's actually a problem.
I imagine this relates to a whole range of broken assumptions it makes about where files actually are in my project, how things are configured on my system, etc. Normally you'd fix that by configuring these things. Since it doesn't provide a whole lot of documentation or guidance other than this thing needing no configuration because it is so smart, I decided against pursuing this thing any further and uninstalled parcel.
Bundlers probably have a certain minimum complexity that can’t be reduced if they want to be universally applicable, but a lot of that can be hidden for most use cases, particularly if using the same framework.
The only real problem I am having is lazy loading and dynamic component's. I am being forced really to add routes to lazy load some heavy components but I would really like not to have to deal with that. I believe there is a way to use SystemJS to load dynamic components at runtime but there is scant information and have no interest to pursue it. A small price to pay.
° Sourcemaps not working (wrong files / no source translation)
° Randomly losing exports (a module with multiple exports where one of them ends up as an empty object - fix by clearing cache and restarting)
° Errors like "module 71b not found"
° Hot module reload enabled by default, meaning that all top level code runs again when you reload the code (e.g. here's an extra canvas in your dom)
My preferred zero config setup for hobby projects has become <script type="module">[1] and a live reload server[2].
If I'm working on a React project then I will always use Create React App when I can[3].
When I take something beyond the hobby stage and into maintaining it as an ongoing project, I use TypeScript Quickstart[4]—to abstract the underlying Webpack config and start writing code immediately.
I'll only reach for Webpack when I know that I need more flexibility than any of these other tools offer—which isn't very often.
[1]: https://jakearchibald.com/2017/es-modules-in-browsers/
[2]: https://github.com/tapio/live-server
[3]: https://github.com/facebook/create-react-app
[4]: https://github.com/danprince/typescript-quickstart
https://news.ycombinator.com/item?id=15853149 (435 points/163 comments)
There is indeed something uncomfortable about a big node_modules directory or a magic build tool. It's almost like bathophobia, where instead of depths there is 3rd-party javascript code.
[1]: https://github.com/gvalkov/tailon-next/blob/master/frontend/...