Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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


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.


For Node create-react-app is a counter-example. I happily use it and get all the benefits of an optimized build and live reload, but I don't have to configure any of it.


Configuration is static while conventions tend to be ideological. That said I've lost a lot of hours to webpack bugs, some having to do with versioning, others having to do with its interaction with 3rd party libraries. Far from a solved problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: