The Wait is Almost Over

After almost 2 years of work I'm finally ready to open this site.

The Wait is Almost Over

After almost 2 years of development I am finally almost ready to open Learn JavaScript the Hard Way to the public. This blog post is an explanation for the delay, a review of what I've created, and what to expect when the early access opens.

Why The Delay?

I originally created a simple course for $20 years ago that only covered the basics of JavaScript, but I wanted to do more. A series of moves across the country and a lack of ideas kept me from going much farther until 2019 when I finally figured out what I wanted to do:

Teach people how to make websites that can accept money.

At first I thought this was too simple, but after exploring the idea I realized that accepting money online is a weirdly difficult topic to cover. More importantly it is a real topic. Nothing gets more realistic and real world than actually processing money, and that gives the course a standard purpose that I feel most students will understand. Charging money is not an abstract concept like "games" or "web sites", so nobody's going to go "why would I need this?"

My Amnesia is Strong

With my primal topic in hand I started to write the content and realized: I had forgotten almost everything everything I knew about web development. I hadn't written code for the web in probably about 6 years and the last framework I seriously used was Django. I was way behind on the new hotness in the web development world like React, Vue, Svelte, and all the new fancy features in CSS. There were also changes to the JavaScript language I had to learn and things that improved in the ecosystem to make it much more reliable for course material.

That meant I had to start from nearly nothing and rebuild my skills. I first tackled relearning CSS by copying every website that wasn't nailed down. After I learned modern CSS I focused on the new front-end technologies like React, Vue, and Svelte, finally settling on Svelte as it's the simplest of the three. Then I took the Sapper project from the Svelte folks and starting rewriting the website.

This took most of 2019, and I was ready to go when disaster struck. The Sapper project decided to end it and I was left with this whole course that was effectively dead on arrival. Honestly, Sapper had some huge flaws that made me constantly second guess using it, so I'm kind of glad they killed it off. This motivated me to then formulate a new plan that wouldn't rely on other projects as much.

Svelte is Great, Sapper Sucked

Sapper's major flaw was its goal of trying to hide the backend from the user, and failing to do all the things necessary to make that work. Before Sapper I cranked out an art website using just Express and Svelte and it was easy. I thought Sapper would be a nice system that handled all that for me but it ended up having one signification design flaw in its session system.

Sapper had a "session" that actually was never maintained like every other session system on the planet. It'd send the browser an initial session on the first page load, and if your SPA updated the $session it seemed to work, but they failed to write any coordination system so all your changes weren't reflected on the server. None of this was documented anywhere, and all the documentation made it seem like it was being updated. It took me almost 6 months to realize why I kept having these weird bugs with the session because of this flaw.

After realizing this I had to spend a few weeks hacking in my own system that "piggy backed" the session changes on request/response data. It was a nightmare and I kept thinking, "I should just go back to plain old Svelte and Express. That worked great." As things progressed and basic simple things got harder to do I was ready to kill it when the Sapper folks did me the service of putting their ugly baby out of its misery.

The death of Sapper was a blessing, but now I needed to start over...again.

The Idea of Learnable Components

I find that beginners (and pros) treat code written by other people as magic black boxes they aren't allowed to open. This inability (or lack of desire) to look in the code they use leads to magical thinking that has them guessing at what they think is going on, instead of what is really happening. The idea of Learnable Components is simply components that you're supposed to copy, explore, change, and understand. You copy the component directly into your project's code rather than bind to a module someone else maintains.

For this to work the components have to be small so a single person can understand them and change the code. Expecting people to copy in 20 files and maintain them just to get a Calendar component won't work. A single file--or a couple--is easily something a person can change. A single file that's thousands of lines long also won't work. They have to be around 100-300 lines of code, and not too many dependencies that aren't also learnable. You can't get around dependencies (since that's also good coding style), but a 100 line component that's 60 lines of imports isn't really helping anyone.

