5 Common Mistakes JavaScript developers have always done and will do in 2021

I started to learn JavaScript way back in 2013 and learned a fair share of it by experimenting, hit and trail, a few excellent blog posts, and many projects.

To establish authority why you could probably consider my advice, I’ll list a few things:

I run a 140K+ YouTube channel where I have seen and learned a lot by interacting with people and how they learn things.
I run three codedamn 1337 mentorship groups with 150 people right now, and I see people repeating many mistakes all the time.
I have been a freelancer on Fiverr for a very long time (actively for 3-4 years), and have seen some horrible codebases along the way.
I am a college student and have seen my peers learn from different places/resources and how they approach things in a short time. I have their experience and methods to compare to mine.
I am the author of two books – Learning ECMAScript and Advanced Web Development with React – both available on amazon.

Let’s start.

#1: Trying to master overlapping libraries/frameworks

It might sound stupid to master 2 ways of doing one thing, but you’ll be surprised how many people try to learn React and Angular both. Or Angular and Vue. Or as a matter of fact any combination of modern frameworks and libraries.

In my personal opinion, you should not do this. A few reasons which come to my mind:

You will need a lot of time and practice with the individual framework/library you choose, like React. This will involve the library itself and choosing the right suite of tools to go with it (framer motion, react-query, material UI, typescript, etc.) Learning the equivalents for the other framework, with the framework itself, say Angular, is a waste of your time, which you could use to improve your React skills alone.
No company should require you to master more than one such library or framework. Products are never built with Angular/React/Vue all 3 together, or any combination of these two. You almost always need only one field of expertise.
Going deep into a library/framework like this is much more important than going wide across multiple frameworks. If you own a little tech stack using which you can build anything, you are much more powerful than most people.

As Bruce Lee said:

I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times.

This applies very much to programming knowledge too. Knowing about many things is fine, but you should never be/attempt to be the master of a lot of things in the overlapping space.

#2: Algorithmic practice hell

You have heard about tutorial hell, meet algorithmic hell. If you’re trying to crack an interview where you will be asked difficult algorithmic-based questions, then it is fine. If you are focusing on becoming a better developer, alongside basic algorithm and logic building, learn to also use your tools. Your tools (prettier, webpack, npm, devtools, debuggers, etc.) will help you be much more productive and you will learn a lot of things that applies to real-world job work too.

You should absolutely have a good amount of data structures and algorithms knowledge to build your logic. But if you find yourself spending a lot of hours on leetcode solving problems for weeks, you are going way deep into DSA than required. Again, one man’s p.o.v.

#3: Not focusing on basics

I am a firm believer that everyone learns differently. However, if you’re new and see React is the hot kid in the town, do not pick it up straight away. Spend some time with JavaScript, not only before but also when you’re learning React. Spend some time learning about fundamentals of the language, dot notation, bracket notation, common manipulations with arrays using filter, map, functions, variable scopes, and so on. A good basic course will go over all these things. Heck, build a few applications just using vanilla JS too. You don’t need those frameworks just yet.

#4: Not eventually using TypeScript

JavaScript has come a long way, but because web needs to be compatible, sometimes all the way back to late 1990s, JavaScript cannot drop its bad things. When you use JavaScript, a lot of weird things and edge cases always exist.

Lack of type support is also a big issue as your codebase grows. As much as I love working with JavaScript, it cannot be defended that not only JavaScript, any language without a proper typing system and edge cases like JavaScript has (in non-strict mode), is very difficult to maintain on a bigger codebase. Here’s when TypeScript comes in.

TypeScript can behave very very close to how a statically typed language works if:

You always operate TypeScript in the strictest possible mode.
You do not lie about your data types in code.

Point 2. is especially important because unlike other languages, your TypeScript program (which eventually runs as JS) will not crash if the types mismatch, because types are never checked at runtime.

This is especially an issue with a variable data payload, say from network. Not lying about your data means to put guards in TypeScript to check if the data shape and form is exactly how you expect it to be. Granted, it requires you to go an extra mile beyond your business logic of application, but this way you maintain the flexibility of JavaScript with the ability to use it in highly sophisticated production environments without the fear of breaking.

So the question is, when should you learn TypeScript? I would try to postpone it for a while, at least after learning your first JavaScript framework/library like React or Angular (Angular requires you to learn TypeScript anyway). But you’re more than welcome to learn it from start too.

#5: Not realizing JavaScript ecosystem is huge

You can learn a good amount of JS in a while, but you cannot master JavaScript in weeks, or even months. JavaScript started as a language meant to be sprinkled over for a little interactivity on the web. It has now grown to be used as full blown servers, IoT devices, mobile apps, with a dozen of runtimes and engines.

You cannot, and should not optimize to learn JS completely in a small time-frame. There’s just too much, even for web development front – Node.js and browser JS. Instead, you should focus on the things you want JS to solve and learn APIs/practicing around those.

Want to learn about developing games on the browser? Learn about canvas API and popular tools around it. Want to know about squeezing out max performance out of your 8-core server? Learn about JavaScript event queue/microtasks and flame graphs, running Node in cluster load balanced with pm2 or with docker containers.

You see, the more you will learn, the more you will realize there is so much more you can learn. According to me, aiming to learn 100% should not be the initial goal. Start small, and then learn parts of ecosystem as you need, i.e. start with browser JS, move to Node.js servers (while learning browser JS too), maybe then try out NativeScript or React Native to build mobile apps, or try out Electron for desktop applications. But I wouldn’t try to learn everything at once.

Conclusion

In this article, a fair amount of text is for 13-year old me, who had no direction and was learning things, not in the most optimized order. Sure, it took me a lot more than some people to know, but I always enjoyed what I did (of course, except for the peaks of crazy frustration when code doesn’t work). This was not mentioned as a point, but probably the most important point is to enjoy what you do. There would be highs and lows always, if you don’t enjoy what you do, I fear you might give up in your lows.