tl;dr I'm systematically learning JavaScript using these resources.

Why?

Because JS is inescapable in web development.

Sure, you can use any number of JS-avoidance libraries. I'm a fan of Turbo, and there's also htmx, Unpoly, Alpine, hyperscript, swup, barba.js, and probably others.

Then there are stack-specific libraries: StimulusReflex for Rails, Phoenix LiveView, Laravel Livewire, Unicorn and Tetra for Django, Blazor for .NET, … and the list goes on.

You get the picture. Lots of people would rather not build a JS front end.

I myself avoided the JS ecosystem a few years ago when it would have been the default path for me as a beginning second-career developer. But I was going the self-taught route, so I needed an ecosystem with strong conventions. I didn't know how to choose from a dozen popular JS frameworks. And none of them is an all-in-one, "batteries-included" framework, so it looked like I'd need to make many decisions about how to put together an app, which would mean (for me at that time, as a beginner who lacked context) lots of frustration and stabbing in the dark.

It was in the Ruby world that I found the conventions I needed. Plus, I found (and still find) Ruby to be more enjoyable.

But now I've had enough web development experience that I can circle back and learn JS thoroughly, confidently, and without wasting as much time on rabbit trails.

Not that I can't get around in JS. At my last job, I was comfortable building full-stack features in Rails and React.

Oh, and speaking of my last job—recently I was laid off as part of a massive reduction in force. (Stay tuned for a future post on my job search and what I'm learning from it.)

Being unemployed and seeing so many jobs involving a JS front end—that's ultimately what gave me the push I needed to get serious about JS.

That's what I mean when I say JS is "inescapable": not that we can't build anything without it—in fact, I quite enjoy making sites with minimal JS and plenty of interactivity. I only mean that JS skills are mandatory for someone like me who has only a few years of experience, and therefore fewer job options. Even if I could find a backend-only position, I'm not sure I want to pigeonhole myself like that.

Plus, I really do enjoy full-stack development. And even if in some utopian universe I were able to land a full-stack position using some of the above-mentioned libraries instead of a heavy JS front end, it would still be important to understand what's going on behind the scenes. After all, those libraries are JS that's running on the page allowing my non-JS code to do cool interactive things.

So many reasons to learn JS!

How?

I'm using the resources listed below. Almost all are free. Besides a comprehensive look at JS syntax, I made sure to include a few other areas:

Guided practice and projects, to turn knowledge into skills.
Web APIs, especially the DOM, forms, and web components.
Deep dives into how JS works, and the rationale (or at least reasons) behind its quirks.
Functional JS, because I'm interested in functional programming. I recently started learning Haskell, but JS will be useful as an example of how to apply functional concepts in a not-really-functional language.

There's a lot in the bottom two-thirds of the list, only because I haven't gone through it yet and weeded out the less-than-awesome resources.

Also, note that this list is copied straight from the "JS" section of my learning road map, and the latest version may have evolved from what you see here.

Basics:
Practice:
- Exercism - JavaScript
- JavaScript30
DOM and forms:
Going deeper:
Functional JS:
Web components:
- Rob Eisenberg - "Hello Web Components"
- Dave Rupert - HTML with Superpowers: The Guidebook or the course version
- MDN - Web Components
- The Modern JavaScript Tutorial - Web Components
- Web Components Today
- Build a UI following Jared White - How Ruby and Web Components Can Work Together
- SSR web components in Ruby with the upcoming Heartml (see this Spicy Web article for context)
- Experiment using Turbo to drive front-end behavior: "Turbo 7.2.0 (currently in beta) allows you to define your own Stream actions which can be any JS code you want. By combining a custom Stream action or two with web components, you can essentially drive reactive frontend behavior from the backend stupidly easily. Loooove it! 😍 […] For a turnkey example, you could check out https://github.com/hopsoft/turbo_ready " —Jared White on The Spicy Web Discord

A word on JS frameworks

You may be wondering why my learning plan doesn't include any JS frameworks. No React deep dives? Not even the more hip Vue or Svelte??

I do plan on familiarizing myself with popular front-end frameworks, including the parts of React that I haven't used. Learning the patterns that are common across frameworks will be valuable, I think.

But if there's anything I focus on, I want it to be JS itself (along with other web standards) because they're a more durable investment, changing more slowly than JS frameworks.

Learning JS, re-learning Ruby

Readers who aren't into Ruby can feel free to leave now (it's OK, I won't feel bad), but I wanted to conclude by showing how learning JS has helped me re-learn Ruby features that I rarely use. Here are two examples.

Object destructuring

In JS:

const obj = { first: "Willard", middle: "Wilbur", last: "Wonka" }
const { first, last } = obj

Did you know Ruby can do something similar with hash destructuring?

obj_hash = { first: "Willard", middle: "Wilbur", last: "Wonka" }
# `=>` is the rightward assignment operator.
obj_hash => { first:, last: }

This is thanks to Ruby's pattern matching, which is actually a lot more flexible than JS destructuring. (For more complex examples, see "Everything You Need to Know About Destructuring in Ruby 3".)

Note, however, that there is a proposal to add pattern matching to JS.

Object literals

In JS:

const obj = {
  first: "Willard",
  last: "Wonka",
  full() {
    return `${this.first} ${this.last}`;
  },
}

In Ruby, every object has a class, so there's no concise way to define a one-off object, right?

My first attempt to prove this wrong was to add a method to an OpenStruct:

require "ostruct"

obj = OpenStruct.new(first: "Willard", last: "Wonka") do
  def full = "#{first} #{last}"
end

# Uh oh, that didn't work as intended!
# The `#full` method isn't actually defined.
obj.full
# => nil

It turns out this only works with a Struct:

Person = Struct.new(:first, :last) do
  def full = "#{first} #{last}"
end

obj = Person.new(first: "Willard", last: "Wonka")

obj.full
# => "Willard Wonka"

But now we're nearly in the territory of an explicit class definition, far from a JS-style one-off object.

OK, then just for fun, how about we expand OpenStruct so that it actually does something with that block?

require "ostruct"

class OpenStruct
  def self.create_with_methods(**kwargs, &methods)
    open_struct = new(**kwargs)
    open_struct.instance_eval(&methods)

    open_struct
  end

  # Now add a shortcut syntax.
  class << self
    alias_method :[], :create_with_methods
  end
end

# Or, OpenStruct.create_with_methods(...)
obj = OpenStruct[first: "Willard", last: "Wonka"] do
  def full = "#{first} #{last}"
end

This still doesn't look as uniform as JS object literals, and performance-wise I'm sure Ruby is not optimized for this sort of object. That's because it goes against the grain of Ruby, where classes play a central role, as distinct from instances of them. In JS, with its prototype-based object model, "classes" are syntactic sugar, and individual objects are more central than in Ruby. (On how and why this is so, it's helpful to read about JS's early history.)

But we shouldn't overstate the difference: the JS and Ruby object models are actually similar in how dynamic both of them are. This makes Ruby-to-JS compilers like Opal easier to implement, according to an Opal maintainer.

In the end, learning more JS has given me a deeper appreciation of both JS and Ruby: JS for the ingeniously simple idea behind its object model, and Ruby… for everything else 😄

Coming to grips with JS: a Rubyist's deep dive