JavaScript Fatigue: An Alternative Perspective

Recognizing Progress Requires a Certain Degree of Churn

First, let me get this out of the way: There were definitely some valid points made in the JavaScript Fatigue post written by @ericclemmons. The current React/JavaScript/front-end landscape can be complex for beginners. There are many similar (but slightly different) variations of tools, many libraries with overlapping functionality, many competing frameworks, and, honestly, many fundamentally conflicting ideologies about how to structure large apps and how to write clean, maintainable code. Hell, JavaScript programmers are even divided about which paradigms & features of the language should be used and which should be ignored. (OOP vs FP, imperative vs declarative, the use of type coercion, ASI & the semicolon debate, the need for ES6 classes, etc.)

For those new to JS development, or for those who are primarily back-end (but occasional front-end) engineers, coming from other languages, who don’t particularly like or might not intimately know the intricacies of the language, this can be troublesome. However, I’ve seen far too much negativity about this subject on Twitter, Medium, & Reddit (/r/javascript), and I think we need to take a step back and examine the reality of the situation and why it is the way it is. The nature of JavaScript, the language, is that it cannot break existing code in production. All updates to the language must provide backwards compatibility. Some people hate this. They want problematic features removed… but it is the way it is. It shouldn’t be viewed as a negative that can’t be overcome. It’s not a dark cloud looming overhead, forever burdening the front-end. It’s just a fact. The direct result of this is that JS is a language in which any given problem can be solved in many different ways.

How do we combat this? Well, you combat it by gradually shifting away from the features/syntax/paradigms you no longer feel best serve you as valuable programming tools. This is the same way people are writing JS code in a functional style. Is it a purely functional language like Haskell? No, it’s a multi-paradigm language that supports various forms of OOP, it doesn’t have strong or static typing, and it’s just now getting proper tail call optimization… but you can still code in a functional manner by exercising self-discipline & restraint. You can choose to use stateless functions and push side-effects to the edges of your app. You can use const to avoid reassignment and Object.freeze, deep-freeze, or Immutable.js to avoid object mutation. You can reap the benefits of strong typing by using TypeScript or Flow

…Or you can forget all of that and embrace OOP in JavaScript, whether through attempting to emulate the class-based classical inheritance patterns of C++/Java/C#, using simple prototype behavior delegation & ducktype checking, or going all in on composition. That’s your choice. This is part of the beauty of the language. Some languages are purposefully narrow in scope to the point of there always being only “one true way” without room for decision making… There are obvious pros that come with that, but there are also cons unless you happen to agree with each and every decision made by the language authors. Have you ever found a programming language you believe has no flaws? I sure haven’t, and, regardless, the reality of the situation is that JavaScript is not that type of language. It’s in every browser. It’s on the server. It’s in your tooling. It’s powering robotics and IoT. It’s everywhere. JavaScript is deceptively simple. It’s one of the easiest languages to dive into, yet simultaneously incredibly misunderstood and rarely mastered. It features a diverse pool of programmers who come from different backgrounds, have different skill levels, and favor different architectural patterns. It doesn’t have the freedom to be so dogmatic.

The important thing to realize is that you have that level of choice because these options are available to you. Can having a lot of choice be overwhelming at times? Of course! Can setting constraints for yourself help you establish more productive workflows & write more modular, maintainable code? Definitely! However, you’re the one that needs to make that call. Having that flexibility to evolve your programming style as you grow is invaluable. The same is true when it comes to choosing frameworks, libraries, and tools.

React & the Flux architecture came into existence because engineers at Facebook took the time to throw out preconceived notions about “best practices” in order to solve their own real world problems with large MVC-style single page apps. Redux borrowed ideas from Elm and brought them to JavaScript to streamline & simplify Flux. Tools like Babel & Webpack allow us to bypass waiting on new standards to be implemented. Features like hot reloading and time travel debugging vastly improve the workflow of front-end development. “CSS in JSinline styles & CSS modules recognize the problems with CSS scoping and attempt to offer better alternatives. GraphQL, Falcor, and Relay give us modern replacements for traditional RPC & REST APIs.

We’re even already seeing fresh new frameworks like Cycle, Motorcycle, & Yolk proposing more radical ideas about how we can improve on React. Some people call this churn, but I call it progress. All of these things are attempting to advance the way we build applications on the web. Both JavaScript and the web are rapidly evolving and will continue to do so for the foreseeable future. The truth is, if you don’t like to constantly be learning new things, web development is probably not for you. You might have chosen the wrong career!

It’s important to recognize that this explosive growth and highly competitive landscape fosters innovation. I don’t want any one framework or library to have a monopoly on the way we write JavaScript. We shouldn’t be content to repeat ourselves over and over without questioning whether or not there’s a better way. We need rapid churn and experimentation to move forward. Remember, no one is forcing you to immediately adopt the latest and greatest, and you don’t have to jump on it all at once! Do your research and form your own conclusions. Work in the tools you like when circumstances allow you to and disregard the rest. It’s okay for some of these ideas to fail! It’s all in the name of progress.
Like what you read? Give Josh Burgess a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.