The Passion of the JavaScript Developer

In this video we’re going to talk about tortures, endurance and perseverance

Transcript:

Hey, hey, welcome to my talk, “The Passion of the JavaScript Developer.” The title is a reference to a Mel Gibson’s movie about torture and the comparison is that being a JavaScript developer does feel like torture sometimes. I’m going to be talking about memes, and this is one of them: 

• Just because your language is widely used doesn’t mean it is any good. 
• If those JavaScript developers could read, they’d be very upset.

Super funny meme. I’ve seen a lot of memes like that, and I can totally relate and I laugh genuinely, but after many years of working with JavaScript, I learned a lot more context. I learned about how the community overcomes the mess that JavaScript really is and I also learned that there are some good parts in JavaScript. And so I just want to share my view of it with you guys without threatening memes in any way, because I love them. I hope that you will like it. 

My name is Vlad Feskov. I’m an engineering manager and lead at Kayzen. We lend infrastructure and machine learning models to compete in billions of mobile ad auctions every day. I started coding for money in 2009 and I never stopped — and I feel very strongly about JavaScript. Let’s first talk about the current state of things just to demonstrate how relevant this is.

As you may know, all major websites use JavaScript one way or another. There is just no alternative. But it’s also present in servers, written in NodeJS.

Then there are a lot of successful desktop apps built with JavaScript and Electron, which is a browser and NodeJS bundled in a single standalone package — and examples are Visual Studio Code, Slack, Discord, and many more.

Then there are native mobile apps that you can install in Apple App Store or Google Play Store that are built with JavaScript and React Native, Ionic, or Cordova. Some of them are Facebook, Instagram, and more. 

There are also progressive web apps, which have the biggest support from Google. One example is the YouTube Music website. If you open it in Google Chrome, it will suggest to you to download the website as an app. And that’s the progressive part of it — that it progresses from being a website to an app. 

Then there are apps built in JavaScript for TVs like Samsung Smart TV and Apple TV. You can also control robots and the internet of things using JavaScript and Johnny-Five platform. And finally, JavaScript is good enough to assist astronauts on space missions because NASA and SpaceX use JavaScript for mission critical UIs and APIs.

So yeah, despite all the perceived bad quality and bad reputation, JavaScript is still chosen by big corporations and big organizations. So they must know something, right? Let’s dig deeper into it. Let’s unravel this conspiracy. 

Let’s look at the history of it first. JavaScript was created in 1995 by this handsome fella, Brendan Eich. He only took 10 days to do it. And originally it was just a part of Netscape Navigator, which was the first internet browser.

Then Microsoft saw the success and added their own version called JScript to Internet Explorer. And so there were already two implementations of the language and it was necessary to have a standard specification somewhere. This responsibility was given to the European Computer Manufacturers Association or ECMA. And in 1997, they published their first edition of such a standard, they called it ECMAScript. Since then this organization has published more editions and browser manufacturers and JavaScript engine developers have been following the standard, implementing it piece by piece according to their own priorities and agenda.

So essentially that’s what JavaScript is. It’s a document on the internet with a bunch of different implementations that differ either slightly or a lot.

So what are the problems with this standard? It follows a thorough bureaucracy. There is a committee and many phases a feature has to go through to be added. So it’s slow to add new features. Plus, all the concerned parties are enormous in numbers. So yeah, it is slow. Then this standard at the end of the day is just a suggestion to companies like Apple and Microsoft.

So they may postpone implementing certain features of the standard forever. They may deviate slightly from the standards or they might develop their own features that are not part of the standard at all.

And the final nail in the coffin is the outdated browsers that users are still using. So whatever new features got through the document and the company agenda, they may still not be available to your users because they use outdated browsers. And secondly, whatever old mistakes JavaScript had in the beginning, or at any point in time, they have to stay there forever and you cannot just deprecate some problematic stuff in JavaScript, you have to drag it on and on until the end of time because some users still use outdated browsers.

So yeah, it does seem grim, but the community came up with a few cool ideas and solutions to this problem, and it all begins with just tracking the differences between browser versions and that’s what caniuse.com database does. It’s a registry where you can look up a JavaScript feature and it will show you in which browser versions it has full support, partial support, or no support at all.

And it also shows you how many users worldwide will have no problem with this feature. So here, for example, 96% of users worldwide will be able to use your website with this feature. Then the community of enthusiasts took it even further and implemented a set of transpilation tools whose aim is to make your code compatible with older versions. So essentially you provide a config and you select which browser versions you want to target. So here: 

• not Internet Explorer 
• the latest two versions of of every other browser and 
• every browser version that has more than 5% usage worldwide

And then you write whatever code you want using the new features or old ones and the set of transpilation tools will do their best to make your code compatible with these versions.

So three lines of code may become an abomination like this, but it will work. This set of tools is so good actually that the internet giants like Facebook and Google include it in their major frameworks, Angular and React.

