Tooling should Disappear

date
Jan 9, 2021
published
slug
tooling-should-disappear
description
Developer tooling is expensive. I hate setting it up. Maybe in the future I won’t need too.
When I got into web development, I had very few tools. Maybe a PHP server, eventually a MySQL database. I had a simple editor like Notepad++ or even directly editing the site inside cPanel on a shared host. It was a simple time, and I loved it.
Things are different now. We have webpack or rollup. We use client side libraries like React or Vue to create HTML. Calls to the database are through GraphQL now, which requires we setup a schema. I can’t possible continue without prettier, and eslint. Don’t forget about the testing framework, we need Jest, Supertest, Rewire, and Cypress. And don’t forget about babel or typescript. Clearly we can’t live without ES6, ES7, ES9 features. Got to use the latest hotness.
I know I am not alone in this frustration.
Standing up a new project use to be easy. You create a new folder with a index.html file and get too it. Maybe you had to configure a new SFTP in your FileZilla. Now, you have to install a ton of modules, write more code, and you don’t even touch HTML or CSS files anymore. I know I am not alone in this frustration.

Deno

Deno was a fresh take when I used it for the first time a year ago. I installed Deno, and it came with a testing framework, linting, formatting, and the ability to process TS. It even has a bundle for non-web facing code. Need a module? No need to install, just reference the URL to the resource directly and move on. That was it. It had a blessed first party library similarly to GoLang. It was amazing.
With little effort, I was productive. It was way better than node to get started. I could not only build small test script files, but I could include TS for the first time without setting up the tooling. And it was fast, and getting faster.

Snowpack and Vite

Snowpack and Vite have been refreshing for the community. They support ES6 modules as the primary source of building during development. They are fast because they used a ESBuild modules to compile instead of TS Compiler or the node tools. Within ms a page is rendered or hot reloaded.
When deploying, they can bundle a more traditional payload to the browser, as not all browsers can handle ES6 modules, and there is a large network waterfall that can happen.
But for development, they cut out a lot of the problem space. It is a reoccurring theme.

Next.js

Next.js is even trying to lower the barrier. It has done a lot of obfuscate and remove the webpack config. Want TypeScript, add a empty tsconfig.json and it just works. While tied to older technology, it has made it a priority to improved reload speed during development. Of all the tools here, it has done more to make the existing tooling more manageable, showcasing what you can do by doubling down on the developer experience for the existing tools.

Final Thoughts

I hope this trend continues. We over indexed in the past few years on setting up a large amount of tools. We are at the start of a land grab to earn the keystrokes of the future developers. While there will not be one winning technology, it is clear we are at the start of a shift. Focusing on developer ergonomics while still ensuring best practices for the final output.