Do Not Let JavaScript Fatigue Become A Buzzword

If you write JavaScript for the web or have followed open source over the past few weeks, you have probably heard the phrase “JavaScript fatigue.” Despite the excitement in JavaScript, this phenomenon is real. The phrase refers the notion that the current popular JavaScript frameworks, namely ReactJs, require painstaking setup around the tooling just to get a basic "Hello World" application out the door, and the productivity gains are tough to realize until a project has been well oiled and managed. Eric Clemmons summed up JavaScript Fatigue well in a recent blog post and provided a concise summary of the community’s central frustration.

Ultimately, the problem is that by choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.

-Eric Clemmons

Rails doesn’t scale

“Rails doesn’t scale” is a thing people say, but means very little. It is a buzzword with a popularity that seems to date back to the news that Twitter was moving off of Rails as the central structure for its service in 2011. People took the phrase and ran with it, sometimes to make a quick explanation about a software choice, sometimes to sound smart, and sometimes because it fit the context in which it was said. Ruby on Rails thoroughly did not fit in with what Twitter was doing, for reasons that would seem obvious to experienced developers. But experienced developers also tend to recognize the strengths of the Ruby language and the benefits of the Rails framework. Inexperienced developers and ignorant decision makers have used the buzzword “Rails doesn’t scale” to reach for overly complicated systems that extend the time to first product shipped by months or years for no reason beyond the fear of the “scaling” boogeyman.

Similarly, the phrase “JavaScript fatigue” is context-specific, timeframe-specific and ultimately shorthand for the state of tooling at the time in which it was popularized. It does not mean whatever “JavaScript Fatigue” might be interpreted as by the second-hand observer now and in the future. JavaScript Fatigue as a buzzword provides a lack of incentive for the greater programming community to jump in and give some of these exciting new ideas a try, but it’s an exciting space to be in and worth exploring fearlessly. Prohibitive buzzwords can stop developers in their tracks and provides flawed heuristics for making technology decisions.

The nature of open source software

Open source software is built by humans with varying styles, goals, cultures and spoken languages. The wisdom (and effort) of the crowds approach to software development sometimes seems out of place in a world where lack of reasonable consensus is about as guaranteed as death and taxes. But despite some hardships along the way, great things have come out of it. Open source software powers thousands of companies across the world of varying sizes and provides the glue for much of the usable web as we know it. The side effects of open-source software tend to be exposed and managed over time.

Because of this distributed nature of open source software development, public debates are a critical factor in the health and stability of any project. The health and stability of popular projects is ultimately critical to the long term productivity of software developers. And because stable, economical software development is so critical to global economic strength, it cannot be understated how important these open debates are. But we should recognize when debates are oversimplified and boiled down into chunks that are too easily digested when not properly chewed.

So what do we do?

JavaScript fatigue is ripe to become one of the top tech buzzwords of 2016. It seems describe more than it does. At the moment, the community has used it to describe tooling issues facing the JavaScript community at the time it was coined, but as the phrase diffuses into buzzword-land it is easy for the original context to be lost and for people to infer their own meaning to it.

Use up-and-coming buzzwords like “JavaScript fatigue” with caution. Provide context and elaboration whenever you can. Do not use it to provide general criticism towards JavaScript, even if you have become a hardcore Elm evangelist or excited about some other supposed succeeder. JavaScript is a language and an ecosystem every programmer has had some experience in and has its strengths and weaknesses, but it is an area of great excitement and growth and deserves to be judged on its merits rather than on buzzwords.

JavaScript is a real thing, but did you also know that the phrase “disrupt” also refers to a specifically observed phenomenon originally brought forth by Clayton Christensen? Because it was turned into a tech buzzword used ad-nauseum to seemingly any business concept, it lost all meaning despite Christensen’s attempts to clarify. Let's learn from some history and try to avoid letting “JavaScript fatigue” and future buzz-worthy phrases in tech go the way of “Rails doesn’t scale” and “disruption”.