5 ms·

> An all new plugin system, which makes Parcel fully extensible. This allows Parcel to scale from small side projects to massive production applications with co

> An all new plugin system, which makes Parcel fully extensible. This allows Parcel to scale from small side projects to massive production applications with complex build requirements. Everything old is new again! Parcel embarks on the path that Webpack did, and it's only a matter of time before the plugins are doing more and more core work, and Parcel's successor will again rewrite them and bring those in to the core.

izelnakri 5y ago
controversial comments always make the first page/gets the most attention. I suggest you refrain from them because I found your comment pointless/fake and wrong after using both tools & webpack plugins for many years.
- AaronFriel 5y ago
  I'm sorry you felt that an observation on the cyclical nature of technology tools was controversial, pointless, fake, and wrong. I think it's pretty impressive if my comment was all of those things.
- hsn915 5y ago
  I think anyone who has the misfortune of having to deal with webpack knows the pain very well.
  - izelnakri 5y ago
    Webpack is a pain to use I agree, I've never liked webpack. My comment is on the behavior of trying to look smart/funny(meme-y) while lacking actual substance.
    - hsn915 5y ago
      When A points out a real problem, and B comments with "old man yelling at cloud". Who's the one exhibiting "problematic" behavior? I think it's B.
      - root_axis 5y ago
        A free open source tool exists for you to use if it suits your needs. What exactly is the "real problem" here?
        bryanrasmussen 5y ago
        >A free open source tool exists for you to use if it suits your needs. I do not believe that webpack suits my needs, it is in my opinion incredibly inferior to Gulp. So Gulp suits my needs. Nonetheless I have had to basically use nothing but webpack for the last 5-6 years unless I do something for myself! Why is that? Well it turns out that when I go to work at some place they have set up everything with webpack, why? Well that's what everybody else does, nothing we can do about it now. Hardly anyone in the real world only uses tools because they suit their needs, they use the tools that have been chosen by someone else. Ok, so then something goes wrong with webpack build, anyone at the place know the depths of webpack and how every different plugin/module is screwed together - nope, we use webpack here but have no webpack experts - so they spend some days fixing things. Or even worse we want something that there is no webpack solution for that we can find - either we need to fix it ourselves with a plugin / module / fork of plugin module we want to extend (after asking fruitlessly on StackOverflow if someone knows) or we have to do a horrible hack to fix it. I am sure there are some webpack experts out there who take minutes to fix problems they encounter in webpack, but my experience is that a webpack problem any more complex than we don't have a plugin for that file extension seems to require a developer day to fix (not just me as the developer, other developers always seem to take the same amount of time). now before someone jumps in and cleverly changes my complaints to use Gulp instead of webpack (if you weren't thinking of doing this you can stop reading now) - can you point out to having a similar experience with gulp? Because I can't, and if I wanted to write a gulp plugin (which I have done twice) it was insanely easy because all you have to do is to understand vinyl streams and that's it; everything in Gulp has the same model of how things work - that really speeds up problem solving time.
        root_axis 5y ago
        I'm still not understanding the problem. If webpack doesn't suit your needs then don't use it. If your employer's technical leadership picks technologies based on fashion rather than suitability for the problem that's not a failure of the technology, that same problem surrounds literally every popular technology irrespective of its technical properties.
tshaddox 5y ago
That sounds...good!
AnonHP 5y ago
This comment by @stupidcar (December 5, 2017) [1] from the first Parceljs post seems pertinent. I’m not pasting the entire comment; visit the link below to read it: > The eternal cycle of developer tool bullshit: > 1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!" > 2. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast." > 3. "SuperTool™ v1.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension." > ...repeat for a while... > 10. "Introducing SuperTool™ v2.0.0, which now has a more flexible API and configuration , allowing many former hacks to be done in a straightforward way." > … [1]: https://news.ycombinator.com/item?id=15853907 https://news.ycombinator.com/item?id=15853907
- duiker101 5y ago
  The other day I was playing around with parcel V2 and I ended up having to write a config file for something that I believe was included in v1... The whole point of parcel for me was avoiding config files... I feel like this release is missing the point
  - FinalBriefing 5y ago
    I think they discovered that if a library tries to provide "zero config", users quickly end up needing to configure something, or reconfigure something else. I still don't think that Parcel is right for me given how comfortable I am with Webpack, but I welcome a "simpler config" option. Provide language support, but don't assume I want to use Babel, or PostCSS, or any other build tool.
- repsilat 5y ago
  I guess the whiggish interpretation is that if each step is an improvement then the cycle represents steady progress, if not arrived at as directly as could be hoped. Maybe a cynic says that the extensions are negative-sum, or the rewrite is (either to adopting teams, or to a fragmented wider community.) I'm an optimist, though admittedly entirely ignorant of this project. I think some capacity is sometimes lost when new projects are started with new technologies that don't live up to their predecessors, but that accusations of tool choice being fashion-driven are mostly misplaced. There are real, tangible, frequent improvements, and disruption is probably the price of innovation. And it's a price you can mostly avoid paying if you want to keep using what you're using.
jjeaff 5y ago
I could be wrong, but I don't think webpack ever "just worked" right out of the box to the extent that parceljs does. I was in the middle of all kinds of gulp and webpack configuration when I discovered parcel a few years ago. A single command "parcel watch *.html" just worked. It detected that I was using react, followed the js includes and all the other dependencies and handled hot reloading and typescript and all the included css and sass and everything else. It was magic. It even did yarn add for any new dependency imports that weren't already in the packages.json. My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.
- k3liutZu 5y ago
  > My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack. Uff, really hits the nail on the head from my experience with setting projects in the early webpack days.
- wruza 5y ago
  And also go to a vacation at every release, because your config uses plugins that a) can’t keep up, b) can’t help but break previous version compat, and now it’s snafu for few months. And for beginners, good luck finding out the correct set of versions that support what you need simultaneously. One LARGE upside of all-in-one include-all packages is that you can’t find yourself in that sort of a gridlock.
