Hi, I’m Alex Russell, I’m a Software Engineer on the Chrome Team; I’ve been working on Chrome since 2008, I guess. I initially started working on Chrome frame which is a pluggin for IE and then have more recently been focused on sort of web platform technologies and for this year 2012, I’m splitting my time between that and Chrome for Android here in London.
2. Before Google, you were working for Dojo?
I worked in Dojo toolkit which is an open source JavaScript toolkit like jQuery or YUI and helped found the project with my friend Dylan Shieman and David Schontzler] and friends, I guess, and it kept growing and eventually I wanted to work on sort of solving the same problems but from the inside working on the browser itself and so I went to Google.
I’m not the world’s finest C++ engineer and I think everyone who knows me, knows it but I’m grateful to work with some of them and you know, it’s funny especially working on Chrome frame. I felt like I was doing the same job but from a different side because as a web developer, who was working on a library, you’re trying to find hacks to sort of call together to build a coherent thing that you could sort of build a platform for; and when you’re sort of assuming in the guts of IE or sort of doing the same thing, I mean, the day is different; the compiler cycles are a lot longer; so the iteration is slower and you feel like you’re going slower but there is more leverage to be had on the C++ side of the side of the fence.
Sure, I think if you talk to someone as a print designer; they’ll tell you that CSS are sort of inadequate for what they’re trying to do; and some of that is just implementation. So we have performance requirements where like it’s not really reasonable to the orphans and widows yet; or to do sort of new quality text lay out. In a lot of cases, we have plenty of real time layout on the browsers. So there are hard constraints that way.
But there’s also sort of expressiveness constraints with CSS and I think a lot of those are artificial, you know, the fact that we don’t have variables, mix-ins and hierarchical CSS yet in 2012 is, it’s frankly, embarrassing and so the team that I work on has been trying to find ways to add those sorts of capabilities into the platform in a way that everyone likes and I can sense building this thing is slow but if you look at the set of tools that people work on, working on desktop layout, they’re superior, right? Real style sheets, there are sorts that are built and the things that are built in design are vastly powerful and they give you flexibility that we just don’t have yet; so yeah, that’s a long way to go.
So I think there’s a huge potential for improvement all the way through the tool chain. If I had to pick one, I would obviously pick CSS but the next in line would be DOM; so today, the HTML DOM, the document object model is not maybe designed with JavaScript in mind and HTML sort of specified this DOM in terms of IDLs; so they don’t already talk well together and I feel like if DOM was specified in a more idiomatic way, with regards to JavaScript, we wouldn’t need to curb so much of our own infrastructure around the network with us because that’s already the most expensive thing when you’re loading with pages is waiting for resources to load and if you’re waiting on JavaScript, that can block rendering as well.
So getting ourselves to a place where DOM is more expressive and more idiomatic and we have less need for tool kits like Dojo of jQuery or Prototype for YUI is, I think, the thing we should need to do is for the DOM working group and they’re making big strides here. We got API find and findAll through to replace this sort of slightly busted queries like querySelector and querySelectorAll.
So those are good and that’s a real improvement and I hope we continue to have more of that because I think it’s the kind of thing where we’re going to have big gains when we add that sort of integrated view of how an API should feel from both regular JavaScript and from sort of browser provider APIs and it means that you have less things to wrap it and fewer barriers when you’re thinking about building your program.
I don’t know that it’s hopeless like that. I think it is sort of an unfortunate reality of the history of web platform that lots of different parts are specified in lots of different places; so for instance, SVG’s integration with HTML until recently wasn’t that great. It’s only gotten recently but it’s because people said, "Hey, this thing should talk together better."
We had a similar situation with, I think, some of the way that JavaScript interacted with DOM or classes and prototypes, that’s getting better and that’s all about getting people in the same and talking to each other; but the fact that they happen in different organizations may not be the key determinant of how often these conversations happen. I think it’s more of a question of: "Do the people in both organizations take it as an important task to further that kind of dialogue?" and I think there’s more of that happening now than it has been in the past, so I’m hopeful.
There are differences in type between them but it’s also the case that the people who are at the committee for TC39 there’s JavaScript committee which I also attend meetings for mostly come from browser vendors; so it’s not like it’s us and them; it’s us and us. There is some, I think, frustration from the perspective of some web developers that they haven’t had as large voices they might in either conversation.
And it’s a little bit more esoteric to talk about the syntax and semantics of program languages than it is to say, "We need new tag to do it," and it’s a little harder to walk back mistakes inside of program language like JavaScript if you make a syntactic or semantics error; so maybe you need a slightly longer date cycle for program and language than you do for HTML because HTML has and CSS have this nice error correction capabilities built into them which allow you to sort of iterate alongside of the existing stuff with good fallback.
So JavaScript just doesn’t have that yet. So, looking for versions and mechanisms in the platform is actually something that I think it’s going to become a more pressing need; and I know the HTML working group doesn’t feel the pressure right now but I think everyone else is sort of seeing the need to sort of like flush these APIs out so we can keep moving forward and JavaScript is in a similar boat although not in that version I think.
We decided in the last meeting that we’re not going to do versioning in ECMAScripts in anyway.
Imagine that the JavaScript language as we specified is actually kind of the smallest bit of the experience of what developed for the JavaScript. The canonical complaint is: "JavaScript sucks. What do you mean? Well, I always have different browsers and they don’t rock the same way. And I’d say is, "What you mean is that the DOM sucks," or, "The DOM sucks for you in this way because it’s incompatible or because you have some frustration with it," and so the DOM is JavaScript’s largest library, and its most important library; and I think to the extent that DOM can get better, can give us better hooks; can be more idiomatic, can give us a better ability to use JavaScript than in the natural way to help ourselves out when we need it. We can do better there and a lot of the things that we would want eventually turn off are DOM APIs, not JavaScript syntactic quirks.
JavaScript is actually, some of you might disagree but it’s still a relatively small language and that’s certainly very well specified language, thanks to Allen’s hard work.
I hope no one will take everything I said in 2004 against me but luckily Brendan was patient. He was right that the adoption dynamics of XML were poor; so Dart doesn’t necessarily suffer from the same adoption dynamic problem. If you look at what we’re doing in JavaScript as a community, we were carrying a very large tool chain across the way with us in order to just get anything done; and so you have language like CoffeeScript which are compiled JavaScript or you have Dart which in most today’s uses are compiled to JavaScript where they can be very efficient and they can actually strip a lot of the stuff that would be in a normal jQuery download that you might have to ship down the wire.
So there’s a rule there for them - that team to go make big strides to help people think better about structuring their program and I helped design the Dart DOM API with Erich Robertson and Jacob Richmond and all the other folks on the Dart team; and I think being able to take the opportunity to have a clean slate there in the DOM area where it’s like the DOM being the largest API that you have to deal with on a day-to-day basis; that’s already is sort of the kind of thing that’s going to change what and how you do things but because it isn’t an exclusive choice, the adoption dynamics are a little bit different and I think it’s unclear whether or not the Dart strategy is going to be the one that will deliver the most value to the most people.
My focus has been on the APIs, I mean, I work on JavaScript language; and again, if I had to pick a thing that had to get better immediately, it would be the APIs; it would be DOM and it will be JavaScript; there would be the levels of obstruction that are available to you in the platform to plug into, to sort ot take hold of the power that’s already sitting there and that’s a challenge that exists for every language not just JavaScript.
11. No, I was talking about technologies that seem to be not necessarily failing.
I think what we’re going is that there are series of (and I’ve been proven wrong for many times) so let’s put a big asterisk next to this but I think that it has been folly to attempt to specify low level APIs at the level of something like WebGL which has no retained mode component which is entirely direct mode. Direct mode is good; we want direct mode but the level of obstruction is so low that if our strategy for saying in the web is going to be competitive in terms of building responsive applications, it’s to take that for low level thing and build everything up on top of it; put everything you need out of WebGL content.
12. You mean the vendors or people that come to ...
Yes, because what we’re doing here is we’re shifting costs from vendors to users by saying, "You should go and find three.js and a bunch of other different libraries and do things like unpacking models, managing sound and all that stuff that will be going to give you no declarative of high level form or even a scene graph even that much to get you out of the gates with.
I think WebGL is an example, Mozilla’s audio API is an example; doing too much on the YUI thread is always bad architecture and I think this exacerbate a bad architecture and they are the new shine now and are doing well but I think they will be proven to have had limited utility outside of their initial target user base which is the sign of a good point technology and a poor platform.
Well, I think part of it is that audio APIs on operating systems have gone through a lot of contortions themselves. Chris Ryders are working on the audio API for the web audio API which is a low latency, multi-channel audio API which we’re working on in Chrome and does very low latency multiplex spacial and filtered sounds like you would see in a AAA 3D game today but from JavaScript.
The key to making that work is having really solid underpinnings that you can plug into strategically as opposed to trying to do all the processing in JavaScript. And that’s the sort of domain lesson that you don’ t learn quickly, I mean, Chris was one of the guys who helped built core audio with Apple; so he knows that entire set of problems and finding talented designers in that way - people who understand the entire scope of the problem. Progress really does block on finding the right people in a lot of cases. People are not interchangeable when it comes to making things better.
I think they’re getting better. The reality is that you as a user most often continue to get your browser from your operating system; that’s just how it works; statistically speaking, that’s true. Mobile devices and on the desktop , it’s more true on mobile but in part that’s because there isn’t the same sort of overhang of it, of excess CPU and memory bandwidth and I/O that we have sort of laying around on the desktop.
And so I’m hopeful that we’ll see that tradition of multiple browsers available on operating systems in your pocket as well as on your desktop starts to take hold.
But in terms of having choices, it’s a really good time to have choices. There are multiple high quality browser available for almost every operating system I can think of. The only places where that’s not already not possible are iOS and I guess Windows phone doesn’t allow you to have alternative renderer or ship unmanaged code either; so I think those are kinds of the sorts of places right now; but again, they’re tied to relatively limited platforms at the moment; so we’ll see what the future holds but it’s a already good time.
And in terms of sort of the trailing edge that kind of causes so much pain for developers getting cleaned up, the difference between the leading edge and the trailing edge is getting so large; it’s accelerating so much faster, I hear that it’s getting fixed back here that I think options like Chrome frame become viable in the gap where the goal is to give developers the excuse to go build awesome stuff so that they then have awesome stuff to say to users, "Hey, you should change what you’re doing," because if they’re in a sort of the same band, that’s an easy choice for a developer to make, it’s an incremental market share; but if there’s a way out here and the gap between what you want to do and what you can do based on those requirements is so large; you’re going to be looking for other options and I think the next year or two is going to change what happens with the way browser evolve even more dramatically than the last couple of years have and it’s a good year for us collectively as web developers.