My first two years at Mozilla have been great fun and an amazingly positive experience. This year promises to be even more fun, where I define fun as going after some ambitious goals. This year, we’re going to be building some very cool tools and setting the stage to push the boundaries of web developer tools even farther in 2012.
Now is your chance to get in on the ground floor of this work. Be a part of the open web and help us make better tools. It doesn’t matter where you’re located… if you’re an amazing web developer or have deep developer tools knowledge, I want to talk to you.
I’m going to use this opportunity to make a couple of observations about Mozilla and planning. If you really just want to know about what we’re thinking of doing next in Mozilla’s developer tools group, you can take a look at the current draft of what we’ve got in mind for later this quarter. There are links in that document to join the dev-apps-firefox list or to email me. If you have feedback, let me know.
Now, for some thoughts on planning at Mozilla. I started working at Mozilla as part of Mozilla Labs. In Labs, we would often let an idea bake a little bit before turning it loose on the world. We wanted to have enough of an expression of the project available to show people what the truly idea is before they pass judgment on it. Open Web Apps was like that. A couple months back, an early take on some of that code was in a project called “vapour” on github. But, there are a lot of pieces involved in creating a coherent open web app ecosystem and getting a coherent picture together before starting the public conversation around it seems like a good approach to me.
Working on Firefox, however, is different. Firefox is an established project with a huge and active community. There have been a couple of times since I joined the Firefox team where I was discussing something with someone who then said “this discussion should really be in some public forum”. I think that’s fantastic. Firefox development is a public project from the first kernels of new ideas, as those ideas grow, when they ship and beyond. Firefox 4’s Panorama feature was like that. Ditto for Personas, which started out in Labs and eventually became a core, and very popular, part of Firefox.
Working on open source software is great, because it makes it possible for people to add to the project in so many ways. Collaborating with other projects both complementary and similar is much less formal (and risky!) than the kinds of partnerships that form between closed companies.
On the flip side, software projects get messy at times and, with Firefox and other Mozilla projects, that mess is out in the public to see. I’ve seen a handful of articles over the past few months written by people that didn’t really get this. Every company has dates that slip, features that are dropped, etc. With Mozilla projects, you get to see this happening as it happens. With closed software projects, you just see the final result.
I did some work with a company a few years back where one of their mottos was “plan is a verb”. Sure, plan is also a noun… but, in their world, planning is something that happens all the time and a plan is just a snapshot of the planning that’s going on. Any plans you see me post should definitely be viewed in that light.
For some time, I’ve thought that many applications written as native applications for many different platforms could be done just as well as cross-platform web applications. I understand why people would make a unit conversion sort of application as a native iOS app, to give one example, but I’ve thought it’s a shame.
This is really cool. They’ve come up with a good solution that is truly open along every axis. Anyone can build apps and sell them through any channel (including their own!). This is the way apps should work.
Most “app store” designs lock people into a platform. It’s great to see an alternative ecosystem without the lock in.
Last year, I was disappointed to have to cancel my trip to JSConf.eu. This year, my luck was better, and I spent this past weekend in Berlin, along with two of my Mozilla Developer Tools colleagues, Joe Walker and Patrick Walton. Mozilla was out in force at the conference. Axel Hecht, who has been incredibly helpful bringing my team up to speed with localization, was in attendance. Oh yeah, and that guy from A Minute With Brendan was there. More seriously, I appreciated getting some good feedback from Brendan regarding where we’re heading with developer tools.
The conference organizers for JSConf.eu are fantastic, and I’ve got to thank Anja and Jan in particular for being exceedingly helpful. Jan even got us set up at co.up, which is a really nice coworking space that was easily reachible from our hotel.
You’re probably wondering if I’m just going to blather on about people… What about the conference? Seriously, the talking to people is what a conference is all about. The talks are great, but the hallway track is also fantastic in a small conference of enthusiastic people like JSConf.
JSConf is one of those conferences where you feel like everyone around is smarter than you are but, thankfully, also approachable, friendly and wanting to share.
Among JSConf goers, at least, the presence of Node is huge now. Even Peter Higgins was forced to mention Node in his talk after saying he wasn’t going to. There were several talks that presented solutions to the callback craziness that is a natural side effect of async programming in JS today. Jed Schmidt‘s (fab) talk was really entertaining and nicely done, though I fear that misplaced parens would lead to hard to debug problems. Tim Caswell‘s Step library looks like a more straightforward solution to the problem.
By the way, apparently Python 2.5-style generators have a decent shot at appearing in a future ECMAScript spec. These can provide a nice solution for making async code look synchronous without bad side effects.
Funny story: Saturday morning, Joe, Patrick and I were talking about the feasibility of making a fast, DOM-based code editing component, and whether that would help with accessibility. Later that day, Fabian Jakobs showed off ACE, which is indeed a fast, DOM-based code editor. His presentation, which was overall nicely done, had a factual error about Mozilla Skywriter. He stated that Skywriter would be slow for a big canvas because it has to redraw every pixel for each character typed, which is rubbish. Skywriter does a saner job of painting than that… That said, his demo was very cool and their server has a lot in common with the server that we’re planning for Skywriter. Fabian and I agreed that it would be great to find ways for our projects to work together.
On Sunday, I spoke with Nick from Shopify who has also been working on code editing sorts of problems. He ended up with the Canvas approach rather than DOM DOM approach to editing also and his editor even uses Skywriter syntax highlighters. Nice!
As for Skywriter, I think our talk went reasonably well, albeit with a couple of technical glitches. My computer randomly decided to go to sleep early in the talk (huh?). After we got past that, we talked about how Skywriter is different from the original Bespin project and showed off the Bookmarklet and Embedded uses of Skywriter. We did a live coding portion of the talk in which we created a Skywriter plugin on the fly (a live version of a tutorial I wrote in June). We altered the script just before the talk to save a little typing by dropping the third parameter to window.open. It turns out that dropping the third parameter to window.open (at least in Firefox nightlies) results in a new window that doesn’t have a document body. Oops. Looks like a bug we need to report, or something. Pro Tip: don’t alter your live coding script by even a byte just before your talk!
I finally understand from Kris Kowal‘s talk why Q.when is sometimes nicer than promise.then() (you can treat synchronous and asynchronous calls the same way), but I still think that promise.then is a fine way to go for many cases.
The conference venue was neat and very different from the typical US conference venue. Overall, the conference was simply great. The after parties were fun. My group also had a good chance to have some wide ranging discussions and work through some designs for Skywriter.
1. show respect for other languages as well, since most of us started with others
2. not to become JS fanbois
David Dahl has been leading the work on Firefox 4’s Web Console feature and has blogged about the work along the way. Over the past month, we’ve landed a whole bunch of improvements to the Web Console in Firefox 4 Beta, and I wanted to give my take on what the Web Console has to offer for web developers.
What is the Web Console?
I first learned to program a computer in BASIC on a TRS-80 Model III. I’m dating myself there, but oh well. Believe it or not, my first programs didn’t always work the way I intended them to and, surprisingly enough, they still don’t. I had two main tools to help me figure out what was going on: a “read eval print loop” (REPL) and “print”. Using the REPL, I could type in simple statements and get immediate results, as a way of testing that how I think an individual operation should work is actually how it does work. Using “print”, I could have my program display certain values along the way so that I could make sure that they met my expectations while the program was running.
Even today, REPL and print continue to be two simple and fundamental tools for learning how a system works and troubleshooting problems. The Web Console gives you these two features for web pages that appear in Firefox.
You can see the Web Console for yourself today by downloading the Firefox 4 beta.
When you open the Web Console from Firefox’s Tools menu (or using the ctrl-shift-K/cmd-shift-K keyboard shortcut), you’ll see a panel drop down from the top of the content area of the browser. In the current Firefox 4 beta release, the panel is empty when it first opens, but the Firefox 4 final release will collect up logging messages even while the console is closed.
The Net, CSS and JS controls determine which of those types of messages from the browser should appear in the output.
Finally, there’s a search box to filter the output based on whatever you type there
Using these controls, you should be able to quickly zero in on the messages that will help you debug a problem with your page.
With the request and response headers and body and the cookies from the request, you can dive deep into the requests made from your web pages.
The console Object
By strategically using the different logging levels, you can make it easy to focus on just the messages that matter to you using the filter controls.
One more note: for Firefox 4, we’re playing it conservatively with the console object. If one is already defined on the page, we won’t override it. As of this writing, there is a bug that prevents the console from working properly on sites that define their own console object, but you can bet we’ll have that bug resolved soon.
For your convenience, the Web Console will automatically try to fill in variable and function names that it knows about:
By using the up and down arrow keys, you can also cycle through the history of commands that you’ve entered.
You can directly access variables that are on the page:
Note that variables that you define in the Web Console are not automatically exposed to the page. If you would like to change a variable on the page, you just need to put “window.” in front of the variable name. For example, if you enter the expression “window.foo = 1”, then the variable “foo” on the page will change to 1.
With access to jQuery and knowledge that Reddit has an element on the page with an id of “header”, it becomes a simple matter to remove the header from the page we’re looking at:
One more note about using the REPL: if your expression returns an object, the console will just show [object Object] currently. However, you can click on [object Object] and see the object inspector:
One nice feature of the object inspector is that it shows you a snapshot in time of the object. You can click the “Update” button if you want to see the current contents of the object.
The Firebug add-on has millions of users and has been making web development easier for years. If you’re one of those users, you’re probably wondering why the Web Console exists when Firebug already provides a console and much, much more. Back at the beginning of this post, I talked about how useful a REPL and print are in debugging, experimentation and learning. These things are so fundamental that we wanted them to exist in Firefox with no add-ons required.
Consider this case: you’re a web developer and you have a distant user of your application. They’re running into a problem with your app. They can tell you what’s on the screen, but they have no way of sharing a view of what the application has done to that point. If you have useful logging messages in your app, you can ask the user to copy the console output into an email message and send it to you, all without requiring them to install an add-on.
The Web Console is not a replacement for Firebug, but it will be a great tool to have in a pinch.
What’s Next for the Web Console?
We’re still in the middle of the Firefox 4 beta test cycle, so you can expect to see additional improvements and polish as the beta progresses and we head to the release of Firefox 4. If you’d like to get involved and help make the Firefox developer tools beyond awesome, talk to us! Discussion about the Firefox developer tools comes on the dev-apps-firefox mailing list/newsgroup and in realtime in the #devtools channel on irc.mozilla.org. I’m also happy to receive feedback by email.
OK, we weren’t actually hiding, but we have been spending a lot of time learning, coding and figuring things out. We’ve been so busy creating things that we haven’t had much time to talk about the things we’ve been creating.
A little more than a month ago, I announced here that Mozilla officially has a Developer Tools group again, with tooling for both Firefox and the open web in general in our sights. Much of our group is new to Firefox development, and so the past few weeks have been quite an education in the processes used to ship a feature-filled, open source, stable browser to 400 million+ people. And that’s just the process. There’s the technology, too, and the Bespin team had to learn a lot there as well. The people who have been working on Firefox for a long time have been great mentors in getting us up to speed.
Now that we’re getting an idea of what the developer tools in Firefox 4 look like, the devtools team is going to be a lot more public about what we’re doing and invite the community to join in and help us make tools that make the web a better place. Keep on eye on Planet Mozilla or dev-apps-firefox (newsgroup/mailing list) in the coming weeks to learn more about what we’re up to and where we’re going next.
Also, one more word about Firefox 4 dev tools: Firebug 1.6b1 is out and is awesome. If you’re a web developer using Firefox 4 beta, you should definitely check it out.
When I joined Mozilla at the beginning of 2009, I was a part of Ben and Dion‘s “Developer Tools Lab”. As part of Mozilla Labs, the plan was basically that we’d try out a bunch of ideas for developers and see what we could learn from them. The biggest of those ideas was the Bespin project, into which we’ve put a good deal of effort. When Ben and Dion left to join Palm, the Bespin project was rolled into Labs directly and the various other bits of experimentation fell by the wayside.
Meanwhile, Mozilla has been gradually adding to developer tool support in Firefox through Jan Odvarko‘s work on the amazing Firebug and, more recently, work that Rob Campbell and David Dahl have been doing on some new tools that are directly part of the Firefox product.
Bespin is a very interesting project on its own, but for quite a while I’ve viewed it as part of a bigger picture, which is why we’ve put so much effort into our “Embedded” releases which make it easy to make Bespin a part of many “bigger pictures”. Likewise, I think that developer tools and platform improvements that ship with Firefox will ultimately be part of a bigger picture that will help developers build the kinds of powerful apps that HTML5 makes possible.
I’ve taken on a new role at Mozilla as the manager of a unified Developer Tools group that lives within the Firefox product organization. Though we’ll likely do some experimentation that may show up under Mozilla Labs, our focus in this new group is much more on shipping great, real-world-ready developer tools. I’m really excited about this change, because we’ll be in a better position than before to make our big picture dreams for dev tools come true. I’m also really excited to be working with such a talented group of people including the Firefox/Firebug engineers mentioned earlier and the Bespin team (Joe Walker, Patrick Walton and our interns for the summer Julian Viereck and Mihai Sucan).