I think the configurations are a necessary evil, at least for now. Especially in the Node environment, we complain about too much configuration being necessary but we like the results: HMR, Native mobile apps, backwards-compatibility, syntax sugar, plugin support, higher performance, smaller size.

I am shamefully at fault of blaming configurations myself, hoping to see the day that Webpack becomes more imperative than declarative (a new tool like Gulp was to Grunt). But I know that, like everything, these things are not magic. You need to have code in a certain way to get the wanted benefits.

I agree you can get burnt out by adopting too many tools at once. And in the Node community, we are especially bad at this, expecting novices to adopt Babel, Webpack and another framework like Angular or React from the get-go. Especially since you never get to use them to their full extent.

If all you use Babel for is the arrow function, you should just not install it and use the old notation.

> Humans are bad with choices, and they’d rather not make them.

This has a name, it's called choice paralysis. It is not that we are bad at making choices, it is the fact that sometimes it takes too much effort to make them compared to the reward.

> Convention over configuration

I prefer as little convention as possible. It forces me to change my project structure if I intend to use your library. Chances are my project structure is gonna win over your library.

Also, consider this, it is relatively easy to get from configuration to convention. It is almost impossible to do it in reverse.

> “I need the user’s name so I can associate it with—” ask the OS for that information.

Please don't.

Requirements vary per users. If you want a zero-conf solution, you can use create-react-app [0].

I use fish as my shell because it has far more sensible defaults than bash and zsh, but I understand why they can't just "fix" the quirks. Fixing their quirks and changing the defaults would likely break tons of existing scripts.

This pretty much goes for every large software project. As another example, consider many of the web's defaults. You need to specify the doctype or you get quirky legacy behavior. If you don't explicitly specify utf-8 as the charset it'll try its best to guess [1] and will likely default to the wrong value. And don't get me started on CSS!

I think the complexity is being overblown though. Take a look at the build scripts for some truly huge projects like Android or Chrome. Now those sure are insane. Trying to figure out how it all connects together is an exercise in futility.

[0] https://github.com/facebookincubator/create-react-app

[1] https://html.spec.whatwg.org/#determining-the-character-enco...

Laravel Mix[0], Rails Webpacker[1], and Dotnet's Spa Services[2] (among others) all do fantastic jobs getting you going with new frontend tech alongside backend apps. It's kind of amazing that the JS world does a bit of a worse job here. Too much focus on the hip new way vs getting things done? Seems boilerplate exists mostly to make "Universal" apps now, but I've yet to see a straightforward attempt at that (not to mention, the distinction for things that work in-browser vs not is going to be confusing for beginners in the single-language-JS approach). create-react-app is fine but it only does half the job.

[0] https://laravel.com/docs/5.5/mix

[1] https://github.com/rails/webpacker

[2] https://blogs.msdn.microsoft.com/webdev/2017/02/14/building-...

TLDR convention over configuration improves out of the box usability

But the author’s definition of application is pretty narrow - similar to but opposite from the narrow view of an ERP vendor that anything but ERPs are “toy applications”

I agree with the fact that error messages in some applications can be improved. This article shows a good example.

Conventions are really important to speed up the basic usage understanding of a tool, both cli and gui applications. In my memory ESR did a good job at explaining cli applications Unix conventions (defaults arguments, configuration file locations etc.) in is book "The Art of Unix Programming".

But the complexity of a tool depends on the domain it covers and targeted users. In fact i disagree with the conclusions of the coffee machine analogy. One machine is for professional user the other not.

I disagree with the "no documentation" argument too. "Understand by intuition" paradigm works for basic scenarios from domains understund by anyone (music player, email) but it has its own limits when the software involves complex concepts sometimes inherent to the domain covered. In theses cases, a well written documentation is far more useful to understand theses concepts than clicking everywhere like a monkey ihmo.

No, please, no interactivity! Make a decision here and now.

A better approach to the "use stable" part of nvm:

    $ /.nvm use stable

    Node stable (5.0.0) not found. Installing...

    Now using node v5.0.0.

    Setting v5.0.0 as the default since it's the only version installed. To change the default, run 'nvm default <version>'

The example regarding nvm reminds me of my microwave, of all things. I love this particular interaction it has:

1. Hit the timer button, because you want to start a timer.

2. Enter the desired time.

3. Hit start.

4. Watch microwave tell you to hit the timer button.

5. Hit the timer button, watch your timer start.

In what world of engineering did they think it was better to output an error message, instead of just doing what you wanted to do?

The author is advocating adding a lot of complexity to the install routines to avoid having to ask users questions in order to configure the application.

This is itself problematic. Using their example:

1. Reading info from package.json. What happens when there are multiple files schemas for these files (add complexity to handle these use cases) 2. What happens when some users have multiple package.json files (add complexity, by letting them change from the default) 3. What happens when the values change in the file (should this be handled? If so, it adds complexity)

And so on and so forth. Eventually every installer ends up trying to be everything to everyone, with many added potential points of failure, added dependencies, etc. Just to integrate all this stuff away from the user having to do something. Then the installer ends up as bloated, complicated and fragile as the application it installs.

At least, this is my experience with Windows installers. (Which I have a lot of experience with)

Old clickbait.

This article sums up what I think is wrong with "kids today" in software engineering. It's supposed to be hard, you're supposed to have to figure out confusing errors, powerful tools require understanding and configuration, and nobody is supposed to be there to catch you.