Why we teach JavaScript — but that’s not the detail that matters

With dozens of possible programming languages to learn, it can be hard to know whether JavaScript is the “right” one. But is that the most important question?

Joshua Vial eschews job titles but calls himself a “catalyst” at Enspiral Dev Academy. He’s an entrepreneur and a founder of the Enspiral network. Here he explains a bit about what you’ll be learning at Dev Academy during the 18-week course, which runs in both Auckland and Wellington, New Zealand.

We currently train people in full-stack JavaScript, but this isn’t the first iteration of the Dev Academy curriculum. A lot of thought’s gone into deciding which programming language to teach and why. The brief history is that we started out with a Ruby curriculum and translated it to C#, and then we were training in both simultaneously. Then we stopped the C# curriculum and just trained Ruby, and then we stopped Ruby and switched the Ruby curriculum to JavaScript.

That transition over the past few years has been motivated by a few things. First of all, Ruby gained a lot of popularity over the past decade, particularly in the United States. On the other hand, in Wellington there are more C# jobs so when we set up the school we translated the curriculum into C# and taught it alongside Ruby. What we often found was that C# companies would hire our Rubyists and Ruby companies would hire our Sharpies, and it didn’t matter that much what people were trained for in terms of the job they got.

That means that when we train people in JavaScript, we’re not training them for JavaScript jobs; we’re training them for programming jobs. And some of those will be in JavaScript. We want to train in modern languages and industry-relevant languages; we don’t want to do what some universities do and just train in Java all the time and never change our curriculum for 10 years. So it’s a balance: we want to train in the modern stuff, but it’s also that it really is teaching people programming, not teaching people just JavaScript.

In my own career, I got into Ruby on Rails in 2006. It took off in a really big way, and there was lots of work out there. For developers, choosing your technology is quite important. JavaScript is one of the most dynamic areas of web development; a huge amount of innovation is happening in that community, there’s a lot of energy going into JavaScript language and JavaScript libraries, so it’s a really flourishing area technically. A lot of new, cool stuff is happening. It’s a good technology to back, and it’s one that’s growing rather than diminishing.


JavaScript is like the Latin of the web. If you’re building web applications, then it’s likely you will need to learn JavaScript at some stage. Compared to any other language we could teach students, JavaScript gives them the highest likelihood of using that language, no matter which company they work for.

Another great thing about JavaScript is that you can use it to teach different programming paradigms (such as procedural, imperative, declarative, functional, object-oriented, and event-driven). With most of the other languages you’re limited to a subset of these. JavaScript is also capable of object-oriented (OO) programming using either prototypes or classes. While the implementation of the class-based approach is subpar, it’s enough to get a sense of how OO is written in other languages. Prototype-based OO is very powerful and considered superior by many developers. With that said, the current trend is away from OO and toward functional programming.

Confused? In object-oriented programming, the data, and the functions that operate on the data, are bundled together and they live in objects. It’s a way of thinking about the world that goes a bit like: “Oh, there’s a chair in this room; I’m going to make a chair an object, and it’s going to have, ‘Chair can be sat on, and chair has four legs, and chair is blue,’” sort of stuff. You start to reason about the world in that kind of way.

In functional programming, you have your data and it lives somewhere; it’s your state and then you have functions that transform it but they are separate. That means it’s much less about reasoning about chairs and more reasoning about data structures and operations that transform them. It’s a very different way of reasoning about software.

You might think of them like styles of literature — one is science fiction; one is romantic comedy. They’re both writing but they’re very different types of literature or movies. JavaScript is better suited to teaching both those types of literature.


The experience we had of going from Ruby to C# meant that we learned a little bit about translating curricula; we’d take the same structures and challenges and concepts and then rewrite them in a different language. As part of that, we used some challenges that we knew would really teach people about functions, or databases, or recursion, or how to introduce APIs and the web. Those concepts are exactly the same; we’re just using a different language to teach them. There was also thought going into what libraries we were going to use, and how and when we were going to teach automated testing. There was a lot of evaluating technologies and libraries and striking a balance between maturity and modernness.


JavaScript used to be the mongrel of the internet; it used to be the sort of thing people were dismissive about like it wasn’t an engineering area; it was something people would pick up and they’d hack with and it was messy and awful. That’s not what modern JavaScript is like at all. Modern JavaScript is really cutting-edge and has deep engineering behind it.

