Ben Galbraith, of Mozilla Labs, is speaking at Web Directions South ’09 on The State of Browser Tools. I had the opportunity to interview him about his Web Directions session, the Bespin project, and browser tools in general.
The focus on developer tools by browser makers – inspired by the rise of Firebug, I believe – is welcome and exciting in the web development industry. What can people expect from your Web Directions session?
Recently, I heard someone claim that “developers can never have too many choices! That’s what’s so great about the Web!” Respectfully, I disagree.
While I’m a passionate supporter of liberty, as we reflect upon the state of the Web and its future, I think we need to balance our respect for liberty’s bounty – choice – with the great research done by Barry Schwartz, who articulates so well that “more choice makes us less happy.” The more energy we have to spend choosing between nuanced options, the less we have to enjoy the choice we’ve made. What’s worse, it can rob us of enjoyment altogether if we spend our time wondering what might have been had we chosen another path.
In my talk, I want to address this by helping attendees cut through the sea of choices, to discover some of the tools available to help them create amazing web applications.
We now have DOM and CSS inspectors, as well as JavaScript debugging and benchmarking widely available within browsers. Where do you think developer tools will go from here? What do you think are the most exciting ideas currently being explored in the world of developer tools?
The trend that has me most excited is the opening up of the browser’s debugging facilities so that external tools can be easily integrated with them. At Mozilla, many of us are jazzed about this direction and we’re working to see how we can best open up Firefox in this manner. I’m a big fan of the work Sun has done with their Java Platform Debugger Architecture (JPDA) in this regard; it really sets the bar for the kinds of debugging services runtimes should expose.
Related to this, I am super excited to see the tools emerge that are necessary for treating the browser as a sophisticated application runtime, like the new memory tool we’re working on here at Mozilla Labs and the work that Google has done with their own memory tool in Chrome.
I think we’re going to see a ton of extremely exciting developments in both of these areas in years to come.
We’ve come a long way since the days of having to use the alert function for debugging. Aided by the great level of standards support in modern browsers developers now have a choice, and often have a favorite browser in which to do the bulk of their development. Thomas Fuchs has said his preferred development browser is Safari 4. Our own technical director, Kevin Yank, says he prefers Safari for daily browsing but Firefox for development, because of Firebug. Do you see in your work that the quality of the available development tools have an effect on the popularity of a particular browser to developers?
I’m unsure what the relationship is between a browser’s developer tools and the browser a developer uses to surf the Web. In some cases, it can actually be more convenient to use different browsers for these different activities. Certainly for Firefox, I suspect the percentage of our 300 million or so users that are web developers is … fairly low.
Having said that, we at Mozilla are committed to the developer tools space and very much want Firefox’s developer tools to be fantastic. This isn’t so much for browser popularity – you could argue that there are far more productive investments we could make if were that our goal – but because we think it’s right for the Web as a whole. We love that Safari, IE, Opera, and Chrome are doing great things in this space and we hope that our work in this area can, collectively with theirs, raise the bar for everyone.
As to Safari versus Firebug, I look fairly closely at this. What I love about Safari’s tools is their attention to fashion and detail (which comes as no surprise from Apple). For example, I love the way their debugger’s source code viewer highlights the current line as you mouse over it and I’m a sucker for the aesthetics of their network timing information. But on the other hand, I much prefer Firebug’s very detailed breakdown of the networking timing when you mouse-over an item and richer JavaScript debugger features (like providing a more useful stack list and a central breakpoint list).
Firebug certainly has its share of weaknesses; we’re working with Firebug’s primary maintainer – the amazing and prolific John J. Barton – to help resolve them.
Even though a developer may have a favorite, testing still needs to be done in all browsers. As much as it’s important to be able to peek into what’s going on inside a browser’s rendering engine, having a different set of developer tools for each browser adds complexity. Do you think it benefits developers to have so many dev tools to manage? And is there anything we can really do about it? Is there a better way? Are developer tools all converging on the same usage model?
I addressed a bit of this earlier in calling out the trend of browser runtimes opening up debugger APIs. But until we get to that magical world where we have tools that work across browsers and consume the different platform debugger APIs, most of the tools have actually converged on very similar user experiences by following Firebug’s lead. While details can differ significantly from browser to browser, the basic usage model is very much the same.
Opera Dragonfly included a remote debugging capability that was useful when developing for Opera on mobile devices. Do you think this is an expanding area for development tools? What’s more useful to developers: live testing on a real device or testing on emulators? Any plans at the Developer Tools Lab for mobile development tools?
Again, I talked about some of this earlier, but to your last question: Yes. Bespin has already had some work to connect remotely to browsers with mobile browser platforms specifically in mind. There’s just a small amount of work left to connect this feature to, say, Firefox, Fennec, Chrome, or other such browsers running on desktop or mobile.
Bespin is immediately impressive, but also puzzling. Is it just a code editor? Is it a collaboration tool? Is it a hosted service? Is it an application platform? Is it all of these, or none of them? What’s your vision for Bespin?
It’s all of those things. Right now, Bespin is an experiment, so its definition and boundaries are a bit fuzzy. But what’s emerged since we kicked off the project a few months ago is that Bespin needs to be (1) an embeddable editor, (2) a full web-based social coding environment built around the editor, and (3) a hosted service that provides the web-based experience.
We’ve seen lots of folks embed the editor, spin up their own Bespin instances, and use the current service we offer experimentally at bespin.mozilla.com – and we’re profoundly grateful for all of these users, their feedback, and especially their patches!
Our vision is that Bespin transforms the way that you and I write code by (1) moving our coding environment to the cloud, making it available from any browser (including mobile browsers), (2) making the experience extremely social, and (3) decreasing the friction of contributing to open source projects.
Making use of the canvas element is an interesting decision. How much of the Bespin interface is within the canvas element? How versatile is the canvas element? Why did you choose to do it that way? Do you think Microsoft will ever support the canvas element? Do you think it has potential to be an application interface platform? Is that the idea behind Thunderhead?
We initially chose canvas to power the editor because I felt that was the only way we’d gain the performance and control necessary to create a high-quality text editing experience. Even code editors developed on platforms designed to support custom text editing components wind up rolling their own text editors, so it didn’t seem like that big a stretch to go that direction. As it happens, I have a good deal of experience with an API like canvas (Java’s Java 2D API) so I was able to whip up the basic prototype for Bespin in an hour or two. The rest flowed quite naturally from there.
I hope Microsoft supports canvas; we’ll just have to wait and see. The politics behind that decision depend on Silverlight, Windows, Internet Explorer, and other dynamics that interrelate in non-obvious ways. If I had to guess, I’d say they’ll wait to see if any large web property makes use of it and actively encourages users to switch to something besides IE before they’ll roll it out. I don’t see how it would serve their Windows or Office franchises to proactively implement it. After all, Microsoft’s motives are fairly transparent.
Early in Bespin’s life, we experimented with using canvas to do more than just being a code editor; we implemented a file browser component with it as well. As part of that exercise we created Thunderhead, a JavaScript GUI toolkit that renders with canvas and interoperates with DOM elements. At the time, some folks said we were reinventing the wheel but we had a vision of implementing features and effects in 2D-rendering that were just not possible with the DOM API. But two things happened that have convinced us this was a wrong turn. First, Apple’s pioneered CSS effects caught on big time and are generally accepted by a lot of people as being an effective model for integrating fancy 2D and 3D effects into the DOM API; second, we realized just how much work building a general-purpose UI toolkit is. I thought I knew how hard it would be, but I was off by an order of magnitude. It’s very hard work. Any benefits to be gained from implementing cool features, and so on are pretty much nullified by the time investment required to get a thousand little details right.
So we’re in the process of applying the lessons learned from Thunderhead; it will be pared down in scope to become the framework that drives Bespin’s code editor (which will be canvas long into the future) and we’re likely to use DOM elements for all the other UI pieces in the system. But we may yet use it here and there for small parts of the UI that need custom, dynamic rendering.
A slight detour: I have a problem with that name [Thunderhead]. I keep thinking “head” in the nautical sense. Isn’t there a better name? How about Tibanna, Lobot, or my favourite: Ugnaught?
How about Dreadnaught? ;-)
In the Bespin video you mentioned performance optimizations you were able to implement. Microsoft released a report detailing what they expressed as the “limitations” of browser performance benchmarking tools, and that “real world” performance is not reflected in microsecond differences in the results of JavaScript runtime performance tests. Would you agree, and why or why not? What is a good testing of browser performance? What were the major performance hurdles you faced developing Bespin and how did you overcome them?
Ultimately, I only care about perceived performance. Keep the interface responsive, blocking for no more than 50-100 milliseconds after a click and pushing longer delays into the background. JavaScript gives us the tools we need to do this, so that’s fine. And, thanks to web workers, we can now actually do expensive computation on the browser client in a separate thread to the user interface, opening the way for even more classes of apps to run in the browser.
In general, measuring performance at the microsecond level is meaningless for application developers; only runtime platform engineers should care about that kind of granularity.
Our major performance hurdles with Bespin have been and remain keeping the text editor’s rendering loop – the code that repaints it when needed – as fast as possible. It seems code is constantly being added to this critical path that causes Bespin to be less responsive than we’d like, and we have to go in and push it off the main path. The faster the JavaScript runtimes become, the less of a problem this is; but when mashing the keyboard, you can sense delays down to the 10-millisecond level, so on principle we try to keep this path as smooth as possible.
Other areas of performance are not generally a problem.
What developer tools were useful during the development of Bespin?
Firebug! :-)
What else can we expect from the Developer Tools Lab at Mozilla?
We’re focused right now on the areas I described above: Bespin, opening up the browser runtime by exposing debugging APIs, helping developers choose the right tools, and improving Firebug. But, we’re a lab, you never know what else might escape!
Andrew TetlawiOS Developer, sometimes web developer and Technical Editor.
