Tool Overkill: The Joys of Simple Development
I’ve read countless posts bemoaning how complicated front-end development has become. I would always read those and think, yes I agree, but at the same time the front-end is incredibly complex. We have to support lots of different screen sizes and browsers, and I figured the complexity in the tooling was a result of the complexity of the problem.
Then I decided to conduct an experiment. I created two silly projects – one is a site to list all the spot and on demand prices of EC2 machines, and the other is a chrome extension that allows me to quickly filter the first page of my email.
As for the extension: a couple of years ago I created something similar named Gmail on Rails. For that I used Angular, Require.js, JQuery, and several other libraries I don’t remember. There were around 1000 lines total.
Both of these projects work, at least to the degree that I need them to, and I completed them with minimal effort. I didn’t have to waste energy doing complicated developer setup.
This got me wondering if all of the tools we’ve created for development: TypeScript, Webpack, React, Redux, Angular, Vue.JS, Node.js, are really necessary or if we’re just shooting ourselves in the foot.
I have two points about this topic:
- Most tools solve a problem you don’t have
- Side Projects are different than Production Applications
1) Most Tools Solve a Problem You Don’t Have
I remember reading about Redux when it came out as an add-on for React. The developers described a complicated bug in the Facebook chat system. They created Redux as a state management tool that would have made debugging that bug dramatically simpler.
To be fair, the Facebook developers list this exact point in the Redux documentation, but I still see way too many people trying to use it because we always assume that tools will make our lives easier.
Let’s try another: Node.js. I watched one of the first Node.JS presentations when the project was announced. One of the major selling points was that it would address the C10K problem – which is the tendency of thread-based servers to consume more and more memory as their connection count increases.
But again: how many people who were running Java, PHP, or whatever, were really running into memory pressure on their servers? My guess is almost no-one, except again, the top 5-10% of the industry who were running ridiculous workloads and who needed to optimize everything to save money.
Finally: what about Sass. As far as I can tell, the biggest advantage of Sass was to allow us to more easily deal with cross browser CSS differences and to deal with varying levels of CSS3 support. But today, with most browsers supporting most of CSS3 and Edge becoming more standards compliant and losing market share, do you still need it? Is the capability of functions in CSS worth the effort of adding a build step?
Keep in mind, I’m not saying don’t use these tools – I actually use them all on my teams at my day job. I’m just pointing out the discrepancy between what the tools were designed for and how people are actually using them. It’s worth reminding ourselves that everything has trade offs before jumping on a bandwagon.
2) Side Projects are different than Production Applications
Side projects are usually only meant to test an idea, whereas a production application has been proven, and it’s been serving customers for a number of years. Side projects can get away with bugs in edge cases whereas production applications can’t.
When you’re creating a side project, your most important asset is your energy. Usually you’re working a day job, and you have 1-2 hours a day to spend on your hobby. 1-2 hours isn’t much.
In a professional development environment, you might be able to devote up to 40 hours into setting up your project. You might configure build files, learn about new, popular frameworks, and integrate with continuous integration. If you have more than a 2 person team, most of those efforts will pay off.
But when you’re alone and working on something “for fun”, spending 20-40 hours configuring a build system would be unfathomable. That’s 2-4 weeks just getting things setup properly.
When I first started building things on my own, I built several using the newest framework. I wasted hours learning setup, or how to do things in the “React way” or the “Angular way”.
By the time I was finally productive, I was out of energy, and the enthusiasm I had for my side project was gone. I would implement a minor feature or two, and then call it quits. The side project would never see the light of day.
I’m not saying to throw away all your tools. I realize a lot of them come with dramatic benefits. But try to avoid thinking that a tool will always make your life easier. That tool was created to handle complexity that your application probably doesn’t have. Or maybe it does, in which case, go ahead. But ask yourself if you really have the time and energy to invest in the learning and the setup that the tool will require.