And the whole situation does resemble this meme: all modern digital infrastructure sits on the project some random person in Nebraska has been thanklessly maintaining since 2003. So again there are huge problems with JavaScript that don’t seem to have a solution, but the community perseveres. 

Let’s talk about the design that was established in the beginning, the way I see it.

And I think it’s like the Wild West with the cowboys and horses roaming freely because it’s easy to start writing in JavaScript. You can get away with errors and it’s easy to snatch and use stuff from the internet because every JavaScript page is open source. But there are problems with it just like in the Wild West where cowboys would start shooting everybody. 

In JavaScript, there are also problems related to its design and most come from the fact that JavaScript is loosely typed. So it has poor tooling, and it doesn’t help you when coding, like, you may make a lot of typos and a lot of mistakes while you’re coding, and the code editor will not be able to help you because it is going to be confused a lot. And another side effect of this is that there is automatic type casting: it’s perfectly valid to add an empty array to an empty string and then add a zero on top and to get something in return.But what you will get is not obvious and very confusing and yeah… 

Then declaring variables is actually optional in pure JavaScript. Some mistakes will be ignored, meaning that you may have a broken line of code and JavaScript will just go through it as if it’s not there and you wouldn’t even know the code is broken. 

Then, a surprise to Java developers, “this” keyword is kind of a variable in JavaScript. And you gotta be careful with it because you might not expect what’s going to be in there. Loose function signatures, meaning that you can call a function with as many parameters as you want and JavaScript will be fine with it. And if you make a mistake JavaScript will not tell you about it.  

But there is tech to bring order to this chaos.

1. And the first tech I recommend is the strict mode, which is part of the JavaScript standard. You just add one line of code “‘use strict’;” at the top of your script and you already get a much better version of JavaScript. You will be forced to declare variables correctly, and you will get a lot better error reporting.
2. Then you can also add the code linter to your development process and get a uniform code style across your app: spaces, semicolons etc,. But also, you will get a complexity warning wherever your code is too complex and you will have to simplify somehow, which is a good practice to make your code more readable. 
3. Then there’s TypeScript by Microsoft. Essentially you can configure it and make JavaScript strictly typed as if it was some sort of Java. And what’s great about it is the tooling, as I said earlier, because once you do this the code editor will be able to help you tremendously. It will fix your errors for you, it will highlight typos you make — it’s great. And it’s also done in a way that you can use JavaScript with third party libraries like jQuery that were written in JavaScript, and you can still use it in your TypeScript app because somebody else created type definitions for it. For example, I can create type definitions for query, publish it, and install it as a separate package and voilà: I get everything working in TypeScript, so it’s very convenient.  

Parallel computing is something I feel strongly is a reason why JavaScript is perceived as too complex, difficult, and confusing. But I think it’s actually a good part of JavaScript and I’ll compare it to the classical way of doing parallel computing. By classical, I mean two programs running really in parallel on separate threads. So in this example, I run a button click program on thread one and key press program on thread two. Both programs start at the same time, Step 1 and Step A. Both programs finish with their first step and move on to the second step. Second step finishes for both of them at the same time and the third step starts. Finally, both programs finish at the same time. I don’t think it’s too difficult to comprehend that it’s just two things running truly in parallel. 

But there are problems with applying it to JavaScript, in my opinion:

1. And the first problem is sharing data between threads is not easy. Imagine that one thread is processing some data and then the second thread changes this data midway. And now the data is corrupted for the first step because of processing. So yeah, there are ways to prevent this, obviously, but it’s not easy for sure.
2. The second issue is that when a thread needs some data from an external data source, it has to send the request and wait and stay idle until this data source returns something. That’s not super optimized. 
3. And then also there is always a limit to the number of threads on any given CPU. So threads are limited, and then some of them just stay idle, which is not optimized. 
4. And the final problem is that JavaScript has to work on weak CPUs where the number of threads is even more limited. And why it needs to do that is because you don’t want to lose users or buyers of your product just because they have a weak computer or a phone.

So instead JavaScript does something different. They call it the “event loop.” Essentially, it’s just a single thread. And since it’s a single thread, there is no true parallel computing and things are being processed one step at a time.

Let’s look at one example here, again, button click and key press programs need to run at the same time. But since it’s a single thread only the Step 1 of button click can run right now. So that’s what it does. And at the end of Step 1 there is a request to a server, for example, to get some data.

This arrow represents a request to the server, and this is the JavaScript engine and Step 1 sends an instruction “call my Step 2 when you’re done.” So the JavaScript engine receives the instruction and starts waiting for the server response. Meanwhile, Step 1 is now finished and the thread is idle again, so the key press program can start. At the end of step A there is another request sent to the server, asking for some other data and instruction to call Step B, when the response comes. In this case the latter request was resolved faster so the server responded much faster than the first request. Meanwhile, request one is still going on. The response for Step A is now put in the task queue as per instruction from the key press program. JavaScript engine doesn’t call Step B directly, instead it puts it in the task queue. And then since the thread got idle after Step A it can now start processing Step B from the task queue. And now it’s occupied with Step B.

