A Change Is As Good As Rest

How To Cure Javascript (front-end) Fatigue

In football you’ll sometimes hear a coach tell you to “play back”. It means, back up so you can get a better read on the ball and therefore be in a better position to see what you’re dealing with. If you play too close up, you’re vulnerable. You’re opponent will have the advantage and beat you play after play. Suffering too many defeats results in feeling defeated. My old football coach used to quote Vince Lombardi:

“Fatigue Makes Cowards of Us All”

Playing too close to the bleeding/cutting edge in technology will result in many defeats. You’re vulnerable and you’ll suffer death by a thousand cuts. Those defeats will mentally wear you down. It’s better to “play back”, get some perspective and proceed with caution.

Google And Pray:

Over the past 5 years I have to attempted to explore and master as many major front-end javascript tools, frameworks and features as possible. I confess to experiencing what is known as “javascript fatigue”. However I would argue that this fatigue was not the merely result of my endless efforts to keep up. The fatigue was coming from a sense of defeat. These new tools were not making my life easier. They were over complicating my workflow, introducing issues that previously did not exist and sometimes led to problems that reduced me to a neophyte who could do nothing more than Google and pray.

Technical Debt:

These previously non-existent problems are essentially an increase in technical debt. Evolution drives extinction as much as it drives new features. Many of these “extinctions” come in the form of deprecated apis, dependency chains and workflows. Deprecations that directly convert to technical debt. Instead of working on adding a new feature to my application–I found myself spending more and more time working on my tools themselves. A never ending attempt to bail myself out of technical debt that seemed to have no end in sight.

A False Dichotomy:

I began to wonder why I was using all these tools. Was it out of need? Could I meet the needs of my application without these tools? That’s a yes in both cases. It’s a false dichotomy to presume that you can only write a modern application with modern tools. I have always leaned towards writing “native javascript”. I‘ve never wanted to rely on libraries such as Lodash and Underscore to leverage the power of functionality I could could do natively. However, that functionality isn’t always natively available. Therefore I reached out to tools such as Babel to compensate for this lack of available functionality. Instead of having to use libraries, Babel allowed me to write native syntax and transpile it down code to the lowest common denominator. Transpiling it to “plain” javascript if you will. It was fulfilling a need. However I was now one abstraction layer removed from my code. I kept thinking: heck, I can write plain javascript. Add in tools like Webpack, PostCss, Gulp, etc. and now were really cooking with gas. Explosive gas. Your part time job is now trying to find out where that smell of gas is coming from because you’ve got yet another leak.


As time went on and frustrations grew I found myself implementing my own patterns instead of relying on frameworks like Bootstrap and RequireJs for my application structure. I also started manually polyfilling many of those ES5+ functional features I once used Lodash and jQuery for. I grew tired of the limitations of tools like bower and fighting syntax issues in Webpack. I wrote my own dev tasks using plain ol’ javascript scripts executed with npm run. Soon I realized that I didn’t need 95% of the tools I was using. I could accomplish everything I “needed” with “plain” javascript. I could write “native” javascript with “plain” javascript. I started supplying my own needs. Sure I didn’t have as many capabilities at my disposal as I had before (out of the gate) but my field of vision dramatically improved. I had once again felt like I had full control of my application. Everything was in plain view. Technical debt was no longer an issue. Workflow was no longer an issue, dependencies became manageable, documentation became simpler, troubleshooting became simpler. I became happier. It felt like the inter-workings of my application were less complicated and subject to refactoring with less effort. And I felt confident that the code I was deploying was less of a matrix of trip wires but a collection of well thought out modules that could live on for the indefinite future.

Become A Jedi:

Granted this path I’ve taken has a much higher bar of entry when compared to tools such as Yeoman. Yeoman let’s somebody quickly scaffold out an application. You hit the ground running. But how much of the application do you actually understand? What happens when you deploy that application? Any “modern” front end application you write needs javascript. With good patterns, you can accomplish anything with plain javascript. If you can’t, you probably don’t know what you’re doing or you’re not working on something all that important. Sorry, that was really snotty. It’s my way of provoking you to think for yourself. You can do it! How’s that? In fact I think the learning path is shorter and provide you with a deeper understanding of how to design an application.

The Proof Is In The Pudding:

I’m now thinking how shameful it would be if I ended this article here. I should at least make an attempt at providing you with a starting point. I should also provide an example of something I’ve done that demonstrates such an approach.

Where to start:

  1. You can decompose your applications code into modules using the module pattern. You don’t need a module bundler. Check out this article: http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html
  2. You can implement anything you could possibly need in an application with good patterns. Check out Addy Osmani’s book Learning Javascript Design Patterns.
  3. You can manually polyfill almost any feature you need in javascript. Look up MDN’s references for javascript. Check out the Array.prototype.reduce page for an example (scroll down until you see the polyfill section).
  4. You probably don’t need jQuery. That stuff all can be polyfilled. In case you’re unfamiliar with what’s available to you in plain javascript check out You Might Not Need jQuery
  5. You don’t need grunt, gulp, etc. All they do is point to npm packages that you can install and configure yourself. You can easily roll your own build and dev tools. You can even call them with npm run if you want. I keep reading more articles on this more and more...here’s one (TLDR;)

An Example:

Although I can’t share code I’ve written on the job with you I can show you the beginnings of a project that I’m working on. It’s probably the best example I could provide because it’s non-trivial and touches an many different facets including: structure, build tools, testing, polyfilling, etc. It’s called OEM. Irony of ironies–it’s a small web component framework that allows you to write and maintain your own custom web component library. I wrote it for myself. It’s not perfect and it’s probably not ready for primetime but I have put some serious thought into it and rebuilt from the ground up 3 or 4 times until I felt I was on the right track. I’d love for you to check it out and tell me what you think in light of this article. I’d also like to hear/see from those of you out there rolling your own solutions.

But What About New Language Features?

As you’re reading this it might have crossed your mind that you can easily polyfill Array.prototype.reduce. However you can not polyfill a javascript keyword like class or anything syntactical new(like Destructuring Assignment). You’re right. If you want to use fancy new syntax but want it to run on older browsers, you can’t do it without a transpiler. Sorry. This isn’t an argument against writing“plain” javascript or rolling your own solutions, it’s just a matter of requirements. It also doesn’t mean that you’re now adopting “old techniques” that aren’t helping you grow as a developer. You can adopt and implement evolutionary patterns within your application. If you want to see how I’ve handled that situation, check out my Prototype module in my OEM project. Given the plethora of creational patterns in javascript, I implemented a factory method. I can switch that out anytime and use whatever syntax I want and my app shall live on. Maybe I’ll use class in the future. Who knows. I can tell you this though: I’m not worried about it.

The End Of The Beginning

Hopefully this article has been a word of encouragement. It’s the idea to end the never-ending cycle of feeling like you’re always having to start at the beginning. To start taking control of your own codebase and programming the solutions that don’t do one thing and do it well — and then change out from underneath you but do the one thing well that you designed it to dowell into the future. Only then will you probably finally get any rest from your “javascript fatigue.”

*drop’s mouse*