6 ms·

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

by joshwa 7y 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 7y 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.
- e12e 7y 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...
devongovett 7y 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! :)
- ironmagma 7y 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.
  - Sawamara 7y ago
    I feel that pain, yeah. On the other hand, at least the error messages are often helpful with Webpack.
  - devongovett 7y ago
    Yep! I think we should be able to publish a JSON schema definition that editors like vscode can use to provide autocomplete etc.
    - orf 7y ago
      That’s not strong typing, that’s automated (and not necessarily up to date) documentation :(
      - devongovett 7y ago
        Is there another way to provide strong types for a JSON file? I believe vscode uses schemas from http://schemastore.org/ http://schemastore.org/ for many config files already.
        orf 7y ago
        It wasn't clear until now that the configuration is done through JSON rather than being configurable through code (i.e TypeScript). Urgh, JSON for configuration. That's going to be horrible.
        devongovett 7y ago
franciscop 7y 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 7y 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.
jchw 7y 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 7y 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.
- erikpukinskis 7y 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.
  - smallnamespace 7y ago
    One person’s bedrock is another person’s pile of anachronisms, cruft, and poorly designed abstractions held together with duct tape.
    - erikpukinskis 7y ago
      Bedrock in this sense is small tools that you either build on or you don’t. What you’re describing is different: “Abstractions” are by definition unnecessary, they are imaginary things which imperfectly model of some real things underneath. They are contrasted with control systems, which strive to manipulate those things without any metaphor. “Cruft” is items which you don’t need that are bundled with items you do need. It is contrasted with tools that are easy to just not use at all. I don’t know what anachronism means in this context. I’m not saying it’s easy to make tools that are neither abstract, nor bundled with unrelated things. Just that it is a place you can aim for. I disagree with your notion that abstractions and cruft are inevitable. They’re not inevitable, they are encouraged in the present development climate.
  - 7y ago
j1elo 7y 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.

by joshwa 7y ago

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

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

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

ironmagma 7y 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.
- Sawamara 7y ago
  I feel that pain, yeah. On the other hand, at least the error messages are often helpful with Webpack.
- devongovett 7y ago
  Yep! I think we should be able to publish a JSON schema definition that editors like vscode can use to provide autocomplete etc.
  - orf 7y ago
    That’s not strong typing, that’s automated (and not necessarily up to date) documentation :(
    - devongovett 7y ago
      Is there another way to provide strong types for a JSON file? I believe vscode uses schemas from http://schemastore.org/ http://schemastore.org/ for many config files already.
      - orf 7y ago
        It wasn't clear until now that the configuration is done through JSON rather than being configurable through code (i.e TypeScript). Urgh, JSON for configuration. That's going to be horrible.
        devongovett 7y ago

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

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

erikpukinskis 7y 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.
- smallnamespace 7y ago
  One person’s bedrock is another person’s pile of anachronisms, cruft, and poorly designed abstractions held together with duct tape.
  - erikpukinskis 7y ago
    Bedrock in this sense is small tools that you either build on or you don’t. What you’re describing is different: “Abstractions” are by definition unnecessary, they are imaginary things which imperfectly model of some real things underneath. They are contrasted with control systems, which strive to manipulate those things without any metaphor. “Cruft” is items which you don’t need that are bundled with items you do need. It is contrasted with tools that are easy to just not use at all. I don’t know what anachronism means in this context. I’m not saying it’s easy to make tools that are neither abstract, nor bundled with unrelated things. Just that it is a place you can aim for. I disagree with your notion that abstractions and cruft are inevitable. They’re not inevitable, they are encouraged in the present development climate.
- 7y ago

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