Leave your comfort zone.

Leave your comfort zone.

Getting Your Feet Wet

Suppose you want a quick overview of JavaScript before diving into the real deal. In that case, JavaScript Garden is an oldie but goldie.

Here are some other resources that you’ll find helpful too:

Once you read the ones above, the following books can supplement your knowledge:

Along with these, here are a few additional resources for those who are just getting started with JavaScript:

Digging Into the Mildly-Confusing

Here are a couple of “relatively” confusing parts of JavaScript that you
might want to pay extra attention to:

Historical?

The resources marked as “historical” might have outdated examples and recommendations, so read them with a grain of salt. Though they still are worth reading, don’t skip them.

Patterns and Practices

The more you practice, the more you establish your personal style. There are also well-known and adopted JavaScript patterns and practices that are tailored for specific use cases. The following resources can help you in those areas. When you learn these best practices, you can adapt them to match your style and make them yours:

Functions and Functional JavaScript

Functional programming is not strictly related to JavaScript; however, JavaScript is a better fit to be used along with Functional Programming paradigms.

Learn Asynchronous JavaScript Well First
Before diving deeper into functional programming with JavaScript, you might want to get more comfortable with asynchronous flow control concepts, including async/await, and Promises.

Along with those, diving further into Functional Programming will change the way you look at the world—in a good way.

