DEV Community: Natalie Martin

W3Schools Then and Now: How Have JavaScript Tutorials Changed?

Natalie Martin — Fri, 06 Nov 2020 17:50:25 +0000

JavaScript has changed so much since it was first introduced in the mid 1990's. I don't just mean the language itself (though it has changed a lot as a language). I also mean the community and culture surrounding the language as well as its place in the larger programming community. That got me thinking: how have the guides and tutorials that teach JavaScript changed over the years?

I first started learning JavaScript quite a while ago... about 12 years ago as of the time of this writing (at this point in writing the article, 24-year-old me realizes with great horror that she has been learning JavaScript for over half of her life now). Since I've known JavaScript for so long, I don't often find myself seeking out resources for learning JavaScript basics; typically if I need to look something up I head straight to a resource like MDN's Javascript Reference instead of trying to parse through any tutorials. I don't even remember the last time I read a beginner JavaScript tutorial... I've definitely read beginner tutorials for frameworks and other libraries or technologies that use JavaScript, but when was the last time I read a tutorial on the base language itself?

I thought it'd be interesting to go to a modern JavaScript tutorial and see how things have changed since JavaScript has blown up in popularity. But I also wanted to go back to the very first JavaScript tutorial I looked at years ago: the tutorial on W3Schools. So to keep it simple, for this article I'll be comparing the old W3Schools site with the modern version of the site. Specifically, I'm going to use the Wayback Machine's archive from 2005, since 15 years ago seemed like a nice round number (even though I started learning JS in 2008). Let's see how things have changed!

But first, a note on W3Schools

For a while, W3Schools had a bit of a bad reputation. Actually in researching for this article, I've found that its reputation still kind of persists. But it used to be a lot worse. I can't be the only one who remembers "W3Fools", a site that used to list out all the problems in various W3Schools tutorials. If you visit this site now, you can see that W3Schools has since fixed those problems and the site points out that it's a decent resource for learning nowadays.

Anyway, for this article we'll be going back to the days before that site went up, but I couldn't not mention that elephant in the room! Now with that out of the way, let's go over how W3Schools has changed!

What is JavaScript?

Before we even get into the actual specific programming content proper, I want to talk about the introduction pages of the tutorial that explain what JavaScript even is, because I think it does a good job of communicating how exactly JavaScript's place in the programming landscape has changed over time.

W3Schools from 2005

In this 2005 tutorial introduction, you may notice some very... of-their-time phrases being thrown around. I love the pluralized "JavaScripts" being used. Back in the day, JavaScript was seen as a thing you would just plop onto an HTML file instead of being a much more integral part of the programming landscape, so calling individual JS files "JavaScripts" made sense. With how modern development goes, where many JS files make up whole applications, it doesn't really make sense to call anything "a JavaScript" anymore.

W3Schools from 2020

You can see on the modern site, they still retain the "JavaScript is the [...] language of the web" description, although they have since changed "scripting language" to "programming language". This definitely represents a shift in how JS is seen as a language. These days we don't often refer to languages like JavaScript or Python as "scripting languages". Back in the day I felt like there was a certain connotation to what a "scripting language" was, in that it was an interpreted language that wasn't as sophisticated as the "real" languages like Java or C++.

Most languages are just called "programming languages" these days because I think the programming community has realized that programming in JS is just as "real" as programming in C.

By the way, we can also see this attitude reflected further in this quote from the 2005 version of W3Schools: "JavaScript is a scripting language - a scripting language is a lightweight programming language". They further downplay the power of JavaScript in this section that clarifies the difference between Java and JavaScript:

Note how they imply the difference between Java and JavaScript is that Java is powerful and complex and JavaScript is not

In the modern version of the website, they just specify that they are two different languages and pretty much leave it at that, without putting down one language or the other.

Okay let's actually look at the tutorial content now

If I were to do a full play-by-play on every single difference between the 2005 tutorial and the 2020 tutorial, I'd be here all day, so I mainly want to focus on very specific examples from here on out. I strongly recommend you check out the 2005 tutorial on the Wayback Machine for yourself if you have the time.

When I initially thought about comparing the old to the new, the first thing that came to mind that would probably be different would be the usage of document.write in the old tutorial. If you check the tutorial it is filled with document.write calls whereas the newer tutorial typically uses more modern ways to output a string (typically by changing the innerHTML of an element on the page). However, I was surprised to see them still mention document.write on their modern tutorial, although their example is surrounded by warnings about how you should basically never do use it outside of testing.