A bunch of things changed for that to happen. A big one was that JavaScript became ubiquitous. The first version was written in 13 days for Netscape and then it was just patched for ages; all the browsers had different versions of JavaScript and so on. As the internet became dominant, JavaScript was the language that every browser supported, so everyone was using it and it reached a critical mass. And as that happened, people started to engineer things and rebuild things and it got really significant. One of the big developments was when Node came along in 2009, which meant JavaScript could now run on the server. To back up: in the past, you’d have a server-side language (Ruby, C#, etc), which runs on the server, and you’d learn JavaScript for the front end — so the students who went through our old course would have to learn both languages.

Now, with Node, you can run JavaScript on the server as well as the front end. That opened up this whole world where you could just know one language and do pretty much everything you needed with it.

This gives JavaScript a big advantage for training developers since students, especially new students, can build better stuff faster than if they were just doing C# or just doing Ruby. That way, if they wanted do anything modern on the client side, they’d have to learn JavaScript and whatever other language they were doing. This way it reduces the volume of stuff they have to learn.

The other thing that happened to make JavaScript more viable was that the internet got a whole lot faster and we started to see real-time responsive apps, like Gmail. It seems normal to us now that Gmail doesn’t load the page every time, whereas when you click on an old website, you click it and it loads up fresh each time, and it’s much slower. So Ajax and Web 2.0 happened, and JavaScript was a core part of of Web 2.0 — interactive websites, and highly user-focused websites. JavaScript blossomed and became really popular and you saw libraries like Angular and React created, and all of the big websites like Facebook starting to build very intensive JavaScript apps on the front end. That was the beginning of the trend where all the big apps — Gmail, Facebook, Twitter — stopped asking you to refresh the page each time and they behaved a bit more like an application in their own right, running in your browser — and we can thank JavaScript for all of this.


So what does it mean if you’re seeing job ads for people with a programming language other than JavaScript? Well, if you’re applying through a job ad, you’re behind the eight ball already. You get jobs in New Zealand by knowing companies and reaching out to them. Some of that, at EDA, happens through our employer networks, and us connecting people. Sometimes companies might be advertising but they’ll be advertising for something completely different. When you look at the realities of how hiring managers work, they think, “If I find someone good, I’ll hire them.”

I don’t know how many of our graduates have got jobs through job ads but I know that many don’t. I would treat the requirements of the ads fairly lightly, personally. The only jobs I’ve ever got have been from ignoring the ad and saying, “Hey, hire me.” The reality of the tech talent shortage is that if you find a good developer, you should hire them, even if they don’t fit your exact requirements. A lot of big companies are less flexible around their selection. Often our graduates find success when they say, “Six months ago I couldn’t program — now look at what I’ve just built. What do you think I can build for you in a year’s time?” and the company is excited by that.

All developers need to continuously learn new things and our students are no different. Say there’s a Ruby ad out there, a lot of companies when hiring will say, “Hey, here’s a code challenge, do it in whatever language you want,” so someone who learned JavaScript can still get that job. Or it’ll be, “Hey, here’s a code challenge, you have to learn Angular,” or, “Here’s a Python challenge,” and you use your existing programming knowledge to see how fast you can learn that language. A programmer might be applying for a Python job and hasn’t done much Python before, so they might spend a weekend or a week to get enough Python to solve it.

That’s especially the case for graduate roles; if people are hiring graduates and they’re looking for someone with one or two years’ experience in a language, then it’s the wrong kind of ad and that company’s got the wrong approach to hiring. There are lots of companies like that. Some companies will never hire our grads because they don’t tick the boxes and the company’s very conservative about that — and our grads shouldn’t be working there anyway.


The biggest thing we teach our students is how to use technology, because they’re going to spend the rest of their careers doing that. It’s a way of thinking, not a particular language. One of our students (now working with React in Sydney) was applying for a job where they gave him a code challenge to do over a week with a , “Please rewrite this in Angular.” His response was, “Better learn Angular!”

What students learn at Dev Academy — the exact technologies and libraries they learn — are only used by a small number of companies. That’d be the case for any technology we taught, even if we went with the biggest, most popular ones, like the big C# stacks — every company would have a different stack and different tweaks on it. You get hired anywhere; you have to learn some new stuff. That’s what we prepare our students for.

Think EDA might be a good fit for you? Apply now.