The forgotten developer who saved JavaScript...

[00:00] It's 2009. You're at a Hannah Montana

[00:02] movie and your phone won't stop buzzing

[00:04] with notifications from a new dating app

[00:05] you just downloaded. Your favorite

[00:07] artist is supposed to be releasing a new

[00:09] album next year. Your favorite TV show

[00:11] is currently being made into a movie and

[00:13] you're still riding high from arguing

[00:14] how many days are in a week on the

[00:16] bodybuilding.com forums. Life is good,

[00:18] at least on the weekends, because during

[00:20] the week you have to spend all day using

[00:22] the worst programming language ever

[00:23] invented, a language that was famously

[00:25] designed in 10 days. But after using it,

[00:28] it had you wondering what Brendan did

[00:29] after day two. A language that every

[00:31] browser interpreted differently, had no

[00:33] standard library, modules, or classes.

[00:36] And if your primary job was to write it,

[00:37] I'm told you were a massive loser who

[00:39] didn't deserve to feel loved. At least

[00:41] that's how things were in 2009. But over

[00:43] the next decade, that sentiment changed.

[00:45] JavaScript went from being a language

[00:47] that you'd never touch directly without

[00:49] putting on a jQuery hazmat suit first to

[00:51] arguably the most popular programming

[00:53] language in the world. while JavaScript

[00:55] developers, despite all the stupid

[00:57] stickers on their MacBooks, went from

[00:58] being considered script kitties to real

[01:00] programmers with actual feelings and

[01:02] emotions. So, how exactly did this mass

[01:04] psychosis happen? There's a bunch of

[01:06] different reasons, but in my opinion, I

[01:08] think the most underrated was all led by

[01:10] a single person who has since been

[01:12] forgotten to time, Jeremy Ashkenus. In

[01:15] 2009, Jeremy was a developer at Document

[01:17] Cloud, where he had the unfortunate task

[01:19] of working on a heavy clientside

[01:21] JavaScript application, which was rare

[01:23] at that time. Having a background in

[01:25] Ruby, but being forced to write

[01:26] JavaScript, I assume every morning he'd

[01:28] wake up and think to himself, "Wow,

[01:30] today might be a good day to myself off

[01:32] theing Golden Gate Bridge." But unlike

[01:34] everyone else who had JavaScript

[01:36] Stockholm syndrome, Jeremy had the

[01:38] audacity to think he could fix it. And

[01:40] so he did. His first act was dealing

[01:42] with the fact that JavaScript had no

[01:44] standard library. Again, this was 2009.

[01:46] Although Firefox had shipped support for

[01:48] some array helper methods like map,

[01:50] reduce, and for each, Internet Explorer

[01:52] hadn't yet, which meant you couldn't use

[01:54] them unless you polyfilled them. So, to

[01:56] fix this, Jeremy released underscore.js,

[01:59] a utility belt library that contained

[02:01] about 60 helper functions that made it

[02:03] easier to work with arrays and objects.

[02:05] Now, I know that doesn't sound exciting

[02:07] today, but building for the web was so

[02:09] bad back then that underscore likely did

[02:11] save a few people from throwing

[02:12] themselves off theing Golden Gate

[02:14] Bridge. Underscore got so popular that

[02:16] many of its features were adopted into

[02:18] the JavaScript language itself, which

[02:20] eventually made it obsolete. But

[02:22] underscore was only Jeremy's first act.

[02:24] Next, he decided instead of augmenting

[02:26] fish head JavaScript with a new library,

[02:28] he'd have more freedom if he just

[02:30] created an entirely new language with

[02:32] large cannons. Again, I can't stress

[02:34] this enough. The JavaScript in 2009 was

[02:36] very different than it is today. There

[02:38] were no classes, so inheritance was done

[02:40] through a pattern where you'd manually

[02:42] attach properties to a hidden object

[02:44] called prototype that every function had

[02:46] access to. The only way to declare a

[02:48] variable had bizarre scoping rules that

[02:50] hoisted declarations to the top of a

[02:52] function whether you were aware of it or

[02:54] not. No one really understood or cared

[02:56] about the difference between the

[02:57] equality operator and the identity

[02:59] operator is so you'd have a bunch of

[03:01] type coercion happening without even

[03:03] realizing it. And to define even a

[03:04] simple function, you had to literally

[03:06] type out the word function every single

[03:08] time, which led to some pretty ugly