A lot of the code uses it in ways that make me go "oh god... I personally would not do that today". Can you see what this code is doing, and could you ever see yourself doing something similar today?

<script type="text/javascript">
for (i = 1; i <= 6; i++)
{
document.write("<h" + i + ">This is header " + i)
document.write("</h" + i + ">")
}
</script>

Speaking of expected changes, I was curious about how modern W3Schools would handle newer keywords like let and const. In the 2005 tutorial, they use var as that was what was used at the time, however they also define a lot of variables with no keyword at all. That was pretty standard back then but... it is quite weird to see nowadays.

This is not really okay anymore

Meanwhile, I was optimistically expecting the 2020 tutorial to not even use var anymore. I was a bit surprised to see that while it does mention the new keywords, it still mainly uses var for its examples. I do understand why they made the decision to still use the older style of code, but from my own personal JavaScript experience I've been using the new keywords for years now so it's a bit weird to see.

There are plenty of pages that haven't really evolved that much in the last decade and a half though. The "JS Operators" page in particular has very obviously evolved from the 2005 original, where some of the same tables from 15 years ago still exist, altered only slightly over the years.

I actually don't really have many more things to talk about regarding the old tutorial. It is so much more basic and quite casual, probably a product of the attitude regarding JavaScript at the time of just this thing you drop into web pages to make them do little interactive things. The whole tutorial itself is just 16 pages, compared to the 100+ pages that make the W3Schools JavaScript tutorial today. The modern code examples are all nicely formatted with syntax highlighting, which is a stark contrast to the uncolored code from 2005, often lacking any form of indentation at all.

I strongly urge you to check out the 2005 tutorial and see just how different JavaScript was back then!

Some random things I found and want to mention real quick

Back in the day, W3Schools offered tutorials on client-side scripting languages besides JavaScript. On certain old versions of Internet Explorer, instead of using JavaScript, you could use VBScript as a scripting language. So W3Schools had a tutorial on it. Although it was even more basic (no pun intended?) than the JavaScript tutorial.

Imagine a world where VBScript won the "script war"

W3Schools also had a tutorial on WMLScript, which was for scripting web pages for pre-smartphone mobile devices.

Okay I have to talk about one specific part about the old JS tutorial on the boolean data type. They list out (almost) all the ways you can create a false value from the Boolean constructor:

That's a pretty decent list. They then go on to show values that when passed into the Boolean constructor will return true, however back when I started learning JavaScript I misinterpreted that, much like the previous list, these were the only values that would return true:

While the "false" and "Richard" example was there to show how most arbitrary non-empty values in JS will evaluate as truthy, I thought for at least a few months that JavaScript had specifically programmed easter eggs that would evaluate "false" and "Richard" as true. It would have really helped if they explained how it really worked!

Finally, I want to mention something from the modern version of W3Schools: W3.js. It's a JavaScript library made by W3Schools to make certain JavaScript operations simpler. Has anyone ever used this? While its source code is available, there is no public version control repository that you can contribute to or clone the project from. You just download it from their website. It doesn't even have an NPM package.

While this wouldn't really be out of place if it were made in like, 2009, the download page for W3.js states that version 1.0 was released in January of 2018, although I found a StackOverflow question talking about it that apparently dates back to 2017.

I guess it's good for beginners, especially for those who aren't used to using code from external libraries, but W3Schools advertises the library as if its some widely-adopted, critical piece of technology. The name "W3.js" also sounds like the library is officially affiliated with the W3C, which it is not. I find the whole thing quite odd...

So, what's the take away from all of this?

JavaScript has changed a lot and is going to continue to change in the future. And so many people are going to be learning JavaScript through various online tutorials and lessons. I think even if you're an experienced developer it can be helpful to look at how people are learning JavaScript today, and also how people used to learn JavaScript.

In general, JavaScript guides have gotten better since 2005. I think it's important to reflect on how these guides got better, so we can hopefully continue to make improvements to our current educational resources. (Although to be fair W3Schools was in part improved by a group of people bullying them into action... so maybe ignore that part).

So, when and how did you start learning JavaScript? If you're an experienced dev, when was the last time you looked at a tutorial aimed toward beginners? Did any of you find anything interesting in the old W3Schools? I'd love to see any interesting finds in the comments! Thanks for reading!

Looking Back at the My Little Pony Game I Made in High School

Natalie Martin — Mon, 06 May 2019 00:09:10 +0000

The Backstory

