Why Javascript Sucks. From Someone that Loves It.

We’ve all read the horror stories from developers trying to make the transition to web. The echo chamber is full of unhappy and unsatisfied users of Javascript and it’s respective ecosystem screaming things like: “The language is poorly designed!”, “Developers of the ecosystem clearly don’t know what they’re doing!”, and “It is literally Hitler!”…ok well maybe not that last one, but there certainly are some colorful opinions out there.

Trying to understand why

Coming from someone that’s been involved in professional front-end web development 10+ years I’ve had the unfortunate privilege of seeing this story unfold. I often times feel frustrated — not from using the language/ecosystem, but rather from this consensus many developers have that Javascript and web development just plain sucks, and there’s no way to change that.

I’ve wrested with this idea for years, trying to come up with some semblance for how folks are funneled to this conclusion. Keep in mind this is an opinion piece, but I’ve noticed a trend. Most of the time frustration for users stems not from the language itself or it’s capability, but rather the poor user experience first time users encounter. Specifically when migrating from other platforms, and especially over the last few years.

How did this happen?

If you go back around five to ten years ago you’ll plenty of comments about about the state of the language, and it’s pitfalls at the time. Issues with speed, the syntax being difficult to learn, and having few options for structuring large scale applications in a standardized fashion.

Remember also the types of products being produced for the web at this time. Most developers were starting to form the online presence for their company. Including mostly static websites with some dynamic conten, usually utilizing a basic CMS (powered by PHP, Wordpress, or similar). Sure, fully featured web applications existed, but were still relatively new to the space.

Fast forward to today. Every tech company from startups to large enterprise companies live and breath on the web. It is abnormal not to have some sort of a online login to manage your product — or perhaps the entire product itself is made up of a web application. All signs point to this continuing to be the need and requirement for the web platform today and going forward.

The tech stack has also shifted, from PHP back in the day, to solutions like Ruby/Rails, to more Javascript-heavy solutions recently. I feel this is partly due to the power and simplicity of javascript (the only scripting language natively available in browser) and the improvements that the language has received over the last few years (from faster rendering with V8, to spec improvements with ES6). Not to mention the desire to have responsive front end that reacts instantaneously to use interaction. One of the core functions of Javascript one the web.

What has spurred this transition?

This where things get a little complicated. What we’ve witness over the last few years is an influx of ideas from a vast array of minds trying to develop opinionated solutions to the problems and desires of “the modern web”.

This has clearly not been a painless process. In fact, the growing pains have been fairly widespread. Which in turn has resulted in one of the biggest problems of the platform — that being, the barrier of entry being a vertical wall, than a curve. There are so many ideas (some good, some bad) all trying to define the “best” way to solve a complex set of problems for an expanding system. Which has resulting in the misplaced notion that you must learn every single one to keep up and compete.

Does Javascript’s standard library of functionality not cut it for you? Try Underscore or Lodash. Having issues structuring a large applications? Tools like Angular and Ember can provide solutions. Need a simplified way to install and maintain all your various third party packages? Try NPM or Bower. And the list goes on…

This is a major problem for new users. There’s almost never a singular answer for what new users should learn and use to solve a problem. Instead they get opinions thrown at them as if they were fact. With many people making recommendations based on their preference and personal bias, rather than quantifiable data.

Choice paralysis can also strike when there’s so many options available. How do you decide what’s best for you? How do you even discover and learn what‘s options exist? Much less find time to learn them all. This can be a foreign concept from someone coming from another language that has clearly defined answers to common tasks.

A state of constant change

Another major complaint I hear lobbed at the web world is things change too rapidly, new options are introduced too fast, and it’s “impossible” to keep up.

Again, this is coming from folks that are used to using the same framework or tooling standardized for upwards of 10+ years. Something web developers may envy, but a luxury obviously not available to a platform changing so drastically over such a short amount of time.

Not only are the requirements for the web shifting quickly towards mobile and web apps but the release of the recent ECMAScript 6 spec further confounded this.

(Just FYI, ECMA is the committee that defines the spec for ECMAScript language — better known as Javascript. New releases don’t come often, so when they do it’s a big deal.)

Anyone that’s spent time in this space knows there’s a considerable amount of politics of the “when and how” specs are implemented by browser vendors. Not to mention these changes are not always immediately mirrored from desktop to mobile, even for the same vendor. This again causes yet a pain point when it’s not easy to determine what works in each browser/device.

To try and address issues like this, specifically with the introduction of EC6, we’ve seen the rise of tools such as Typescript. Providing a means to use tomorrow’s JS technology today. Typescript allows users to write code in ES6 standard which is then transpiled into ES5 (since ES6 primarily consists of syntaxic sugar). Furthermore it uniquely introduces the concept of types to Javascript, which is normally a dynamically typed language. With all the perks in tooling that come along with that.

However, this presents it’s own set of problems — first off, explaining to new users what Typescript is, and explaining it’s benefits. Especially when all new users may see initially is a requirement to learn two “versions” of the same language and add additional tools and steps for an already complex process.

How do we address this?

The burden becomes on developing a better way to explain the need and reason for the fluctuation, as well as the benefit these tools provide. Not to mention, making it crystal clear that these tools are 100% optional. Something that is amiss on even some experienced Javascript developers I know.

My personal proposal is a free, open source guide that presents a roadmap for learning the language and the ecosystem in bite-sized chunks. Here’s an example of how that might look:

1. Javascript 101: Learn the core language (the syntax, standard library, debugging, prototype inheritance, DOM manipulation, etc.)
2. Explain the improvement coming from ES6, and how to use it today (Typescript/Babel)
3. “Quality of life” libraries (underscore, lodash, jQuery)
4. Package managers for managing and third party dependencies (Bower/NPM)
5. Introduction to build tools for automation (Gulp/Grunt)
6. Learning and using Javascript on the server (Node)
7. Structuring large scale applications and modules (Angular/React+Flux/Ember, Vue, etc.)

You get the idea. The order above is no set in stone obviously. Keeping in mind that each step might take a considerable amount of time to learn, much less master. This should absolutely be echoed to the users.

Laying down a clearly defined path that starts with the core of JS and web development, then expands over time with solutions that will improve structure and productivity, and explains the benefits over time.

The guide could attempt to clearly define a few of the most popular options available for each part of the process, going into detail about their general advantages, and doing so (as much as possible) in an unbiased fashion.

What comes next?

We would need to keep in mind the level of effort and knowledge the person or team responsible would be required to put forth to build and maintain such a guide. Especially when things are still in such flux. New tech might come and go, and curbing bias would be a real challenge. So perhaps as an alternative would be a set of opinionated guides. With options tailored to different user needs and branching paths in place of a one size fits all approach.

It’s clear that something needs to happen unless we want Javascript and the web ecosystem to continue to to retain it’s notorious reputation. So if you or someone you know would be interested in contributing to something like this please let me know in the comments.

I’d love to have the opportunity to work with like-minded individuals to provide a solution that helps new users overcome these obstacles, and strengthens and reinforces the Javascript and web platform overall. Especially if it means providing a means to share the love for the platform I’ve enjoyed for so many years.