Home » Javascript » 7 Reasons Every Programmer Needs to Learn JavaScript

7 Reasons Every Programmer Needs to Learn JavaScript

In my recent discussions with hiring managers about how hard it is to find good developers, the realization has slowly dawned on me that the programming language to learn today is JavaScript.  This is particularly true if you are a web developer, but I would be inclined to just make a blanket statement.  If you are a programmer, you should learn JavaScript.



The main reason that I say this, is that as JavaScript matures and things like Node.js become increasingly viable options, the demand for JavaScript programmers will continue to increase.  JavaScript already surpasses C# as rated by demand, and is surpassed only by Java.  And if you were to take a look at projects available to GitHub, you would find that JavaScript has a growing representation that surpasses previous kingpins including Java and C#.  And finally, looking at the representation on StackOverflow, we can see that JavaScript is in the top tier there as well.

Better Pay

According to SitePoint, JavaScript pays better than C#.  Again, Java pays a bit better right now.  But as demand for JavaScript grows, you can expect the pay to increase as well.

On Gooroo, the pay vs demand shows a little different picture.  While the demand for JavaScript is evident, it is obvious that several languages that have a smaller demand actually pay better.  I suspect this is because many organizations still think of JavaScript as the language that anyone can use.  It will be a very painful lesson when they find out that “Anyone can program in JavaScript” really means, “Anyone can write crappy code in JavaScript”.  Which is where you and I step in to clean up the mess that was left behind.

Over on StackOverflow, we see a very detailed breakdown of developers for the last three years.  When you finally get down to the “Technologies Used” section what we find is that if you just call yourself a JavaScript programmer (I’m assuming client side here) you get paid better than Java and less than C# but if you say you are a Node.js programmer (which is all JavaScript) you are the second highest paid skill.  The only thing that pays better is Objective-C (and I’m assuming soon, Swift).

JavaScript is Maturing

With the recent commitment of the standards committee to release a new JavaScript standard every year, it is clear that the amount of Syntactic Sugar that will be added on to JavaScript is going to be increasing every year for a while now.  One of the features I’m looking forward to is the ability to use the async and await keywords in my JavaScript code to eliminate callback hell.

But, the reason this matters to you is that the sooner you start learning JavaScript, the easier it will be to learn.  All of the changes that happen after you learn it will all be incremental.  The browsers are also continually improving how they handle JavaScript code.  I can see a time in the future when browsers not only cache the JavaScript files, but cache the compiled version of the JavaScript files.  Bringing us closer to near binary speed.

It is interesting to me that several years ago, people were debating the future of JavaScript and now, there is active work being done to make JavaScript a first class language.

Some JavaScript Programmers Are More Equal Than Others

I was talking with an old friend about a year ago.  He mentioned that he was the only one in his group of about 20 programmers who wrote JavaScript in such a way as to eliminate polluting the global scope with variables.  That is just the most simple of examples.  Many people who call themselves JavaScript programmers, don’t know the basics.  And that is today.  Imagine what this is going to look like three to five years from now.

And don’t forget that a lot of the tooling to support profiling and memory leaks is just at its infancy.  If you have those skills today, and you have marketed yourself well, you are already realizing that a lot of what I’m saying here is true.

If you are interested in this kind of stuff, there are some courses over on PluralSight.  Just search for “JavaScript profiling

Frameworks Are Maturing

With the new version of Angular in the works, Aurelia in the works as an alternative.  Commercial products such as Scencha’s EXTjs.  Node.js for server side programing.  And others…  No one can say that it is too hard to develop real applications using JavaScript.  I’m pretty sure, if I wanted to, I could write a desktop application that ran using nothing but JavaScript.  Oh.  Wait.  That’s already been done.  (Visual Studio Code for those of you who were asleep for that announcement.)

Actually, since I’ve written that last paragraph I’ve started writing a desktop application that uses HTML with Bootstrap and Angular for the presentation layer and C# for mostly data access.  Yes, I know I could do the whole thing in JavaScript if I wanted to, but I’m going with what is most familiar right now.  Apologies to XAML fans.

JavaScript Runs Everywhere

JavaScript runs on every major browser on every major platform.  It runs on the server side on every major operating system.  Anyone writing a web site today of any major functionality is going to need someone who knows JavaScript to write the front end.  It doesn’t matter what the back end code was written in be it Java, PHP, .NET, Node.js or something else, the client side is going to need a JavaScript developer.  In fact, I still run into pockets of developers who just don’t know how powerful JavaScript is.  What this means for you is this.  If you become an awesome JavaScript programmer, you will have jobs available to you across all of the various server side platforms.  It will help if you learn a little bit about those platforms.  But I’m talking about niching down in JavaScript so that you become THE go to person.

JavaScript is a Compiled Language

It may shock you to know that, technically, JavaScript is a compiled language.  This has two implications.  First, once the code is compiled, it is possible for it to run as fast as any other executable.  Second, it is technically possible to write tooling for JavaScript that would create a binary file that does not need to be recompiled every time the code is loaded into memory.

What Do You Think?

