Konstantinov.CC

Keep calm and twirl on

To the Developers and beyond

Some observers heavily criticize the current state of W3C-developers relations, i.e. so called “workshops”. Indeed, this form of conversation could hardly produce any successful dialog because it lively reminds more of school exam than a dialog. And I, of course, totally agree with the critics: W3C should be more flexible and more open to developers and their ideas. There should be a friendly meeting, not a formal exam. But let me extend this thought.

The less formal procedure attracts more developers and more ideas, but, still, is just a face-to-face talk with some selected developers, usually of big companies. Though I don’t mean to underestimate their knowledge and experience, I should mark that big companies are more or less blinkered as they (a) tend to think in terms of their own needs, (b) pretty accustomed to the current state of affairs. So, if we really want to see more, we need to go farther to collect opinions of that great mass of developers that aren’t working for big companies (and maybe not for the web industry at all).

Why do I think that’s important? Because we have already walked that way here, at Yandex. We organized conferences and developer meetings (and, of course, it was very helpful meetings); we talked to developers face-to-face after the formal part and even at the after party. And finally we came to the simple thought; let me say it by the words of Henry Ford: If I had asked people what they wanted, they would have said faster horses.

The ultimate goal of every web developer effort is to solve their users’ problems. And the most valuable thing that we may collect from them is their users’ problems. When developer asks for a new functionality, we should ask him (or her) in return “what problem are you trying to solve?” Collecting just raw developers’ requests is deceiving as we are trying to implement some features without understanding the real purposes. I can tell from our experience that thinking in terms of businesses’ and users’ tasks solving leads to more accurate and precise solutions. Meetings are great, organize more meetings; they give you very important feedback, but the interpretation of this feedback is even more important.

For example, every developer at some moment begins to optimize the page load time of his application, and every developer has his own view how to improve this time. So we have lots of new APIs that should fasten the page load, and no one really works. We still have no cache-control, no mechanism to store byte-code, no control of browser’s network subsystem, no control over resources loading and execution. In fact, the only thing that somehow fastens the page load is the increasing of browsers’ performance. (And, maybe, SPDY for https pages.)

Another problem is non-transparency of browser DOM rendering process. For years we have only some fragmented knowledge on ‘reflow’ and ‘repaint’ events. Browser is a sort of black box: you’re doing some magical optimization following some magical rules, and it works faster. Or not. So we need some mechanism to control reflow/repaint. What we got instead? requestAnimationFrame API. Does it optimize the rendering? Yes. Does it solve the problem? No. We still have no control on the rendering process, and now we have two sets of magical rules: one for reflow/repaint optimization, one for requestAnimationFrame usage.

And so on. As far as we just implement features without understanding their goal, we would just multiply total amount of magic. (That, of course, is cool if our purpose is to raise web developers’ salaries.)

So, the first point is: find the reason and the very problem in any developers’ request. From our own experience the most valuable source for these purposes is the one, which is greatly underestimated: questions and complains at blogs and forums. Nothing shows the problem more vividly than tons of amateurs’ questions like “why my page is so slow” and “I wrote <something> and it doesn’t work”. I personally read most of email and forum questions regarding our APIs, and I find this task boring but necessary.

So, the second point is: get more opinions. Collect it from StackOverflow or MSDN forums, not from developers and architects who see no problem in writing 100 lines to solve the simple task.

And the third topic I’d like to discuss is the problem of obtaining developers’ feedback. It is said that attracting more developers on earlier stages of spec development lifecycle will produce more valuable feedback. It is, but, from our own experience, we can’t rely on this source. There is one major problem: most of developers, which are able to read the spec and formulate their thoughts on it, are already working with W3C. If you want developers to test the spec, you need to implement it; and since you implement it, you cannot break backwards compatibility. Our recipe is simple: just do APIs that could be altered withoutbreaking the back compat. Oh, that’s a tricky thing, of course, but our experience tells us that it’s the only correct way here.

So, my conclusion (and my program) on the W3C-developers relations is:

  • get more opinions;
  • solve developers’ problems;
  • read all the feedback;
  • make APIs extendable and alterable.