And while it’s occupied, Step 2 gets put into the task queue, because the response from the server finally comes. Step 2 cannot be picked up by the thread yet because it’s thread busy with Step B.

It finishes and moves on to Step C, again, occupying the thread. And so Step 2 yet again cannot be picked up so it becomes inpatient. Finally, Step C finishes as well. And now two can be picked up by the thread. And you see, Step 2 is very happy about this.

Step 2 finishes and Step 3 finishes as well, and we’re done. So that’s how it works. And the sharing of the data is easy here because no two steps access data at the same time, they don’t run at the same time ever.

So you can just have a global variable, one step can write things to it, and another can read from it. The parallelism is very deep in JavaScript. The engine forces you to use the event loop and the task queue for every little thing you have to do in JavaScript. And so every program in JavaScript is parallel by default like this. And parallelism in general is not an easy task, never is an easy task.

It’s easier to program “do this then that then that” than to architect a program that utilizes parallel computing and JavaScript is by default like that. So that’s a big complexity for a developer and there are patterns and libraries to change the parallelism a little bit, change syntax of it, like Reactive Extensions, or Async Package for NodeJS, promises. Those are all cool techniques. And the challenge of a JavaScript developer is to first architect the parallel computing part of a program, and secondly, use the right tools for the right situations. There was a great talk on YouTube by Phillip Roberts at the JSConfEU called “What the heck is the event loop anyway?” This is how I learned about the event loop, and I highly recommend it.

Tech to kick it up a notch, to improve parallelism.

Workers are additional threads that you can start. And the limitation is that these web workers cannot access cookies or HTML elements. So the use case is pretty narrow in my opinion. You can send messages to it  and you can receive messages back. They are great for heavy mathematical computations, for example, Bitcoin mining. If you ever want to do that, web workers would be the choice. 

Then there is a special kind of web workers called service workers and the idea is that they can work even if a website is not open. So they are great for push notifications and pre-caching when you download a new version of a website beforehand and then when the user visits  the website, the new version is already there so it loads faster. 

And another way to improve JavaScript performance is to move animations and element positioning away from JavaScript into CSS. If it’s possible, it is preferable because CSS is not part of the JavaScript main thread.  

Inheritance is very funky and it is more powerful, but also a lot more confusing and error prone in my opinion than in Java.

It’s based on prototypes. The idea is that if an object doesn’t have a property or a method, the engine will ask for the same property or a method it’s prototype, and the prototype itself can have a prototype. So the engine will ask for the thing up the prototype chain until it finds the first match. It allows you to do multiple inheritance via mixins and it’s not necessarily a great thing. Community uses classes a lot nowadays. The frameworks use classes like Angular and VueJS.But you gotta be aware of the fact that they are syntactic sugar built on prototypes. So sometimes you might encounter some limitation, which comes from this fact. Also classes are a relatively new thing in JavaScript, they were added to the standard in 2015. So again, something that got improved a lot, the prototype logic is still there, still available and will always be there, but classes are more convenient to use. 

Now HTML and CSS.

These are technologies not directly related to JavaScript and they’re only relevant for front end guys. But nevertheless, they are worth noting — frontend devs have to know them partly because of the reason I said earlier, like CSS is preferable over JS. So you got to know the latest features to know how to optimize your javascript code. Like if CSS already supports something cool you better move it to CSS, what you had in JavaScript before. And also just the fact that positioning and responsiveness are major challenges.

You need new CSS features because they simplify hard problems. The websites become even more beautiful every year. So really you need a solid technology behind it to make it look good. And also I don’t like the fact that HTML and CSS are looked down upon as if they’re not, like programming languages, or whatever. I think it’s very hard to write a good frontend and it takes skill and creativity. Just wanting to say that, and my personal recommendation which helped me a lot: Flexbox is amazing.

Once I learned it, I could solve 90% of the issues I had with positioning and responsiveness. So I recommend. 

26 years of evolution of JavaScript, what do we have? 

• The products of JavaScript are exposed to literally billions of users. 
• It has the largest developer community because of that, I think. 
• 41 of the 100 most starred repositories on GitHub are JavaScript related.
• And if you’re a frontend guy, just pick one of VueJS, React, or Angular frameworks, because they are completely safe to work with. They have rich ecosystems and an enormous amount of recipes for every kind of situation. 
• Some cool concepts from those frameworks are: 
  • Virtual DOM 
  • Ahead of time compilation and 
  • Reactivity via proxies in VueJS. 

They’re all worth learning. 

So, yeah, with this context, I feel very secure about reading memes like the one I mentioned in the beginning, and I do appreciate them still, and will always laugh at them, and will always share them.

So keep on making those. I hope this was interesting. And thank you very much, make sure you check out our kayzen.io/careers page because we are hiring.

Thank you very much. See ya.