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.
Greasemonkey and Fluid userscripts. AIR and the newTitanium apps. Browser add-ons. When you go to a website do you know if you are getting the best experience for you? You could search for script on userscripts, or Google for apps, but what if the developers of the sites had a way of pointing out that there were enhanced experiences for you?
This is where App Discover comes in. It is a Firefox add-on that notifies you of these very items. All the developer has to do is add a simple link tag to their page, and the add-on will find it for you.
For example, if Twitter added the following tag, you would be notified of TweetDeck:
<link rel="application"
type="application/vnd.adobe.air-application-installer-package+zip"
title="TweetDeck Adobe AIR Twitter App"
href="http://www.tweetdeck.com/beta/TweetDeck_0_20.air" />
That line would mean you would see this in the browser:
The type is a mime-type of course, and these are mapped into custom verbiage, but if you come up with something new… as long as the href is good, you should be golden.
I just added support for Appcelerator Titanium for example:
This is just a simple beginning of course. Where would we really want to go from here?
The current limitation is that it only really works well with one link tag (items get replaced)
I want to add preferences so the user can let the add-on know what they want to be alerted about (e.g. yes to Titanium apps and Greasemonkey scripts only!)
Be smart based on installation: E.g. if you don’t have Fluid (and especially if not on a Mac), don’t show it
Get social: “You have three friends who have installed TweetDeck”. This requires the browser being smarter about your social graph, which I think is a natural progression.
It should be smarter and not bug you when you go back to the same page. That can be fixed via the AnnotationService.
That leads me to XUL. I tweeted how it can feel a little strange to look up XUL docs and see dates in the lower 2000s. You have this nagging feeling of “has something really not changed since them? Is there an new better way of doing this?” As @mfinkle pointed out, “XUL is stable.”
To say that I am excited is a huge understatement. Ben and I have been talking about developer tools from the first day that we met on the No Fluff tour. For a very brief period I consulted together with him, and got to start on a vision for a productive Java stack. When consulting, I always saw huge productivity problems, and wanted to think of ways to solve them. Tools are one way to go, and the developer tools group at Mozilla is going to be different. We aren’t narrowly going to look at a way to build Eclipse plugins for example. Rather, we want to take a step back and see how we can help Web developers build compelling software with great user experiences in a productive way. We don’t want to think “we need VB on the Web.” We want something more.
Why are we doing this? Ben and I are passionate about a couple of things: compelling software and developers. In various roles in the past, we have built tools that attempt to make developers productive. We are huge advocates for the Open Web, yet we feel that tools are lacking on our collective platform. We want to help make a difference.
As we ramp up this new group, we will be looking at the problem and seeing where it makes sense to step in. We are going to be experimenting, and thinking about how to make developers lives better in different ways, so we aren’t expecting to see traditional tools come out of this group. Also, we don’t want to do this alone. We want to involve the entire community which is one reason that we are so excited to kick off this work at Mozilla. We believe that we have a unique opportunity to put developers first. We can build these tools in the open, with total transparency; the Mozilla way.
We respect the work being done by other vendors, and very much want to work together. We can’t wait to reach out early-on in the process, involving companies that believe in the Open Web like we do. Together we can drastically improve productivity, allowing developers to build compelling user experiences.
We are just getting started. As soon as we come up with some ideas, we will be sharing then with you and asking for community participation in various forms. You, the Ajaxian community, have been phenomenal over the years, and we can’t wait to do more together.
We also included a personal message:
There are a lot of personal issues here too. I strongly feel that my best work has been done when working with Ben. He has been an inspiration, as well as a great friend, and we have long wanted to work together. It is nuts that our paths haven’t brought us together in a full time capacity in the past. I can’t wait to get started with him now. I learnt from my Dad that you should have fun at work. Part of that is being around people you truly like, working on something you feel is important, and being able to excel. I think that I will get an abundance of that.
I am also very proud to be join Mozilla, the non-profit Foundation stands for what I believe in. Being someone who thrives on Open and transparent, how great and freeing will it be to develop all of this in the Open, being directly part of the community. At any company there are things that you strategically can and can’t talk about. At Mozilla on the other hand, everything is out there for all to see. That fits me to a tee! I have also long admired the talent that lives at the company and I look forward to working together.
What about Google though? Some people will think I am crazy for leaving the fastest growing company in history! :)
I have been running an Open Web advocacy group, and Google is definitely on the right track. You could argue that it is easy for it to be, since it is dependent on an Open Web. Also, it doesn’t need to come up with a business model. That is all true, but it is still pretty amazing to see exactly how much engineering is given away, or I should say shared with the community, through Open Source and APIs.
Being on the inside you get to really see what the company is all about. People have their views on Google, and any large company. Some talk of Big Brother and the like. Of course, the reality is that a company isn’t one being. It is a large group of people with varied ideas. These employees really hold the company to a high standard, as I have talked about before. I will continue to hold Google to those standards from the outside. How many companies would make a stand on Proposition 8? Google is special.
In the time that I have worked there, it sure has changed as it has grown too. How can you grow that fast and not have big changes? I have moved offices 9 times for example :) There are some things that have irritated me, and that I have wanted to change. The hiring process is one of them! However, recently, I found peace with a lot of the issues. I realized that without them, Google wouldn’t be Google. The last thing it needs to become is “just another company.” I hope it continues being as different as it can as it scales and brings in more and more outside forces.
I have to laugh when people talk about its future. We just saw the 10 year old birthday of the place, and it has only just begun. You can talk about advertising being a one trick pony, but the scope of advertising is also very young indeed. Just watch Minority Report again, but then think about how it could be done in a useful way.
Then think about the server side processing power that the company has. A handful of companies have that much processing ability which will enable solutions to problems that only they can do a good job coming up with. It is tough for a startup to come along and tackle some of these issues.
As I experienced my last week at Google, and had the tough job of saying good bye to the amazing group of people, I had a thought. It felt like I was leaving one premier league football team for another, and I knew that I would get to play with a bunch of the old team mates when the national games happened.
This is a new world. Google is of the Open Web, just as Mozilla is (and many others of course). This means that I really WILL get to work with old friends there. When in history has that been the case? If you went from factory X to factory Y, that was it. “See ya at the pub lads” was as far as you got.
The notion of company has drastically changed. The people who pay the bills may not be the people you work with all the time. I bet that Ian Hickson works with folks from Apple, Mozilla, and Opera just as much as Google counterparts! The goals that Mozilla and Google have are so aligned, that I think we will naturally continue to work together.
Finally, I am looking forward to a little sabbatical. Whenever I take a new job I am so excited that I jump right in. Then you look back and think “why didn’t I take a bit of time off then?”
This time I hope to help Obama a little on the final stretch, get some personal issues cleaned up, and in general take some time to change my lifestyle.
If you have pain points in development that you wish someone helped you with, please let us know!