There is also an advantage when seeing how things change in the components. If someone is tracking the code for a component using git then updates are painfully obvious. There's merge conflicts and obvious annotation of exactly what changed. This would be terrible for maintenance on a giant software project with 100s of people, but for a single student trying to study how these components are built and maintained, it's highly educational.

I'll cover the idea more, but once I figured out this could be a great way to learn how things are done I had to spend close to a year writing these components. They needed to be crafted to be small and easy to understand without being "toys." Nobody wants to learn a video component that can only play basic video. They want to learn how to do HLS Video, WebTorrent video, streaming video, and regular video. I took the time to craft the easiest to understand video components I could (which is a whole other blog post on its own).

Eating a Whole Stack of Dog Food

I also wanted all of this work to be real things I actually use, not just theoretical "pet stores" that nobody would actually write. The components I created are actual things I needed when creating about 10 different websites over the course of a year. I'd implement a user interface, pull out common elements into components, clean them up, document them, then try to use them across all the sites. This process refined them and helped make them cleaner while still maintaining features.

This also meant that my "components" have to encompass the entire stack, not just the HTML bits in the browser. If I'm teaching people how to build "websites that charge money" then I have to include all the features you need to properly charge money. I need email systems, backend systems, database object-relational mapping libraries, video rendering code, and payment gateway libraries.

I built all of these elements in a reasonably small and understandable style. If you want to know how an ORM works, then I've got a tiny one that you could probably study in a weekend. It's also fully capable, being used in real work, and contains some interesting tricks you might not find anywhere else.

They say the best way to learn something is to teach it, and this process definitely taught me a lot about modern web technologies. There's something about making a system specifically designed to be understood and modified by another person that forces you to really understand the concepts.

The Early Access Concept

All of this is going well, but to implement the full plan of a complete course that takes someone from nothing to able to make websites that accept money will take a long time. The course is at a point now where I can record videos for the first three modules and people will get an introduction to HTML, CSS, and JavaScript. Making people wait even longer for the full course when there's content they can get now is kind of stupid.

I decided to adopt an idea from video games called "Early Access Release." In the indie gaming world developers will release a game while it's still rough. Gamers know to give the game the benefit of the doubt on bugs and defects in exchange for a lower price and chance to experience something new while it grows. The developers then get a group of people who are willing to test the game out and provide feedback.

But, nobody is going to try a game that's not actually a game yet. Typically the developers will work on a game for a couple years to get it playable, then do an Early Access release to get some initial funding and early feedback.

I like this concept a lot, so I'm going to adopt it for the JavaScript course. I'll use the "Early Access" idea to release it to people now so they can go through it and give me feedback, in exchange for a lower price and potentially dealing with bugs and problems in the teaching. The great thing is I'm now in a position where I can easily change it if people are having problems.

What to Expect

Currently I have three fully written and edited modules:

The JavaScript module has some old videos, but I'll be recording new videos for all three modules. You should be able to sign up for the course and attempt these modules without the videos, then review them again when the videos are ready.

I'm waiting for people to go through these modules and provide feedback so I can include important advice in the videos.

I also have all of the learnable components and the entire learnable stack written and I've been using it for about a year. This site uses it, and previous versions run various other smaller sites. Once I have the videos for the first three modules done I'll then do modules that cover all the techniques in the components to teach the entire stack.

After that we'll see where to go next, but I'm planning on implementing 4 complete sites using what's been taught so far, and giving the code out for all for along with showing how they were made.


I will soon open the site for the first Alpha Early Access release, after I solve a few problems with managing a Discord chat server. If you'd like to purchase the course early then DM me on Twitter @lzsthw and request access. You'll be a very early tester and will pay the $59 rate, but you'll get access to the discord now to talk with me while you're going through it.

Previous Purchases

If you purchased it years ago off then I'll be sending you an invite to access the site once I write the code for that, or figure out how to dump your information into this website's database. You'll receive an email, and I'll announce on Twitter when the previous customers are added to the system.

Ten Reasons Youtube's Streaming is Awful
Starting Free JavaScript Live Streams
How to Create Your Own `npm init` and Get Off
Stripe is Paypal circa 2010
See More...