[0:00] It's 2009. You're at a Hannah Montana
[0:02] movie and your phone won't stop buzzing
[0:04] with notifications from a new dating app
[0:05] you just downloaded. Your favorite
[0:07] artist is supposed to be releasing a new
[0:09] album next year. Your favorite TV show
[0:11] is currently being made into a movie and
[0:13] you're still riding high from arguing
[0:14] how many days are in a week on the
[0:16] bodybuilding.com forums. Life is good,
[0:18] at least on the weekends, because during
[0:20] the week you have to spend all day using
[0:22] the worst programming language ever
[0:23] invented, a language that was famously
[0:25] designed in 10 days. But after using it,
[0:28] it had you wondering what Brendan did
[0:29] after day two. A language that every
[0:31] browser interpreted differently, had no
[0:33] standard library, modules, or classes.
[0:36] And if your primary job was to write it,
[0:37] I'm told you were a massive loser who
[0:39] didn't deserve to feel loved. At least
[0:41] that's how things were in 2009. But over
[0:43] the next decade, that sentiment changed.
[0:45] JavaScript went from being a language
[0:47] that you'd never touch directly without
[0:49] putting on a jQuery hazmat suit first to
[0:51] arguably the most popular programming
[0:53] language in the world. while JavaScript
[0:55] developers, despite all the stupid
[0:57] stickers on their MacBooks, went from
[0:58] being considered script kitties to real
[1:00] programmers with actual feelings and
[1:02] emotions. So, how exactly did this mass
[1:04] psychosis happen? There's a bunch of
[1:06] different reasons, but in my opinion, I
[1:08] think the most underrated was all led by
[1:10] a single person who has since been
[1:12] forgotten to time, Jeremy Ashkenus. In
[1:15] 2009, Jeremy was a developer at Document
[1:17] Cloud, where he had the unfortunate task
[1:19] of working on a heavy clientside
[1:21] JavaScript application, which was rare
[1:23] at that time. Having a background in
[1:25] Ruby, but being forced to write
[1:26] JavaScript, I assume every morning he'd
[1:28] wake up and think to himself, "Wow,
[1:30] today might be a good day to myself off
[1:32] theing Golden Gate Bridge." But unlike
[1:34] everyone else who had JavaScript
[1:36] Stockholm syndrome, Jeremy had the
[1:38] audacity to think he could fix it. And
[1:40] so he did. His first act was dealing
[1:42] with the fact that JavaScript had no
[1:44] standard library. Again, this was 2009.
[1:46] Although Firefox had shipped support for
[1:48] some array helper methods like map,
[1:50] reduce, and for each, Internet Explorer
[1:52] hadn't yet, which meant you couldn't use
[1:54] them unless you polyfilled them. So, to
[1:56] fix this, Jeremy released underscore.js,
[1:59] a utility belt library that contained
[2:01] about 60 helper functions that made it
[2:03] easier to work with arrays and objects.
[2:05] Now, I know that doesn't sound exciting
[2:07] today, but building for the web was so
[2:09] bad back then that underscore likely did
[2:11] save a few people from throwing
[2:12] themselves off theing Golden Gate
[2:14] Bridge. Underscore got so popular that
[2:16] many of its features were adopted into
[2:18] the JavaScript language itself, which
[2:20] eventually made it obsolete. But
[2:22] underscore was only Jeremy's first act.
[2:24] Next, he decided instead of augmenting
[2:26] fish head JavaScript with a new library,
[2:28] he'd have more freedom if he just
[2:30] created an entirely new language with
[2:32] large cannons. Again, I can't stress
[2:34] this enough. The JavaScript in 2009 was
[2:36] very different than it is today. There
[2:38] were no classes, so inheritance was done
[2:40] through a pattern where you'd manually
[2:42] attach properties to a hidden object
[2:44] called prototype that every function had
[2:46] access to. The only way to declare a
[2:48] variable had bizarre scoping rules that
[2:50] hoisted declarations to the top of a
[2:52] function whether you were aware of it or
[2:54] not. No one really understood or cared
[2:56] about the difference between the
[2:57] equality operator and the identity
[2:59] operator is so you'd have a bunch of
[3:01] type coercion happening without even
[3:03] realizing it. And to define even a
[3:04] simple function, you had to literally
[3:06] type out the word function every single
[3:08] time, which led to some pretty ugly
[3:10] code. But by building a new language
[3:12] that compiled a JavaScript, Jeremy could
[3:14] fix it without having to wait for the
[3:16] standards committee or browser vendors
[3:18] to do it themselves. And even better, he
[3:20] could leave JavaScript the bad parts in
[3:22] that musty room Brendan spent 10 days
[3:24] in. And for a while, Coffecript was
[3:26] huge. The father DHH adopted it almost
[3:28] overnight. And in 2011, it shipped as
[3:31] the default JavaScript prep-processor in
[3:33] Rails 3.1, meaning the front end for
[3:35] every new Rails app in the world was
[3:37] suddenly written in coffecript. A
[3:38] GitHub, Dropbox, and a long list of
[3:41] early 2010 startups adopted it. And for
[3:43] a few years, it was the default choice
[3:45] for anyone who took JavaScript
[3:46] seriously. Today, Coffecript is
[3:48] basically dead after its best features
[3:50] were absorbed into JavaScript itself.
[3:52] But every time your agent writes a
[3:54] class, arrow function, default
[3:56] parameters, a spread operator, does
[3:58] string interpolation or dstructures a
[4:00] value, you can thank coffecript. But
[4:02] Jeremy still wasn't done yet. By 2010,
[4:05] he had given JavaScript a standard
[4:06] library with underscore and a better
[4:08] syntax with coffecript. But there was
[4:10] still one massive problem left. There
[4:12] was no good way to actually structure a
[4:14] JavaScript application. If you wanted to
[4:16] build a large clientsideheavy app, you
[4:18] would still end up with thousands of
[4:20] lines of spaghetti where your data, DOM
[4:22] manipulation, and event handlers were
[4:24] all tangled together. So, in 2010,
[4:26] Jeremy released Backbone.js, a tiny
[4:29] library of less than 2,000 lines of code
[4:31] that gave JavaScript developers their
[4:33] first real taste of MVC on the front
[4:36] end. It introduced models for your data,
[4:38] collections for groups of models, views
[4:40] for rendering, and an event system that
[4:43] let everything stay in sync without the
[4:45] need to wire it up by hand. But for the
[4:47] first time, you could build a serious
[4:49] clientside app without it collapsing
[4:51] under its own weight. And with Jeremy's
[4:52] track record, it quickly caught on,
[4:54] powering the early versions of Trello,
[4:56] Airbnb, Hulu, Pinterest, and basically
[4:59] every other startup that needed a real
[5:01] front end between 2011 and 2014. If you
[5:04] were a JavaScript developer during that
[5:05] window, you almost certainly wrote
[5:07] Backbone and you probably thought it was
[5:09] the future. But as it turns out, it
[5:11] wasn't. Angular, Ember, and eventually
[5:13] React would make Backbone obsolete by
[5:16] taking its core ideas and pushing them
[5:18] further. But Backbone was the library
[5:19] that proved you could actually build
[5:21] clientsideheavy applications. It's easy
[5:23] to forget how bad JavaScript used to be,
[5:25] and even easier to forget the people who
[5:27] fixed it. But the modern web was built
[5:29] on top of ideas that Jeremy Ashken has
[5:31] pioneered, even if no one remembers him.
[5:34] But speaking of things you no longer
[5:35] have to build yourself, O is another one
[5:37] that thanks to Clerk, the sponsor of
[5:39] today's video, they just launched the
[5:41] Clerk CLI, which comes with commands
[5:43] that are even more powerful than the
[5:44] ones I saw at that human dog show. Just
[5:47] run Clerk andit in any directory, and
[5:49] it'll set up endto-end authentication
[5:51] for your entire project with custom
[5:53] middleware, O pages, and environment
[5:55] variables. It even detects if you're
[5:57] migrating from next off or off zero and
[5:59] walks you through the entire process.
[6:01] And since they know you're using agents
[6:03] to do all your dirty work, they also
[6:05] created clerk skills which ships
[6:07] framework specific patterns pinned to
[6:09] the CLI version. They see your coding
[6:10] agent knows exactly how to use it. And
[6:12] the clerk API command lets your agent
[6:15] hit the entire clerk backend API from
[6:17] the terminal without copy and pasting
[6:19] credentials. Try it out for free today
[6:21] at the link below or just run clerk init
[6:23] to get started. the thanks for watching
[6:25] and I will see you in the next one.