The Wait is Almost OverAfter almost 2 years of work I'm finally ready to open this site.
The Wait is Almost Over
Why The Delay?
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
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 learnjsthehardway.com 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
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.
What to Expect
Currently I have three fully written and edited modules:
- HTML Basics
- CSS Basics
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.
If you purchased it years ago off learncodethehardway.org 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.