Why people hate JavaScript


Photo by Auréanne Mailhiot on Unsplash

Disclaimer

This is my personal opinion. I’ll not try to convince you that your language is good or bad. Programming language is a matter of preference. But of course your programming language is the best.

Introduction

A lot of people dislike JavaScript. From my perspective there are a couple of reasons for this:

  1. It’s really hard to avoid it;
  2. It’s not strictly typed;
  3. Browsers behavior may vary;
  4. Dozens of frameworks and libraries with different API and sometimes even syntax (e.g. Angular);

Let’s go through these items and I’ll explain what I mean.

It’s really hard to avoid it

This one is quite simple but one of the most important. Nowadays a lot of back-end developers are involved into front-end/client-side development. And when back-end developer dives into front-end world he/she faces a lot of issues and thinks that it’s a problem of language.

But is it really a problem of language? In my opinion: NO! The main problem is that back-end and front-end development are really different.

A huge amount of back-end code (now I’m talking about REST-like back-end) is quite straight-forward: server receives request -> developer performs some operations with input based on the business logic -> requests required data from the database -> processes it based on the business logic -> serialize and return to client. That’s it.

On the client (we are talking about modern graphic UI and Single Page Applications) everything is much more complicated. You have dozens of independent components displayed at the same time. They have internal state which is hidden from other components but can affect them. The behavior of application is asynchronous and event-based and if at some point one of the events will modify the state to one which was not expected – the application is dead. If you think that this problem is synthetic let me share the most common mistake I see in UI applications:

  1. User clicks on the button to expand a list of items returned from server;
  2. Request is sent to the server;
  3. User changes his mind and clicks cancel button;
  4. The list is collapsed, list placeholder is removed from the DOM;
  5. Server returns data. Callback is trying to attach new data to removed placehodler;
  6. User sees “unexpected error occurred” or exception is logged to the server;

And this is not something uncommon, this is happening in production applications all the time. It’s really hard to manage the state of entire application without having a client-side database.

But as I said it’s not the problem of the language.

It’s not strictly typed

There are plenty of languages in the world which do not provide compile-time type checking (e.g. Python or Ruby). But JavaScript is one of the most hated by this criteria. I believe that’s the consequence of first bullet point.

Is it really a problem of the language? Is it really a problem at all?
I’ve worked a lot with C#, JavaScript and Typescript and want to share my opinion.

  • Compile-time type checking will not help you to find bugs. Seriously. I’m working with JavaScript more than 6 years and I hardly can remember any bug in production which was a result of wrong type assumed by developer;
  • Compile-time type checking will definitely make your code more verbose. I can hardly imagine a person who think that this code is easy-to-read:
Action<string[], string[], int> copyOperation =
delegate(string[] s1, string[] s2, int pos) { CopyStrings(s1, s2, pos); };

This is a code sample from MSDN, it’s not mine;

  • Compile-time type checking sometimes will help you to refactor small pieces of code quicker. My personal experience is that small refactoring can be done without type-checking easily. And in huge refactoring type checking is not really helping;
  • Compile-time type checking will definitely make your IDE helpful because code completion will provide you a lot of information;
  • My personal experience was not really good with Typescript. I’ve worked with huge solution. It has Typescript 1.8 without ability to upgrade (literally hundreds of compilation errors occur). As a result of inability to update TS we are unable to change/upgrade frameworks – type definitions are not available for old version of TS and modern frameworks. So we need to stop development for some time and update the TS in the entire solution to move forward. Was it worth is?

    Browsers behavior may vary

    This is true. The world is getting better each day. Internet Explorer is dying. Other browsers are more or less stable. Moreover you can transpile your code using Babel (I’m not a big fan, but it’s better than nothing). Also frameworks and libraries encapsulate a lot of browser-specific logic for you.

    And of course, it’s not a language issue. As an example from back-end world I can imagine situation when someone wants to make .NET solution available on Linux. I doubt that it will work AS-IS. It’s the problem of environment not language.

    Dozens of frameworks

    As usual it’s not the problem of JavaScript. But the problem of course exists. New framework appear on front-end quite often. It’s the result of market needs. Client-side applications are evolving and getting more and more complex. JQuery was a revolution 10 years ago. But nowadays no one will start a complex project with JQuery (sometimes complex projects start with Vanilla JS because of performance concerns). Front-end community is still searching for the best way to quickly develop stable and fast applications. That’s why a variety of frameworks appear. It’s not a problem. You should not be concerned about this fact.

    Summary

    Basically that’s all I wanted to share. Whether you like it or not JavaScript is a standard for browsers and it will be main language for some time in the future. My experience is that introduction of additional language (TypeScript, F#, ClojureScript, etc.) will not make your life easier:

    • Some of these languages may receive backward incompatible changes. It will require additional changes to upgrade. And in case of huge projects it may result in a significant effort (real production case). When you are writing code using JavaScript backward compatibility is guaranteed by ES-standard;
    • You still need to know JavaScript. Especially when we are talking about JavaScript produced by functional languages. It’s not always easy to debug them using map-files. And of course on production where map-files can be unavailable in some cases. Take into account that debugging minified code is much harder;
    • Language will not solve browser compatibility, state management or data flow issues for you (and from my experience these issues are the most common on the client);

    Thanks!

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Google photo

    You are commenting using your Google account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s