How Do You Become Good At JavaScript?

This is how I got really good at JavaScript…

About 5 years ago I started learning to code. At the time I didn’t know what I wanted to code. I just knew I wanted to be a programmer, sick of the daily political non-sense of the finance industry.

I happened to receive an Arduino as a gift. I also purchased Hello World in Python and downloaded the Android 2.2 SDK for Eclipse. Then I got to work. Hello World in Python is a great book if you are looking for a place to start. I can’t recommend this book enough for it’s simplicity, clarity and fun approach.

As I was jumping into programming I was all over the place. I knew I needed to learn to program, which to me at the time, meant learning the newest versions of Java or C# to be marketable and modern. I now realize that mindset is not entirely sound, that there are tons of useful places for other languages, and versions, and that binding yourself to a particular technology is not necessarily the most efficient or rewarding mentality to have.

As I was teaching myself, I quickly realized that web development was where I wanted to be. IT is a huge field and web development is by far not the only choice for prospects, but for me, it was the right one. I started using the Headfirst C# series and learning with the Microsoft provided Visual Studio MVC tutorials. Another really good resource for me was, an amazing site with tons of really useful and easy to follow material.

In my self-paced, self-learning, the templates that Microsoft provided, and the lessons I found, relied heavily on JavaScript libraries like jQuery and jQueryUI.  As a result of months and months of library usage, I started to understand the concepts of JavaScript but couldn’t write any of it without the libraries. The libraries made web development fun for me at this point. They really masked the many lines of code necessary to accomplish a task and for that they were useful. At the same time, I couldn’t do things outside of what the libraries allowed. Still, someone thought I knew enough with just that.

About 6 months into my learning, I got my first job as a programmer for a mid-size software company. The job was tedious and very strict in my opinion. Working for a software company for me was more like being on an assembly line than being in a creative role. In that software production environment you are given a set of requirements, a picture of the expected result, and a time frame, you churn and burn, have it tested and move on to the next task as your code makes its way into production.

In my first couple of months as a professional software developer, I didn’t actually touch JavaScript. In my free time, I continued to tinker with those JavaScript libraries, including KnockoutJS. Then finally at roughly 6 months in, I was given a new task which was almost solely JavaScript. I opened up the code and just about panicked. What I was looking at was nowhere near as simple as jQuery had led me to believe it was.

I spent nearly a week reading, noting, and testing each line I was to touch and interact with. I didn’t understand it and the idea of publishing code that just sucked, for everyone to see, was incredibly overwhelming. Then I found my escape buried in the file. A huge chunk of jQuery was already written into the repository, and so I thought I would do the same. I was so happy at this point, I thought how I was going to wow them with my code on my first attempt. I wrote my module for an enterprise financial application entirely in jQuery. I tested it, sent it to QA, passed and pushed it up the pipeline. Then I got my first on the job scare.

I was brought into a small room where about 10 programmers were working side by side. Apparently, this was where the code was thoroughly tested and inspected before production. I was informed my code was not being pushed to production. They told me my code was inefficient, it created an unnecessary amount of memory and slowed the program down. This was entirely unacceptable in a massively scaled enterprise application.

The problem was jQuery. It turned out that the chunk I mirrored was also removed. I didn’t understand it then, but that chunk had also passed QA and been checked in and so I was able to see it in my version of the code but it was removed before production. I was told to work with another developer and rewrite my piece entirely in plain JavaScript and I did. It was a humbling experience. For the next month, my code had to go through an additional inspection as a sort of reprimand. I never attempted to push junk through to production again. As a result, I learned to start writing plain JavaScript which was nice.  That ended rather abruptly though.

The company I was working for encountered a series of financial setbacks, and a lawsuit. Half of the company was gathered into a room and told their services would no longer be needed. I was one of those people. Lucky for me, I had a recruiter contact me on the way home that day and had another job in about 15 minutes. Huge demand is another reason I am so glad to work in IT as a programmer.

At my new job, I was given much more leeway to decide how to structure and write my code. With this freedom, I really tried to utilize my knowledge of those JavaScript libraries I had acquired and used over the last year. This job was different though and more challenging.

This new role required that I interface much more with various systems and technologies. I had to make Symphony version 1 applications communicate with MySQL and MSSQL databases, and at the same time with VB.Net and C#.Net applications. When my job began to require very intricate customized code I began to move away from JavaScript libraries.

The problem I found with many of these libraries, was that as the complexity and diversity of the data sources grew, and the customization requirements compounded, libraries like jQuery began to fail. I encountered stack issues or memory on so many occasions until I finally ceased using them. These errors forced me to start writing pure JavaScript code, and as I wrote more and more I stopped being intimidated by JavaScript.

It wasn’t long before I started actually realized that pure JavaScript was more efficient and cleaner, once I understood it, than any abstraction, although I know the JSX and Typescript teams would disagree. Writing pure JavaScript also helps contribute to the overall web development industry, because it is through iteration and real world usage that we find where the language itself should be grown and where it should be fixed. By supporting pure JavaScript, we are helping to battle test JavaScript and improve upon it.

After years now of writing pure JavaScript, I can say the way that you become really good at JavaScript, is you put down the crutches and run with it. That is not to say libraries like KnockoutJS can’t be invaluable in your arsenal. I’m saying that you won’t be able to truly appreciate the problem you are facing and provide the most efficient solution until you understand what the libraries are really doing under the covers. If you want to be a highly skilled web developer then you have to be great at JavaScript, there is no way around this. JavaScript is the glue that makes the internet fun and interactive.

Leave a Reply

Your email address will not be published. Required fields are marked *