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.

I did a lot of things “wrong” when creating these projects. For EC2Pricing, I did everything in Golang. I didn’t use a real database, I had no front-end framework, and I inlined all my CSS and JavaScript inside Go HTML templates. Blasphemy!

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.

This time, I only used JQuery, and I kept everything in a single JavaScript file that totaled 140 lines of code. Granted the functionality in the first extension was more extensive, but there was still more code than was needed. I was trying to use components, do routing using Angular, and to manage dependencies with Require.JS, whereas I did none of that with the new extension.

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:

  1. Most tools solve a problem you don’t have
  2. 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.

That’s all fine and dandy, but here’s the problem: how many developers have a website as complicated as Facebook’s with millions of lines of JavaScript that all compete with one another? Some of the Google properties come close, and is not simple, but the rest of the industry? Does everyone really need Redux?

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.

Like any other JavaScript interpreter, Node would use a single thread and do asynchronous IO, thus keeping the memory under control.

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.

To be fair again, Node.js has other advantages – using JavaScript on both the client and server is kind of cool, but it also has disadvantages. Writing asynchronous, callback driven code is not trivial, and losing the compiler server side makes code less maintainable. All you have to do is read some of the thousands of blog posts about all the trouble people have had with Node to get a better idea.

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.

Anyway, if something needs to be maintained, then it probably makes sense to invest in setup. If it’s a side project, and you’re not sure anybody will like it: I’d say avoid tools as much as possible. You don’t need React just to throw together a web page with an Html table. You can do a lot with raw JavaScript and CSS and even JQuery.

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.