JavaScript: The Origin Story

So, you know how JavaScript can feel like a chaotic, constantly shifting landscape, and you're afraid its history is just a dry list of forgotten tech? It seems safer to just keep up with the latest framework, right? But what if understanding that past could unlock a deeper comprehension of the web today and make you a significantly better developer?
Imagine finally grasping why jQuery was a revolution, how Node.js changed everything, and the real problems today's frameworks are solving! This captivating talk takes you on that very journey. You’ll witness JavaScript's birth in a mere 10 days, navigate the fiery browser wars, see AJAX make web pages dynamic without reloads, and understand how Google's V8 engine gave JS the speed it needed to conquer the server-side. This isn't just a history lesson; it’s the essential context that transforms you from a coder into a truly informed engineer, ready to make smarter decisions.
Share this talk
Transcript
So quick disclaimer, JavaScript is 30 years old and this is a twenty minute talk. So I might've left a few things out, but if there's a bit of nostalgia that you wanna reminisce about, please come find me in the hallway. I'd love to chitchat about it. Anyways, that's not my talk. This is my talk. Okay.
The year is 1991. Everyone's wearing side ponytails, doing the MC Hammer dance. Fresh print season one is in full swing and the internet has just seen its very first webpage. And this is it. You can still visit it today. All right.
And it was written by a man named Tim Berners Lee, which if you haven't heard of him, he's the father of a few things you have heard of. Right? Namely, HTML, web browsers, URLs, HTTP, the world wide web. He's also a knight. So that's cool. Right? But while this page is academically, historically fascinating, let's be honest.
It's a little boring. And that's because the web was a little boring, at least compared to modern standards. Right? It didn't sing. It didn't dance. It was just static. And this is where our story begins. Alright? The story of JavaScript.
How did it go from a little toy language to one that would ultimately transform the face of the Internet? Dare I say world? Maybe not But, before I get into that I should probably introduce myself My name is Annie Sexton I work at fly.io as a developer advocate slash YouTube person, you know?
I worked at a lot of cloud companies I used to work at Heroku and then render and now fly.io This is what I do for a living It's a bunch of technical content and half of it is just me making faces for thumbnails
I also, moonlight as one of the producers for the amazing web developer game show, Leet Heat
Where developers have to quickly answer questions or else face the heat. AKA, I hand them a spicy chicken nugget. If you know Jason Langsdorf, I see over there. Jason Langsdorf, he does the web dev challenge that happened yesterday. This is his new show and it's hosted by none other than Mark Texan
Let's talk about web browsers So there weren't that many to begin with In fact the very first one was called World Wide Web written written by Timmy over here But the web wasn't widely utilized. Alright? It was mostly academics and researchers. Alright?
But then, in 1994, alright, a new browser came on the scene and it was named Netscape Navigator. Oh, this is gonna be a very nostalgic talk, y'all. And by the following year, it held 80% of the market share. Alright? Now Microsoft got a little jealous. Alright? And it said, I shall squash them.
And so the very next year, it came out with its own browser. And they called it Internet Explorer. Let's see if the sound works.
Oops.
Oops. There we go. Oh, no. There we go.
Your move, Netscape. Alright. Now remember, the web is still pretty static, right, at this point? But one day, our very static web would be visited by a magical blue fairy. A blue fairy whose name was Brendan Ike. Alright? Now Brendan started out his career started out his career Oh, no. Is it stop working?
I'll just do it this way. Started out his career in operating system development. Alright? And Netscape decided to poach him. Alright? And they went up to him and they're like, hey, Brendan, buddy, you wouldn't mind building us an entire programming language right before our next launch. And Brendan was like, no problem.
In fact, he was a big language, right? So he was like, Oh, can I base it on lisp? And his manager were like, no, Brendan, you cannot base it on lisp. JavaScript was almost lisp for you guys. Now, he did it. He built that new language for Netscape two point o.
And he did it in how many days? Shout it out. 10. Very good children. Now, in ten days, he wrote a little project called Mocha, but nobody liked that name. So they called it Live Script, but nobody liked that name. But there was another language that was very popular. It came out in the same year. Right?
And this is how we got the name JavaScript. It was literally just a marketing ploy, a decision that would, never come back to haunt us ever again. Right? Totally fine. Now, Internet Explorer got a little jealous by the success of Netscape two point zero. Alright? And it said, I went to JavaScript too, daddy.
So in 1996, Microsoft released IE three point o, which came with support for J script, which is just JavaScript by a different name. But there were slight differences. Alright? Enough so that developers had to write things one way for Netscape and another way for IE. Don't we love that? Yeah.
And this is around when we enter the era known as the browser wars. Alright? The browser wars. And this is when let's see if this is working. No, it's not. It's fine. I'll just switch to the other one. This is when Netscape and IE are duking it out for the soul of the Internet. Alright.
And this is a bit of a tangent, but one of my favorite anecdotes during this time is that during the launch of IE four point o, Microsoft decided to pull a prank on their favorite competitor. So they put a 10 foot tall IE logo on the lawn of the Netscape headquarters. Right?
Well, a few hours later, Netscape was like, alright, let's go. So they knock over the logo, vandalize it, put their own mascot on top, holding a poster that read Netscape seventy two, Microsoft eighteen, which is the relative market share of each browser. Booyah.
Now, so we got all these differences between the browsers, but then in 1997, JavaScript was submitted to ECMA international. And this is when our language becomes the standard known as ECMA script.
Now, in case this is not crystal clear to everyone in the audience, let me clarify that JavaScript is to Velcro, stick with me, as ECMAScript is to hook and loop. And that it's a trademark that no one remembers is a trademark. Sorry, Oracle, use it or lose it.
Now, there were, you know, ECMAScript did help ease some of the differences between these two versions of JavaScript. Right? But there were still plenty of differences. For one thing, they each had their own way of, accessing elements on the page. Right? In other words, there was no standard for accessing parts of the HTML document as objects. Alright?
Now, in 1998 though, right? DOM level one became an official w three c recommendation. Hooray standards. Right? Well, unfortunately, standards don't always get adopted right away. Alright. And there were still a lot of differences in our browser wars was still going on until we hit the end of the twentieth century.
And this is when it kind of comes to the end, by the way, there were two browser wars. I'm not even gonna cover the second one, but, we all know who won right by 02/2002 Internet Explorer held 90%, over 90% of the market share. Right? And here's the deal. Microsoft was really innovating during this time. Alright?
In fact, they were working on something that would change JavaScript and the Internet forever. So what you have to remember is that during this time, if you wanted to fetch new data from the server, that would cost you a whole new page refresh. But in 1998, right, Microsoft started developing the concept behind a XML HTTP requests. Alright?
And I say concept behind because the syntax was a little different, but the idea is the same. Right? It allows you to asynchronously fetch data without incurring a page reload. Right? Imagine that. Now in 02/2005, the web designer, Jesse James Garrett, gave us a name and he called it Ajax. Asynchronous, asynchronous JSON and web, and XML.
Of course, these days we mostly use JSON, but it's important to note that Ajax was the development pattern, not the technology itself. Right? The technology looked like this. All right? And during the early two thousands, we saw Ajax blow up. Right? This is the foundational practice upon which all single page applications are built. Right?
And of course, non multiple pages as well. But you can still write code like this today and it works. Right? If you wanna make a little get request, you can do this. But if you look at this code and you're like, yeah, I'd rather not, you wouldn't be alone.
Because it was during this time that we started to see a lot of new languages cropping up that aim to make writing JavaScript a little nicer. And the fairest one of all was named jQuery. Yes. JQuery. JQuery was jQuery was the query for JavaScript. Alright. It took one look at this and it said, oh, no.
We can do better. Right? Look at that. Delicious. Amazing. Right? And it wasn't just Ajax. Right? It was all sorts of things. JQuery aimed to make JavaScript fun to write. And honestly, honestly, I think they accomplished that. Now some of you might disagree with that, but I'm the one with the microphone.
So I cannot stress how much this little library changed the internet. All right? Even today, nearly 80% of websites still use jQuery. Right? Wanna know what, what percentage of websites use React? 4.7. Four point seven. Right? Now, the early odds were when, we saw a lot of single page applications really blow up.
But despite this innovation, JavaScript was still really considered like a toy language by serious developers. Right? And the reality is, it was kinda slow. Right? It was kinda slow. People were making all these complicated interactions and, pages were getting really bogged down. But then, in 02/2008, something huge came out. Right? Oh, sorry. Not that. No.
Not that either. No. Close enough. Google came out with the v eight JavaScript engine, which used just in time compilation. Alright? Just in time compilation, not only did it provide two full servings of vegetables, it also meant that JavaScript could be compiled to machine code at run time. Bananas. Right?
Now, how this actually works behind the scenes is beyond the scope of this conversation, but needless to say, it was fast. Alright? And later, other browsers would follow suit with their own engines that use just in time compilation. We had Spidermonkey for Firefox, JavaScript core for Safari. Right?
But I think the biggest impact that we saw V eight have is when Ryan Dahl used it to create a new JavaScript run time that ran outside of the browser. What? JavaScript on the back end? Who'd have thunk? All of a sudden JavaScript was a real programming language. Right?
So you could build full stack applications entirely with JavaScript, much to the chagrin of many people. And this idea was distilled by a quote that became known as Atwood's law. Raise your hand if you know this Atwood's law. Shout it out if you know the answer.
Atwood's law states that anything that can be written in JavaScript, nobody, will eventually be written in JavaScript. Very good. Yes. Alright. Now, while things were picking up steam on the back end, on the front end, things were getting a little messy.
Now, I love jQuery for what it did at the time, but I still have nightmares about some of the spaghetti code that I wrote back then. Alright. It was a little crazy. Right? But then, between, during the twenty tens, we saw a lot of new frameworks come out. Right? Not a lot of new build tools. Okay?
That really changed things. Okay? Some of this might be a little familiar. Alright? Now this is just my opinion, but I believe that the JavaScript community that the JavaScript community's reputation for being a little fickle about their technology started during this time. Alright?
But here's the deal, after dealing with the hot mess that was jQuery apps, frameworks like these were a godsend. Right? All of a sudden, things were more organized, more semantic. It was easier to manage state. Alright? And with this came other tools that helped facilitate this. Things like task runners. Who remembers these?
These could transpire your Sass to CSS. It could minify your your files, optimize images, provide linting, and concatenate your files. Now, concatenation has kind of fallen out of favor, don't you think? And there's a good reason for this. For one thing, it's not bundling. Right?
Back in the early days, you just had to hope and pray that you remembered to load your scripts in the right order. Right? Fun times. But then finally, we got standardized module systems. First, we got common JS that came with node and then later ES modules. It would take a little while for that to be standardized.
It wasn't until like 2017 that ES modules was fully supported in the browsers. But this is around when we start to see the rise in bundlers and Browserify was a big one, one of the big first ones.
And I'll be honest, I didn't realize that Browserify had a logo or that it was so Wingardium Leviosa, but it's cool. But Browserify was amazing. All of a sudden, you didn't have to worry about the order of your scripts. You had a bundler. And so it just took care of that for you. It was amazing. Right?
But Browserify was limited. It only did bundle it. Right? It didn't mess with your style sheets or your images or provide much performance optimization. All right? But then in 02/2014, something shifted. For one thing, Taylor Swift stopped pretending to be a country western singer.
Sorry, I realized I had stopped putting pop culture references in my slides so I had to throw something in there. But we got Webpack. Alright? Now I'll be honest, I don't love Webpack. But it's undeniable the impact that it had on the community. Right?
It, all of a sudden, could do everything that Browserify and Task Runners could do all in one neat little package. It could also do more. Right? It could do first of all, it could handle ES modules. That was cool. It could do tree shaking, code splitting, caching, hot module reloading, style sheet stuff. Right?
All in one neat little package. Alright? Now, this is where we gotta speed things up. Alright? Between 02/2015, '20 '20, a lot of things happened. And this is gonna start to look extremely familiar. All right. During this time, we got let const arrow functions, a single wait promises spread operators. He's a spread operator.
We got package managers, TypeScript, web assembly, Deno. That's a lot of things, But I think one of the most impactful things that we saw during this time was not a change to the language, was not a change to a framework, but a change in how developers began to approach architecture. And of course, I'm talking about serverless functions.
All right? JavaScript was the first language to be supported by serverless. All right. And for good reason, right? Node JS has relatively fast startup time. It's a lightweight run time, right? It's very widely utilized. Everyone knows JavaScript And it's event driven. Alright?
And I don't know that serverless as a trend would have had the success that it did had they chosen a different language to start with. Alright? And serverless made things much easier to get started on the back end for many developers. Now, am I saying you should use serverless? Maybe, maybe not. Not necessarily. Alright?
I happen to work for a company. We don't do serverless. But even fly.io was built on the shoulders of this architecture pattern. This architecture pattern that was heavily facilitated by JavaScript. Alright? You see, I promise this is not a pitch. Fly.io, we give you virtual machines, specifically Firecracker VMs. Alright?
Firecracker is a technology that Amazon created for Lambda. The reason functions can spin up and down so quickly is because they're using these lightweight virtual machines, these Firecracker virtual machines. And at Fly, we give you those VMs. Alright? So even we are not outside the scope of this influence. So the question remains, what's next?
Now listen, I'm a history nerd. I'm not a fortune teller. So the people you should really listen to for what's next are the the talks that follow mine. But obviously, we're gonna see a lot of new a lot of new changes to our favorite frameworks. TypeScript is becoming more widely accepted.
TypeScript whose greatest accomplishment is convincing JavaScript developers that dynamic typing sucks. And JavaScript is gonna start getting a lot of new things that lots of other programming languages have had for a while. Things like pipe operators and, two pools and things like that. Right? But, one library that just happened to stand out to me was transformer JS.
This is kind of interesting. It's by hugging face and it allows you to run machine learning models in the browser. No API calls, no server calls. You download the model, you run it in the browser. That's pretty cool. Now I'll be honest.
I'm a little skeptical that my mom's 20 year old laptop could run this, but still pretty interesting. Right? Something to look forward to.
As JavaScript has evolved and matured, so has its community. All right? And the heart of the JavaScript story has always been about empowering developers to do more and more. But I didn't write this talk because I'm just in love with JavaScript. All right?
When you understand the history of certain technology, you better understand the problems it was trying to solve. And this allows you to better evaluate modern tools for the problems you are trying to solve. Alright? Learning about programming history is not just an academic curiosity. Alright? It gives us the essential context that makes us better developers. Hit it.
That's my talk, y'all.
Ball me on Blue Sky.