(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.
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.
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.
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.
I have no idea why I thought those were important, but for some reason I did back in the day.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 there are a number of increased demands that are driving us in that direction.
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.
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.
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.
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.
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.
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.