[03:10] code. But by building a new language

[03:12] that compiled a JavaScript, Jeremy could

[03:14] fix it without having to wait for the

[03:16] standards committee or browser vendors

[03:18] to do it themselves. And even better, he

[03:20] could leave JavaScript the bad parts in

[03:22] that musty room Brendan spent 10 days

[03:24] in. And for a while, Coffecript was

[03:26] huge. The father DHH adopted it almost

[03:28] overnight. And in 2011, it shipped as

[03:31] the default JavaScript prep-processor in

[03:33] Rails 3.1, meaning the front end for

[03:35] every new Rails app in the world was

[03:37] suddenly written in coffecript. A

[03:38] GitHub, Dropbox, and a long list of

[03:41] early 2010 startups adopted it. And for

[03:43] a few years, it was the default choice

[03:45] for anyone who took JavaScript

[03:46] seriously. Today, Coffecript is

[03:48] basically dead after its best features

[03:50] were absorbed into JavaScript itself.

[03:52] But every time your agent writes a

[03:54] class, arrow function, default

[03:56] parameters, a spread operator, does

[03:58] string interpolation or dstructures a

[04:00] value, you can thank coffecript. But

[04:02] Jeremy still wasn't done yet. By 2010,

[04:05] he had given JavaScript a standard

[04:06] library with underscore and a better

[04:08] syntax with coffecript. But there was

[04:10] still one massive problem left. There

[04:12] was no good way to actually structure a

[04:14] JavaScript application. If you wanted to

[04:16] build a large clientsideheavy app, you

[04:18] would still end up with thousands of

[04:20] lines of spaghetti where your data, DOM

[04:22] manipulation, and event handlers were

[04:24] all tangled together. So, in 2010,

[04:26] Jeremy released Backbone.js, a tiny

[04:29] library of less than 2,000 lines of code

[04:31] that gave JavaScript developers their

[04:33] first real taste of MVC on the front

[04:36] end. It introduced models for your data,

[04:38] collections for groups of models, views

[04:40] for rendering, and an event system that

[04:43] let everything stay in sync without the

[04:45] need to wire it up by hand. But for the

[04:47] first time, you could build a serious

[04:49] clientside app without it collapsing

[04:51] under its own weight. And with Jeremy's

[04:52] track record, it quickly caught on,

[04:54] powering the early versions of Trello,

[04:56] Airbnb, Hulu, Pinterest, and basically

[04:59] every other startup that needed a real

[05:01] front end between 2011 and 2014. If you

[05:04] were a JavaScript developer during that

[05:05] window, you almost certainly wrote

[05:07] Backbone and you probably thought it was

[05:09] the future. But as it turns out, it

[05:11] wasn't. Angular, Ember, and eventually

[05:13] React would make Backbone obsolete by

[05:16] taking its core ideas and pushing them

[05:18] further. But Backbone was the library

[05:19] that proved you could actually build

[05:21] clientsideheavy applications. It's easy

[05:23] to forget how bad JavaScript used to be,

[05:25] and even easier to forget the people who

[05:27] fixed it. But the modern web was built

[05:29] on top of ideas that Jeremy Ashken has

[05:31] pioneered, even if no one remembers him.

[05:34] But speaking of things you no longer

[05:35] have to build yourself, O is another one

[05:37] that thanks to Clerk, the sponsor of

[05:39] today's video, they just launched the

[05:41] Clerk CLI, which comes with commands

[05:43] that are even more powerful than the

[05:44] ones I saw at that human dog show. Just

[05:47] run Clerk andit in any directory, and

[05:49] it'll set up endto-end authentication

[05:51] for your entire project with custom

[05:53] middleware, O pages, and environment

[05:55] variables. It even detects if you're

[05:57] migrating from next off or off zero and

[05:59] walks you through the entire process.

[06:01] And since they know you're using agents

[06:03] to do all your dirty work, they also

[06:05] created clerk skills which ships

[06:07] framework specific patterns pinned to

[06:09] the CLI version. They see your coding

[06:10] agent knows exactly how to use it. And

[06:12] the clerk API command lets your agent

[06:15] hit the entire clerk backend API from

[06:17] the terminal without copy and pasting

[06:19] credentials. Try it out for free today

[06:21] at the link below or just run clerk init

[06:23] to get started. the thanks for watching

[06:25] and I will see you in the next one.