Upgrading JavaScript to ES6 and using TypeScript as a shortcut
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 96 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/51854 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201670 / 96
2
7
8
9
12
14
19
20
26
28
31
33
38
40
43
45
48
50
51
61
63
65
76
79
80
83
87
88
90
93
94
96
00:00
Integrated development environmentCode division multiple accessPoint (geometry)Content (media)Covering spaceSeries (mathematics)Error correction modelScripting languageRippingCodeWeb browserSoftware frameworkBuffer overflowMultiplication signStack (abstract data type)Computer architectureGoogolWindowComputing platformDifferent (Kate Ryan album)Row (database)Revision controlTrailMathematicsGoodness of fitTelecommunication40 (number)Web 2.0Address spaceBitPoint (geometry)Graphical user interfaceProcess (computing)ResultantBand matrixLibrary (computing)Wave packetMaxima and minimaPairwise comparisonSocial classAngleFormal languageScripting languageService (economics)Video gameOverhead (computing)Web browserFunctional (mathematics)Programming paradigmFacebookVisualization (computer graphics)QuicksortText editorDrop (liquid)Right angleJava appletData conversionCompilation albumArithmetic progressionWeb pageData structureCovering spaceCore dumpOpen setExtension (kinesiology)Latent heatInformationSound effectModule (mathematics)Computer fileWebsiteCartesian coordinate systemProduct (business)VideoconferencingMobile appFrame problemBit rateMereologyCalculationNeuroinformatikCue sportsHand fanField (computer science)Set (mathematics)Connectivity (graph theory)Range (statistics)Function (mathematics)Musical ensembleUniverse (mathematics)2 (number)CuboidCodeSoftware developerForcing (mathematics)System callInternetworkingError messageMeasurementReal numberAreaIntegrated development environmentPattern languageNumberRoundness (object)Line (geometry)Assembly languageGame theoryWritingFactory (trading post)Loop (music)Translation (relic)Type theoryInsertion lossTransformation (genetics)Level (video gaming)Source codeView (database)Client (computing)Internet service providerAndroid (robot)Virtual machineTwitterPredictabilityInformation securityTerm (mathematics)Semiconductor memoryMedical imagingCycle (graph theory)Automatic differentiationString (computer science)Keyboard shortcutDegree (graph theory)Inheritance (object-oriented programming)Physical systemDisk read-and-write headDynamical systemComputer simulationElectronic mailing listMathematical optimization1 (number)DampingCodecDigital photographyMobile WebState of matterReading (process)Software bugDemo (music)Endliche ModelltheorieElectric generatorObject (grammar)Block (periodic table)Category of beingConnected spaceProxy serverCommunications protocolAsynchronous Transfer ModeSymbol tableGraph coloringCivil engineeringFlash memoryBuildingQuantum stateSheaf (mathematics)Template (C++)Power (physics)Open sourceNetwork topologyRing (mathematics)WordSoftware testingBridging (networking)Control flowGraph (mathematics)Subject indexingPlastikkarteGame controllerOffice suiteServer (computing)PrototypeForm (programming)Wireless LANTable (information)Content (media)TouchscreenBootingSquare numberSpacetimeMassArrow of timeSoftware development kitElectronic program guideTriangleGradientRectangleComputer virusTrusted ComputingSoftware maintenanceUser interfaceWeb-DesignerAxiom of choiceInternet der DingeStatement (computer science)Standard deviationTypprüfungOperating systemMoment (mathematics)Run time (program lifecycle phase)Coefficient of determinationProgramming languageSineIndependence (probability theory)Natural numberComputer chessExpressionOnline helpExpert systemCASE <Informatik>EvoluteVideo game consolePiSmartphoneCausalityBlogUnit testingElectronic GovernmentFile systemComputer configurationMultitier architectureNormal (geometry)Similarity (geometry)Computer programmingPlanningData managementFreewareLattice (order)ExistenceUniform boundedness principleTorusWorkstation <Musikinstrument>Element (mathematics)Validity (statistics)Artistic renderingRemote procedure callStability theoryRepetitionException handlingArmSoftware crackingUniform resource locatorDefault (computer science)Closed setParsingGUI widgetFlow separationCryptanalysisEmailProper mapCompilerParallel portoutputExecution unitSingle-precision floating-point formatComplete metric spaceDoubling the cubeComa BerenicesArray data structureComputer sciencePerturbation theoryFault-tolerant systemNeue MathematikBytecodeHead-mounted displayDebuggerBefehlsprozessorChainTopological vector spaceStructural loadHyperlinkMappingDigitale VideotechnikVulnerability (computing)Front and back endsSurjective functionBookmark (World Wide Web)Diagram
Transcript: English(auto-generated)
00:04
All right. Better? Yes, excellent. Thanks for coming. End of the conference. We're all probably over-caffeinated, underslept and have far too much information in our heads that we could remember. I actually thought I'm already at the airport because I was wondering about the strike and wanted to go earlier.
00:23
And then I realized I have another talk to give, so that was good. Nice shock in the afternoon. Luckily enough, the planes are going off again, so I'll be going home to London later and then to New York the day after tomorrow. Because that was my big worry, where I'm going to be stuck on my way to New York before I go back to London, before I go to Israel. So I'm Chris, code poet on Twitter.
00:42
If you need some information about JavaScript, hedgehogs, nice pictures of puppies and general tech news, I do a lot of stuff there. I'm a program manager, a senior program manager at Microsoft. I'm working on the JavaScript engine and Microsoft Edge browser, the new browser that replaced the Internet Explorer,
01:01
where I'm happily dancing on its grave because as a web developer for years and years, this was the bane of my existence. I'm based in London. I work for Redmond, which means I don't work in the morning. So if you want to reach me on Twitter, that's where I get mostly answers because the Americans wake up at 4 o'clock my time. Then it's when I have to start working and have real meetings and stuff like that.
01:22
I used to work for Mozilla before, so I worked on Firefox OS and on Firefox itself. Before that, I was in Yahoo, where I worked on the YUI user interface library and the YQL language to access APIs over the Internet. Before that, I built lots of websites. So I've been doing this JavaScript thing for a long, long time. I want to today talk about what we're doing with JavaScript at the moment and why this is a good time to brush up on your JavaScript skills
01:46
and to use the new features of JavaScript in a safe manner rather than in a manner of trying to dictate the end user what browser to use, which is something we cannot do. So let's talk about JavaScript as in the agenda of this talk right now.
02:01
First, I'm going to talk about old issues of JavaScript that are here and are not going to go away for a while. The learning process of JavaScript, how do we learn JavaScript, how do we teach JavaScript as well. The tooling issue, what problem we have around tooling of JavaScript. The library framework issue, what is the benefits of using libraries and frameworks and where are we going wrong with it.
02:22
ES6 and its promises, what ES6 is and why it is a new technology you should embrace and not just use JavaScript the way we used it in the past. ES6 and its realities, what the problem with using the new features of JavaScript in our environment is. What TypeScript helped us to do that with, that's just a quick side note.
02:42
And then I'll talk quickly about ChakraCore, the new JavaScript engine that powers Microsoft Edge and is also a standalone engine that you can use for Node and what that means for the innovation of JavaScript itself. And for you to think about when you write Node solutions because there's another problem with that, that we're repeating an older issue of JavaScript.
03:03
Talking of which, let's go for the old issues of JavaScript. JavaScript client-side in the browser, which means client-side, has issues. It is not fault tolerant. What do I mean by that? Fault tolerance is built into all the standards of the web. If something is not understood by a browser, the browser says whatever.
03:24
You can put an HTML element in there that's called elephant and elephant is not defined in the HTML specification yet. And it will just render the text or the content inside the elephant element and that's about it. It will not say, oh, that's an invalid element, I cannot show that. XHTML tried to do that, that's why it died a really quick death and nobody
03:43
wanted to use it because 99% of the internet, sadly enough, is invalid HTML code. Because somewhere, somehow, somebody put an unencoded ampersand in there or didn't close a tag or a third-party widget generated some HTML that's totally random because they like what browsers can do.
04:02
So browsers are very, very tolerant towards HTML. The HTML5 parser is defined as fixing the end user's problems for them. So if you put a p tag in the browser and you load the page, it shows totally up as a paragraph. The browser has no issue with that, even if you omit the closing p tag.
04:22
The browser itself, if you look at the generated DOM that the browser did for you, closed the p tag automatically for you and did that kind of assumption for you. I personally don't like it that much because it makes people lazy, it makes people trust computers to do magical things for them. But sadly enough, this is the world we live in.
04:41
If you look around the web, finding valid HTML in 2016 is still a hard thing to do because people don't value HTML as a technology as much as they would value C Sharp or Java or real programming languages. The other good thing about default tolerance is that if we innovate HTML, older browsers just basically say,
05:02
yeah, whatever, I don't know what that is, I'm not going to do anything with it, and not give up and say, well, sorry, I can't do this for you, I'm an old browser, I don't want to be bothered anymore. CSS is the same way. In CSS, when I write a selector that the browser doesn't understand, it just skips that line and goes to the next line. If there's a syntax error in a CSS line, no problem either, I just go to the next line and see what I can do with that.
05:25
In JavaScript, any syntax error is end of game, and I'm not going to do anything anymore because I cannot validate line by line. I validate the whole script that you include in the script tag or embedded in the script tag. Which is kind of good because it means JavaScript gets faster that way, but at the same time, it's against the other standards if you think about it.
05:46
That's always when people say, oh, JavaScript, HTML, CSS are all web standards. JavaScript is a different standard than HTML and CSS. It's not to the nature of the web, the forgiving nature of the web, and the independence of the end user's computer. We have to do that as JavaScript developers ourselves.
06:03
We have to write paranoid or defensive JavaScript, and the if statement is a really good point there. Because you don't know the environment that your JavaScript runs in. The end user could have an old Android phone, they could be in an internet cafe in Calcutta, and have a really old Internet Explorer 6, Internet Explorer 5 that is so virus-ridden that you don't know what's going on.
06:26
But it's not up to you to tell those users, please download the newest Chrome, and please upgrade your machine to an Occor cluster, because my website needs to do that because I'm pretty. We are there to deliver content to end users.
06:40
We use JavaScript, CSS, and HTML, and all these technologies to make these experiences more enjoyable and more interesting. We are not here to tell the user what to do with their environment, because most of the time they can't even do that. They're not allowed to install another browser. They don't even know what a browser is. And your website better be very, very important for people to do any changes on their environment,
07:02
because most of the time we do it wrongly. All these websites out there that tell us now, oh, your browser's outdated, please upgrade to Internet Explorer 6, is really painful, because they try to guess what the browser is, and using a user agent sniffer is the most stupid thing you can do on the web, because there's no way to detect what browser or what environment is in use.
07:21
Think about features. Don't think about capabilities of the browser itself. Think about capabilities of the web standards and put an if statement around them, and you always write good code. The other problem with JavaScript is that many different parties mess with it. Your JavaScript could be the most crystal clear and fast performing and wonderful script in the world,
07:41
and then later down the line somebody in maintenance puts five tracker scripts and two advertising scripts and four libraries in there, and they all clash with your JavaScript. So the error can happen anywhere in the chain, not only in the code that you maintain. There will always be some third party that messes with your JavaScript. That could even be mobile phone providers, like in England, a lot of mobile phone providers in the past minified JavaScript.
08:05
Before they send it to the mobile phones. They also took images and loosened their quality so there's less traffic going on, which was ironic on Android when all the banner ads in games were basically just blurry JPEGs. You didn't even know what the banner was about, and then they wanted nobody clicked on it.
08:22
It has always been part of the browser and dependent on the release and upgrade cycle. That was the other issue. The runtime that executes your JavaScript on the client side is the browser. So if the browser does not get updated, then the JavaScript will not be able to get these new features. And luckily enough, we're in a world now where all browsers are evergreen,
08:42
including Microsoft Edge, Chrome, Firefox, Opera, Safari. Safari is the only one that is still a bit of a problem because it doesn't have an open roadmap like all the other browsers where you know what's coming next. So we have to do a lot of predictions there and finding out things about it. The other problem was in older Android devices, for example, we hardwired the browser with the operating system again.
09:04
So you needed to upgrade your Android to get a better browser. Luckily enough, that has changed with Android M and Android K actually already, which is really, really good. But still, there are mobile phone providers that put their own browser in there. And of course, the other big issue is things like Facebook and Twitter and other apps,
09:22
including a WebView browser inside their app, that could be anything as well and not the coolest, newest Chrome that you have on your Android machine right now. JavaScript, the language has issues, of course. It's been done in 10 days. It had to be rolled out really quickly, and we make a new language up quickly.
09:40
And it has things like type of not a number is number. And there is reasons for it, but when you see that the first time, you're like, okay, I don't want to work with this language. This is just driving me crazy. There's no type safety in JavaScript. That is by design, but for somebody who has to write in an environment where memory consumption is an important thing, type safety is an important part.
10:01
Also, not being able to override a variable to something else in terms of security is probably a good thing as well. There's no classes. A lot of our computer science and computer degrees are about class-based languages, and it's touted as the only way to write huge applications
10:20
and huge systems with class-based inheritance. JavaScript is prototypical inheritance, which is a bit of a head... You've got to get a head around it the first time. But we didn't have classes in JavaScript for a long, long time, so we wrote a lot of libraries to simulate classes in JavaScript, and now we have them as well, so this is out of the window, that argument.
10:42
The problem is, as JavaScript is such a versatile language and such a dynamic language, it's pretty hungry in terms of memory, because when I define a variable in JavaScript, it defines the most allocated memory possible because we don't know what that variable is going to be. We don't know if it's just an integer, if it's a number, if it's a long,
11:01
if it's a string, if it's a boat, if it's an elephant. It could be anything, and anywhere in our script, we can change this variable around as well. So a lot of JavaScript solutions run out of memory rather quickly, which wasn't ever an issue, because we were on desktop machines with big, fat computers, and it was all okay. I mean, fat computers that still are like a tenth of my mobile phone now,
11:22
but still back then it was not an issue. If you go to the Internet of Things, of course, it's a different issue, because then you have very, very low-end devices, and memory is a scarcity again, so you've got to be sure to know where your memory goes and what your script needs. The biggest broken thing I always found in JavaScript was the learning process.
11:44
I myself have written several JavaScript books, and I caught myself writing the books that I was professionally doing JavaScript, getting lots of money for it, without really knowing what I was doing. When I started writing the book, I knew I cannot fake it any longer, and I actually have to understand what I'm doing, because otherwise you get caught out really quickly.
12:01
That is a great example for all of you. If you want to learn something properly, start teaching it to others. Then you have no excuse anymore to just take shortcuts, and it's amazing how empowering it feels to learn by teaching. Now, the original JavaScript learning process has always been a bit interesting.
12:21
The first thing we did is use ViewSource what others are doing. So we looked at other websites, and how is this thing done? That's the beauty of the web. Nothing is hidden. You can find out how things work. You can look under the hood, you can play around with the cables, and you get enough rope to kill yourself every single time you do something with it. So we looked at what others were doing, we copied and pasted the bits that looked like they were responsible for doing some things,
12:42
we then changed some numbers around, and then we ran into errors, and then we blamed Internet Explorer. That was mostly how we learned JavaScript back then, and it's still prevailing for a long, long time. The amount of people who don't want to write proper JavaScript and say, yeah, we've got to support old Internet Explorer, and you're like, do you really test in Internet Explorer 6 as well?
13:03
No, but we have to support it, so you don't support it. You don't even know if it works, but you have an excuse of saying, oh, I can't clean up my code because I have all this old crap to support. Of course, this was not maintainable, and this is an unprofessional way of doing it, so we're doing it differently nowadays. We search for a solution on Stack Overflow, we copy and paste the bits that look like they're responsible for some things,
13:23
we change some numbers around, we run into errors, we blame JavaScript for being a terrible and not a real language, and for good measure, we also blame Internet Explorer. This is rampant. This is not a joke. This is like there is actually a copying and pasting from Stack Overflow is starting to become a development pattern.
13:40
I call it the full Stack Overflow developer. And I loved this the other day when somebody had the only error message you need in JavaScript exception handler is try something and catch if something happens, go window of location href Stack Overflow, search for the solution, and find it out there. Once you paste something like that onto Twitter, of course people will say this is not right,
14:01
and they will write it in ES6 to make it a bit shorter, but they actually say it's the same thing. It's sad, but we came to this world because it's not only us being lazy, it's actually our managers not giving us enough time, not understanding that front-end development and JavaScript development takes time as well.
14:22
Of course, there's lots of out-of-the-box solutions that you can use, but if you don't understand what you're doing, you're not going to have a good time later on maintaining that thing, and that's why our systems become bigger and bigger and more and more bloated. We are in a good space right now because we have ES6. ES6 is the latest ratified version of JavaScript,
14:41
the fully ratified standardized ECMAScript 6 version. This is something you can use in government websites. This is something you can use in systems that need security audits and these kind of things. This is the language that's coming. This is the ratified version. There's unit tests for the language itself. Everything is standardized.
15:00
It's been since June 2015, I think, and this is a great point. We have now a new version of JavaScript, so if you have junior developers wanting to learn JavaScript, look for ES6 tutorials. Don't look for JavaScript tutorials because you will find SEO crap from seven years ago that tells you, oh, here's an alert box
15:21
and here's how to do a pop-up window, and nobody needs these kind of things any longer. So look for the new standard tutorials and help write some of those as well. We have a good chance to clean up our act as educators in our technology right now. Double.js is a great example website. I'm going to go back to that later, which allows you to use ES6 now
15:41
by converting it to ES5 in older ones, but also has a great learning section in there. The learning section has all the features of ES6 explained with great code examples and with explanations of what they do, proper documentation, and it even has a REPL in there where you can type in the things and you see what kind of ES5 JavaScript
16:03
gets generated from the ES6. So if you know JavaScript and you wonder how under the hood that's done, that explains it to you. So that REPL here, if you click on it, you can type some ES6 on the left-hand side and you get some ES5 on the right-hand side so you can see the difference between the two versions of the same language.
16:22
I've given this talk, or similar ones, for quite a while, and it's so good nowadays that I have to say most of the things I'm talking to you about saying you need to do this is not necessary anymore because the support in browsers is damn good by now. ES6 has been taken on by browsers much faster than any of the other technologies that we tried to get into the browser,
16:42
like CSS animations are unprefixed. These kind of things took ages. ES6 came around really, really fast, mostly because browser makers themselves need ES6 for internals of browsers as well. Bewakwa, whatever his first name is right now, Pony Fu, has a great blog post
17:02
where he has ES6 overview and 350 bullet points, so if you just need something in a toilet break that you want to read on your mobile phone, you can read one bullet point at a time. Let's face it, that's why we use our mobile phones. It's basically, that's the main use case. If you like books, there's a great book by Axel Rauschmayer,
17:21
and it's free online to read. It's called Exploring ES6. It's also like $20 if you want to buy it, and it's one of those books that keeps changing, so every week you get a new version of it, so he does update it all the time as well. The great thing about that one is not only it explains you what new features are in ES6, but also how to use them and what they're good for,
17:43
and it shows you the discussion between different browser makers, how long it took to implement them, and what the problems with them were in different environments, so it's a proper way to use ES6 and not only to say like, oh, it's the new syntax, please use it, everybody. It's because the cool kids use it. Now, tooling has always been a thing
18:01
where people coming from larger environments like C Sharp or Java were always sniggering about JavaScript because there was no proper tooling and debugging tools out there, and it's come long ways for that since that started. We have a really, really good way of debugging JavaScript inside the browser
18:21
and even remotely in other browsers from developer tools. There's some really, really good stuff happening there, but it still feels rudimentary to other people, but that's also an approach thing. I work for Microsoft right now. I still cannot use an IDE. It still drives me crazy. I came from Vim, and I went to TextMate,
18:41
and I went to TextPad++ and these kind of things. I'm not used to all these windows telling me all cool things, and I feel like, okay, I want to learn this, but I never have time for it. I want to write some code instead. So it might be my fault, but telling a JavaScript developer or somebody who actually wants to do something cool, Web 2.0, Web 4.0 thingy,
19:01
and giving them an IDE and saying, here's all the features I see you in three weeks after you learned everything in it, that's not going to happen. But developer tools are getting in that space right now as well. If you look at the developer tools in Chrome, they become super complicated. So we're merging these two worlds already right now. The problem is that developer tools are mostly in browsers,
19:21
so they differ from browser to browser. Firefox has different developer tools than Chrome has, has different developer tools than Microsoft Edge has, has different developer tools than Opera had, because they more or less removed theirs, and again has different ones that Safari has. This is good. It means there's a competition, but for years the browsers have been focusing far too much
19:43
on being the number one developer browser and seeing developers as our main audience while we forgot that the people that pay money and click on ads are not developers. So it's good to have developer tools in the browser, but also if you are a web developer that takes this job serious,
20:02
you have to test across different browsers. So you also have to get yourself accustomed to all the different developer tools, and that can take a lot of time, and that's really rather annoying, but that's the way we live in right now because we have no standardization in the developer tools across browsers. There's things happening like there.
20:21
There's like remote debugging and these kind of things. There's a wonderful demo where I can take Visual Studio code, and I can set breakpoints in my JavaScript, and I run Chrome in the background without even showing the browser, and I do all my debugging in Visual Studio code, which is possible because these remote debugging protocols
20:42
that we're working on right now. So hopefully there will be some overlap between browsers over time, but right now the big competition in browsers is like who do developers think is the coolest browser because we all spend far too much money hiring developers, so if they're already excited about your browser, it's easier to get them into your company.
21:02
Now, whenever we started about different browser issues and differences across browsers, especially in the rendering and in the CSS and in the JavaScript support, a lot of people start with libraries and frameworks. Like, okay, I don't want to think about different browsers. jQuery tells me it's worked everywhere. They test that for me. Great job done.
21:21
jQuery 3.0 is out today. Take a look. It's really much leaner, much faster. It's a really beautiful way, and it also kicked out the compatibility mode. So saying you use jQuery so you support old Internet Explorer is not true any longer because that's been removed from that one as well, so they gave up on that one. That's the final straw for some people.
21:41
The problem is a lot of people rely too much on JavaScript and libraries. This is nasa.gov a few months ago, and I love that because that was on my connection at home. So you load the page. After four seconds, it shows you the darkness of space and what it feels like to be an astronaut for about ten seconds before there's some squares, and then you get some spinning loaders,
22:01
and then you get some content. So it took like 14.8 seconds on my connection, on my wireless connection at home on my mobile device to show this website. The average user after three seconds starts poking their mobile phone and thinks something is wrong and starts reloading the page continuously and these kind of things. This is not a good experience.
22:21
And looking at it, and it's fixed by now, they used Ember and jQuery in one JavaScript file in the header of the page without a defer just embedded in the header and that means the browser does nothing until this is loaded, executed, and accessed the document, and then it actually starts doing something.
22:40
That's why the spinners and the loaders. This is not because they're bad developers. This is because somebody said, we've got a press release tomorrow. Make this website happen. And this is why we as developers have to stand up and say, well, you could have told me that a week ago. Let's plan your next press releases so I don't have to release things that are embarrassing, and we lose end users because the first impression is a bad, bad thing to do wrong.
23:02
I worked with a large corporation in England the other day, and my favorite quote was, it's 150,000 pages, roughly, maintained by 72 different departments in the company. And that one poor guy that I talked to, now his job is to re-architect the whole website and find a framework that makes it faster and better
23:22
and works on every platform and wonderful. And his quote was like, he did not even know who maintained different parts of the page anymore. So he just did a grab on the folder structure, and he realized how old parts of the page were, which version of jQuery they were using. It was like rings in a tree trunk for him.
23:42
And that is so painful. He found like 26 different versions of jQuery in the same website because different departments don't talk to each other and just put more JavaScript in, it's going to be fine. We need a carousel right now. Or probably you should put prototype in there as well, and Scriptaculous and HammerJS and all these things. We just add and add and add
24:01
and wonder why it's slow for our end users because we, in a fast connection in the office with those wonderful machines, don't feel their pain. Paul Lewis, last year actually, gave a really good talk about this. You should use insert library framework, it's the bestest. And he did some really good research into how expensive it is
24:21
to use libraries and frameworks for us. He did, on an N5 device, on a mobile device, he used React, and he wrote also an application with vanilla JavaScript, just out-of-the-box JavaScript. What he did was a photo page that showed images and loaded them.
24:41
And here is actually, because everybody says accessing the DOM and changing the DOM around is the slow bit. But he found out that with React having a virtual DOM, which is not a DOM at all, they do everything, the DOM manipulation in memory, and then flush it out to the DOM in one string, he found out with the amount of photos getting more and more,
25:01
the DOM access, the red access, stays more or less the same. The time needed for that. Whereas the time to run the JavaScript itself, to run the React and do the virtual DOM and generate that string to flush out, became more and more with more images that they're using because it kept rewriting.
25:21
On the other hand, he found out with the vanilla JavaScript, with more images, it actually stayed the same or even became less time. It became faster over time because the JavaScript engine does a lot of caching internally, and the DOM does a lot of caching internally as well. So if these images didn't change, the browser just said, okay, I take the ones I already have in memory.
25:41
I don't have to do anything with them. They do a diffing between those two, so there's no issue there. And that was a very interesting insight. I didn't even think that the JavaScript engine optimizes so much, but Chrome is really, really good at that. Then he actually ran a to-do list,
26:00
I think it was, on different libraries and different frameworks. He said Polymer, Angular, React, Backbone, Ember, and vanilla JavaScript. He looked at the size needed to actually run this kind of thing and how long it took to load on the N5 and how long it took to load on an iOS device or an iPhone device.
26:20
And some of them took two seconds to start executing. Again, end users on mobile phones don't have any patience whatsoever, so they'd be very, very unhappy. His findings were basically saying a lot of our library usage is for the benefit of the developer or the benefit of the maintainer and not the benefit of the end user. In essence, we make them slow
26:41
and we make them harder to look at our stuff that we could do with vanilla JS. Of course, it's much easier to use something out of the box than start something from scratch. But he had some good findings in there. Frameworks are a great thing because they're fun to use. You can achieve a lot very quickly. And I'm getting very angry when I go to conferences and I see this, like,
27:01
can we do Facebook in 12 seconds with our new JavaScript library? Find out in this talk. And you're like, okay, that demo I can build in two minutes. What about a change in that demo? Well, then you have to start learning that framework. Then you have to start understanding that framework. You build complex apps in a matter of minutes. They work around pesky browser bugs.
27:21
And frameworks are also good for your CV. If you have React on your CV right now, I'm quite sure you get 10 times the amount of drop-off than when you have Prototype there or YUI. And sadly enough, that changes every half year, so you have to keep changing your CV as well and finding new things there. They also come with developer costs. You have to learn new frameworks all the time.
27:41
Every half year, there's a new framework that has a new paradigm of doing it and new way of understanding what the web is like. You have to relearn the new framework. So if a framework changes, a lot of them have breaking changes from version to version, so you have to understand what's going on, and then it's up to you to fix your old solution and replace that old jQuery with the new jQuery.
28:02
Otherwise, you run into the same problem that that company had with the 27 different jQuerys. Setting up the developer, debugging the framework itself, you get errors out of a sudden, like, this is not my code, what's going on here. So you have to go to GitHub and file a request and find out what's going on and use Google to find things and Stack Overflow
28:21
to see what problems are in the framework itself. Setting up the developer environment, some of those frameworks take a lot of effort to install, especially when you outsource to countries where people don't have Macs and your first setup for JavaScript is like, go to the command line on your Mac and run these 12 Ruby things, and they're like, what?
28:41
You're like, okay, that's another overhead that you have to think about. And you have to cut down on possible hires and adding to onboarding time, because if your company is a React shop and everybody you hire wants to come in and use something else, you have to convince them to start working with React, and that means training them, that means understanding them. What if then the company that runs React
29:00
or the company that runs Angular 1 doesn't like it anymore and totally drops it, it becomes harder and harder to maintain your stuff and you get people to maintain it for you as well? We all should consider the effects we have on our end users. The time to load and execute is paramount. That's the most important thing. Don't make your end users wait.
29:21
The bandwidth used, how heavy is your JavaScript? If I'm on my mobile phone and I'm roaming and I have to load 1.2 meg of JavaScript just to see the entry of the address of a conference, for example, that's not a good experience. That is not fun. Twitter's web client is a great thing. 140 characters, 2 megabyte of JavaScript to load that thing,
29:42
to see the 140 characters. Really? This is not what we wanted to have. CPU usage, how much is the fan of your computer starting just because you do a lot of JavaScript calculations? Frame rate, less than 60 frames per second, feel laggy. When you start scrolling and the thing doesn't, it feels odd for us. My favorite with web VR,
30:02
now that we have VR in JavaScript as well, it's the first time you can literally make people puke with JavaScript. This is great. If you get less than 60 frames per second, people get travel sick using VR headsets like I do, and it's good fun. Yay, my JavaScript did that. Memory usage and, of course, the battery hunger on a mobile device is super important as well because if your website made me lose half my battery,
30:23
then I have a real problem. I love, for example, using Uber, but when my phone is actually draining while I'm getting to the airport and I get to the airport and it's empty because I had an Uber ride, I'm like, why didn't it tell me at the end of it, give me a notification, your ride is done, rather than just keep pinging and keep loading?
30:43
And we're going full speed on innovation on the web. The componentized web is a very interesting way of thinking about it. Web components, if you haven't looked into those, now with Polymer being a fully-fledged 1.0, it's getting interesting. Extensible Map Manifesto, instead of the browsers telling us what we have,
31:01
we as developers get little bits of information from the browser that we can put together and extend the functionality of the language itself. WebGL is OpenGL in JavaScript. WebAssembly, asm.js is turning byte code, having native byte code on the web. PostCSS allows you to access CSS in JavaScript
31:21
and do any conversion that you want to do in JavaScript to your CSS before it gets rendered on the page. And progressive apps, if you haven't been at Google I.O. or you haven't heard about it, download all the videos. It's a really cool, hot thing, and I'm very excited about this because it's a way to promote a website or a web product to an application by using it several times. So when you go to the website for the first time,
31:42
it says, like, okay, here's a fast website loading really cool on your mobile phone. The second time you go there, hey, by the way, I'm now offline as well, so you don't have to go online next time to see this page. But if there's something new, I tell you that I'm something new in my page. So we're breaking apart that app model, and that's very important right now. Now, building libraries and frameworks
32:02
and magical fix things has become fashionable. There's a big competition of being the winner of hack and use for that day to make that one small library to fix that one big thing. We work around browser issues with those. We make web standards of tomorrow work today. Every time there's a new standard discussed, people already make a polyfill in JavaScript
32:21
so you can use it immediately. We build solutions to clean up others and make them smaller. That always cracks me up when you're like, oh, this library is 4K minus 2K, and then six weeks later, minus 16K, the other one is 2 megabyte. It's an endless arms race that we do. Whenever it's like, it's only 4K, never trust that. Give it two weeks, look back at how big it is then. And each of those comes with a don't use in production label.
32:43
That's always my favorite. After I spent an hour getting my head around some of those things and read out the documentation, and in the final line, it's like, oh, by the way, don't use this in production. This is just something. So who are we building those for? For each other to show each other off or to get hired by Facebook or Google or Microsoft,
33:01
it just feels weird to me that we build all these things that solve all solutions but don't use in production. In the end, sooner or later, we should produce things. VC money will get out as well. Sooner or later, you will be having to deliver some product to end users. Now, ES6 has a lot of promises in them. It has promises as well.
33:20
That's a JavaScript thing, but I'm talking about what the promise of ES6 itself was. JavaScript evolves. 1997, we had ECMAScript 1. That's the first version of JavaScript that was ratified. 1998, ECMAScript 2. 1999, ECMAScript 3. You see the pattern. Every year, a new version, except something happened, and we don't know what really happened. Flash happened. Silverlight happened.
33:41
Transformers movies came out. People went to raves and took drugs. I don't know. But in between 2005 and 2007, we had ECMAScript 4, which then got abandoned. This is like seven years of nothing or eight years of nothing where we discussed what the language, what new features the language needs for the new use cases that we have.
34:00
And 2009, 2000, smartphones came out. Before that, we had those smart TVs and game consoles and all kind of stuff. The language should have had much more evolution in that time already. 2009, we got ECMAScript 5. So that's what we call JavaScript nowadays in essence. And then 2015, we finally had ECMAScript 6 ratified as the new standard
34:20
that we're having right now. ES6 took five years since ES5. It has the most significant changes in 15 years. In between ES3 and ES5, there wasn't much change to the language itself. In ES6, we have syntactic changes. We have structural changes. Now we have classes instead of just prototypical factory methods.
34:44
And the language is now something different. It's backwards compatible. That's a good thing. We cannot break the web. It's just impossible to do. We cannot say, oh, that's the ES6 page. Sorry, you have an old browser. You cannot see that anymore. That was the problem of Flash. That was the problem of Silverlight. And we learned that lesson. It's ratified, and it comes with so much goodness
35:01
it technically has to be fattening. If you read through all the good things that are in ES6, it's pretty overwhelming because I just wanted to change the color of some things on the page, like why do I need about weak maps and symbols and proxies now? Don't get too excited about it.
35:21
Every single part of ES6 is for different audiences. We have the syntactic sugar, like arrow functions, object literals, all the new array functions, template strings, which is things that can now replace handlebars or mustache or whatever you use for client-side templating now. We have new math things.
35:41
We have new number sections. And especially for objects and arrays, we have so many cool new things. The for-off loop is super exciting, which is much, much better than doing all the jumping that we had to go for, like checking if everything is like has own property kind of things. For people who want to build scalable apps, we have let const and blocks go binding.
36:02
So we got const, and we got, more or less, type safety. Not quite there yet, but at least you can say this should never change. And you can also freeze objects now that they cannot be modified any longer, which is another great thing for memory consumption. We've got classes. We've got promises, which is a simple way to do asynchronous development,
36:24
asynchronous scripting. Generators, typed arrays, modules. Typed arrays is a fallout from WebGL. It's basically much faster array computation than using a normal array because also using the GPU and these kind of things. For library builders itself, we got map set and weak map.
36:40
Instead of arrays, you can have a map and a set. We've got proto proxies and so on and so forth. ES6 tried to cater to a lot more users, and that was the problem with JavaScript in the past. We always thought it's just the guys who build websites, but nowadays we do everything with JavaScript. We build editors in JavaScript. We build massive applications in JavaScript. We build servers in JavaScript,
37:01
so the language had to evolve as well. The support is encouraging. This is an old screenshot by Kangax. He works somewhere in San Francisco. I think Facebook. He maintains that compatibility table for ES6, ES2015, ES2016, all the other versions.
37:21
You always see which browser, which pre-compiler, which polyfill, which server, and which mobile browser supports which part of ES6 and which parts are not available. Each of those that have a little rectangle, a triangle, you can click on that and find out the information that is not supported. Nowadays, almost that is green for all the overgreen browsers.
37:43
Even iOS has completely caught on, and ES6 is 100% supported in the latest WebKit nightly, so when that's coming out, when the next version of iOS is coming out, we have full ES6 support on iOS as well. There's, of course, some reality issues with that, and the biggest problem is that for non-supporting browsers,
38:00
ES6 features, especially the syntax errors, the syntactic ones like arrow functions, are just a syntax error. You cannot say, okay, the older browser will just skip that. That's not an issue. Because we changed the syntax, we had to find a way to make old browsers, if we want to support them with our ES6, to not break.
38:24
Now, personally, I think if you want to build something useful, think about progressive enhancement. Think about escalators. Escalators cannot break. When an escalator is broken, it's a set of stairs. You know, you can still go up there. It's much more work, but it still works.
38:41
A lift or an elevator, if that one breaks, it's basically broken. It's a small room that does nothing. So think of writing your code with like, okay, here's the features that everybody has. HTML, a bit of CSS, a bit of JavaScript even if you want to. And then put if statements around everything else and test if the browser supports it
39:02
and apply it when the browser or the environment supports it. Otherwise, don't bother the browser with it. Don't give people experiences that look beautiful but perform terribly. Some of our functionality that we build in ES6 and other higher versions of JavaScript is also dependent on a richer environment.
39:21
And people who have to support Internet Explorer 6 and work on that thing, they're not happy people. And they're not used to beauty. So don't give them anything beautiful. Just give them what they're used for, a form that reloads every time you put something in. That's okay. That works. That's better than them waiting for five megabytes of JavaScript that do nothing on their computer.
39:43
The solution of course transpiling into ES6 and Babel.js is the big thing there. It converts ES6 to older versions on the server or the client. Please do it on the server because I said before you don't control the client and you don't want my mobile phone to convert five megabytes of ES6 into ten megabytes of ES5.
40:01
That's a very, very bad solution for me. It's used by Facebook and many others as well and it's used in editors and tool chains. So a lot of people use transpilation in their Webpack systems or their module systems, whatever they use for that. The fun thing is that transpiled code can look absolutely terrible. I loved this Perl developer when he was complaining that this is what JavaScript looks like and people complain about Perl.
40:23
And this was the outcome of a Webpack system. So a lot of JavaScript we have on the web live right now has been done by computers, with computers, through computers. So don't look at the view source any longer because we are past that stage quite some time ago.
40:40
Again, the problem with transpilation and with converting is that it's an overhead. This time it's not necessarily an overhead on the client side unless you're evil and you do it on the client side. But you have, for example, Closure, TypeScript and Webpack, Babel, TypeScript Browserify, Webpack, Webpack, Babel and Babelify and Uglify. It's all with phis at the end, so it's getting rather confusing after a while.
41:01
But here you can see how much gzip, how much bytes given over the line for all of those, how long it takes to compile and execute, and how long the tool runs. So again, it's maybe wondering, is it worthwhile to really convert everything to ES5 for these 0.02% users that you have, whereas the others have, after doing some preliminary checking,
41:23
can run ES6 in their browser and you don't have to give them all this extra code. The problems with transpiling is an extra step between writing code and running it in the browser. It's the compilation code that I never wanted to do. That's why I became a JavaScript developer. I hated compilation. I used to write assembly language,
41:41
games in assembly language, and then it was in my assembler. Went to bed, eight hours later, oh, well, that didn't work, great. And eight hours later, oh, that didn't work, great. So I didn't, when I had a really slow computer. And I liked in JavaScript, I typed the thing, I get the error immediately, I fix it, I type the error immediately, and so on and so forth.
42:01
We also don't run or debug the code we write. In the end, when the browser has a problem with our code, it's been transpiled code. So we have to see what happened in the transpilation, not what is in the bug in our original code. So getting in our toolchain from the error to the error of the browser, it sometimes doesn't look like an error in our code. It was the transpiler that did the problem.
42:22
We hope the transpiler creates efficient code. A lot of them do, but a lot of times it's just, okay, a loop will generate a lot of code in between. We create a lot of code because we simulate functionality of ES6 in ES5, and just a class has to be a factory function, so that becomes much, much more code than just a class itself.
42:40
And browsers that support ES6 will never get any, and that's the biggest problem I have with transpiling. As somebody who works for a browser who wants to support ES6, I want to see ES6 code in the wild so I can make my browser engine faster. I want to optimize for that new code. I want to optimize for this cool new functionality that makes us more effective as developers.
43:01
But if nobody writes ES6 code live because we converted to ES5, we can never make our engines faster because we never get this code. So if you work in a node environment, in a server-side environment where you control everything, please stick with ES6 because that's the only way how we can train V8 and ChakraCore to run ES6 code faster.
43:21
One way to get around all these problems if you want to just have the goodness of classes and type safety is TypeScript. It's an open-source language maintained and done by Microsoft, but a lot of other people are in there as well. Angular 2 of Google now runs on TypeScript as well, so they embrace that,
43:40
and other people like Dojo are working on that as well right now. And that one gives you the type safety and the classes without all the overhead because the compilation and the conversion from JavaScript to JavaScript happens in TypeScript for you. It works in the browser. It creates JavaScript. It's class-paced, type-safe. It's got editor and tooling support, so the Visual Studio support
44:02
and the Visual Studio code support is amazingly good in TypeScript. Some of the tooling inside Facebook that they did for Electron is also using TypeScript and does some really good debugging stuff for TypeScript. It's used to write large frameworks, and it's used heavily in Microsoft. A lot of our stuff is written in TypeScript
44:22
because we wanted our C-Sharp developers to write JavaScript but not re-educate them on writing JavaScript because it costs too much time and too much effort. I'm finishing up with the Chakra core JavaScript engine that we have released now as open source, which will be available for Linux and other platforms soon as well.
44:40
Right now it's on Windows 10. You can download it on GitHub and play with it. I'm not going to go through the architecture because I have no time for this, but the interesting bit is the speed comparisons. Microsoft Edge compared to IE 11 is about three times faster or two times faster depending on which of the comparison libraries you do,
45:00
and this is what we concentrated on. We wanted to beat ourselves. We wanted to make sure that the IE 11 problem is not there anymore and you have a fast browser on Windows 10. We also, at the beginning, and probably this changed by now because these comparison libraries, there's always new results, we were faster than Chrome and Firefox Alpha back then, and this is good because browsers get lazy
45:23
when they don't have any competition. So now Chrome and Firefox and Safari keep us sane and keep us fast and keep us on our toes because we've got an evergreen browser as well and they actually have somebody new in the playing field to compare against. Surprises happen in Node.js,
45:41
which I always thought was a complete Linux and OS X world. Forty-two percent of the users use Windows as a desktop environment, and that was really exciting for us to see. So we made sure that we put ChakraCore, which is a lighter version of the Chakra engine in IE 11, that that one works really, really well with Node, and that is now part of the Node infrastructure. You can run Node on ChakraCore,
46:02
not only on V8 as Node was out of the box, and that's a monoculture, and I want to break monocultures. That's a very bad thing to happen. So the Chakra engine, which is the engine of Microsoft Edge in Windows 10, and the ChakraCore are slightly different. The browser part,
46:21
the universal Windows platform part, and the com diagnostic APIs are taken out of ChakraCore, which means it's much more lightweight, it's much faster and much simpler than the main Chakra engine and easier to compile as well because you don't have to care about the file access garbage that you do in there because in Node solutions you use the FS module rather than relying on the thing
46:41
and having an own file system in there. That's good for the Internet of Things, of course, and then we realized that a lot of Node solutions rely on V8 APIs, on APIs that are not standardized in ECMAScript but are V8 specific. So we wrote a Chakra shim library on top of ChakraCore that allows you to run your V8 code
47:02
also in ChakraCore without having to change it, although it's a good idea to start taking out all this V8-only code from your Node solutions because sooner or later a third JavaScript engine will come out or V8 will change its core structure and out of a sudden your old code breaks as well. Write to a standard
47:20
and these kind of surprises will not happen to you, so that's a very, very good thing that we now have a choice between two libraries in our Node solutions as well. The performance is pretty good. The blue one is how Node performed with V8, the baseline, and then we said, okay, with Chakra is the orange one and with ChakraCore it's the green one, so it took us a while to overtake them,
47:42
but then we're actually getting faster and faster right now, so it's very nice to see to get the performance of the engine itself better. We are running the Microsoft Edge website, our developer website, where all the documentation of what Microsoft Edge supports and other browsers support. That one is running on ChakraCore on Node already,
48:02
so we're dogfooding that at the moment, and we found a few memory problems that we're fixing right now, so that's good. We're not saying please test it for us. We're doing it ourselves. The TypeScript compiler, Visual Studio Code, Team Foundation server, and Encyclopedia app, they're all written in TypeScript itself, although the TypeScript compiler, of course, isn't,
48:21
and all of them became much, much faster when we compared them with Node.js in V8 with Node.js with ChakraCore, so all of these things, internally we saved a lot of bytes and saved a lot of time in Microsoft, and that can help you in the long run as well. It's on GitHub. It's open source, so you can basically play with it. You can build it yourself. There's an executable that you can run parallel
48:41
to your normal Node installation so you don't mess up all your Node structuring that you have right now if you just want to play with it, and I'm working on getting a VM that you can just play with to just install with the remote access so you can play with ChakraCore server yourself. Now, in summary, what do we have going here in what I talk about
49:02
and what I wanted to say here? JavaScript is now ES6. Stop looking for JavaScript. Look for ES6 features. You will find the better documentation. You will find the cleaner tutorials. You will find the more interesting things. JavaScript moved beyond the browser. Client-side JavaScript isn't that much of the JavaScript world. Everything else, with Electron,
49:22
Slack runs on JavaScript, and people are always like, oh, it's so much better than your JavaScript stuff on the web. It's actually JavaScript inside Electron. We have a tooling problem. We have too many options. There's too many tools to choose from, and some of them get very complex Using Webpack is not easy for a lot of people the first time you look at it,
49:40
so we have to think about... We have the same with client-side libraries. Before jQuery became the norm and everybody used that one, I wrote for Jackson as a blogger. There were like 126 different Ajax libraries, and all of them died except for three big ones, and the same will be happening in the compiler space and in the packing space and in the tool chaining space as well.
50:03
JavaScript needs to cater for a lot of different developer needs. Don't just think that we have to support the people in browsers. We also have to support the Electron people. We have to support server-side people who want to write massive Express.js servers, and they perform really well. We help the language by picking what makes you effective
50:22
and doesn't hurt your users, so don't feel bad if you feel overwhelmed by looking at ES6 and see all the features and you don't know what a proxy is or you don't know what a symbol is. Most of the time, you will not need it for your use case. Pick the things that make sense in your use case and become an expert on those, and tell other people about it as well. As I said, the best way to learn something
50:41
is to teach it to other people. Help improve the tools that are being built right now. Visual Studio Code is written in TypeScript. Electron is written in TypeScript. All these environments, all these build scripts are done in JavaScript as well, so if you want to help maintaining them, please do. Don't write another one that is a competitor of those
51:02
because that fight has to stop. We have to grow up as a community and not show off to each other, but actually build things that people can use in production instead. And that's all I had, so thanks very much.