Initial thoughts on Eclipse’s Orion

Last week, I had the opportunity to join a planning meeting for the newly coming together Orion project. Orion is a new take on the IDE coming from some people with a raftload of IDE experience with Eclipse. Orion is also a new take on the web-based IDE, which is something I’ve enjoyed exploring a bit through the Bespin project.

The meeting brought together people from the Eclipse Foundation, IBM, SAP, Microsoft, Nokia, RIM, GitHub, Nitobi and I represented Mozilla there. Rik Arends from, makers of Cloud9 IDE, also made it to the meeting, which was really cool. I like the way that open source “competitors” are often willing to exchange knowledge and ideas in ways in which traditional commercial competitors are not.

Cloud9 and Orion are taking two different approaches to the IDE-in-the-cloud concept. Cloud9 is similar to Bespin and can be thought of as something like the “Google Docs of Code”. It’s a “single page app” that provides something akin to the desktop editor experience in your browser. Orion is taking the approach of being “completely webby”. Instead of a single page app, each URL represents a tool+resource, much more like a “CGI-style” webapp. Practically, this means that when you’re navigating your files, you’re using a page whose sole purpose is file navigation. When you’re editing, you’re using an editor page that has a URL that refers to the file you’re editing. When you’re committing to a git repository, you go to a git page.

The offshoot of Orion’s approach is that Orion does not provide UI bits like a tabbed editing interface. Instead, if you want to open multiple files you just open multiple browser tabs. Not only does this mean that the Orion folks have less code to maintain, it also lets them automatically take advantage of neat browser features like Firefox 4’s Panorama.

One of the keys to the Orion approach is that rather than trying to invent everything and house it within Orion, they want to effectively make the whole web part of Orion (or, put another way, they want Orion to just be part of the web). Rather than giving Orion a “new project wizard”, they can just link over to Initializr, for example.

This is a powerful idea. The web’s loose coupling is likely one of the reasons it has been so wildly successful, and that’s what Orion wants to tap into. The tension is going to come when they try to provide an nicely integrated and consistent user experience for common tasks. If you look at Cloud9 and Orion today, you’ll see what I mean. Cloud9 already has a polished and consistent flow that Orion presently lacks.

Part of Orion’s solution to this problem is through the use of plugins. Orion’s plugin system is far simpler than that of Eclipse and is also quite webby. Plugins are basically HTML pages that are loaded through iframes. This means that plugins have automatic security restrictions imposed by the browser. They communicate with the rest of Orion through postMessage. That means that only JSON data passes between plugins and Orion (no code can get through) and only the APIs that Orion provides at the other side of the postMessage bridge are accessible.

That plugin system is loosely coupled and can be used on its own. If you’ve got a JavaScript app that you want to make extendable, you should check it out.

John Barton (IBM and Firebug) demoed Firebug with editing integration with Orion. The Orion server provided the browser with a header with the URL to edit the file being served. Firebug used this header to provide an “edit with Orion” feature. John showed off editing integration for CSS where the changes to the CSS made in Orion were instantly reflected in the browser. Nicely done! One of the most popular requests to the Firebug project is the desired ability to be able to save changes made to the CSS via Firebug’s UI. There are some solutions available as Firebug extensions, but Orion potentially provides another solution that will integrate very nicely.

There were quite a few times in our discussions where topics and issues that came up were exactly things that we had dealt with for Bespin. Ben and Dion came by and presented about their experiences with Bespin. We all want to see this kind of exploration make progress and are happy to help people avoid the mistakes we made and the pitfalls we encountered.

The activity around Cloud9 IDE and Orion is great to see, because browser-based development is one area that is not yet the norm for web developers but I think will come to be at some point in the future.

More challenging puzzle for the devtools job

Yesterday, I posted about the Developer Tools Engineer position we’re hiring for at Mozilla. The response to my little puzzle has been terrific, but “it’s too easy” was a common refrain. So, I decided to add two more little puzzles that follow the first. The puzzles are not intended to be time consuming, but they do use a couple of modern browser features.

Give it a whirl and say hi if you make it all the way through. One person completed it last night after I put it up but before I had a chance to write this blog post.

Update: it looks like this may only work in Firefox at the moment, and possibly only Firefox 4.

Work with me at Mozilla! Solve the puzzle

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.

There are two ways to apply:

  1. Read the job posting and apply normally
  2. Solve the puzzle for extra credit

I hope to hear from you!

Next steps for Mozilla Developer Tools

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.

We want Firefox to have the best developer tools of any web browser, and we want to push dev tools for the open web in new directions. You can help through ideas, code, tutorials, etc. Join us on the dev-apps-firefox mailing list/newsgroup, join the Firebug project or email me directly if you want to help.

And, in case you’ve read this far, here’s a link again to the current snapshot of our planning.

The Open Web App Prototype

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.

Some others within Mozilla gathered up a lot of opinions, put in a bunch of thought and then put together a prototype which they’ve announced today: Prototype of an Open Web App Ecosystem.

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.

Go: reasonably high level programming, but with performance

I’ve always thought that it should be possible to design a language that is both usable and performant. JavaScript performance has improved tremendously, but it is still quite a distance behind C and even Java. Of course, programmer productivity is certainly more important than raw performance for most applications. It’s only as you try to scale up services that you really wish you could squeeze out more performance. In fact, being able to squeeze out more performance is one way to avoid the complexity shift of moving from one box to two/many. Of course, there’s always an upperbound to this, but that upperbound can be remarkably high.

