Raindrop was so exciting to me, as it allows me to take ownership of how I handle communications.
Gmail is fantastic in that I have been able to extend my experience via Greasemonkey and the Labs tweaks, but it isn’t really open to me.
With Raindrop, you not only get to scrape out some flexibility in the client, but you get to do it the entire stack down. You can write code that changes BOTH frontend and backend. Have you ever wanted to do more than simple filters? Write handlers for particular content in an email? Help you mashup your email in any way? Raindrop will give you that.
It is early days of course. Mozilla is known for getting something out there early so the community can influence it, so jump in.
I am also excited to see that you can hack on things right int he client via an embedded Bespin. Awesome, I can’t wait to see what happens next guys!
Ben, myself, and the Bespin team are obviously excited about what we are doing. Giving Web developers a tool platform that is self-hackable and is also built-in-social has us up at night dreaming. We need help though! One way of course is joining the community, but if you fancy hacking on this problem full time, we have a new job opening for a Mozilla Labs engineer.
If you have a passion for open source, working with community, at an open company and want to spend some time making the editor sexy, please apply.
If you are interested in other positions, Mozilla is hiring across the board. I can tell you from experience that it is very difference working for a mission based organization, and if you think you would like that, come check us out.
Do you sometimes feel like the browser is a black box? We are building richer and richer applications on the Web platform and this means that developers are running up against new issues to debug and test.
We feel like it is a great time to develop new tools that afford you the ability to look into the runtime to hopefully help you find a bug, or allow you to keep your application as responsive as possible.
Today we want to start a conversation about some of our thinking, with the hope that you will join in.
We have been taking a hard look at the tools landscape, and here is a presentation that gives you an idea of our thinking:
We will be posting more of our thoughts, but as you can hear, our vision for these tools is that they:
Are able to run out-of-process. We view out of process tools as the preferred way to observe the runtime because it enables us to somewhat ignore the Heisenberg uncertainty principle. If we are profiler the browser, having to deal with NOT profiling the profiler code can be painful. Also, we want to be able to use the same tools on devices. I would much rather point my desktop tool to a Fennec device, compared to trying to use the tool on the phone itself! This leads us too…
Enable cross browser experiences: Our lab doesn’t have the resources to develop deep integrations with multiple browsers, but we very much want to enable that. Since we are running out-of-process, we can document the communication API and many hosts can then be wired up.
The first experiment in this vein is a stand-alone memory tool prototype that lets you poke around in the JavaScript heap. What objects are there? How many of them are there? Any dangling references due to closures or event listeners?
To kick this off we worked with awesome Mozilla colleagues such as David Barron and Atul Varma which enabled us to spike down to the bare metal of the browser.
We ended up with an architecture for the tool that contains these components:
Firefox Add-on
A special Firefox add-on installs a binary component that gives us access to the low level JavaScript heap. This gives us a simple API with methods that allow you to enable profiling, get the root objects in the heap, and get detailed information on the objects themselves.
Firefox Memory Server
The current consumer of the core API is a min server. Once activated, the browser freezes and your only option to interact with it is via this server. It exposes a simple socket API with URLs mapping to the high level APIs. For example, you can access /gc-roots to get the root object ids. Or you can ask for details on an object via /objects/XXX where XXX is the object id you are inspecting. When you are done, you access /quit and the browser is unfrozen.
All of these APIs support JSONP which is how we get the data back into our main application.
The main application itself is a simple Web application that can be run in any browser (not just Firefox!) After you have installed the Firefox Add-on, and turned on profiling via the Memory Server, you can visit the tool. Currently, after you connect, the tool gets a dump of the root object for the first tab in the browser (not including the memory server tab). You will see the meta data associated with the object, and you can click on any of the data elements that have their own memory id (memory locations are integers with 9 digits). This tree view lets you poke around the heap.
If you want to aggregate the data, you can click on the “2. Dump Heap” button, which goes through the entire heap (which can be big!) and aggregates all of the objects for you. If you see a massive number of objects of a particular type, this could be a flag!
Enough talk, lets see it briefly in action:
The tool is very early stage and changing constantly. However, it is all out in the open. You can grab the open source pieces:
As is always the case with Mozilla, and Mozilla Labs, we want to get ideas out into the community as soon as possible. This tool is very much alpha, and the goal of getting it out in the wild is to start a conversation about tools like these.
What tools in this area would help your job as a Web developer? We are all ears, and would like to share our dev tools mailing list / group as a good area to share ideas.
What about Firebug? This particular tool freezes the browser, and since Firebug is in-process right now, it wasn’t a great fit. However, we very much want to take this kind of work and get it into Firebug at some stage. We just aren’t at that stage yet!
On our side, we will be engaging with the Mozillans who truly grok the JavaScript (and entire browser) internals to see what interesting data we can expose to developers. We have found that the Firefox team has already added a lot of the infrastructure there, and now the task is to work out what will be useful, and how can we best report it.
We have plenty of ideas too. A wish list could contain:
Short term clean up (fix the backend code that interfaces with the heap, abstract out the service into a Jetpack, and make sure we are using the correct APIs, and get these APIs added where appropriate)
We want to visually add the graph to the object dump, so you can really understand what you are looking at. It will probably look something like this:
We have wired up Bespin, and we will suck out the source code from functions and showing that inline to the tool itself. There is much more to do though, and we want to find out what you need.
More profiling info: break up buckets of memory (images, js, DOM, etc)
Great way to see who is reference whom (memory leak detection)
Garbage Collection: When and how long are collections occuring?
Granular filtered profiling: Profile this event and measure every event-of-interest from the start of navigation to the present e.g. DNS & TCP connections, page header parsing, resource fetching, DOM parsing, reflow, etc.
Web Worker thread monitoring
Have a profiling mode that gives you data without having to freaze the heap, and only when you need to do a deep dive do we get to that.
We have learned a lot as we created this prototype. Atul is going to write up his experience, and we will continue to talk in the open about how we take this prototype and your ideas to the next level with browsers.
Update
Atul has posted on his experience with SpiderMonkey and how the JS Runtime works. Nice in depth stuff. He also created PyMonkey “a Python C extension module to expose the Mozilla SpiderMonkey engine to Python.” which is crazy cool.
It was cool to see the second release of Jetpack with its storage, slidebars, and time travel from the .future().
I quickly hacked up a trivial slidebar that lets me mouse to see the source of the current tab, and click on it to have it stick around. All in a few lines of code that use the new future API, slideBar, and tabs:
When I first saw the top sites feature that Safari took to the extreme (look wise) I jumped up and down shouting about how I wouldn’t want this feature at all. I am the king of about:blank.
Why would I want to waste time for this new tab page to come up when I normally want to just go somewhere (often the “where” is in my clipboard).
Well, after a week of using Safari 4 I realised that I hadn’t switched it off, and it hadn’t bothered me even though I knew it would bother me!
The reason is of course due to the speed. The reason I always hated setting my “home page” to anything but about:blank was because of the time it would take to grab and render the page. I have never been a “put iGoogle there!” kinda guy. Too slow, and not in my flow at all.
I don’t find that I often USE the top sites to get somewhere because the way I get to common sites is that I put them into tabs and I use APPLE-# (where # is a number of the tab) to get there. Thus, the whole notion of top sites doesn’t make much sense for me. The history area has been used once or twice and coverflow is waaaay too much here.
Now, Aza and company have been doing fun work with what this would look like in Firefox. It is a lot more subtle, especially the latest visual update. I love the subtle things such as knowing that I often go to my clipboard to having an action right there.
I also have really enjoyed how this has all been done as a plugin itself, and the process has happened very much in the open. Imagine if you could talk to the Apple engineers and help them do the best job they could for Safari? You can’t. With us, you can.
Also, this being Firefox, you can tweak the hell out of this puppy by greasemonkeying the page, setting the page to your own beast, or writing your own plugin to do something really fancy (like being able to tie into the same places database to do cool things).
You may think that you will hate these new pages, but as long as they load up just as fast as an empty page (perceived to be) you may find that, like me, you don’t actually care at all.
I was excited to hear about the Canvas 3D effort that Mozilla, Google, and Khronos are engaged in (and others can too of course).
Khronos is the group being OpenGL, and thus a good set of folks to be involved in the Canvas 3D approach that is in the mould of “OpenGL ES like for the Web” in that it is a low level API that others can build on top of. Others have played with higher level “Games” APIs, or virtual worlds, and this is not the same. It is a primitive that will enable people to do interesting things that sit on top.
I noted Ryan Stewart (friend and great chap) weighing in:
So it’s unfortunate to see that even the browser vendors have given up on moving the open web forward through standards. Whether it’s the WHATWG versus the W3C or the trials and tribulations of actually implementing HTML5, things are very broken and everyone is moving on regardless. I don’t blame any of them, but it doesn’t seem like it’s good for web developers.
I already talked about how many of the leaps on the Web haven’t started in the W3C (and rarely start inside standards orgs first) and rather come out in browser implementations that are then shared. Think XMLHttpRequest. Think Canvas itself from Apple! Do something well, see people use it and get excited about it, and then get multiple implementations and standards. Everyone wins.
John’s wording is interesting:
“But Mozilla’s proposal relies upon further proprietary extensions to the experimental CANVAS tag”
“And you’d lose the moral fulsomeness of the ‘Web Standards for The Open Web!’ pitch when focusing on your own proprietary alternatives to existing standards.”
Look at how browsers have done some things recently. Take some of the new CSS work that Apple started out. When the Mozilla community liked what they saw, and had developers demanding, they went and implemented it too. When you see WebKit and Gecko doing this kind of work it is particularly Open because the projects are open source and you can check them out (well, if you are allowed ;) How great is that, to iterate nicely in the open…. and then when ready we can drive into the standards bodies.
Back to the Canvas 3D work. Having Mozilla, Google, and Khronos work on this in the open seems pretty darn good to me. This won’t be hidden behind a proprietary binary that no-one can see. There will be some work in marrying the world of OpenGL ES and JavaScript as nicely as possible, and there will be plenty of room for the jQuery/Dojo/Prototype/YUI/…. of the world to do nice abstractions on top, but this is good stuff. This is more than just throwing out an API on top of a proprietary system, and I can’t wait to see what comes of it all. Want to get involved? You can in this world.
Do you remember when Web applications were CGI scripts? You had that cheeky bit of Perl that would be exec’d away. It was a haven for the lazy among us. What if you didn’t close the DB connection down perfectly? Didn’t matter. Use too much memory? Who cares. The process would die in seconds!
I then remember the real Web 2.0, when mod_perl and the like came about (yah yah there was NSAPI/ISAPI which I had to deal with too) and you realized that all of that bad programming now came at a price. The applications would be sitting on the server for a long time, so you could share a lot, but if you were sloppy you could cause bad things. Now you have to audit the code and gets thing right (as well as working around mod_perl bugs, but that is another story!)
The same has happened with the world of Ajax. Applications that used to be pages that would be refreshed are now replaced by sites like Gmail that sit in a browser tab all day long. If your application does something a little bad now, it can be noticed.
This is where the post that Ben just made on a new memory tool for the Web comes in. As we write Bespin and other Web applications we feel the pain where we wish certain items weren’t as much of a black box as they are now in the browser. A first bite is memory, and being able to get some visibility into the heap, or see when the garbage collector is kicking in and how long it is taking.
What other tools like this would you like to see as you write long living Ajax applications in the browser? We are all ears!
Talk is cheap. Shipping code is important. I have always felt that to be the case, so I always look forward to the first time that I ship something. At my latest adventure I got to do that yesterday.
It was a fun ride to go from the technical challenge of “can this be done” to having the experiment out of Mozilla Labs and into the hands of the wider community. One of the reasons I am so excited to be at Mozilla is that I get to develop in the open. You can watch our source code repository and see a community on irc and join us in our news group. Running an open project well is part art, and is incredible hard to do well. I have deep respect for those in the open source community that have succeeded. I am really looking forward to that challenge with Bespin and beyond. I want to make sure that we are truly transparent (no hidden agendas and back channels). I want to raise the profile of anyone who contributes to the project so people really know who the people behind Bespin are. I want to try hard to get designs out there early in the process so decisions can be shared, but I want to make sure that a vision drives the project forward.
Foolish chaps and companies have come to me in the past thinking that open source will be a silver bullet for “getting other people to do our work.” Those that have been involved in open source know that it isn’t the case. It is often more work. But, it is worth it. I have no doubt that the community that we hope to grow will come up with amazing ideas and contributions. I am humbled by the contributions even a DAY after launch. I am stunned that people think our experiment is worthy of their time and thought.
The wind is at my back, but I know that announcing Bespin is the beginning and not the end. The birth of the project. Now we get to see if we can have the kid grow up.
Not sure what Bespin is? Here is some info from the announcement and more. Thanks again to all of the kind words from people across the Web. It means a lot:
Bespin proposes an open extensible web-based framework for code editing that aims to increase developer productivity, enable compelling user experiences, and promote the use of open standards.
Based upon discussions with hundreds of developers, and our own experience developing for the Open Web, we’ve come up with a proposed set of features along with some high-level goals:
Ease of Use — the editor experience should not be intimidating and should facilitate quickly getting straight into the code
Real-time Collaboration — sharing live coding sessions with colleagues should be easy and collaboratively coding with one or more partners should Just Work
Integrated Command-Line — tools like vi and Emacs have demonstrated the power of integrating command-lines into editors; Bespin needs one, too
Extensible and Self-Hosted — the interface and capabilities of Bespin should be highly extensible and easily accessible to users through Ubiquity-like commands or via the plug-in API
Wicked Fast — the editor is just a toy unless it stays smooth and responsive editing files of very large sizes
Accessible from Anywhere — the code editor should work from anywhere, and from any device, using any modern standards-compliant browser
There have been a lot of people that we can thank for getting us out there today. Firstly, our new team of Kevin Dangoor and Joe Walker. Secondly, the great new colleagues that we have at Mozilla. Our Labs team members have been inspiring. We are building on the shoulders of great work. We are not only working closely with the Ubiquity team (Atul Varma, Aza Raskin, Jono, and others) to make sure the command line and Ubiquity are integrated, but we use Atul’s code illuminated to house the documentation for Bespin code. The Weave team has provided guidance for a future where Bespin data can be housed in their scalable infrastructure, which excites us. Whenever we chat with a Labs team we see places for integration, and we can’t wait to get there.
We care about design, and have been fortunate enough to have input from two great designers: Sean Martell and Chris Jochitz.
Other Mozilla folk have helped a lot too. You will notice that Bespin makes heavy, heavy use of canvas. Vladimir Vukićević has given far too much of his time to let us run through ideas and profile the canvas performance. We have also already seen contributions from outside of Mozilla. A few issues have been put into Bugzilla by beta testers, and even code patches (for example, thanks to Ernest Delgado for his canvas skills).
We have only just begun. We really wanted to get this tech preview out as soon as we could to embrace the community and experiment heavily. We hope to have your name in the credits soon!
Get Involved
There are many ways to get involved with the Bespin project and the Developer Tools lab. You could start by giving us feedback on the product (via comments, in our group, on irc in channel #bespin, or in Bugzilla).
Have a feature you would love as a developer? Fancy sharing a design concept? (We like those). We would love to hear from you on all fronts, from ideas to design to code. One of the reasons that we are excited about Bespin is that it is written for the Web platform, on the Web platform. This means that your Web skills can be applied to your tool. Want a nicer syntax highlighter? With that we had support for a version control system that we don’t support? Wish that there was interesting Python support? Help us build it!
Bespin has been built with extensibility in mind. We want you to be able to tweak your tool. Bespin Commands are just one example. Would you like to embed the Bespin editor into your own project? We want to enable these kinds of use cases.
From EC: “Microsoft’s tying of Internet Explorer to the Windows operating system harms competition between web browsers, undermines product innovation and ultimately reduces consumer choice.”
Mitchell has some very interesting points, and the two high level ones that stick out at me are:
They did a bad bad thing
In my mind, there is absolutely no doubt that the statement above is correct. Not the single smallest iota of doubt. I’ve been involved in building and shipping web browsers continuously since before Microsoft started developing IE, and the damage Microsoft has done to competition, innovation, and the pace of the web development itself is both glaring and ongoing.
Bloody hell, coming up with a remedy that is fair and good for the Web is tough!
There are separate questions of whether there is a good remedy, and what that remedy might be.
…
The extent of the damage is so great that it makes it difficult to figure out an effective and timely remedy. I believe it’s worth some effort to try.
Also, take a good look at the entire Mitchell post as it is really interesting to see how Firefox has grown despite of the barriers, and that Microsoft shouldn’t be able to use it as a “see, look what can be done.”
A lot of people are talking about the interview with John Lilly that discusses the relationship between Mozilla and Google.
People like to paint think black and white. Either Mozilla is Google’s poodle (Mozilla is to Google as Tony Blair was to George Bush) or there is a falling out and they hate each other.
Of course, the answer is grey as John points out. From my standpoint, focusing on the Open Web, I see more areas to collaborate on than to fight over. When I was at Google I knew that the Open Web was very important to the long term future. Now I am at Mozilla, the same is true. At the micro level there will be differences, but at the macro-level there is alignment.
Switching gears a little, I have had some folks talk to me about responsiveness issues with Firefox 3. I have had a fantastic experience, and currently I run Mozilla nightlies / Minefield / Shiretoka (3.1.*) and WebKit nightlies side by side. I am very happy with the shape that Minefield is in.
Of course, the issue with the extension mechanism with Firefox is that you get a window to the entire world (which has also been a reason that lead to amazing add-ons). Since this is the case a bad add-on can do a lot.
Chrome does a good job showing you basic info about a tab (memory etc). What if we did that and more for add-ons. Give me top for the browser.
Now, this is a lot of engineering away, so can we use the crowd to help out?
What if we created an add-on that would track responsiveness information and send it back (anonymously) to the cloud (say, to Weave). We could use math to work out probable culprits and could even ship that information back to the people using the add-on. Thus, you would then find out that FooAddOn seems to be a culprit that slows down the browser. Maybe it could be called Vacinate-addon.
I am honoured to be working at Palm where I get the opportunity to work with my long time friend and collaborator Ben Galbraith on delivering a fantastic developer experience on the mobile Web.
That being said, please note that the opinions expressed on this site are my own, and don't necessarily reflect those of my employer.
