While most of us can agree on that, and while it’s good to have a laugh at our own expense, I feel the need to address this problem. There was a certain familiarity to the fictional dialogue in Jose’s piece; twice in the past two weeks I’ve onboarded predominently back-end developers to a front-end project. These were smart, experienced developers, but as we went down the rabbit-hole of front-end tooling I could see almost see their thoughts turning to “Jesus, this is a lot of moving parts. Aren’t we just building a few screens here? Why all this complexity?”
It was, as they say, a bit of an eye-opener, and as a custodian of that particular front-end codebase I felt an obligation to make it better for next time. So, here are my ideas:
Provide a simple developer CLI
Newcomers don’t need to know right away (it might be quite a while before they care) which particular tools you’re using for task running, transpiling, linting, testing, bundling etc. and how they all work together. npm scripts can help with this. I find their value is in abtracting your “developer CLI” away from the many individual tools it uses, and removing the requirement to have anyone working on the project install a bunch of dependencies globally.
For example, you might use npm scripts to produce a developer CLI something like this:
# pull in all dependencies, both npm and bower, # do all transpiling and copying - the project # should be browser-ready after this $ npm install # check for lint and run all unit/integration/e2e tests # if this finishes green, your changes should be okay $ npm test # start the local web server and launch the app in your browser $ npm start # watch for code changes and automatically recompile $ npm run watch
Most projects shouldn’t need any more than that. The fact that under the surface you are using Bower, Gulp, LESS, eslint, Jasmine, Karma, Express and whatever else doesn’t need to be a thing for someone until they’re ready to start digging into it. In the meantime, the only things they have to make sure they install are Node and npm.
- Which versions of Node and npm are safe to use?
- What if I have problems installing?
- Why does the watch fail sometimes?
- How can I best set my editor/IDE up for this project?
Have all these questions (and more) answered, and not on some distant wiki that no one thinks to check — put your documentation in the source (in Markdown format, of course), and keep it updated. People say documentation just sits there getting out of date, but only if it’s no one’s job to update it. If it’s no one’s job right now, make it yours.
Go back over your tooling choices periodically, looking at each one. Do we need this? Is the tool providing enough benefit when weighed against its costs? Could this problem be solved more simply?
(In amongst the outranged responses, Addy Osmani’s was refreshingly measured and helpful.)