(upbeat music) - Thanks so much I appreciate it and thank you all for being here and thank you for braving that post-lunch coma that I know you're about to get into, to listen to some thoughts that I have. My second time here in Sydney and even better than the first visit that I got to, so I love the city, it's beautiful, thank you for having me.
Before I get into my talk I wanna use the privilege that I feel having this opportunity, having this stage, I wanna take just an opportunity for a brief moment to talk about, not about the talk topic or about the tech, but really about us, and about our industry and community. And this is something, if you've followed any of my talks over the last few years, this is something that has become a staple, because I believe more of us need to be talking about the fact that what we do, if you call yourself a developer, if that happens to be your job title, we often think of that as my job is to write code and instruct a computer, and we've built up around ourselves this insulation layer, or this attempt at an installation layer to convince ourselves that it's all about technology, and it's all about the best ideas, and best ideas win, and we use words like meritocracy to enshrine those ideas. And it's almost as if in that mentality that people don't matter, that it's only the tech, and it's only the ideas that matter, and I think that's complete bullshit.
Pardon my French.
I think that we've gotten that completely wrong to suggest that this is all about ideas and that people don't matter, I think it's completely backwards. I think actually the only thing that really matters at the end of the day is the people that make up what we do and that fundamentally our jobs is not to instruct a computer, but rather to cooperate and communicate with other human beings. I'll come back to that particular concept later in this talk but I just want you to take a look at the person to the left and to the right of you, you may know them, you may not, but I want you to think about wherever you're at in your career, even if that person is at the same point in their career, same point in their skills, same point in their journey, you did not take the same path to get there.
That person has more challenges than you did, you had challenges in other areas they didn't have, and I think the biggest missing skill that we have in being a good community and being a group of good people is our lack of ability to have empathy when somebody else's reality is so completely foreign to our own, that we can't even make a connection, but that's what empathy's about.
You're in a different reality than me but I still have to respect you.
So I just want to challenge you to think about that when you interact with people, that the pixels that you're seeing on the screen, there really is a person behind those pixels, and that is the most important thing.
So I just wanna leave you with that challenge to think about through the rest of this conference and throughout what I have to share with you. So let's get into the talk now.
This is an interesting quote from Alan Kay, if you don't know who Alan Kay is, one of the godfathers of what we do for a living so you should definitely check him out, but he says, the best way to predict the future is to invent it.
And I think a lot of people take that quote to mean that it is our responsibility to go do, do, do, to invent the future we wanna be doers of this thing and not just simply talking about it, predicting it. I have a slightly different take away from that and it's how I wanna frame our discussion.
I feel like this actually does a pretty good job of picking up from where our opening keynote this morning left us, it left us asking some questions.
This conference is called Web Directions and it left us asking some questions about the directions of the Web. And I think that's very important, John we he asked me to come and speak at this conference, he said I want you to talk about the directions around JavaScript and where they're headed and what that means.
And so that's our topic and this quote to me asks the question, what is our responsibility in the future direction of any given thing that we're talking about, and for us it will be JavaScript.
To get into that I actually am gonna talk to you about something, I'm gonna give you a brief history lesson, but this is not about JavaScript the way you might expect me to start, and by the way it's totally incomplete, but this a brief history lesson of American spaceflight. And I'm gonna give full credit to David Hasan, a former NASA engineer, he gave a talk at my son's elementary school and it inspired some of the thoughts I'll share in the next moment or two with you.
So he talked about the early history of American spaceflight and it starts out with the Mercury missions which were based on the Atlas rocket and he talks about the idea behind, we have this grand vision of where we wanna get to, which is we wanna be able to put anybody, anywhere in space, but that grand vision is not something that you can simply accomplish given a year, or two, or even five, or 10 years, you can't just simply jump from we don't know how to get into space to now we are masters of space.
What he talked about was actually they knew from the very beginning that it was gonna take a lot of incremental steps to get there.
And you notice here the rockets that they were talking about, that first rocket on the left there, that tiny little red thing at the very, very top, that's where the pilot of this mission flew and it was one person, and it wasn't really what we might envision from the movies as like a big space capsule where they got to move around, he was essentially bolted in place inside of this capsule, really couldn't move around, really couldn't do anything cos we didn't even know if a human could survive in space, and we didn't know if we could trust the human to do it. So the machine was gonna do most of it and that's where they started, and you see that they took some progressions and they made some improvements, but what's interesting about these missions is that each one of them was designed to test and figure out certain things they knew they would eventually need, not even in these missions, but while the Mercury missions were happening they were talking about the next mission already, which was the Gemini missions.
Those were based on a more advanced rocket, the Titan rockets and you notice that they made some significant changes and we would say improvements to the rocket design there, and Gemini by the way, that's Latin for twin, because the Gemini missions had two people in the pilot, and they weren't bolted in, they could actually get up and move just a little bit, there wasn't a lot of space but they could get up and move a little bit, and they had to be active participants in the spaceflight at this point, cos they realised through the Mercury missions, it's never gonna work for us to completely rely upon the computer, we need the human to be part of it, the pilot is an important component.
And they made all of these steps and so while they were working on Mercury they were already thinking about and planning Gemini, and they knew there were things that Gemini would need that they couldn't figure out in that particular project span, so they early on were doing experiments to figure those things out to use them in Gemini.
And Gemini, the missions were basically, okay now we know we can get to space but we need to stuff in space. We need to be able to get outside of the spacecraft, we need spacecrafts to be able to dock with each, things like that, something to leave the rocket and then come back, all that stuff, they had to figure out. We take it for granted now but they started literally from scratch.
And then we moved into the third phase of missions, the Apollo missions, those are the ones that are most famous you've heard of, you've seen the movie Apollo 13, and you've of the Apollo 9 mission, was famously when a man set foot on the Moon for the first time. So this was, okay now that we're pretty good with moving around in space and doing this spacecraft stuff, let's try to actually put somebody on the Moon. First we gotta get to the Moon, get around the Moon, get back safely, and then we gotta figure out how to get out of the spacecraft and land, and then get back to a rocket and then head home. So they had to figure all that stuff out and again, very, very, incremental, a lot of questions they had to go through, by the way Apollo, the name for Apollo comes because Apollo is the Greek God, he was flying across the sky in his chariot, and they guy who named Apollo thought that was a fitting vision for this sweeping vision of what we were doing, putting a man on the Moon. And what you notice is we really came quite a long way over that span of 10, 15 years or whatever, we came a long way in our advances in technology from those early primitive rockets, which by the way, quite literally are rocket science.
Most of us probably wouldn't be qualified to talk about, I certainly couldn't talk about, the psychics behind that, but we would call that the most primitive of spaceflight. And the we took steps into Gemini where we had spacecrafts that could dock and undock and people could do space walks and then we put somebody on the Moon.
By the way that's not Neil Armstrong, cos Neil Armstrong's the one who took all the pictures on the Moon, everybody thinks that's Neil, but it's actually Buzz, and you can see Neil Armstrong in the reflection on Buzz's visor.
So we put people on the Moon and the we got em back and they were safe, and we went through all of those missions, and the thing that I take away from this and what I credit David so aptly pointing out, is that to get to the Moon it quite literally took lots of baby steps. And he made the point that that really does play out in a whole lot of areas of technology evolution. And I think again it asks as a responsibility if we're going to part of the evolution of a piece of technology, we get these great ideas, these big visions, but are we principled enough to do what these engineers did and take very small baby steps, to plan sometimes a decade or more into the future.
I know a decade from now I'm gonna need to figure out how to make that thing plug into that thing, let's experiment with it now, that's a tremendous amount of discipline and I think we can learn some lessons from that.
So American spaceflight was all about baby steps, but you didn't come to hear about American spaceflight, you came to hear about JavaScript.
Some of you might know our fearless leader Brendan Eich, the creator of the JavaScript language, and he coined this, I think it was 2012, he coined this phrase always bet on JavaScript and this was a slide in one of his talks, and he goes through the history of how there were bets against the JavaScript language, you know it couldn't be useful, and then it couldn't be fast, and it couldn't be fixed, and it couldn't do multicore, and just points out that as you go through the history of JavaScript over now a little more than 22 years, every single one of those bets against JavaScript turned out to be a bad bet, cos it turned out that JavaScript won every single time, and he makes the case then that we should always be betting on JavaScript.
Now if you know anything at all about gambling, the history of how you're doing in gambling, while you would think if I'm on a hot run on the table, I should keep gambling right, so we have that romantic idea from Hollywood, but actually every single bet, and every single scenario that you're in is very much independent from the previous bet. If you've seen 15 blacks and then you put your money on black, you still only have a 50/50 chance of it being black or red, actually technically less cos the green, but you still basically have only a 50/50 chance and so the notion of always bet on JavaScript is a bit of a leap and that's really kind of what I wanna talk about. I don't wanna go back and look at all of those incremental baby steps that JavaScript took, and so that's what this talk is about, is that I do think you should keep on betting on JavaScript, maybe not such a bold statement as Brendan put of always bet on JavaScript, but I think you should keep on betting, I think it's a good bet and I wanna talk about why, but I also wanna talk about the responsibility and what that means, because the future of JavaScript is not as certain as you might assume.
So let's jump into that, to do so I'm gonna give you another brief history lesson, this is my journey into JavaScript, and your journey may have been similar in this journey, so along the way we may pick up some nostalgia from you.
I started first understanding that there was a thing such as the Web in the mid 90s, mid to late 90s, when I was in the middle of and finishing high school, and I remember at my high school we had Netscape 3 and then some of the computers in the school had been upgraded to Netscape 4, so it was kind of in that bridge between Netscape 3 and Netscape 4, and I also remember IE4 came out in that similar time frame and this is how I first started to experience the Web.
Some of you were maybe around at that time or some others of you have only heard stories of the golden days of what the Web was like. Now I wasn't really a developer cos I was still in high school, and I don't even know why, but I didn't even really think about when I just clicked on this link to go look at a thing, it didn't even occur to me, I was already a programmer, but it didn't occur to me like how that was happening, it almost seemed natural, like I didn't even wonder how I could make my own. It wasn't until a couple years later I got into college and I started asking more questions about things, and when I started asking questions about the Web, I did what I think many people have done, which is when I saw something cool on the web, I wanted to figure out how they did it, so I went to view source.
Now I would make the case that even though we sort of smile about it, there's a nostalgic attachment there, but this is one of the most critical, fundamental reasons for why the Web has won and why in particular JavaScript has won, because of our ability with our curiosity piqued, our ability to answer that question how did they do it.
When I was learning programming in 1991, there was no internet, there was barely not even something we knew as Windows at the time, and my parents had to go and buy these crappy old books from old bookstores, and I was 10, 11 years old and I didn't even know what I was doing, but that's how I was learning.
And this is leaps and bounds more advanced that you can see something and actually go and look at the source code and figure out how they did it.
I think view source is one of the most important inflexion points in the entire history of computing. The ability for us to see that, that it is not this closed off wall.
And I want you to hold on to that thought because we're gonna come back to that more than once through the rest of my remarks. Now I wanted to understand how people did fun stuff like put cursors around the mouse and make it follow it, and I was thinking about leaving this as the only rest of my slides because then you'll just be mesmerised like a cat following the laser.
But I wasn't doing something particular responsible with my time to figure out how you put a cursor on a mouse, but in the good old days of the Web that's what we wanted to figure out.
How did somebody make the snowflakes fall? How did you make the text scroll across or whatever and view source was how we did that. Now as I went along I got into some programming, I did some contracting work when I was late in high school and early in college and I wrote some old websites, and I went back to the web archive to find, this is my actual code from a website that I built for my uncle, and you notice this is some pretty awesome JavaScript that I wrote, in particular I love the completely unnecessary parentheses.
I have no idea why I thought those were important, but for some reason I did back in the day.
So this is like circa 2000ish when I was building my first websites, I'd already done programming but now, I'm gonna programme and I'm gonna do it on the Web. And I was trying to use JavaScript like a full-fledged programming language, using functions, and variables, and if statements, and loops and things like that. And another website from that same time period, another one of my favourite mistakes if you will, you'll notice that I've got a bunch of image arrays being mentioned up there at the top, this was basically an early precursor to an SPA, a single-page web application where the data was getting baked into the JavaScript and this was all inside of script tag in the markup, because I didn't understand the idea that you could request the data remotely, but then I had it all packed into a string and I split it up based on the semicolon, and I love this, I just evaled to figure out the variable name to use. I mean this is just terrible but this was a big step forward in my evolution to understanding what JavaScript was about, I'm sure I saw somebody do that on a website and I learned that trick.
And as I went through in my career, so now we're advanced to kind of 2004, 2006, one of the projects I got to work on, I was very fortunate I got to help build this website for a regional airline in the United States called Southwest Airlines, I got to build the homepage, I was the lead engineer, and a few others were working on this, and just a little piece of trivia, this was like 2006, we working on it for about three weeks, the re-design, you notice we have this calendar widget here, this is YUI calender, this is my first exposure to a JavaScript framework and a JavaScript library YUI, and we didn't really even understand how to make it work, but I was already having to hack the code because we didn't want the year to show a certain way or something, we were hacking this code, right before we launched, right before Christmas they came back and said, oh by the way this whole webpage has to work in Netscape 4. What? Like you didn't put that in the requirements document, we're already way advanced into like Netscape 6 at this point, and you're talking about Netscape 4, we literally just had to end up hiding with conditional comments whole swathes of this webpage to make it still work in Netscape 4.
But that was my experience, so I started hacking around on other people's code and then I took a bit of a diversion because I got real excited about how cool you could do stuff if you cheated with Flash, and I built Flash websites for a while and this was a grocery store chain in my part of the country and I got to build their kid's website, with all these games and stuff like that.
This website still exists but I can't view it because I've long since banned Flash from my computer. I had to back to an old emulator just to get this screenshot.
But actually as it turns out I wasn't as much cheating as you'd think because writing the ActionScript, in this case ActionScript 3 for this website was really just an application of writing the JavaScript, more on that in a bit, and then as I progressed to learn more about JavaScript it really kind of came down to the dollar signs, but I don't mean the money, I mean of course jQuery.
jQuery started taking over the world and I just like everybody else got really curious not about what I could do with jQuery but how on earth jQuery even worked. So I view source on the jQuery library and started looking at stuff and I didn't even know that dollar sign could be a variable name.
Like I thought it was some special syntax that I'd never heard of before, but I figured out how they did it, and I was like, wow how are they able to remember this and keep a method coming back, and remembering and I learned about this context, and I learned about closure, all of these things that I was already a CS graduate, I should have known but I didn't know any of that stuff, and I was learning it by the process, these small little baby steps, reading other peoples' code, again, that's why I think view source was so important. And then I started saying, now that I have this new found knowledge of JavaScript I can do some really important stuff.
The very first Open-source project I did in 2008 was a Cross Domain Ajax utility that used an invisible Flash file, because Flash could make cross domain requests and JavaScript couldn't, and it was called flXHR. It was Flash-based XHR and I built this library and it emulated the XHR interface exactly down to the properties and all of this stuff, and I figured out how to do that, there was a tiny bit of Flash, but actually the most important work was how to write a JavaScript library, so flXHR.
You'll notice that one of the things that flXHR had to do was manage script resources, it turned out that that inspired my whole next set of coding, because the library that I wrote that most people who knew me from, was LABjs, which is a dynamic script loader utility.
It still exists, it's actually not dead and is in a current long-running rewrite to a version 3. But LABjs was a script loader that I wrote and it was all about managing script resources.
So I like to think that I learned some things along the way in flXHR that helped me write LABjs. And I hope that maybe there's somebody out there that at some point read some of my code and learned from me in the way that I read so many other peoples' code and learned.
And this has been part of my journey, but I could only get so far by reading other peoples' code, and at some point I just couldn't figure out what they were doing so I started trying to figure out how to really learn JavaScript.
We didn't have degrees that you could go get in JavaScript. You couldn't take a college course in it, but I wanted to read, and you've probably seen this famous picture, and the joke here is the difference between JavaScript Complete and JavaScript: The Good Parts means there's a whole bunch of bad parts, that's the joke that we like to make about JavaScript. That always kind of bothered me by the way, just that joke, it's very demeaning to this language. But what's interesting about this picture, again I have a different takeaway, what's interesting about this picture is that it does sort of point out the gap, not the gap in size really, but the gap in approach, cos when I look at this I kinda look at it as the difference between learning about a topic by going and reading it in an encyclopaedia, versus reading about a topic in CliffsNotes. Now if you read the CliffsNotes for the novel Great Expectations, you're gonna get the high points, you're gonna get the major plot elements, the character names and things like that but you could not in any way, shape, or form pass yourself off as I know that story.
I've read that book. I'm a master of the topic. You couldn't go take a college exam on it having only read the CliffsNotes.
Similarly though, you couldn't go and just effectively learn by reading the whole encyclopaedia.
So there is a huge gap in learning resources, the gap between those, so along the way at some point, I was getting asked questions like, how do you know so much about JavaScript, how have you learned, and have you ever written any of this stuff down. And I thought maybe I will, so I wrote a book series called You Don't Know JS, you can read the entire 1100 page six book series on GitHub for free, because I put all my writing up there, you obviously can also buy them, they've been published. But essentially I fixed that gap.
Because this is not about documenting every nook and cranny, although we do get into all the gaps, it's about trying to give you an opinionated guide on how to learn. So somewhere along the way the lesson that I had figured out was the best way for me to keep learning was to start teaching other people.
And I hope that you take that away, if you don't listen to anything else I say, I hope you take that away. But if you want to learn something, figure out how to teach others, whether that's a blog post, or a book, or a conference talk, whatever you do, teach others.
So my journey was composed of lots of baby steps. Now the stuff that you probably care about, let's look at how JavaScript got here.
And this totally not a history lesson because I'm gonna skip over a whole bunch of stuff, but let's talk about where the JavaScript language came from.
In the earliest days of JavaScript, and by the way in preparation for this talk I go to do some very interesting JavaScript archaeology. This is actual code that somewhere around the year 1996 was deployed on the web and running in a browser and so it worked, so we can assume that JavaScript was at least as capable in its early days, this is pre-standardization of the language. We just had this thing that was shipped in Netscape being copied very imperfectly by the IE folks, this was code that was running in a webpage some time in mid 1996, so that was script early. We got the first standardisation of JavaScript in the form of ES1 and then very shortly after ES2, that version of the language, it had progressed in terms of it's capability, so now we actually had a full prototype system, prior to that the prototype system was pretty dodgy, but now we could actually use prototypes and inherit properties and things like that. So we're standardised and we're like in 1997, 1998 when these things are happening.
And then we got the first full-blown specification where it added a bunch of stuff in ES3, and I put many of the things that were added in ES3, you might be surprised that these things weren't there for the first four years of JavaScript's history. I was blown away, we didn't we have try catch. We didn't have function closure, you couldn't do a function inside of another function, you couldn't do regular expressions, there were a whole bunch of things like switch statements and do while loops, and stuff that did not exist in JavaScript til about 1999 with the advent of ES3.
And then we started talking about the next version of the language and they had a huge change set in mind for ES4, they had a whole bunch of stuff they wanted and there was a bunch of drama that I don't even care to get into, but essentially over a period of about 18 months, ES4 which by the way is ActionScript 3. If you've ever written any Flash ActionScript 3 was an implementation of an early version of that spec, but essentially it just completely died.
There is no such thing as ES4, it was a thought, it was a plan, it died, and Adobe Flash they kept hanging on to it as if it was gonna come back some day but it never did, that's not the direction they wanted to take JavaScript, so around the same time, a lot of people think this is related but it's not, around the same time we had this thing called E4X, which you might see as somewhat similar to some stuff that we've recently invented, JSX you might recognise, XHTML inside of the JavaScript code and then this crazy syntax for how we could essentially almost XPath like querying of DOM elements from those elements. So this was called E4X it was advanced around the same period and it also completely died. That's why that's not a thing.
It completely died, it was actually not a great idea, there were a lot of problems with it, but early ideas do need to get explored so it's not a bad thing that we explored it, it's a good thing that that one didn't work, there were mistakes in the space programme, and some rockets didn't make it, some designs for engines didn't make it.
Any fans of the game Oregon Trail out there, anybody remember Oregon Trail? We basically say, if we wanted to summarise this ES4 and E4X died of dysentery, that's their history. So ES5 came along another decade later from ES3 in 1999 til 2009, it took a long time, to come up with our compromise, the much smaller change set. We notably got very important things like strict mode, getters and setters, not that important, we got better systems like Object.create, so all of these things got added but it was a very small change set relative to when ES4 was gonna happen.
And then we progress another five years into ES6. This is circa 2013, 2014, that they're starting to talk about ES6 seriously, it would land in 2015, which is why a lot of people think it's proper to call it, ES2015, because that's the year that it landed in. We got a whole bunch of stuff like iterators and generators, and we got promises, and we got default parameters, and de-structuring, and spread, and rest operator, a whole bunch of other things that I don't have enough space on the slides to show.
ES6 was a whole change set to the language, but all of those things were things they were working on way back in ES4, and even though ES4 didn't work, we used a lot of that learning, those baby steps were important.
And then, by the way it's not ES2015, if you call it that you're just being pedantic, everybody that knows anything and anybody that wrote a book with the word ES6 in the title knows it's still called ES6, I don't care what TC39 says, but after that, it's called ES2016 because that's the year that each one of these revisions come out.
So if you like to call this ES7, you're also a bad person because it's not ES7, it is ES2016.
But in ES2016 we had this massive change set of two tiny, little features, one which was the double star, the exponentiation operator, and one was the really helpful array includes.
So it was almost like this hangover, like we'd done so much in ES6, we didn't have any energy leftover, ES2016 was just like let's through a couple things out there and call it a day. So that was 2016, and then of course 2017 rolls around, we've got comparatively speaking another very useful set of features that we wanna add in, biggest one that probably many of you have heard of is async function. So we got async functions officially added to the language back earlier this year, in 2017, and we got object entries, and we got a few other things like that.
One of my favourite features that we got, you'll notice if you look at the function signature, I've got a trailing comma in the function signature, and if you look at the function call line 15, another trailing comma, we finally have symmetric trailing commas, we had em in object literals and arrays but now you can do it in functions.
That's a huge feature and I'm obviously being sarcastic. It's helpful for GitHub diffs and things like that. So those are the features that landed earlier this year and we'll talk in just a little bit about some stuff that's coming.
So blah, blah, blah, more baby steps.
There's a talk that I was super privileged in Fronteers Conference in Amsterdam 2014 to hear from Petro Salema, this talk is called Dream Big. Think Small.
And I strongly recommend that you go and watch this talk, it was one of the most inspiring talks I've been to and I very much appreciate his courage to go out and talk about this, but the point that he makes without stealing the thunder and I want you to watch this talk, but the point that he basically makes is all the big ideas that have ever happened actually happened because somebody took something really small and incrementally improved it a whole bunch to make a big thing.
That nobody went out and just completely invented a big thing totally out of thin air.
There's lots of saying that we have in common parlance to describe this, but when somebody says for example, I've just stood on the shoulders of giants. What we mean by this is the context of where we've been is immensely important to where we're headed in the future. And that a lot of that context happens in these small, little steps, so I would just make the case then that from these observations the best kind of progress that ever happens is the progress that's incremental. That trying to go do some huge, big new thing completely out of thin air misses out on the importance of the incremental steps and the incremental learning that occurs; and I think that's a part of our DNA, that's part of the DNA of our industry and we should embrace that and recognise that, be conscious of that and be intentional about that.
So the question that I then basically wanna pose as we move into a discussion of where these things might have gone, is where are the best places to place our bets? What are the things that are gonna happen that are place our bets? And I wanna look at some bets that were made that didn't work some well and some bets that were made that did work so well.
I'll start with some risky bets that turned out in the long run not to pay off so well, you'll notice that in all of these cases, the bet was the future of the Web is going to be oriented around sandboxes.
We need to protect the Web.
We need to have consistency on the Web and the Web is not known for that and wasn't for a long time. So the way to solve that problem is just put a big old iron box around it, whether it be the Flash ironbox, or Adobe AIR, Java, Silverlight, ActiveX, any of those are basically approaches to say we can't really trust the Web natively, we need to create this other special context for interactivity on the web to occur. And I'm gonna throw something on to this slide but maybe is slightly controversial, but I'm also gonna say this was a bad bet, the bet that the future of the Web was gonna be about App stores, and about Apps that we download hundreds of megabytes and instal. I think that it certainly paid off in the short run and a lot of people made a lot of money off of it, but I think when we look back 20 years from now we're gonna say that was a bad bet, to bet that the future of the Web is about these closed off systems. It turns out that if we look through human history, the closed off systems win early on, but in the long run they don't win.
So that maybe wasn't such a great bet.
Some good bets that have been made that turned out to pay off, obviously JavaScript I think has been a pretty good success story at this point, but also HTML5, and CSS3, and we bring those together, the love-child of all those three, Progressive Web Apps.
These are a huge bet that the future of the Web is all about this technology and being open. And I think those have been good bets so far, I think they'll continue to be good bets.
I don't think we're gonna look back and say man, that whole JavaScript thing we did, that didn't work out. It is the most ubiquitous language in the history of computing and it's only gonna get more so. And I don't think Brendan Eich could have possibly imagined when he created it in 10 days so long ago that it would be in robots, and light bulbs, and other things like that, but it is, and it's only get more so, those bets are paying off. The International Space Station is an interesting story because we had lots of advancement in technology in the American spaceflight programme, we had lots of advancement in the Russian and other countries as well, but primarily the Americans and the Russians had lots of parallel advancements but at some point, somebody was like, you know what, to really go the next step we're gonna have to work together.
We're gonna have to agree on the sizing of the screws, and the pipes, and tubes, and all that other stuff so we can come together to build this space station and famously they were able to do so and this is actually an International Space Station flying around above us that's been used for much more than a decade, almost two decades now.
So the International Space Station is a famous success story of the benefit of open collaboration. In other words those closed off silos fell away and the open collaboration is the thing that in the long run won.
And I would say open collaboration is a good bet. So if you're keeping a running track here, incremental progress and open collaboration. Now we've come to the point, literally in the talk but also in the history of the technology evolution that there's a fork in the road.
Because the future is not so linear as we may have, we like to look back with perfect 20/20 vision and tell a narrative that's very linear, the people that lived it would say no, no, no, it wasn't linear but it looks linear to us, but I can say we're at a big fork in the road. If you think about the spaceflight programme we have a big fork because we have what the governments of the world are trying to build for spaceflight, and then we have what private corporations are trying to build as the future of spaceflight.
And I'm not making any comments about whether or not either one of these is right or wrong, but there are some very significant different directions that this may play out, and I think we should be more aware of those directions, because the direction you take obviously is going to relate to the destination you some day arrive at.
But again we're not talking about space we're talking about the JavaScript language.
So, what are some of the differences that are happening in JavaScript over the last few years and are gonna keep happening more.
And I would say that JavaScript has started to fork into two different identities, not new, and this isn't my new idea, Brendan Eich's been talking about this for a while, but we have the JavaScript that's about the language, and the JavaScript that's really about the machine and they are starting to diverge a little bit. And I think we should be a lot more aware of those divergences and about what that means, and somewhere along the way he's just peeking out, like watching as this stuff plays out.
He's working on a new web browser now, but he still pays attention to his creation from so many years ago. So it's as if there are these two galaxies that are far off in the distance and we want to race in a rocket ship in that general direction, and if we had two different rocket ships here that both were headed in that general direction, for a long period of time it would look as if they were on exactly the same trajectory.
But their end destination if we got there is hundreds and hundreds of millions light years different. But from so far away, the small little steps that we look like we're gonna be taking now, look like we're on the same path, so for a long time the stuff that's been happening to JavaScript has looked like we're gonna end up in the same future with JavaScript and I would argue that the divergence is becoming much more pronounced, and some day they're gonna be galaxies apart. And that is gonna have profound impacts, not just on us as technologists but on the future generations that wanna come along and participate in this magical thing that we do, because their path to getting into JavaScript will be very different than my path was, because of the future that we're writing out. So incremental and open did work for a really long time but are they gonna continue to be the good bet? Did we need to have some kind of bigger vision about the end result that we're offering? Let's talk briefly about JavaScript the language, some of the things that are gonna happen, and I just wanna say that JavaScript the language, as I said earlier in my intro, JavaScript the language, and any programming language should be fundamentally about communication.
Now I've done you the favour of giving you much more effective means of communication for this statement by removing all the unnecessary vowels and white space, and all that stuff so I just got it across as efficiently as possible, your brain had to parse fewer characters, and you all knew that what I was saying is that code is human communication.
Right, because communication is all about efficiency, which is total nonsense, cos that's not how the brain works. Actually if we wanna embrace the idea that code is communication and that we need to communicate our ideas with each other, we have to have some very different ideas about the way we write code, than what I see us doing today, we spend so much effort trying to optimise how quickly we can write code and we don't even ask ourselves, wait a minute why does research tell us we spend 70% of our time reading code? If we spend that much time reading, why do we optimise the writing of it? JavaScript really has become a true embodiment of this notion of lingua franca, the common language among which lots of other different constituencies can use to inter-operate, to communicate, JavaScript has become that lingua franca.
There are lots of time where somebody's working over in this camp and they say let me just express those ideas in JavaScript so that somebody from a very different camp, can speak that language more easily. It has become absolutely a means of human communication and will only get more so. I think one of the reasons for that is that JavaScript was one of the first, not the only, but one of the first to really, truly embrace the idea of multi-paradigm. Not that you could do a functional programme, or you could do an object-oriented programme, or you could a procedural-structural programme, but that you could do all three in the same programme. Now some people say that leads to a mess of code, but I think that's one of the beauties of JavaScript, it certainly the reason why, even though I went through a normal CS degree, JavaScript's the one I got fascinated by because I think the flexibility that it gives us to express in a different part of the same programme, an idea in a more natural way, I think that's important to the DNA of JavaScript, it's the thing I appreciate the most. Sometimes I hear early leaders in the language go back and lament and I wish I hadn't done that, I wish I hadn't made those decisions, and I think to myself, man how different this future that we're in would be, if that hadn't been the case for me I for sure would not have picked up and become so excited about JavaScript, if that was not the case.
Another thing that's happening and definitely more recently is that JavaScript is maturing in the effort to be more declarative, and declarative is a powerful notion about code readability; imperative code, the kind that most of us write most of the time focuses on how to do something but declarative code rather is about the outcome.
You can glance at a piece of code and know exactly what the outcome is and not have to execute it in your head to figure out that outcome, that's an important characteristic for readability and a lot of things that JavaScript has been adding, especially in ES6 have been about being a more declarative language. Another thing that I think is a bit controversial because to be honest with you I have strong negative opinions about this, but I cannot deny the fact that where JavaScript has been and I think where JavaScript will go into the future, part of that language success is about the fact that we've always embraced this notion of compatibility, there's a very strong romantic notion within JavaScript that code that was written on day 10 should still be working even if it ran today. Now that's not exactly true, but it's like 99.9999% true, because every time we improve JavaScript, we don't break all the old stuff, and there's an important reason for that that I think many of us don't recognise, because it would be much more convenient for us as developers, I would love it if we would break with the past and fix all the old bugs and a lot of us would, it would make my job as a teacher a whole lot easier, because I teach JavaScript and I have to teach all the weird quirks and explain them, it would be great if we could get rid of it, but the people that would be hurt the most are the users of the Web, and there is a guiding principle to the Web platform, if you haven't read it, the principle of constituency says, wherever possible consider the concerns of the user great the concerns of the author, aka, developers.
The user is the most important and we should not rush to try to make a change, take a course trajectory and fly to a different galaxy because it's more convenient for us and not realise what that's gonna do for users. So a big part of the reason why JavaScript continues to succeed and be bet on so much is because people know it's a bet that will last a long time. JavaScript has also been made fun of a lot and complained about a lot and a lot of these complains, that it's slow, it's a sloppy design for a language, it's buggy, it's inconsistent; a lot of these complaints are misguided. There are some slowness, and sloppiness, and bugginess, and inconsistency inherent to the web platform but actually most of that is not about JavaScript the language, a lot of it's about the DOM APIs, and all that other stuff, that looks like JavaScript but isn't JavaScript. As a language JavaScript has definitively matured and it has addressed almost all of those concerns. The spec itself has undergone tremendous re-writing to make sure that every implementer knows exactly how the language should be implemented and they're guided by that principle of one JavaScript. It's always gonna be this way.
So I think those are important parts of how JavaScript the language will continue to evolve, has evolved and will continue.
Now let's talk about some things that are coming soon to a JavaScript near you, well probably, maybe, obviously these are proposals, but these are some things that are coming down the pipe.
So, those of you that love the class keyword, you might be excited to know that we're gonna finally get, class fields, aka class properties, so that variable I've declared there on line two, it's added to every instance, I don't have to put this dot inside of a constructor to assign it, it's just automatically done for me.
So class fields are amazing because we wanna be more declarative with our code, and I agree it's more declarative to write it that way than to write it imperatively inside of a constructor.
Also people want privacy inside of their structure so they can get true encapsulation with these class. By the way we've had encapsulation for like 17, 18 years since closure came around, you can do encapsulation with closure in the module pattern, but we're excited about classes and we wanted encapsulation in classes so now we have private fields.
That counter with that special hash symbol in front of it, that's gonna stay private to every class instance, it all can be accessed inside of the methods of that class definition and not on the outside. Whether or not you use the has symbol on line 13 you're not going to be able to access that internal private variable.
So we're growing the capabilities to make class, for those who really appreciate classes and think that it's a useful way to structure their code, it's growing and maturing in ways that are very important to the future of the language.
Private methods, same kind of notion as a private field, now we can declare methods that are totally private. They're not accessible from the outside wall. This one I'm actually really excited about cos you probably know about async functions, you may know a little bit about generators, we put the two of them together to get the best of both worlds in async generators. I'm not gonna get into all the nuances of this but an async generator is both able to do an await, line three, and a yield line five, and that's important because we're preserving the push pull semantic of asynchronous programming, instead of muddying those waters.
So that's stuff that's coming down the pike. Async iteration comes directly from that; if you have an asynchronous generator you can for await loop, now that's now exactly what you might think, you might think that it's waiting on each value, it's actually each iteration is producing a promise for the future iteration result, so it's really a little bit more like this imperative version of the code, very much more clean and straightforward for await loops. Optional catch, how many of you have ever written a catch clause that was empty like that and been annoyed by having to put unnecessary, verbose clutter. That's going away, we're gonna have the ability to drop off catch clauses that we don't need anymore. We're getting a whole bunch of new features and regular expressions, like look behinds, positive and negative look behinds, named capturing groups, and a half a dozen other features.
So regular expressions are finally gonna join the 21st Century in JavaScript.
We're getting readable numbers, the ability to put the underscore separator in a numeric literal so that you can read it, so that you know that this is the number one billion instead of having to count the numbers out. You can put that underscore in there.
And optional chaining, this goes by other names in other languages but instead of having to check, I know thank you very much I appreciate that, I agree completely, I'd give it a standing ovation. Instead of having to check each property along a property chain, the question mark dot operator there on line five it just automatically implies that check and it fails that with undefined if it doesn't have the sufficient property. So JavaScript's gone a long way.
From those early missions to put somebody in space to putting a rover on the surface of Mars, from that 10 day JavaScript to now, we've made a lot of progress as a language. And there's no reason to believe that that won't continue, I believe that absolutely will continue.
Now JavaScript the machine, JavaScript has become this platform almost, I hate that word, but it's become this platform almost.
And there are a number of increased demands that are driving us in that direction.
These demands are: it needs to be more performant, and we need to be able to write in other languages that aren't JavaScript, they don't look like JavaScript and still run them inside of the browser.
Now JavaScript's been growing a bunch of features which really quite frankly are not designed for you to ever write, they're designed for them to be the target of some system that compiles to it.
Some examples, for example, proxies, these are a cool feature and I like meta-programming, but I can't really envision any regular web developer writing their own proxy.
I feel like proxies are definitely gonna be relegated to the realm of framework authors or tool compilers. TypedArrays, unless you're really just nuanced into all the bit wise stuff and really need to squeeze out every microsecond, you're probably not gonna go to all extra trouble to do TypedArrays, you can do TypedArrays, but that's probably gonna be stuff that that code's written for you.
This is a big one, it was referred to in an earlier talk today, this notion of adding shared memory, a memory segment that can be shared across multiple threads of JavaScript is a huge deal, and they just sort of stuck into the language as a bullet point in ES2017. Shared memory was added and I'm like what? Now I feel like I can take credit for getting this in because I stood up on a stage a couple years back and said, JavaScript will never have parallelism, it doesn't make sense in the language, and as soon as you predict against it, it's sure to happen, so I'll take credit for that.
But as soon as we added shared memory now we start asking ourselves, how exactly are we gonna manage that? Because programmes that use shared memory and threads they know right off the bat, that's a terrible idea for the management of code, the management of race conditions and things like that, so you might think, well I can just listen for the sharedArray and see if this while loop, just wait until it gets to zero.
There's multiple problems with that.
First off the compilers gonna compile away that while loop because to the compiler that looks like an unnecessary while loop.
And secondly, you can't even think about operations like setting a value to zero as a single thing. If you're a parallel programmer in something like Java you know need atomic operations.
So we added atomics, you can't do that stuff but now you can do atomics store and atomics load out of these shared arrays, but atomic operations are not even good enough, we need a higher level, so we now have wait and wake, so you can actually implement semaphores and things of that nature, these are very low level APIs, none of you are gonna write this code, frameworks are gonna write this stuff for you, transpilers are gonna write this stuff, but now you'll be able to write a parallel programme in something language probably, and have it target the JavaScript runtime and run correctly.
And we know about the Babel tool, Babel of course allows us to take some really nice beautiful code like that and produce some amazing code like that.
But the point I'm trying to bring to you is that that code is not what people wanna read.
Remember the view source question? Nobody wants to read that transpiled code, that automatically generated code, it doesn't matter if it has good white space, people don't wanna read that stuff so we have source maps, source maps are the fix to this so you can have a source map that shows the original source code.
And there are some problems with source maps, for example, when there are stack traces they're not gonna work quite right cos it's different code that actually ran, and also watch expressions, that's an important debugging technique that doesn't work.
TypeScript, people love TypeScript, and I'm a big fan, I think TypeScript's great, I don't personally use it but if you have issues with typing and you don't like JavaScript's coercion system, TypeScript's a great set of things but it produces a whole bunch of code that's not actually even standard, TypeScript is not standard for like JavaScript is. Macros, another huge feature that we hope eventually comes to JavaScript, or at least some of us do. We've got a project like Sweet.js which you can write macros like this one is for the let keyword before we had let, which is a little strange because they're using the let keyword in the macro for let. That's a little weird, but anyways we could write macros and people that know about JavaScript's future have said, if we ever do get macros in the language it's gonna look like the Sweet.js project.
But again we're not gonna be offering the same code that we put in the browser, the bottom code is what's gonna go in the browser, and it's the top code that we wrote in our Editor. Tom Dale, anybody know Tom Dale? One of the main directors of the Ember project. So Tom Dale wrote this great article, I don't have time to get into all of it, but he's basically saying compilers are our new frameworks. We're not gonna have frameworks in the future, we're gonna have compilers and all the code that's running, it's gonna be much more efficient and it's gonna run. And that asks the question I think, is it okay that we just experiment with all this different kind of stuff? I came up with an idea for curried function declarations recently, and I started asking around on Twitter, and a bunch of people are like, that's cool, if you like functional programming being able to write a function that could have curried inputs would be awesome, and I like, okay that's cool I'm gonna write like a little parser so we can play around with this. And then some people on TC39 were like, no, don't start making your own custom syntax.
We have a very strict policy for how the future of JavaScript gets written and it's gotta come through our committee, so maybe not, maybe we can't experiment as much.
Asm.js, you probably know about asm but it was a way to take some weird but valid JavaScript syntax and learn about the type annotations and get efficient JavaScript code out of that, and that was the precursor to WebAssembly.
WebAssembly is actually very important because this is the fort that I was talking about, where now a lot of the code that's going around the Web wasn't even originally written in JavaScript. Every language you can imagine from Rust to whatever, they're all gonna be written in those languages and not even compiled to JavaScript anymore, but compiled to something that looks more like this, which I don't even understand it, but this is what WebAssembly looks like and it ends around the JavaScript compiler, just goes into the virtual machine.
Now that sounds amazing cos we can open so much more of the Web to so many more developers, but it really does come back to what is that gonna mean for view source.
Because now when you go to look at a webpage you're gonna look at almost all JavaScript running that application but in the future you're gonna have nine different languages doing different parts, and eight of those are not gonna be languages you've ever read before.
So you're gonna have a source map that shows you the original language and you're still not gonna be able to do anything with it.
So that future does ask us some questions and I just wanna finish by talking about those Two JavaScripts. This talk was gonna be called A Tale of two JavaScripts, because there really are two and they're starting to diverge and the tale of two JavaScripts so far has been a pretty good bet.
But I really think if we wanna keep betting on JavaScript we need to have the JavaScript that's about us and about communication, because I think that's where the future is gonna be, I think that's the most safe bet, and I don't think we're really talking about the implications of some of that divergence. So I'll leave you with, where are you gonna place your bet? On the future of JavaScript where will that bet be? I appreciate your time very time very much and apologise to the organisers that I went a couple minutes over, thanks very much for listening. And enjoy this funny little GIF.
