
I Don't Want to Configure Apps (2016) - knivets
http://robotlolita.me/2016/01/09/no-i-dont-want-to-configure-your-app.html
======
noneedtoask
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.

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

Since working at a large-ish company, I've come to appreciate "convention"
more -- the last thing I need when trying to implement a new feature in a
random app is having to understand the architecture choices the original
developer made. If they used a standard framework, I can be productive more
quickly.

~~~
sombremesa
In my experience, being "productive more quickly" has costs down the road,
many times paid by other developers who inherit your decisions. I think what
the person you're replying to is saying that having so called "speed bumps" on
the road is a good thing, it forces you to slow down and take a look at what
you're doing. Agile == fragile these days.

------
TheAceOfHearts
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](https://github.com/facebookincubator/create-react-app)

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

------
bpicolo
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](https://laravel.com/docs/5.5/mix)

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

[2]
[https://blogs.msdn.microsoft.com/webdev/2017/02/14/building-...](https://blogs.msdn.microsoft.com/webdev/2017/02/14/building-
single-page-applications-on-asp-net-core-with-javascriptservices/)

~~~
sampl
What would you add to create-react-app?

~~~
bpicolo
My typical case is needing a backend for an API layer (and also pages I just
don't want to fuss with SPAs for - data-heavy admin pages and such where it's
a bunch of wasted effort and boilerplate to do in SPA form). With the
alternatives above you get that integrated in dev environments all the way
through minified in production.

~~~
sampl
Totally makes sense, thanks

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

~~~
yoz-y
I think this thesis could be expanded to complex applications as well. For
example one can use Word out of the box to write documents. That is the
application's "one" purpose.

You can customize things such as the themes, but it does come with one
preinstalled and selected by default. If people needed to download a "default
theme pack" and then configure the default theme in the settings dialog before
they could even write the first document I think many would abandon it very
quickly.

I do disagree with parts about manuals though. Many applications need not only
manuals, but whole series of books written about how to use them.

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

------
kstenerud
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>'

~~~
TeMPOraL
Related, know your users. NVM is a tool for programmers, and programmers like
to:

1) Batch things. Hence no interactivity is a good thing, like you pointed out.

2) Know what's going on in the system. If `nvm use` both selects a node
version and installs it if missing, then I want to also have `nvm install`
_and_ `nvm select* commands - the former so I can batch stuff, and the latter
to feel confident that issuing it won't do significant changes to my system,
won't download stuff, and otherwise won't break anything.

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

~~~
joshribakoff
Can't speak to the microwave, but there are examples of this kind of UI such
as [https://github.com/nvbn/thefuck](https://github.com/nvbn/thefuck) the
trade off is the potential of ambiguity, see
[https://en.wikipedia.org/wiki/Time_flies_like_an_arrow;_frui...](https://en.wikipedia.org/wiki/Time_flies_like_an_arrow;_fruit_flies_like_a_banana)

Your microwave does sound badly designed though.

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

------
akatechis
Old clickbait.

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

~~~
yoz-y
Why? Is there any particular reason why software should be hard to use? There
are no spikes on my kitchen knife's handle.

I'd rather spend more time creating software than fighting with the build
system or the tooling.

~~~
hashkb
Hard to make, not use. It is because it is. Maybe I should have said "It's not
supposed to be easy"