I have a confession to make... I was once a "brony". I was a sophomore in high school when the My Little Pony fad was at its peak. Being a teenager who already found nostalgic charm in watching shows aimed towards little kids, I got sucked into the whole brony thing and after marathoning the entire series until I was ready for the Season 2 premiere, I began the well-known brony habit of making everything I did about those talking cartoon horses. You can probably remember a time way back when it seemed like everyone's profile icons were ponies and all kinds of pony memes were flying fast. Those were the days when memes still had top and bottom text.

An example of what passed as a meme back in those ancient days

Anyway, back in high school I took a variety of programming classes. "Computer Programming" was a very basic class, as one would really expect from a high school elective programming class. It did give me my first opportunity to briefly play around with Linux (the idea of Linux blew my mind at the time but I never thought I'd be using it as my main OS) and also for my final project I got the opportunity to do something quite novel: Make a game prototype using nothing but HTML and JavaScript... before HTML5 was actually a thing!

But the class that actually had a serious impact on me as a programmer was the next level programming class, "Game Design & Development". It functioned more as a "Computer Programming II" course, though obviously it also focused mainly on game development. I loved this class. I learned so many fundamental programming basics that those huge O'Reilly animal books never really taught me (they taught me the programming languages but more complex and abstract programming concepts either weren't discussed or flew right over my head).

I did follow all of the advice in this book though

This class was the first time I actually had to work with object-oriented code before. Prior to this course, the idea of classes and objects seemed more like nice syntactic sugar; a fancier way of making an associative array. When I finally learned the magic of inheritance and abstract classes and such I was blown away and made an unnecessarily fleshed out object architecture for a simple game we made in a Java-based tool called Greenfoot. I originally hated Greenfoot until I learned about the delights of OOP. I even had a little journal at the time and you can see my hate for it grow into "How could I live before Object-Oriented Programming? HOW?!". Anyway, here's a picture of the game I made:

Later I remade this game in C++ while trying to preserve the class structure of the original Java code. No. Just no.

That game is not the My Little Pony game I'll be talking about in this blog post. Instead, I'll be talking about my final project for the class, made in XNA Game Studio. XNA was especially impressive to me because it was my first opportunity to make a game straight from code... no drag-and-drop interfaces or even any actual "engine" code in the framework to help was actually really exciting. It was like I was a real game developer!

Code Review Time

I'll be going over what the actual game itself was like in the next blog post I make. In this post I'll be reviewing some of the actual engineering decisions I made for this game. And oh boy there are plenty of... decisions to review here. But to give a quick introduction to the game, it's a game inspired by roguelikes and turn-based JRPGs. Internally it was always known as "PonyRPG". I wrote a majority of the codebase in two weeks.... as a high schooler with only a very naive grasp on object oriented architecture. Oh no.

Code Issue #1: A Disorganized Mess

The most glaring issue with the codebase is just how incredibly messy it is. Code is just kind of stuffed everywhere and at the time I really didn't know about any "clean" architectural design patterns. The "main" game class that contains the basic game loop and drawing loop is... two thousand lines long. Shoved everywhere in this class are tons of nested "helper classes" that act more as structs than actual classes with methods. I thought splitting classes into their own files was stupid back then so I jammed a lot of the tinier classes into the files that used them and left it at that.

A look at the various nested classes I use in the codebase. Most of these are all located in the massive main game class.

There are a few giant classes like this in the game's codebase, that pretty much are responsible for large sections of game logic and also have tons of subclasses and random helper functions all jammed up inside of them. Spreading out all that code into classes that have a Single Responsibility would make the code much cleaner. There are lots groups of functions within these mega-classes that could easily be extracted into their own classes to make the code cleaner and easier to debug.

Code Issue #2: Enumerator? I Hardly Know Her!

A core part of design a game's architecture is allowing the game to exist in multiple states or "screens". Title screens, loading screens, different game modes, and minigames are all examples of separate game states. You don't want code that controls the title screen to be found in the main Player class. You also want to be able to free up memory that's no longer used by game states. The game logo that shows up on the title screen should probably be unloaded after you actually enter the game, and be reloaded only after the player chooses to go back to the title screen.

In "PonyRPG", the title screen graphics are never unloaded, because there's no actual state management system in the game. The game's state is fully managed by a single variable that exists in the main game class and is checked several times per frame: an Enum called "gameMode". In the main game loop there are a bunch of if statements checking what game mode we're in. So we basically end up having 4 game loops all jammed into one game loop.

Not pictured: the massive "mode == gameMode.gameplay" section of the code

