Monday, September 13th, 2010

Web Ninja Interview: Erik Arvidsson

Category: Web Ninja Interview

Today kicks off a new series focused on interviewing people doing amazing work on the web using JavaScript, CSS, HTML, SVG, WebGL, or any of the other new-fangled Three-Letter Acronyms coming out. We call these people Web Ninjas.

Our kickoff blog post for the Web Ninja Interviews is Erik Arvidsson, one of the original Obi Wan Kenobi’s karate chopping JavaScript whether it’s called DHTML, Ajax, or HTML5. He is one of the original JavaScript bad-asses. Let’s begin.

Brad Neuberg: Tell us a bit about yourself, where you’re from, your background, interests, and some projects you have worked on (don’t be humble!)

Erik Arvidsson: I’m a Frontend Engineer at Google and I’ve been there for 5 years.

I’m currently working on Chrome. A lot of Chrome’s UI is done using HTML+CSS+JS. For example I created the New Tab Page and the new Bookmark Manager. Working on Chrome is a breath of fresh air. I no longer have to care about cross browser issues and I can use all the goodies from HTML5 and CSS3 that we have in Chrome. Another big difference working on Chrome UI compared to working on web apps is that we only have to work with ToT (tip of tree) and when I find bugs in Chrome/WebKit I try to fix them instead of finding work arounds. As soon as the bug gets fixed I know that 100% of the users will have the bug fix.

Before Chrome I worked on Gears and then later moved over to the Gmail team to ship Offline Gmail. Working on Gmail and Offline was very exciting. Gmail is the largest web app I’ve worked with and it taught me a lot about the issues with large scale projects using JS. For example, the large memory working set caused us to have to do major low level refactoring to not get dog slow in IE6 since JScript had an extremely inefficient GC.

When I got to Google the state of JavaScript was a mess. Me and Dan Pupius took it upon ourselves to fix this and Closure (library) was born. A lot of the best practices from creating large scale web apps such as Gmail went into Closure and we worked closely with the Closure Compiler people making sure we would get the most efficient JavaScript possible.

I am also a member of the ECMA TC39 [working group]. The group that is responsible for the standardization of JavaScript. JavaSript as a language has a lot of warts but I love the flexibility that it gives us developers. Yes, it is too easy to do the wrong things in JS and I think JS needs some soft boundaries to encourage the programmer to do the right thing. Today, writing programs that are efficient and easy to maintain requires too much boiler plate code. I also think it is important to continue to keep JavaScript dynamic and flexible. I am afraid of initiatives to make everything static and locked down. There are plenty of good static languages and there are lots of projects that compile from <insert language here> to JavaScript.

Before Google I worked on a small company where I created a GUI toolkit called Bindows. It was a big change going from a 1 engineer company to Google and working on a code base with hundreds of different engineers.

Earlier than that I created WebFX with Emil. This was one of the earlier DHTML web sites and it got quite a lot of creds back in those days.

In 2000 I worked on something called WebOS (yes, that was the name) and we built a complete desktop environment and GUI toolkit for IE5 and later rearchitectured that to work with Netscape 4 and IE4 (yuk).

I got into DHTML around 98. I had a web page at my university where I used a lot of CSS for IE3 and I was into the whole beta scene. I was pretty excited what early alphas of Windows98 where doing with Windows Explorer where a lot of the UI was done in HTML and I absorbed every little method and property as the IE4 developer previews came out. It was like Christmas every time a new beta came out. One thing that made me so excited about DHTML was that I could with, very little code and no compilation, do things that would take hundreds of lines of code to write in Java, C++ or any of the other languages/toolkits they were teaching at the university.

Brad Neuberg: You were one of the first to jump into DHTML, watched the transition and rebrand with ‘Ajax’, and have watched as HTML5 has come on the scene. What are some of the things that excite you the most about what is happening on the web today? Are there any old tricks in particular you are looking forward to not needing to do as more modern browsers arrive on the scene?

Erik Arvidsson: I think one of the most exciting thing about the web is the richness and usability of modern web apps. The speed improvements that Chrome pushed so hard for have paid off and all the browsers today are a lot faster. The other reason applications have become better is the tireless work of people like Steve Souders who keep reminding people that latency is important.

