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.
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.
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.
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 general, measuring performance at the microsecond level is meaningless for application developers; only runtime platform engineers should care about that kind of granularity.
Other areas of performance are not generally a problem.
What developer tools were useful during the development of Bespin?
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!