The current JavaScript programming scene is leaning more and more towards [functional programming, so don’t be surprised if some of the functional paradigms that you see in the libraries get merged into the language standards soon.

How Do New Features Get Introduced Into JavaScript

When it comes to adopting new features into the language standards, that is how it has been so far: If something gains enough popularity, it finds itself in the next version of the language.

For example, first Bluebird and other libraries came up with a Promise implementation, and after its widespread adoption, the native Promise constructor got itself merged into the language.

Here are some resources to get you started you with Functional JavaScript:

While at there, you might want to experiment with some of the functional libraries out there to get a taste of how functional programming with JavaScript feels like. Ramda and RxJS are my favorites:

DOM and Virtual DOM

Strictly speaking Virtual-DOM is not specific to JavaScript. And, in fact, from a 50K feeet overview, it is merely an implementation of the double buffering technique that has been around since the dawn of time.

That being said, it’s so widespread that it will be helpful for you to learn virtual dom along with dom. Here are some resources to get you started:

Learn Your Timers

Related to flow control, one concept that’s important and most do not pay
enough attention is how the event loop, the main thread, the
compositor thread, and various task queues and timers in
JavaScript runtimes work.

Here’s, again, a list of study material to shed some light on it:

Learn Various Methods of Communicating With the Server

If you are writing a web application, you’ll probably find yourself consuming external resources and data streams. You’ll need to know various ways to communicate with the remote endpoints. Here are a few articles and references that can help you with that:

Historical?

In this section, the techniques marked “historical” in this section are—indeed— historical. Never resort to them unless there is no other option because you are dealing with some legacy system.

Know Your Local Stores

Sooner or later, you are going to need to persist your data somewhere on the client too. There are several options that you can try, each with its pros and cons. Learn them, and understand which API, tool or technique is the best fit for what types of scenarios.

Here is a non-exhaustive list of client-side storage technologies:

There are also storage API wrappers that can make your life easier.
Here are a few of my selections—PouchDB is my favorite, by the way:

Learn a JavaScript Type System

If it were a couple of years ago, I’d have said “you can live without
using a type system
”; however, the world is leaning towards a strongly-typed
JavaScript ecosystem, and it’s leaning towards that direction real fast. So, better learn your types sooner than later.

Currently, TypeScript is the only mature type system that is widely adopted and worth learning.

Meta Programming

You’ll rarely find yourself in need to use reflection or meta programming in JavaScript. Even when you feel the urge to use reflection, think of a cleaner way to code that does not involve reflection. Remember: clear is better than clever, and reflection is never clear.

Dialects and Runtimes

Here are several dialects and runtimes that you will likely encounter sooner or later:

I have mixed feelings about Deno, and I still think it’s in an experimental phase as of this writing, yet feel free to play with it too. Node is your choice if you want a battle-tested, stable, and production-ready JavaScript runtime.

Want More Node? Keep on Reading
I’ll provide resources related to learning Node, for the interested, in separate section near the end of this article.

React, or Vue, or Angular, or Alpine, or… Oh my… 🤯

Especially when you are new to JavaScript and Front-End development you have this dilemma: “shall I learn React, or Vue, or Ember, or Alpine, or jQuery…

Choosing a JavaScript framework can be confusing at times.

Choosing a JavaScript framework can be confusing at times.

Well, there is a very simple solution to this:

Choose one framework, and stick with it until you master it.

Your preferences drive your choices.

But when you have two equally appealing choices (popcorn or pringles; Angular or React, etc), your choices will create new neural pathways that literally will define your preferences.

Learning a single JavaScript framework is often good enough because once you learn one framework, it’s not so difficult to translate the underlying concepts to the next.

There are a lot of web frameworks out there, and when it comes to picking one to study most of the time you’ll find yourself choosing between React and Angular.

Both React and Angular are useful tools that solve similar problems that have robust open-source ecosystems behind them. So, learning either one will suffice.

However, if I were you, I’d pick React, and only after I master React, would I look at **Angular **.

I have several reasons for that:

  • First and foremost, once you learn React, it’s easier to learn the rest—The contrary is not always true.
  • React treats JavaScript as a first-class citizen. That is not true for many other frameworks.
  • React is (often) not opinionated, you can bend it to your will.
  • React is well-supported, and well-documented.
  • React is (most of the time) fool-proof. Unless you try hard to shoot yourself in the foot, you can always create a React application that will perform well.

Understanding Client-Side JavaScript Frameworks
If you want to drill down deeper, MDN has a curated list of learning resources on various client-side libraries and frameworks.

Do I Really Need a JavaScript Framework Anyway?

Each framework comes with a performance baggage. Although it is very fast, React is no exception: Virtual DOM is fantastic; however, it is not free. The same is true for all the abstraction layers that **React ** provides over native DOM and Document fragment usage.

In very rare edge cases, you might find yourself opting out from using * React* and Virtual DOM and managing your apps’ performance yourself by using your own caching and DOM-manipulation strategies at a lower level by using the DOM API, Document fragments and all sorts of other clever tricks and black magic. I’ve been there; trust me, it’s not as easy as it looks.

Using a framework eases that burden off of your shoulders, with a slight (often negligible) performance cost. That said, especially when you are developing a hybrid application to some low-end mobile devices, using a framework might not be your best option: You might be better off writing a well-optimized plain JavaScript from scratch instead. Yet, these are more exceptions than the norm: 99% or the time React (or any other front-end framework for that matter) will be good enough for your needs.

Why not Both?

You don’t have to take an all-or-nothing approach:
With APIs like dangerouslySetInnerHTML(), React, for example, can yield total control to your custom framework-agnostic JavaScript, and let you optimize parts of the app using plain JavaScript and DOM as you see fit.

Your Hard Work Will Pay Off

When you consume all the content that I’ve shared so far, learning any JavaScript framework will take a matter of days instead of weeks or months.

You’ll be able to see the similarities and differences between various frameworks, understand them at the core architecture level. You will better understand which framework is a better fit for what kinds of problems.

Trust me, it’s totally worth the opportunity cost of your time.

The Source of Truth

The ECMA-262 specification contains the most in-depth, detailed, and formalized information about JavaScript. It defines the language. But being that formalized, it’s difficult to understand at first. So if you need the most trustworthy source of information about the language details, the specification is the right place. But it’s not for everyday use.

A new specification version is released every year. In-between these releases, the latest specification draft is at https://tc39.es/ecma262.

To read about new bleeding-edge features, including those that are “almost standard” (Stage 3), see proposals at https://github.com/tc39/proposals.

I’ll give an unconventional recommendation again: After you trust yourself that you’ve learned enough JavaScript to be dangerous at least. read the JavaScript Language Specification cover to cover.

I’ll be honest with you: The JavaScript Language Specification is much harder to read than, say, the Go Language Specification. Honestly, it’s much duller to read than the Go Language Specification; however, you will learn a lot by reading it.

Blogs

Free JavaScript Courses

YouTube

Know Your Web Fundamentals

You cannot separate the web, browsers, CSS from JavaScript. So once you get comfortable with programming in JavaScript, you’ll inevitably need to dig into web fundamentals. Here is a list of learning resources to get you started with in that area.

Web Fundamentals In General

Learn Your HTML Like a Pro

Become a CSS Master

CSS Frameworks, Tools, and Paradigms

Get Better at Visualization

Again, sooner or later you’ll need to visualize things. That can be a
simple dashboard, or a real-time histogram, or a time series data visualization.
Knowing of a couple of visualization libraries will be helpful.

Here are a few libraries that you can take a stab at:

Get Comfortable with Developer Tools

When it comes to web development, browser tooling is something that you definitely need to get yourself familiar with. Here are a few pointers that can help you in that area:

Knowing your tools will help a great deal when you need to debug web user interfaces and code.

Know Your Bundlers

Related to developer tooling is bundlers and builders. The most popular ones are Webpack, parcel, rollup, and gulp.

If you are not sure where to start, I’d suggest you master Webpack first, and take a stab at other tools later. But, regardless, all of these tools serve more-or-less similar purposes (with some variations in how you configure them); so once you know how one of them work conceptually, the others will just make sense.

Browsers And Performance Optimization

This section is the last section, and there’s a reason for that. Performance optimization is so tempting that once you get the poison, you’ll want to optimize everything all the time.

Premature optimization is the root of all evil.

There’s an old (and quite correct) saying about performance optimization:

“The first rule of program optimization: Don’t do it. The second rule of program optimization (for experts only!): Don’t do it yet.

There’s no need to prematurely optimize your code until you feel enough * pain* to justify the cause. Remember, everything is fast for small n.

If you don’t take my word for it, maybe you can listen to Donald Knuth:

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

One quick tip before giving performance pointers: Write code for humans to read. When you need to choose between performance and readability, always choose readability.

To quote it differently…

“Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live.”
John Woods, Software Engineer, Google

Those said, here are a few pointers to guide you through the dark alleys of JavaScript performance optimization:

While learning JavaScript, you’ll inevitably have to learn browser internals to a certain extent. I believe this topic deserves a separate article on its own. Yet, here are some resources to get you started if you want to dive into the performance optimization rabbit hole:

Conclusion

The videos, books, links, and resources I shared here are by no means conclusive. JavaScript in particular, and Front-End Development in general, are vast and ever-growing fields. Again, I believe the material you find here will be a good starting point for newcomers and refreshers for the masters alike.

Until next time… May the source be with you 🦄.


Section Contents