I find a lot of the new CSS3 features available in WebKit allows me to do more with less. I really like being able to use a canvas as my background image and CSS transitions (although I often find them too limited) are really amazing. I also like the direction aware CSS properties (padding-start, margin-end, text-align: end etc) which allow me to remove a lot of CSS that is used to display the page correctly in RTL. I understand that most people do not have to care about RTL but for Chrome all the UI has to work in RTL.

With IE9, event abstractions is a thing of the past and good riddance. Just implement your own EventTarget interface and your JS objects works exactly like the DOM objects.

I’m also happy that Explorer Canvas will not be needed much longer. It was a fun project but VML in general was never well implemented and it has caused me a lot of head aches.

Brad Neuberg: What are some of the things you are hacking on these days (that you can talk about)?

We’re finishing up another iteration of the New Tab Page for Chrome as well as moving all the settings UI to HTML. Besides from that I’m getting more into WebKit. It is such a mind blowing change to be able to actually fix the browser when something is not working as it should.

Brad Neuberg: Where do you see HTML5, CSS3, SVG, etc. (i.e. the new stuff on the web) going in the next year? How about the next 3 years?

Erik Arvidsson: I’m really excited about IE9. I feel like all the browsers today are finally supporting a big chunk of CSS, JS, DOM and HTML. If you are willing to use Chrome Frame for your old IE users all your users will have access to modern web APIs. This has never happened before and I expect a lot of applications to be rewritten with this in mind, leading to faster, more interactive and more usable applications.

Another big thing is that I believe that the innovation in the web browser and the standardization communities have been focused on providing missing capabilities like drag and drop of files, offline, rich graphics etc. However, the usability of these APIs have been lacking. Everything feels more disconnected now than it ever did before. I think and hope that we will see a lot of work making things fit better together in the future. I have a few pet peeves that I would like to see fixed:

How come NodeList is not an instance of JS arrays? Why can’t I do document.querySelectorAll(‘.foo’).forEach? Why can’t I splice that collection? Yes, there are issues with some of these collections being read only etc but nothing that cannot be solved. Why is it that DOM and JS never seem to fit together? Why can’t I do “new HTMLButton”? Why can’t I create custom HTML element in JS? How come all JS libraries wrap elements with a JS object and they all build their own component models that never work together.

I think some of this comes down to be able to make the platform self hosting. I’m not saying that we should build the input[type=range] element in user code. I’m just saying that I think it should be possible to do so. Same goes for CSS which is far from extensible today.

Brad Neuberg: What is a clever hack, trick, or elegant turn of code you’ve discovered or created while working with JavaScript, HTML, CSS, etc. that you are particularly proud of? Give good details, and don’t be afraid to be technical :)

Erik Arvidsson: This is a trick that I settled on while working on the Bookmark Manager for Chrome. It allows you to sub class HTML elements which in turn allows you skip the common JS wrapper that all JS toolkits use.

javascript
< view plain text >
  1. var myButton = new MyButton;
  2. myButton.innerHTL = 'Hello &lt;b&gt;World&lt;/b&gt;';
  3. document.body.appendChild(myButton);

The trick here is to use a SpiderMonkey extension that all JS engines except JScript supports. The extension allows you to change the [[Prototype]] of an object using the __proto__ property.

javascript
< view plain text >
  1. function MyButton() {
  2.   var element = document.createElement('button');
  3.   MyButton.decorate(element);
  4.   return element;
  5. }
  6.  
  7. MyButton.decorate = function(element) {
  8.   element.__proto__ = MyButton.prototype;
  9.   element.decorate();
  10. };
  11.  
  12. MyButton.prototype = {
  13.   __proto__: HTMLButtonElement.prototype,
  14.   decorate: function() {
  15.     ...
  16.   },
  17.  
  18.   get myProperty() {
  19.     ...
  20.   }
  21.   ...
  22. );

In the code above the constructor creates an element but it changes the prototype chain of the element to add our custom object before the built in prototype, effectively allowing us to inject our own behavior, and then returns that element. Now you can effectively work with the element instead of having to keep track of whether you got the element or the element wrapper. Things like document.querySelector(‘.foo’).myProperty just works.

Brad Neuberg: For folks that want to do the kinds of cutting edge things you’ve been doing and have done, what advice or resources would you give them?

