by knivets on 12/2/17, 12:06 PM with 26 comments
by noneedtoask on 12/2/17, 1:04 PM
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.
by TheAceOfHearts on 12/4/17, 4:41 PM
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...
by bpicolo on 12/4/17, 2:34 PM
[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-...
by kbutler on 12/4/17, 1:11 PM
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”
by tiben_ on 12/4/17, 4:32 PM
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.
by kstenerud on 12/4/17, 6:24 PM
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>'by jdmichal on 12/4/17, 8:10 PM
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?
by habeebtc on 12/4/17, 5:03 PM
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)
by akatechis on 12/4/17, 4:17 PM
by hashkb on 12/4/17, 2:53 PM