Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
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.
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.
4. You have explicitly expressed your grief about CSS. What are the main issues you have with it? Isn’t it still like the most superior technology for styling stuff, I mean, compared to writing classes for styling?
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 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.
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."
7. ECMAScript is mainly driven by committee whereas HTML5 although it’s being drafted by the W3C actually it feels like the browser vendors are steering the way; which of these two models do you feel more comfortable with?
We decided in the last meeting that we’re not going to do versioning in ECMAScripts in anyway.
9. There is an interesting quote from Brendan Eich in 2004 which goes like this and I quote," The dream of a new web based on XHTML, SVG, SMIL, and XForms is just a dream; it won’t come true no matter how many toy implementations come out," what are your feelings about technologies like Dart which tried to fundamentally change the way we build the web?
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.
Ill-fated technologies, start collecting that on a dead pool, I don’t know, I think.
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.
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.
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.