nextaccountic 5y ago
Who cares? As long as the tools are improving, this shouldn't matter.
foota 5y ago
At least the core gets better with each new system :-) I joke, but only somewhat.
dahart 5y ago
> Everything old is new again! Parcel embarks on the path that Webpack did And Webpack embarked on the path that it’s forefathers did.. gulp, babel, browserify, grunt, and others. But that didn’t stop Webpack from improving on what was there. The core thing Parcel does (or at least did when Parcel was started) that is/was a fundamental improvement over Webpack is parse your index.html (or whatever you name it, of course) to figure out what to do. I always thought Webpack was silly for asking a human to re-describe it’s html dependencies. I haven’t used Webpack in the last year, so I’m unaware if Webpack has fixed this shortcoming.

izelnakri 5y ago

controversial comments always make the first page/gets the most attention. I suggest you refrain from them because I found your comment pointless/fake and wrong after using both tools & webpack plugins for many years.

AaronFriel 5y ago
I'm sorry you felt that an observation on the cyclical nature of technology tools was controversial, pointless, fake, and wrong. I think it's pretty impressive if my comment was all of those things.
hsn915 5y ago
I think anyone who has the misfortune of having to deal with webpack knows the pain very well.
- izelnakri 5y ago
  Webpack is a pain to use I agree, I've never liked webpack. My comment is on the behavior of trying to look smart/funny(meme-y) while lacking actual substance.
  - hsn915 5y ago
    When A points out a real problem, and B comments with "old man yelling at cloud". Who's the one exhibiting "problematic" behavior? I think it's B.
    - root_axis 5y ago
      A free open source tool exists for you to use if it suits your needs. What exactly is the "real problem" here?
      - bryanrasmussen 5y ago
        >A free open source tool exists for you to use if it suits your needs. I do not believe that webpack suits my needs, it is in my opinion incredibly inferior to Gulp. So Gulp suits my needs. Nonetheless I have had to basically use nothing but webpack for the last 5-6 years unless I do something for myself! Why is that? Well it turns out that when I go to work at some place they have set up everything with webpack, why? Well that's what everybody else does, nothing we can do about it now. Hardly anyone in the real world only uses tools because they suit their needs, they use the tools that have been chosen by someone else. Ok, so then something goes wrong with webpack build, anyone at the place know the depths of webpack and how every different plugin/module is screwed together - nope, we use webpack here but have no webpack experts - so they spend some days fixing things. Or even worse we want something that there is no webpack solution for that we can find - either we need to fix it ourselves with a plugin / module / fork of plugin module we want to extend (after asking fruitlessly on StackOverflow if someone knows) or we have to do a horrible hack to fix it. I am sure there are some webpack experts out there who take minutes to fix problems they encounter in webpack, but my experience is that a webpack problem any more complex than we don't have a plugin for that file extension seems to require a developer day to fix (not just me as the developer, other developers always seem to take the same amount of time). now before someone jumps in and cleverly changes my complaints to use Gulp instead of webpack (if you weren't thinking of doing this you can stop reading now) - can you point out to having a similar experience with gulp? Because I can't, and if I wanted to write a gulp plugin (which I have done twice) it was insanely easy because all you have to do is to understand vinyl streams and that's it; everything in Gulp has the same model of how things work - that really speeds up problem solving time.
        root_axis 5y ago
        I'm still not understanding the problem. If webpack doesn't suit your needs then don't use it. If your employer's technical leadership picks technologies based on fashion rather than suitability for the problem that's not a failure of the technology, that same problem surrounds literally every popular technology irrespective of its technical properties.

tshaddox 5y ago

That sounds...good!

AnonHP 5y ago

This comment by @stupidcar (December 5, 2017) [1] from the first Parceljs post seems pertinent. I’m not pasting the entire comment; visit the link below to read it: > The eternal cycle of developer tool bullshit: > 1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!" > 2. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast." > 3. "SuperTool™ v1.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension." > ...repeat for a while... > 10. "Introducing SuperTool™ v2.0.0, which now has a more flexible API and configuration , allowing many former hacks to be done in a straightforward way." > … [1]: https://news.ycombinator.com/item?id=15853907 https://news.ycombinator.com/item?id=15853907

duiker101 5y ago
The other day I was playing around with parcel V2 and I ended up having to write a config file for something that I believe was included in v1... The whole point of parcel for me was avoiding config files... I feel like this release is missing the point
- FinalBriefing 5y ago
  I think they discovered that if a library tries to provide "zero config", users quickly end up needing to configure something, or reconfigure something else. I still don't think that Parcel is right for me given how comfortable I am with Webpack, but I welcome a "simpler config" option. Provide language support, but don't assume I want to use Babel, or PostCSS, or any other build tool.
repsilat 5y ago
I guess the whiggish interpretation is that if each step is an improvement then the cycle represents steady progress, if not arrived at as directly as could be hoped. Maybe a cynic says that the extensions are negative-sum, or the rewrite is (either to adopting teams, or to a fragmented wider community.) I'm an optimist, though admittedly entirely ignorant of this project. I think some capacity is sometimes lost when new projects are started with new technologies that don't live up to their predecessors, but that accusations of tool choice being fashion-driven are mostly misplaced. There are real, tangible, frequent improvements, and disruption is probably the price of innovation. And it's a price you can mostly avoid paying if you want to keep using what you're using.

jjeaff 5y ago

I could be wrong, but I don't think webpack ever "just worked" right out of the box to the extent that parceljs does. I was in the middle of all kinds of gulp and webpack configuration when I discovered parcel a few years ago. A single command "parcel watch *.html" just worked. It detected that I was using react, followed the js includes and all the other dependencies and handled hot reloading and typescript and all the included css and sass and everything else. It was magic. It even did yarn add for any new dependency imports that weren't already in the packages.json. My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.

k3liutZu 5y ago
> My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack. Uff, really hits the nail on the head from my experience with setting projects in the early webpack days.
wruza 5y ago
And also go to a vacation at every release, because your config uses plugins that a) can’t keep up, b) can’t help but break previous version compat, and now it’s snafu for few months. And for beginners, good luck finding out the correct set of versions that support what you need simultaneously. One LARGE upside of all-in-one include-all packages is that you can’t find yourself in that sort of a gridlock.

nextaccountic 5y ago

Who cares? As long as the tools are improving, this shouldn't matter.

foota 5y ago

At least the core gets better with each new system :-) I joke, but only somewhat.

dahart 5y ago

> Everything old is new again! Parcel embarks on the path that Webpack did And Webpack embarked on the path that it’s forefathers did.. gulp, babel, browserify, grunt, and others. But that didn’t stop Webpack from improving on what was there. The core thing Parcel does (or at least did when Parcel was started) that is/was a fundamental improvement over Webpack is parse your index.html (or whatever you name it, of course) to figure out what to do. I always thought Webpack was silly for asking a human to re-describe it’s html dependencies. I haven’t used Webpack in the last year, so I’m unaware if Webpack has fixed this shortcoming.