Introduction

[00:00:00]
>> Kyle Simpson: Welcome to Digging Into Node. In the year of 2019, which is the year we're currently recording this, this is the ten-year anniversary of Node.js being released. I'm actually really excited about that. Because I was at the conference in Berlin in 2009, JSConf EU in Berlin in 2009, when a relatively unknown Ryan Dahl stood up and introduced this thing called Node to the world.

[00:00:28]
And we all lost our minds with excitement over, we could tell what a huge inflection point that was gonna mean for the future of JavaScript. And the last ten years have really shown just how monumental of a change that was, where JavaScript could very easily have begun to fade into some obscurity.

[00:00:49]
And it was just the right timing to reinvigorate a lot of excitement in JavaScript. And now you couldn't hardly find a production stack of any significant scale that doesn't at least in some way, shape, or form, include JavaScript, and often Node.js. Certainly all the big players seem to be using Node.js in one way or another, from the Netflixes of the world and Walmarts, to mid-level players.

[00:01:17]
It's probably even more popular with startups, because it's very low barrier to entry in terms of getting a platform up and going. So Node definitely, permanently re-wrote the future path of where JavaScript was, and that's an exciting thing. I wanna talk just a moment about framing what Node.js is about.

[00:01:40]
Because it means a lot of different things to a lot of different people. And anecdotally, to frame that, I wanna talk about what I was doing in late 2008 and early 2009, prior to Node coming out. I had been, at that point, a developer for about a decade, about ten years or so, eight or nine years, I guess something like that.

[00:02:02]
I'd been a programmer for a while, and had bounced around to a bunch of different tech stacks. But at that point, I was definitely like, I really like JavaScript. I wanna focus entirely on JavaScript. And so I was shifting my career away from doing things like PHP or .NET, to I just wanna write my code in JavaScript.

[00:02:21]
And at the time, I was still dealing with having to write back-end code in one of those languages for wherever I worked, but begrudgingly so. I would do the bare minimum on the server, and then try to bootstrap as much of it as I could in the client.

[00:02:39]
Give me an HTML file, give me a JavaScript file. And I remember actually saying literally that. I showed up at a job and they were a Grail's back-end, which is Groovy on Rails, which is this Java flavor variant or whatever. And I was supposed to build this very client front-end, embed-able widget thing for other people's websites.

[00:02:57]
Didn't need to do anything with the server. And I said to the tech lead on my literal first day at work, I was like, all right, I'm ready to go. I know how to write this. I need an empty HTML file and an empty JavaScript file. Put it somewhere on the server, tell me where it's at, and I'll take it from here.

[00:03:14]
And he paused awkwardly for several moments, and then he picked up this giant book called, I don't know, the Grails Bible or something. I don't know what it was called, but some big, giant book on Grails. And he said you're gonna need to read chapters four through six of this book to figure out how to set up all the routes and stuff, so that you can get an HTML and JavaScript file on our server.

[00:03:38]
And I had that sorta metaphorical jaw drop moment, like you've gotta be kidding me. I'm doing all front-end stuff, and yet I've gotta work with the back-end? How ridiculous is this premise? And so I didn't read that book. [LAUGH] I asked a co-worker to make me the two empty files.

[00:03:59]
[LAUGH] Because I didn't really wanna spend my mental energy focusing on something like Grails. Not to say anything bad about Grails, but that's not where I wanted to be. I wanted to play in the space of JavaScript. And so I share this story because that's really what started me curious about, well, how could I do all of my code in JavaScript?

[00:04:24]
What's wrong with this picture where I have to go learn some other platform entirely, some other language entirely, just so I can do some stuff with JavaScript? And I started thinking about code architecture, and I reflected back upon a lot of jobs that I'd had. I'd worked at jobs that WordPress was the platform, if you can believe it.

[00:04:44]
And I worked at jobs where .NET was the platform, and Python with Django was the platform. And I saw something interesting, consistent across all of those, which was almost a contempt for everything front-end from the people that built the back-end systems. That they sorta considered anything HTML, CSS, or JavaScript to be as impure and dirty as possible, and so we want to abstract it as far as possible.

[00:05:15]
It's kinda the Java serverless approach to things, like I wanna write Java and have somebody generate all of that code for me. I don't ever wanna see a line of JavaScript, or HTML, or CSS. And I saw that consistently across a lot of platforms. And what occurred to me as I was reflecting upon this, and frustrated with the constraints of the particular one I was at, at the time, which was Grails, what frustrated me was, why is it that there are so many things that are related to the front-end, but they're buried deep down inside the guts of a back-end?

[00:05:51]
And a front-end developer can't touch them without going into all of this ridiculousness. Why isn't the stuff that relates to the front-end adjacent to the front-end? Why isn't it nearer to the front-end? And in fact, why isn't it using Web-friendly technologies? Why is it that we're building these systems that are very stratified, where 90% of everything that needs to get done happens in this back-end, and the back-end choice entirely determines what you can do in the front-end?

[00:06:21]
I had a job, remember I said I had a job at a Python Django shop one time. And I remember building this front-end piece. And we had this page, it was an admin portal page where there were a bunch of settings, a bunch of check boxes. And I remember wanting to submit, in a form submit, wanting to submit all of those check boxes, or maybe they were radio buttons or something.

[00:06:45]
I think that maybe they were radio buttons, but radio buttons or check boxes, submit a bunch of these things. And if you know much about how you can do that in forms, you can actually submit it as an array of values, an array of true falses from HTML post.

[00:06:58]
And that's obviously the most natural thing. Embrace what the HTML does, just doing a form post and post these things. Well, no, no, no, that's not gonna work. Because our Python Django routing thing, it doesn't know how to handle arrays of values. So I had to go do all of this ridiculous extra work on the front-end to generate actual unique names for every single one of those elements.

[00:07:25]
So that everything that came through to the server was uniquely named, so that their routing system could handle it or whatever. It's that kinda nonsense. Why do we bastardize what we're doing on the front-end because of some constraints on the back-end? This never made any sense to me.

[00:07:39]
And so what I began to formulate were these thoughts like, we need something in between these two.