Hacker News Reader

Comment by tengbretson | Hacker News Reader

The amount of pressure you feel telling you you are using too many tools should scale linearly with the number of tools you use. This discomfort you feel with seeing all of those config files is telling you something. Use fewer tools.

View on HN

I tend to see a glut of tooling as a sign that a language has serious design flaws, as most important things should be done by the compiler, but I’d rather have JavaScript with proper tooling and types than nothing at all.

JavaScript isn’t the hero we wanted, but TypeScript is the hero we need.

JS is a great language for it's intended purposes but I still can't get onboard the TS train. Adding types post-hoc has never improved a codebase that I've seen but it has caused a lot more bad patterns to show up.

Simplicity is a virtue (at least sometimes).

> JS is a great language for it's intended purposes

Which part of JS, as a programming language, do you see as great or even adequate when compared with contemporary programming languages?

> Adding types post-hoc has never improved a codebase that I've seen but it has caused a lot more bad patterns to show up.

That assertion makes no sense. I mean, all TypeScript does is impose arbitrary sanity checks on a programming language which is plagued for not having any. Where do you interpret the addition of sanity checks as a source of problems?

> Adding types post-hoc has never improved a codebase that I've seen but it has caused a lot more bad patterns to show up.

I mostly meant that I do all my greenfield JS dev using TypeScript. Out of curiosity, what bad patterns have you seen caused by adding types “post-hoc”?

with ESLint and Prettier on top.

also don't forget:

- .eslintrc.json to configure ESLint

- .prettierignore because it tries to format package-lock.json

- prettier.config.json

- npm/yarn and package.json + node_modules

- .nvmrc to pin your node version

- storybook

- renovate to update dependencies

- .editorconfig to ignore node_modules

- mocha for testing and .mochaarc.js

- stylelint and .stylelintrc.json + .stylelintignore

And maybe throw in Jest, tsconfig.json, a gulpfile, and some other stuff.

Maybe it’s just because I was raised on this ecosystem, but in my opinion the sheer amount of incredible functionality you get from all this tooling (at the low price of $0!) is worth 10-15 set-and-forgot files that don’t even show up when you type ls.

While I totally agree that the functionality of most tools is really impressive, this doesn't mean that the current standard of dropping 5 new config files into root for a tool is the best way to handle this. There are ways to do better. It seems that the maintainers of those tools just don't care.

Your comment makes me extremely happy that I haven't needed to deal with anything written in Node. This would drive me absolutely bonkers.

Hell, I thought Flask's root directory was getting a bit fluttery with .gitignore, .venv, .flaskenv, __pycache__, and requirements.txt...

My god, I love Elm.

Systemd pokes its head around the corner. Build tools? Its stomach rumbles. The beast hungers.

So my project will have var/run/.build-unit?

I think the problem isn't the existence of the config files (since they don't change often), but the fact that they take up a disproportionately prominent place in the root directory (since most configure a tool that handles one particular problem that not everyone will have strong opinions about).

Having lots of tools is, in some ways a good thing. That's how Unix was designed: have lots of little tools, each designed really well for its job. If you have a problem, and there is a tool for that problem, there's nothing wrong with using the tool to solve the problem. It may come with a learning curve, but what often happens without the tool is you end up evolving your own tool anyway, it's just not as well designed as the industry leader.

The problem described on this git issue is generally less of a problem on the Java projects I've worked on, since most of the equivalent configuration ends up in the pom.xml. The JS equivalent problem isn't a problem of too many tools in itself, but rather that no tool in JS has done what Maven has for Java.

Not sure I agree with this due to the fact that all projects are different and such their tooling requirements will be different. I don't think it's fair to just apply a blanket rule of 'use fewer tools' - this tends to end up with people writing their own implementation of existing tools which then turns in to tech debt so it's kind of a void argument.

I think this argument is more about utilizing minimalism in software design than always writing-it-yourself. IMHO many of us have seem to favor a form of feature maximalism, and perhaps we should be tempering our ambitions design-wise. Too much software has far too large a surface area.

For anyone doing typescript, there are just a number of tools you need to work with on a project. And then there's value added with things like eslint and prettier. Most of these configs are set and forget.

There's lots to complain about in JavaScript land but IMO having a bunch of config files in the root is a feature, not a bug.

It's the same with libraries, IMO. Of course both tooling and libraries increase with the size of your project, but if either is disproportionately large compared with the size of the code involved, it's a bit smelly.

That's short-sighted. What about repos containing eg. a frontend and a backend? I did that with a Go/React project and I naturally ended up with: eslint conf, prettier conf, tsconfig, package.json, yarn.lock, editorconfig, Makefile, jest config, go.mod/go.sum, golangcilint.yml, Docker file/.dockerignore and travis.yml. Tell me, what should I discard?

And no, splitting the Go part and the React part is not an option as it makes releasing ten times harder.

Telling people to "just use fewer tools" might make you feel clever, but it's just snarky, really.

Linearly? I’d say quadratically.

Reply on news.ycombinator.com