Of course this is all totally opinion.  What do you think?  Leave me a comment.

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • Multi-Threaded JavaScript – Not The Problem You ThinkMulti-Threaded JavaScript – Not The Problem You Think A couple of weeks ago, I posted 7 Reasons Every Programmer Needs to Learn JavaScript.  In the comments, Dean tried to refute my arguments first by claiming that my sources for JavaScript’s […]
  • JavaScript Performance TweaksJavaScript Performance Tweaks So, I started reading High Performance JavaScript recently and I thought now might be a good time to give a summary of what I've learned so far.Up until recently, I wasn’t all that […]
  • Is JavaScript Broken?Is JavaScript Broken? I read a post this week that was essentially a rant on the way JavaScript handles concatenation.  It states that JavaScript is in someway “broken” (without actually using that word) […]
  • JavaScript Crazy Talk – Are you guilty?JavaScript Crazy Talk – Are you guilty? I heard this so frequently, I decided it is time to write about it. (When writing web applications)  Business rules always belong on the server. One of the last conversations I had at […]
  • Are You Doing Angular Right?Are You Doing Angular Right? I’ve written that I’m using Angular to write a couple applications before.  One at my main contract and a couple side projects.  I know I’m kind of late to the game, but one of my […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.

  • Dean Schulze

    There’s a problem with the job sources you cite. Job postings will usually specify multiple languages. It’s not uncommon to find postings for full stack developers that require Java, JavaScript, and SQL, or C#, Javascript, and SQL. Breaking them down into single language bars is probably a mistake.

    The eruption of big data will probably be the biggest driver of the job market in the future, but Javascript is irrelevant in the big data field. Java, Python, and R are the skills for big data, with Scala in high skill niches like deep learning.

    • http://blog.dmbcllc.com/ Dave Bush

      You actually make a strong case for my sixth point. Regardless of what your back end is written in, the client side – if it is a web site – will be HTML, CSS, and JavaScript.

      Big data may also be a technology to watch, I’m not going to pretend to know enough about it one way or another to comment.

      • Dean Schulze

        Yes, for better or worse we are stuck with JavaScript on the client. But JavaScript is poorly suited for server side applications.

        If you are going to write server side applications in a single threaded language like JavaScript you might as well deploy those applications to a single threaded operating system like DOS. Think of the simplicity: You write single threaded code in a JS framework and then stand up DOS virtual machines to deploy them in.

        Of course that is ridiculous, but so is writing single threaded server side apps.

        • http://blog.dmbcllc.com/ Dave Bush

          Regardless of how ridiculous you may think using JavaScript on the server is, Node.js is making this quite possible.

          Also, your assumption that you can’t do multi-threading using JavaScript is wrong. You do this by executing child processes.

          You have to think a little differently about code than you may be used to, but writing server side code, or even a full featured desktop application, using JavaScript is not only possible, but it has none of the issues that you suggest and applications that refute your assumption have already been written.

          • Dean Schulze

            There’s a big difference between a thread and a process.

          • http://brandonclapp.com/ Brandon

            There is also a big difference between a language and a runtime. While JS is single threaded, node treats each http request as it’s own thread. Node handles concurrency well, which makes it great as a server side platform for web and other network applications. For most web applications, this will work and scale great.

            However, if you have CPU intensive tasks, then node is not the correct platform, nor was it designed to be.

            JavaScript as a back end language is most of the time used in the context of web applications, meaning that a web developer can easily code the front end and back end with one language without having to context swap. If you’re doing heavy HTTP requests that require CPU intensive tasks, then you likely need to rethink your architecture.

          • Dean Schulze

            Thanks for the disclosure. Everyone promoting node (and other server side JS frameworks) should include the disclaimer that JS is poorly suited for computationally intensive tasks. If your web site does much more than serve static HTML pages then a JS framework is probably a poor choice. But you can use a single threaded OS! Back to DOS?

            If node is written in JS how does it create new threads for each HTTP request?

          • http://brandonclapp.com/ Brandon

            Note: I edited my last post because it was partially incorrect. I thought that node created a new thread per request, however, it does not – rather, it uses a thread pool for when it see’s fit.

            Node is actually written in C (hence why it can spin up worker threads). It’s a JavaScript runtime built on Chrome’s V8 JavaScript engine (written in C++). One of the ideas behind Node is that I/O is expensive, and the goal is to use an asynchronous non-blocking I/O model. The theory was that doing async processing on a single thread could provide more performance and scalability under typical web loads than the typical thread-based implementation. The idea is that the event loop (i.e. the main thread) never blocks. It is all event driven to provide asynchronicity .

            A node.js app that isn’t doing CPU intensive stuff can run thousands more concurrent connections than Apache or IIS or other thread-based servers. This includes use cases that surpass static pages. There are many node frameworks that contend with with popular frameworks in other languages such as ASP.NET MVC, Rails, Django. Express and Sails.js are a couple that I have been using recently.

            While the web used to be geared toward serving server side generated pages, it has turned toward single page applications where the DOM is not rendered every time a link is clicked. Many node frameworks shine in this regard as well, as many are great for scaffolding API’s and/or providing websocket support.

            tl;dr: Node is a great platform, but it is not the tool for every job. If you’re doing heavy number crunching for something like OCR or image resizing, then it may be a good idea to choose a different platform (or perhaps create a worker process that calls into a C/C++ library). I don’t, however, think that it’s fair to say that JavaScript is a bad server side language simply because it’s single threaded language. Other popular web languages do not (or haven’t until recently) support true multi-threading (Ruby, Python, PHP).

            Here is a good explanation of how the node event loop handles events and multiple requests.