The way I learned it was to read the API docs of MSDN (the whole thing). With every new release I scoured for changes in the DOM (using for in loops) but today you can do the same with Web Inspector or Firebug. Just keep playing with the new stuff, you don’t have to build anything useful, just get a feeling for what the API can do for you. One thing that I found fun and educational was to build small games. Just take one of your favorite games from the 8-bit era and reimplement it. It has never been as easy to do this as today since we now have canvas (WebGL) and fast JS engines.

And of course, read Ajaxian and other blogs to see what crazy shit people are coming up with these days.

Brad Neuberg: Thanks Erik!

Posted by Brad Neuberg at 6:30 am
10 Comments

++---
2.7 rating from 6 votes

10 Comments »

Comments feed TrackBack URI

Nice interview, funny hacks :) In case anyone is wondering, Erik created a HTML5 UI Framework just for Chrome, it has awesome stuff :) http://goo.gl/ERTp and the Bookmark Manager that uses the crui http://goo.gl/9STC

Comment by MohamedMansour — September 13, 2010

Inspiring read. It’s great to hear from someone like Erik who is obviously at the top of his game. Love the tip about HTML element __proto__ property; i’ve seen this before but never really grokked the usefulness until now.

Comment by christopherscott — September 13, 2010

Nice to read about some of the old-skool DHTML heads; I was a reader of eae.net articles back during that time. More of these, please! (cough – Alex, Dan, Mr. Monkeyman etc.! :D)

Comment by Schill — September 13, 2010

Good read! :)
.
The MyButton example is intriguing – especially considering the “Extending-DOM-is-verboten” discussions… Of course the example only extends the created element (no pre-existing elements – and is JScript incompatible) – but the thinking behind it is not too dissimilar to what MooTools does and Prototype used to do.

Comment by rasmusfl0e — September 13, 2010

I love the __proto__ property. I am glad it is getting some love.

@rasmusfl0e Prototype still augments element prototypes and is more aggressive at it than MooTools. That is why Prototype will *crash* IE8 when attempting to use some CSS behaviors (HTC files) and MooTools won’t. It is also why all but the most recent stable Prototype fails in IE8. Both frameworks have stated they are moving away from extending elements in their 2.0 releases which are realistically years away.
.
On top of this there are other gotchas that might crop up when messing with element prototypes. For example some browsers will have SPAN, EM, VAR, B and other elements share the same constructor instead of having their own like HTMLDivElement.

Comment by jdalton — September 13, 2010

I hate to be a killjoy but I have to point out that __proto__ is not a standard part of JavaScript nor is it supported by Internet Explorer. /killjoy

Comment by deanedwards — September 13, 2010

@jdalton: the constructor may be deduced through kangax’s method – no need to hardcode it:

Object.prototype.toString.call(document.createElement('span')).slice(8,-1)

…I think.
.
I didn’t know about the state of Prototype though.

Comment by rasmusfl0e — September 13, 2010

@rasmusfl0e – No prob. For more info:
.
Issues with unexpected element [[Class]] —
http://twitter.com/jdalton/status/21515320598
.
Incorrect __proto__ mapping —
http://twitter.com/kangax/status/18326489724

Comment by jdalton — September 14, 2010

“How come NodeList is not an instance of JS arrays?”

We have gone over and over this. The cure for stupidity has not yet been answered, though the question of why NodeList is not an Array has been answered over and over and over.

The extension allows you to change the [[Prototype]] of an object using the __proto__ property.

Good points by JDalton and killjoy (odd) – thanks, I had a bit of relief in seeing you’re reply to the clever hat trick.

Why use new MyButton when the this value is not used in that constructor?

This: looks like a typo: myButton.innerHTL

You mentioned Bindows. I actually remember that! Hyperion was using that as late as 2006, IIRC. I remember a project lead at Oracle who had actually copied the design architecture — converting XML to HTML using javascript. He was proud of this idea he’d copied. I turned down both of those jobs.

Comment by dhtmlkitchen — September 14, 2010

Garrett: answering the question badly over and over again doesn’t improve the quality of the answer. Arv isn’t looking for a spec-ese response to why ES semantics can’t express a constraint that some DOM interfaces impose (although in some other forum, I guess that’s interesting) — he’s asking the more fundamental, more important question: why *should* these things be different? And what can we do to bring them in line?

Do you have to fix both sides (DOM & JS) to make that better? Yes. But that’s just the shape of the TODO list, not a reason not to fix things.

Regards

Comment by slightlyoff — September 15, 2010

Leave a comment

You must be logged in to post a comment.