I’m Stoyan Stefanov, I’m a Facebook engineer, currently work mostly on the social plugins such is the Like Button, trying to make everything as fast as possible, because there are everywhere on the web it’s a way of trying to make the whole web faster by making all those plugins faster. Before that I was at the Yahoo working on performance, worked on tools such as YSlow or SmashIit image optimizer and generally helping teams improve their performance. I’ve written a couple of books, I like to speak to people at conferences and this is all about it.
Dio's full question: You mentioned the books and you have authored O’Reilly’s book on JavaScript Patterns and then you said you have been very vocal about things like JavaScript Performance, would you like to tell us about the unique challenges that JavaScript developers have to face, especially with large codebases and performance that might be unique to this language. I also know that you have big background on PHP, so what do you think it’s unique as challenges for JavaScript?
I don’t think that is anything all that unique about the languages itself, but it’s mostly about the way JavaScript programs usually run, which is in the browser and the fact that you don’t have compiled bytecode or anything, you have to transfer the program code over the network and have the browser interpret it, so this comes with the challenge of, especially if you have like you said, large codebases, so do you need to think about the JavaScript programs or applications that we write is the network and this is usually where I would advice people to start optimizing before you dive into any sort of optimizing loops or inheritance patterns or anything like this, just to get the network part right, the delivery of the JavaScript code, that means minifying the code, Gzipping, reducing the number of HTTP request or the basic networking things done right, and then the other unique thing is about actually how do you load this JavaScript, do you want to load everything in advance and have something like a splash screen while you load 1Mb of code or much better option will be to just load as that you need, and ideally design the application in a way that they work even without JavaScript, if that all is possible.
And then whenever asynchronously not being in the way of the application or of the page, you load the JavaScript asynchronously and whenever it kicks in, it makes everything much more beautiful in the spirit of progressive enhancement.
The most important thing as I said is the networking stuff and if you can use to such as a
webpagetest.ogr that work YSlow, PageSpeed and get all the basic network layer stuff out of the way and done properly, and then after the loading of all these codes is done in the most efficient way. Then you get diminishing returns the more time you spend, so next thing after the network is right, then usually applications spend a lot of time in the DOM manipulations and causing the browser to reflow and repaint and so on, so anything to do with layouting would be the next thing to focus on and in terms of tools then you have all the browsers built in which are getting so much better now than what you used to have just few short years ago.
Firebug for Firefox and web inspector and definitely helpful it even show you how much time you spend layouting, painting and give you CPU profiling. The built-in tools in the browser are great, also for performance I really like online tools, nothing that you need to install, is just something that you go to a page, you give the URL and you see immediate benefits. So one kind of online tool that we love is www.jsPerf.com, where you can really test any assumptions and any advice you are given, whether it make sense in your use case and whether should be even something you’ll be focusing on, and our advice even every time you decide to do an optimization, is first to test if there is, first thing would be to profiling, using all those profiles since this is really a bottleneck of the application, so no reason optimizing something that will give you virtually no return. So after profiling what do you decide or what you do is just test the assumptions in jsPerf and see is there really worth spending time on this thing or no. When somebody gives you an advice and say: “Do this instead of that” and the right response to me will be show me the jsPerf or test, or it didn’t happen.
Dio's full question: You mentioned also about performance issues when dealing with DOM causing reflows and stuff like that. Now practically dealing with at least 3 different engines in WebKit Gecko, whatever Internet Explorer using at that time and also legacy browser and also particularities of mobile clients, how the developer goes about worring about these things, for example you can get really familiar with a specific open-source browser and understand how it does reflows but does this scale for doing it, for all browsers?
There is some specific about the browsers, that is obvious, but I think in general just focusing on one browser and making all the DOM manipulation fast in one browser is very, very likely that it will give you a return on your time investment in all other browsers, and unless you see something specific to support IE 6 or 7, if you see some specific slow that is not slowing Chrome of Firefox but shows in iE and you might want to invest some time there. There is actually in terms of tools, I forgot to mention, the dynaTrace Ajax edition for IE or also give you how much time you spend during the layout, executing a function, also the network traffic, so it’s like a WebPageTest waterfall plus additional layout things so it will help debugging in IE, but just in general reducing the DOM manipulations, doing all these, constructing your DOM tree offline and not on the live page, reducing the reflows that is very likely to yield good benefit in all the browsers.
Dio's full question: Talking about JavaScript there is a great debate about using it as an assembly language for the front-end, there are several different ways that people are doing this, we’ve had GWT for a long time, CoffeeScript is pretty mainstream, we have Dart which seems pretty ambitious, we also have the several projects that are transforming ECMAScript 6 to JavaScript compatible for current browsers, which do you think it’s the more appropriate way to go about developing JavaScript, do you see any of these ways becoming more mainstream in the next couple of years?
I like the JavaScript the ways it is, so I don’t know about developing, but actually something that came up recently, TypeScript from Microsoft, that looks really good to me in something that I’ll be willing to experiment because it’s based on what ECMAScript6 likely to be in terms of syntax and so on, but the other things I know about GWT, if you are setting your Java ways and you are doing this, that is probably helpful to me, same for CoffeeScript obviously it’s a really good thing that people like and use a lot, but for people who know JavaScript, I don’t really see the benefit of learning yet another syntax or writing your JavaScript in Java, that is abomination. About GWT, CoffeeScript is good, TypeScript seems to be promising, because people like their types, they want to know what these functions accepts and what is it return.
Types can be in the way when you start casting one type to another only to satisfy the type checks, but over all seem like a nice experiment. What I like about this the most, is that it compiles to a very readable JavaScript, so you can use classes that likely would be in ECMAScript 6 and you can see how the ECMAScript 3 or 5 code is being generated and how short and nice it is. The thing that it creates readable JavaScript and does all these type check during the compilation, that is something really nice, so even you introduce any even time checks. And about Dart, I don’t know, it’s a new language, it supposes to replace JavaScript, don’t really move it forward, so I’m not crazy about that.
You mentioned classes in ECMAScript 6, it seems like you are positive about this, what do you think about the rest of the changes coming in ECMAScript 6? So I’m not positive about the classes, I’m not crazy about the idea but seems like this is something people want. But the thing is if you play around with TypeScript before and after you can write TypeScript and see what it compiles, and you can see actually the backwards compatible version is actually shorter and looks very nice and clean, so if you cannot accomplish in the language all this stuff without introducing anymore syntax, is it really all that important to be there.
Yes, probably, because when you instanciate a construct your car that looks so much like classes so people and people thinking: “This is a class”, it’s actually a constructor function and they expect to have class based inheritance. So that is the nice thing about JavaScript, if you want to do inheritance, there are so many ways to do it and you don’t really actually need, I mean inheritance is only one way of reusing code, but that is really not the only way, but people who are used to the concept of classes will welcome these new editions to ECMAScript 6. So for the rest I have not being following all that closely the development of the ECMAScript 6, it just seems to me there is too much going on, I like things minimal and make I guess the next editions of my books even bigger which I don’t like because I like things to be short, so I’m hoping that Douglas Crockford will come at the end and probably on a white horse, I don’t think it help reduce the scope of the project.
ECMAScript 5 was a really nice way to improve the language because it didn’t introduce any use syntax so it was backwards compatible and most of the things you can shim for all the browsers, so that is why it got really nice and quick adoption, and things that you cannot shim I don’t think people are using all that much like defining properties that are not changeable. I think that you don’t .people don’t tend to use, but now days we have so many transpilers and seems like everybody is a language designer now, so I think all these existing transpilers will make the transition much easier, something like TypeScript shows that you can use the new syntax and compile to nice readable old school JavaScript.
Well if you shim just JavaScript methods of arrays and so on, actually that is not really the big bottleneck so if you make those, well it depends on the type of application, if you are creating a game or any video or audio processing in JavaScript those things are starting to matter but for most of the applications even complex applications like Facebook or Gmail, I don’t think that will be the bottleneck of how fast it rate over a race and so on. When talking about shimming HTML 5 features that can be more complex because it start involving the DOM and could be a reason to slow down, but for JavaScript for most users I’m not convinced that this will be a big problem, and actually there was one example jsPerf test from John Dalton that was showing that in most browsers if you shim something like an array map or filter with your own old school for loop that will be faster in most of the browsers, faster than the native map, because his explanation was that because of all of those benchmarks of the browsers, want to look good on the benchmarks, so they’ve spend a lot of time optimizing loops, so your normal four loop will be in some cases faster then, so you are shimming maybe faster than the native thing.
I’m not suggesting not use the native but just an example that it’s hard to tell, you cannot always say native, that will be better, that is your first told but doesn’t always need to be the case, so that is why I always recommend to test any of those assumptions and not just say: “Somebody said that this is faster or slower”, just see the jsPerf test or see if this advice applies to your case, how many elements in the array are you iterating and what exactly you are doing there. If you have a HTML collection that gets elements by tag name and you loop over that and do something, the actual DOM manipulation will be so much slower than any sort of over head of the loop.
That will be out of my real expertise, really I haven’t done any games, recently I have experimenting with web audio which is really nice, but other then that I’ve been focusing most on the regular web page type of applications, so people who do the games would have different set of challenges and then these things will start to matter how fast you can iterate over it, 10.000 pixels.
The main thing with large scale applications to worry about is don’t make them so large scale and just starts small and do what ever works and instead of spending a lot of time designing this beautiful architecture for any sort of use cases that you might or you might not have, so you just make the things work and then you can iterate over time and make things better and abstracts some parts of the code, but I think will be mistake to start planning to build something huge, just let naturally evolve and also plan to throw it away when you need to iterate over and over what you have and replace some of the stuff with better or some more abstract ways.
The main thing to worry is that just don’t plan to write tons of JavaScript’s, you can do without, with little and again, focus on the network, on transferring all those bytes to the client. Think about the mobile browsers because there was this experiment where you can see how long it takes just to parse and evaluate a big library such as jQuery, even if you have it in the cash, even if you don’t have to go over the network, just might take a while to evaluate this thing in the poor mobile browser. So start small, iterate as needed and I think is the mistake to start with planning something huge and designing for use cases, that might not be applicable later on, and then feel not in client to change anything in this architecture because you spend so much time already on it so let it evolve, have duplicate the same code to three times before he decide on abstraction if you need.
I don’t like IDEs at all, since I switch to Mac a few years ago, I’ve been using just as regular text made editor, I know there is now people’s talk about Sublime which is probably better and I’m just setting my way. Before that on Windows I was using a simple text editor called Text Pad, so all you really need is code Highlightning, good search, replays functions, auto-complete is kind of nice but not really required.
There was one talk by Douglas Crockford where he was giving this example where: “If you take all the code that you’ve written last year and start to retyping it, it will probably take you about a day, a day and a half”, not very interesting day but you just sit down and retype everything that you’ve typed in the last year in a very short period of time. So then the question is: ”What are you doing in the rest of the time?”, and it’s not typing, so that is why focusing on the IDE is kind of probably not the right problem to solve. Most of the time they try to eclipse for PHP before that was a Zend Studio, so it’s just too much of IDE to go on, so all you really need is a good text editor, and wherever the tools don’t give you, you can, you know how people say that any problem is really a people-problem. I like to think that any problem would have people-solution, so things like code reviews and training everybody on the team, looking at the same code, you can see the history and why this was done this way and what do you consider the history in the source control.
Working together on the same codebase as opposed to, this is my library and this is my class and nobody touch it and so on, so that is why having code reviews before you commit any code so first of all you get validation, second it gets better with the code reviews and then even people just stay up to speed with whatever it’s going on, people learned from others in this way. In terms of tools I think it’s a better option to invest in some sort of a process and code review tool because the code is that thing that you focus on the most and more kind of a social the development could be that nice, it suppose you just doing something, just protecting it because this is my turf.
I love this stuff, it’s developing so fast and it will probably make mistakes that I have to look for that for the next ten years, but I really like especially what Mozilla is doing with the Firefox OS and trying to standardize new API’s for telephony, SMS, vibrationAPI, all this is exciting and CSS 3 I’ve done nothing more than take one big chunk of JavaScript animation library and just throw it out and replace with a simple CSS 3 animation. I think all this is really exciting and interesting, and looking forward to anything new, any new toys that can use, like say I’ve been exploiting recently the web audio API’s and I really love the fact that….
15. You are also a musician, so you probably have a vested interest in these things?
Yes, going back I think one of the first things, I had one course in Pascal back in the time, in school, and after you learn how to declare variables and even before you get to arrays so when I wanted to see how you can make sounds with this thing, it was nice and exciting so I kind to fill the same way now, because all those, the music software that I’ve seen it’s like Photoshop or like your IDEs, it’s complicated and it’s too much going on, and having this low level access and doing anything you want to do with the sounds, that is really exciting.
Dio: Thank you very much, Stoyan!
Thank you Dio, it was a pleasure!