I always thought that D looked like the language that could unify high level programming and performance. But D has failed to catch on and seems to be in a state that would make anyone seriously question using the language for real work.

Now, along comes Go, a new language sponsored by Google. More interesting than the Google part, is that Go was created by people with a long history dating back to the origins of Unix (Rob Pike, Ken Thomson, apparently even Brian Kernighan are involved). The language is designed to support super fast compilation (yay for programmer ergonomics!) and C-like performance. Importantly, the language also has built in features to help support scalable and safe concurrent programming, via “channels” for passing data back and forth, rather than something like transactional memory.

Go has a simplified object model that looks cool, but I’d be curious to see how it feels to use in practice. Go doesn’t have exceptions, which seems like a real drag to me. Apparently, exceptions are still considered an open issue and they present thorny issues when you’re dealing with concurrent processes.

Go’s standard library looks to have a decent collection of features, and you can call C code pretty easily. More care needs to be taken if you want C code to call into Go. If Go can get its packaging story together more quickly than Python has, it may indeed start having appeal as a high-level, fast, concurrent programming language.

It’s still very early for Go. It’s not used in production in Google yet. It doesn’t run on Windows. But it has arrived on the scene hitting many points at the “good enough” level (fast compiler, decent library, ok interface to C, decent docs). Google has full-time staff assigned to it, and they’re even hiring a program manager. With speculation that Google doesn’t want to use Python for their high volume services, I wouldn’t be surprised to hear that Google really wants to use Go internally. With an “anchor tenant” like Google, Go has a lot more potential than D ever had.

Now they just need to deal with the pesky issue of the name.

Introducing a2div web development user group

I’ve been interested in doing cool stuff with web technology for a long time. I still think that web development is harder than it should be, but new tools, processes and ideas come along all the time to make it easier and more fun.

Many people probably view me as a “Python guy”. Sure, I’ve done a good deal of work with Python over the past few years. But, there are many, many good ideas on the server side that come from places other than Python.

And, the browser as a platform is an entirely different thing than it was a few years ago, particularly when you restrict yourself to “modern browsers”, as we do on Bespin. The performance difference between today’s browsers and those from a couple years back is huge, and that new performance opens the door for all kinds of new applications and toolkits to help us build those apps.

I want to learn firsthand from people using modern tools to make development faster and more fun. I haven’t seen a group here in Ann Arbor that is devoted to the broad range of web development topics, so I decided to get one going. It turns out that Majd Taby sent a message to the a2geeks mailing list in April about starting a web dev group, but I somehow missed that. Majd and I exchanged some email this week and worked out the details of the new group.

The new group is called a2 <div> (or just a2div) because it has the same topic focus as cu <div> and I liked the idea of joining forces in some sense with a similarly minded group. cu <div> has a bit of a student focus that a2 <div> does not (it’s been a long time since I was a student). Thanks to Cameron from cu <div> for giving us the go-ahead to start an Ann Arbor offshoot. Thanks also to Dug Song for passing along the link to cu <div> and connecting me with Majd.

a2 <div> will be a loosely organized group as MichiPUG is… bringing the right people together for good discussion is far more important than creating a formal organization. Meetings are free. Our meeting format will likely be something along the lines of 1 hour presentation/demo followed by lightning talks and discussion.

An important aspect of a2 <div> is that’s non-denominational. Are you doing client and server in Java (for example, with GWT)? Neat. How about in Python (with Pyjamas)? Groovy. Doing the server in Lift and the client side with Cappuccino? How about PHP+Dojo? SproutCore+WebObjects? Using ASP.NET MVC with jQuery? Do you use Cucumber to test your apps? All are welcome, all are interesting.

Our meetings will be at the SRT Solutions office in downtown Ann Arbor. This is a great space to meet at (projector, whiteboards, flexible table arrangement), and the location is nice because it’s easy to walk out for drinks and food afterwards. Thanks to Dianne Marsh for letting us use their office!

Meetings will be on the 3rd Wednesday 4th Thursday of each month at 7pm. That means our first meeting will be on September 16th 24th (less than two weeks away). You can subscribe to our calendar in XML or ical formats.

The first meeting topic is not fully decided yet. Please join the a2div googlegroup and let us know what you might want to hear about or talk about!

If you’re near Ann Arbor on September 16th, join us at SRT Solutions for engaging discussion on all webdev-related topics! See you there!

Update: Date tentatively changed to the 4th Thursday based on conflicts on the 3rd Wednesday.

Project Bespin needs *you*

I work in Mozilla’s Developer Tools Lab, where we’re working to make things easier for web developers and to explore what is possible using open web tools. It turns out there’s quite a bit that’s possible, and we’ve just scratched the surface with what we’ve done with Bespin so far.

I’m really happy with the team that I’m working with, both within Mozilla Labs and in the Bespin community. I’m also really happy to report that we’ve got an opening on our team! We’re looking for fantastic software engineer that will own the Canvas-based editor component that is at the heart of Bespin.

If being at the forefront of JavaScript technology (Canvas, local storage, web workers) sounds fun and exciting to you, drop us a line! We’d love to talk to you!