Fortunately that's the only Enum I use for state management...
...
OKAY, ALRIGHT, so in the core gameplay loop I use a very similar design (anti-)pattern to manage the "inner" gameplay state. So there's another Enum that manages what state the player is in: outside of battle, inside of battle, in a scripted event, using a save point, etc. ...It's pretty bad.

These various states should have been managed with actual classes. The main game loop would only be running the active state object's Update() function and through polymorphism the main game class wouldn't really know or care what state the game is in. While an Enum and Switch statement are practically functionally identical, using polymorphic dispatch is much easier to contain. Instead of the main game class having a bunch of seemingly random variables everywhere, only the game states that care about said random variables should even know about them. Instead of continually adding another if or case statement to my code, I just need to add a new class to the codebase and instantiate it somewhere. The game itself can be updated without having to edit the main game loop or its surrounding class at all.

Code Issue #3: No Spoilers!

Alright this next issue isn't really that big of a deal compared to... well those previous massive architectural flaws that contaminate pretty much the entire codebase, but I think this needs to be addressed! The game is pretty data-driven, with enemies and level parameters and... well pretty much everything loaded in from external data files. That's not the bad design part! I wanted to be able to mask this data to not only prevent people from tampering with it and breaking the game, and also to prevent game spoilers such as what the final boss fight will be like and such. I was very protective of this game data, so I not only had it embedded into game's executable itself, I also used AES Encryption to make it impossible to see it if you opened the executable in a hex editor!

Oh god, I've leaked the decryption code, oh god now people can haxxor the game!!!

This made managing the data a pain as I'd constantly have to re-encrypt any game data that I wanted to edit. This paranoia handling data also extended to the file used for saved data. I basically used encryption along with a complex "security through obscurity" style format with multiple checksums (and I'm not talking about The Theory of Obscurity here). This complex method of storing saved data was so complex that the latest version of the codebase I'm criticizing right now... can't even load saved data. By adding more and more security measures I broke the saved data feature that was working perfectly fine before!

I think there's definitely value in protecting data from being read and manipulated, but the way I did in this game didn't just prevent anyone playing from tampering with the data. It also hindered the development of the game and broke a feature! I probably should have kept this stuff simpler and added more basic checks.

It's Not All Bad

So I've pointed out some of the glaring problems of this horrible code. Does this mean that my high school self was a bad programmer? ... Well, kind of. Though I feel it's important to think of it less in terms of how bad I was back then and more in terms of how much I have grown as a programmer since then. I mean, I was in high school, how was I supposed to know that instead of picturing game state as a finite state machine I should have been picturing it as pushdown automaton instead? This was the first game project I made straight from code, no dragging and dropping. I'm proud that I even made a (mostly) fully playable game! And I think high school me would be proud of present me roasting this code and would also be really curious how the more "professional" game developers do proper game architecture. I mean, to be fair, there's still a lot I don't know about how proper game architecture should be done.

Anyway, there are parts of this codebase that really aren't that bad! The data-driven design I talked about earlier was something I was really proud of when originally developing the game! My previous experiments with XNA used completely hard-coded values. This game has no actual specialized classes for enemies, instead just having a base Enemy class which is instantiated and filled with the proper enemy data from the game data!

How the data is stored for enemies (unencrypted lol)

Another not-too-bad part of the code base revolves around the various in-game dialogues that show up. The PonyRPG.engine.TextWindow class is probably the best-designed class in the entire codebase. It covers scrolling the text 1 character at a time like old video games, wraps the text properly, and is pretty configurable with various padding and margin settings. It has a related class, PonyRPG.engine.TextWindowOptions that is just a data structure for its various options... and it exists in its own separate file instead of being a nested class stuffed somewhere else! While the code here could still be improved upon a lot, it's definitely the most pristine code here...

... and the reason it's so nice is because I actually developed it outside of this project! I originally developed this class for another pony-related game I was working on in XNA and I made it as generic as possible so I could reuse it in other games I made. It has features never used in the "PonyRPG" project, like the ability to display character portraits while talking displayed, like in the Harvest Moon series.

The TextWindow object in the original project it was used in

When I first made this textbox it honestly felt magical that I could insert little video gamey dialogue boxes into my games!

Okay... So What's The Game Actually Like?

Welp, I've talked enough about the game's code. I bet you're wondering what the game looks like. What's it actually called? Is the Game Design good? Was all the messy code just a sacrifice for an amazing My Little Pony fangame experience? My next blog post will be dedicated to actually reviewing the game as a game itself, and not just diving into all the problems with the code. Keep a lookout for the next post on my personal blog, it's gonna be a MESS!