A+ Ajax

You know what time it is…. it’s time for another Web Ninja Interview! Huzzah! The Web Ninja Interview series focuses on people doing amazing and interesting work using JavaScript, CSS, HTML, SVG, WebGL, and more.

One of the goals behind the Web Ninja Interview series is to talk with the web gurus behind many amazing web sites and products that don’t directly blog or speak at conferences as much.

Today we talk with Marcin Wichary. I’m a huge fan of Marcin’s work. He was behind the animated and playable Google Pac-Man logo; created the initial HTML5 fancy (shmancy) slide deck that is now an open source project; and helped with Google Instant. He also has a geek love of computer history; just as artists study the masters who came before them computer scientists should know their history. Let’s begin.

Brad Neuberg: Tell us a bit about yourself, where you’re from, your background, interests, and some projects you have worked on (don’t be humble!)

Marcin Wichary: I grew up in Poland. I have a master’s in computer science, and a doctorate in human-computer interaction. I created my first HTML tag in… 1995? It was probably a <P>, but that’s just a guess.

I am proud of GUIdebook, which is (was) an online gallery of graphical user interfaces. Alas, I have not had time to update it since 2006.

At Google, which I joined in 2005 as a user experience designer, I helped with various internal tools and a number of search-related initiatives, including search options, real-time search, and most recently Google Instant.

Brad Neuberg: You built the HTML5 Pac-Man Google Doodle. What’s the story behind that? Any technical things you ran into that surprised you?

Marcin Wichary: One of the Google illustrators and a good friend of mine Ryan Germick had an idea to create a first playable doodle for Pac-Man’s birthday. Since I’ve been exposed to arcade games a lot in my childhood, he reached out to me; I built a very early prototype the same night.

The biggest surprise was how much thought went into Pac-Man’s details. You’d think it’s a very simple game, but there’s so much nuance and polish in every aspect. I had to recreate all of it from scratch, and since I personally believe that it’s the details that make or break the experience, it was inspiring to see someone thinking about all that already 30 years ago.

Technically, I was sad to witness HTML5 audio not being quite ready to be used in games. (There’s actually very little HTML5 in the Pac-Man doodle.) And the infamous background caching bug in IE6 bit me so bad that no known solutions worked; I had to introduce a separate code path that didn’t use CSS backgrounds, just regular images cropped by parent divs.

Brad Neuberg: You created the amazing HTML5/CSS3 Slide Deck over on API Rocks. What prompted you to create this initially? What are some of the technical things you used to create this?

Marcin Wichary: A colleague suggested I give a talk to my team about HTML5. I agreed, thinking “I’ll just find a nice list of what’s there in HTML5 and make a presentation out of it.” Turned out, there was no such list, so I had to poke around and construct one myself. It was actually an interesting process. I called it “archeology of the future” – I was looking at Web technologies that’ll ultimately span years 2000 to 2020, trying to figure out how they all fit together right now, in 2010.

In terms of choosing a medium, I’ve been making my slide decks in HTML for about a decade now. Before Keynote, it was the only way for presentations to look exactly the way I wanted (have to give credit to IE6 here for its gorgeous full-screen mode), so I felt fairly comfortable following that – but utilizing newer technologies this time around. I’ve also always enjoyed teaching by example, hence the addition of sliders that allowed direct manipulation of CSS.

I am a very hands-on, low-level kind of guy. I created my first website in FrontPage, but since then I’ve been coding everything by hand. These days it means TextMate and Safari’s excellent Web inspector. I also make a point not to reuse much of what I do, but write the same things over and over again. This allows me to learn and adapt to changing technologies. (For example, I wrote two new presentation engines since the said HTML5 presentation.)

Brad Neuberg: What is a clever hack, trick, or elegant turn of code you’ve discovered or created while working with JavaScript, HTML, CSS, etc. that you are particularly proud of? Give good details, and don’t be afraid to be technical :)

Marcin Wichary: Get an iframe, make it tiny using CSS3 translate/scale, cover with a transparent div to intercept events, and voilà – you have a nice site thumbnail without having to create an image, upload it and worry about them getting out of sync. Of course, it also comes with terrible latency, so there you go.

color: transparent and text-shadow with 0px offset means blurry text. How is that not awesome? (Not that I can think of a use for it.)

Not sure if those are particularly clever or useful – I have an attention span of a <marquee> tag and if I do anything innovative I’m usually the first to miss it – but it’s exciting to discover new uses for things that, in and of themselves, are so brand new.

Brad Neuberg: What are some of the things you are hacking on these days (that you can talk about)?

Marcin Wichary: My main project for the past several months was Google Instant, and we just launched it, so right now I’m looking around and learning about projects. I’ll be doing some internal HTML5 advocacy, teaching and workshops – hopefully some of that will surface on HTML5rocks.com.

Brad Neuberg: Tell us about a hobby, interest, or something in your background that most people wouldn’t expect or know about.

Marcin Wichary: One thing that I feel keeps me in balance is collecting (and slowly going through) books about computing history. I probably have some 800 of them by now. My apartment filled with obsolete technology talking about another obsolete technology is a good counterpoint to living in the future at work. And, as always, the best technology stories are those about people – this keeps me focused on our users in the present as well.

Brad Neuberg: Where do you see HTML5, CSS3, SVG, etc. (i.e. the new stuff on the web) going in the next year? How about the next 3 years?

Marcin Wichary: They say nothing ages faster than today’s idea of tomorrow, and I’ve never been a good futurist. :) So I’ll give you my wish list instead.

I would love to see more attention paid to nuances of typography. Computers took most of them away and sure, we reclaimed some back, but not yet very many. And lord, please, layout! We’ve all been using JavaScript crutches to do that for so long that it’s not even funny anymore – indeed, in a lot of my projects the first listener I add is “onresize.”

There’s also a number of avenues in JavaScript to build pretty crappy UIs. alert() and its brethren is the only way to reliably catch the user’s attention. Oftentimes it’s like pillow talk using a bullhorn. :hover allows only for the most rudimentary and unforgiving mouseover actions. We need better defaults for stuff like that.

Brad Neuberg: For folks that want to do the kinds of cutting edge things you’ve been doing and have done, what advice or resources would you give them?

Marcin Wichary: One of the first popular home video game consoles was 1977’s Atari VCS 2600. It was an incredibly simple piece of hardware. It didn’t even have video memory – you literally had to construct pixels just moments before they were handed to the electron gun. It was designed for very specific, trivial games: two players, some bullets and a very sparse background. All the launch games looked like that.

But within five years, companies figured out how to make games like Pitfall, which were much, much cooler and more sophisticated. Here’s the kicker: if you were to take those games, go back in time, and show them even to the *creators* of VCS, I bet they would tell you “Naah, it’s impossible to do that. The hardware we just put together won’t ever be able to handle this.” Likewise, if you were to take Google Maps or iPhone Web apps, take your deLorean to 1991 and show them to Tim Berners-Lee, he’d be all like “get the hell out of here.”

What I’m trying to say is: Assume nothing is impossible. It’s actually easier this way. So many times people asked me if something is doable in HTML, and my initial instinct was to say “no.” But you look around, ask around, *think* around, and there’s always a way.

Something else that took me a while to internalize: you have to accept that with Web development, anything that’s worth anything will be a hack. Not just prototyping; production code as well. That’s hard to swallow when you’re used to proper, clean, sterile programming. I’d go as far as to say if you’re working on something and you never think “what I did here is terrible; hopefully one day there will be a nicer, better way to do it,” you’ve already fallen behind.

And eventually that battery of hacks in your sleeve might make you stand above. My crude and jaded metaphor of Web development is button mashing when playing video games. Everyone hates button mashers, but working with cutting-edge Web really is flying blind a lot of the time – you’re trying out all sorts of things that sometimes don’t logically make a lot of sense. But they somehow work. If you get used to that mentality and you get familiar with those hacks, you will train your instincts to know which buttons to mash first, and give yourself more buttons as well.

Lastly, if you ask a “what if?” question and leave it unanswered, you should be ashamed. :)

Brad Neuberg: Thanks Marcin!

What kinds of questions do you have for Marcin? Ask them below!

Continue reading »

By Dion Almaer
webOS 2.0 SDK has just launched, and it has node.js built in (and more). The following is taken from my personal blog

At our last Palm Developer Day, Ben and I discussed future APIs for webOS including “JavaScript services” as a way to write code that runs on the other side of the device service bus using JavaScript.

If you think about it, node delivers a services platform for the cloud, so is there a way that we could work together? We got together with Ryan Dahl of Node to try this out, and it turns out that node works fantastically well on a mobile device! Major kudos should go to the V8 team for creating a great VM and to Ryan for writing efficient code that scaled down from the cloud to the device.

Today we announce that node is part of webOS 2.0:

The popular Node.js runtime environment is built into webOS 2.0, which means that you can now develop not just webOS apps but also services in JavaScript. The active Node ecosystem is on hand to provide community support and a rapidly growing library of modules that you can use in your webOS services.

Besides powering the new Synergy APIs, JavaScript services strengthen webOS’s support for background processing and add new capabilities—like low-level networking, file system access, and binary data processing—to the web technology stack.

I am really excited about this move for us. The node community is top class. I get to see this time and time again, most recently over the weekend and this week as I judge the node knockout. There is magic in the air with Node. It feels like the Rails days. I remember being so happy to jump to Rails and get away from the heavy world of Enterprise Java. It was a breath of fresh air to not have to argue with folks about every piece of the stack. “What about JSF with HiveMind and Commons-Logging and ….” Argh! Too. Much. Choice. And, a logging abstraction above Log4J was hilarious :)

Node is low level, yet simple. It is more like Sinatra than Rails. The event-based opinions keep you in good stead, and with cloud solutions such as Heroku and no.de you have great deployment stories, unlike Rails back in the day.

If you check out the modules that are growing daily, and the fun real-time hacks from the knockout you will get a good feel for node.

It feels great to have webOS as the first mobile device that embeds node. With db8 we offer a JSON store than can sync to the cloud (e.g. sync with CouchDB). This stack is starting to look pretty great.

Continue reading »

Do you enjoy the “looks at me build something cool in pure CSS”-meme? It is kinda fun. On the one hand is shows what amazing things people can build, and on the other…. it reminds us that we need some tools to help make life easier. At least the platform is here, and tools can come later.

Louis Harboe has followed up his purchase of an iPhone 4 with iOS 4 icons made with CSS. Now only do we get to see his work, but he talks about the high level ideas behind the implementation:

In the contacts icon, I used 5 different shapes for the silhouette icon. The head is a rectangle with rounded corners, followed by another rectangle for the neck and a distorted semi-circle for the body. In order to get the curve of the shoulders to the neck, I placed two circles on top of the shapes.

The weather icon has several rays of light shooting from behind the sun. Each one of these rays is actually a long rectangle with a gradient that fades to transparent on either end. I used -webkit-transform:rotate to rotate each rectangle to a different angle. The same effect was used for the iTunes icon.

To get the cloud icon on the iDisk icon, I used two circles layered on top of each other, above a rounded rectangle. The larger circle has a gradient that cuts off just before the rectangle.

Take a full example such as calendar:

Awesome. One nice thing about this approach is that it can scale. iPhone 4 users are already talking about how glaring it is when apps have low res assets. Even the Facebook applications…. the text looks great, but the icon is blocky.

Also, some other nice CSS gradient examples were put on display.

Continue reading »

Progressive enhancement.

Disconnected offline applications.

There is a tension brewing in how we deliver applications on the Web. This isn’t a new tension. It has been around ever since we started to do more than just throw HTML down the pipe for the hypertext document runtime to render.

With the Ajax revolution we talked a lot about “Web applications”. Gmail. Google Maps. Those are written in a very different manner. The architecture isn’t one of: client asks for a URL…. server does all of the work: business logic, and view logic, since it sends back the entire view as HTML. A popular Ajax pattern was that of still keeping the client kinda dumb, and having the server return interface elements and behaviour in the form of HTML/CSS/JS that the client would eval/innerHTML/etc. This continues to be used a lot as it is flexible (especially if the bulk of the team is on the server side) and sometimes easier to do (chop up the functionality on the backend into more discrete tasks). This is a progressive enhancement style of richer Web applications.

When I was working with Gears I saw first hand how reluctant developers were to move from the progressive enhancement style into a more aggressive client server-esque style of Web application development. The Gears APIs themselves are trivial. Nicely implemented. Simple APIs. We get to use them these days in the form of App Cache, SQL database API, Web Workers, GeoLocation, etc. Taking your application and sprinkling a GeoLocation API is very simple and fits into progressive enhancement easily. Even doing what the WordPress guys did early on, and using App Cache as an aggressive fast cache is easy.

The harder sell to developers was: If you want to have your Web application work offline, you need to re-architect it to enable that. Instead of having your PHPs firing down interfaces, you need the client to coordinate the work and just speak REST to services that give you the data, and then have a layer of abstraction that can get the data locally etc. Then you can look at handling sync and the like. This is real work. This is moving code from point A to point B. It is a big deal. Many developers didn’t see the value proposition. Do they REALLY care about the offline use case? Getting some performance improvements by taking out latency is nice (hit cache first etc) but is that worth the rework?

For many people, it just wasn’t worth it.

As I look at what is changing in the world, I see a few things that may add up collectively to a tipping point:

“HTML5″ hype

HTML5 has a lot of great functionality. There will be pressure for developers and sites to raise the bar. Expectations of what a Web application “can do” is drastically going to change, and as soon as that change happens you don’t want to be left behind. MapQuest was fantastic. Until Google Maps came out. Then, on that day forth, it felt archaic. All of that with XHR++….. what will happen with all of the HTML5 functionality available? A lot of code we will be rewritten and changed for “HTML5ication”, which is an opportunity for a change in how things are done.

“Apps” and the Web as a unified device platform

I haven’t been quiet with my concern at the rise of the proprietary app platforms. The Web needs to fight back, and it has the opportunity to actually solve developer problems (rather than just rant about how the world should be more open damn it!).

As a developer, do you want to port experiences between incredibly varied platforms such as Web, iPhone, Android, WinPho 7, RIM, Kindle SDK, [insert many others!]? No. The Web has the opportunity to share a lot of that code and development. It has to compete with the native platforms on features, performance, and the like…. but I would argue that it is doing a great job and getting better FAST.

Within the apps ecosystem there are some very interesting things happening:

• Chrome Web Store: The Chrome Web Store is happening. I know of other Web store efforts in various stages of life too. A lot of developers want to get into the app distribution bandwagon, and will be looking at the notion of a “web app” in a new light because of this. This will give a lot of momentum, along with the fact that HTML5 is the first real spec envisioned for “app” functionality versus documents, to the web app movement
• Mobile Web: As developers want to get applications to as many devices as possible, they are finding that the Mobile Web is an attractive development platform. But, how do you do it? If you think about Web distribution, then you have the progressive enhancement world again (device and layout tweaks via CSS, JS, etc) all the way up to a mobile framework. We see the two worlds with jQTouch on one side and Sencha Touch on the other.

  Take a look at how an app looks in Sencha Touch:

  templates in HTML

  <div class="legislator-brief">
  <div class="legislator-tnail" style="background-image: url(http://www.govtrack.us/data/photos/{govtrack_id}-50px.jpeg)"></div>
  <h3>{title} {firstname} {middlename} {lastname} ({party})</h3>
  
  {state} {district:this.ordinal}
  </div>
  
  
  

  OO app framework with layout and components

  Geo.App = Ext.extend(Ext.Panel, {
      cls: 'app',
      fullscreen: true,
      layout: 'card',
      activeItem: 0,
  
      initComponent: function() {
          this.startScreen = new Geo.views.StartScreen({
              flex: 1
          });
          this.splash = new Ext.Container({
              cls: 'splash',
              layout: {
                  type: 'vbox',
                  align: 'stretch',
                  pack: 'end'
              },
              listeners: {
                  deactivate: this.onSplashDeactivate,
                  scope: this
              },
              items: [this.startScreen]
          });
          this.detail = new Geo.views.LegislatorDetails();
  
          this.items = [this.splash, this.detail];
          Geo.App.superclass.initComponent.call(this);
  
          this.startScreen.on('legislatorselect', this.onLegislatorSelect, this);
      },
  
      afterRender: function() {
          Geo.App.superclass.afterRender.apply(this, arguments);
          Ext.getBody().on(Ext.isChrome ? 'click' : 'tap', this.onLinkTap, this, {delegate: 'a.goOutside'});
      },
  
      onLinkTap: function(e, t) {
          e.stopEvent();
          Geo.Util.openUrl(t.href);
      },
  
      onSplashDeactivate: function() {
          this.startScreen.list.clearSelections();
      },
  
      onLegislatorSelect: function(govtrack_id) {
          this.setCard(this.detail, Geo.defaultAnim);
          this.detail.update(govtrack_id);
      }
  });
  

  This looks similar to how we build apps on webOS with Mojo and other frameworks like Jo. Rich full featured mobile frameworks.

  Once you have built your Web application, technology such as PhoneGap and Appcelerator Titanium can package it for the various app distribution platforms.

  So, when I put this all together, I see the opportunity for the growth of Web applications through both progressive enhancement, but also via rich client frameworks. The tension will be there between the two, and I am sure that there will be more solutions that blend the best of both worlds.

  What do you think? What are you seeing as you build richer Web applications for a variety of devices and form factors?

Continue reading »

When choosing an Internet connection, it is intuitive to focus on network bandwidth – “Speeds up to 5Mbps!” Bandwidth is important, but it isn’t the only factor in performance. And given the way that HTTP uses short, bursty connections, it turns out that the round-trip-times dominate performance more than bandwidth does.

This comes from a post, and a detailed report, by Google’s Mike Belshe.

Consumers love one magic metric to look at. Bandwidth speed has been in a “more bandwidth == linearly better” way. In fact, just as with many things, there are many variables. Bandwidth can actually peter out, and other factors are even more important at greater bandwidth.

As shown above, the round trip time (RTT) matters a ton:

if users double their bandwidth without reducing their RTT significantly, the effect on Web Browsing will be a minimal improvement. However, decreasing RTT, regardless of current bandwidth always helps make web browsing faster. To speed up the Internet at large, we should look for more ways to bring down RTT. What if we could reduce cross-atlantic RTTs from 150ms to 100ms? This would have a larger effect on the speed of the internet than increasing a user’s bandwidth from 3.9Mbps to 10Mbps or even 1Gbps.

Continue reading »

Scribd is my “favourite company of the month”. First they show off their move from Flash to HTML5 and now they are generously taking time to share with us details on their implementation in a three part series.

The first part delves into the bowels of @font-face, starting with the simple:

and moving to how they support angled text such as this:

How do you encode the diagonal text in this document in a HTML page?

Short of using element transformations (-moz-transform, DXImageTransform etc.) which we found to be rather impractical, we encode the above HTML with a custom font created by transforming the original font. Here’s how our generated font looks in FontForge:

From the above font screenshot you also notice that we reduce fonts to only the characters that are actually used in the document; that helps save space and network bandwidth. Usually, fonts in the pdfs are already reduced, so this is not always necessary.

Naturally, for fonts with diagonal characters every character needs to be offset to a different vertical position (we encode fonts as left-to-right). In fact, this is how other HTML converters basically work: they place every single character on the page using a div with position:absolute:

PLAIN TEXT

HTML:

<!– crude pdf to html conversion –>
<div style=“position:absolute;top:237px;left:250px;”>H</div>
<div style=“position:absolute;top:237px;left:264px;”>e</div>
<div style=“position:absolute;top:237px;left:271px;”>l</div>
<!– etc. –>
 

At Scribd, we invested a lot of time in optimizing this, to the degree that we can now convert almost all documents to “nice” HTML markup. We detect character spacing, line-heights, paragraphs, justification and a lot of other attributes of the input document that can be encoded natively in the HTML. So a PDF document uploaded to Scribd may, in it’s HTML version, look like this (style attributes omitted for legibility):

HTML version:

PLAIN TEXT

HTML:

<p>
  <span>domain block is in a different image than the range block), as</span>
  <span>opposed to mappings which stay in the image (domain block</span>
  <span>and range block are in the same image) – also see Fig. 5.</span>
  <span>It’s also possible to, instead of counting the number of</span>
</p>
 

Together with tags for graphic elements on pages, we can now represent every PDF document in HTML while preserving fonts, layout and style, with text selectability, searchability, and making full use of the optimized rendering engines built into browsers.

I am looking forward to part 2 and 3!

Continue reading »

Dmitry Baranovskiy has been hacking away on Raphael. It is almost like he has had a bunch more time for it recently! :)

Version 1.4 has a bunch of cool new features such as:

• Touch events support
• rgba support
• new method drag
• document.onmousemove = f ? Raphael.mousemove(f)
• resetScale method
• scaling text will change it position, but not size
• sets now have type “set”
• rect in VML doesn’t recreate itself on change of the R
• paths are not rounded to the nearby pixels anymore
• Various small bug fixes and improvements
• added preventDefault and stopPropagation to event object

Very nice.

Continue reading »

Twitter released an official Android application today that looks clean and to the point.

A mobile Web version of a Twitter client, Tweet Me was released on webOS, and I think it raises the bar. It is beautiful and a pleasure to use:

This is a segue into some posts that I have penned recently on the topic of Mobile UX. I recently discussed some rich examples of the notification system and how certain webOS apps use it in creative ways. I then cover some of the cool interactions from Tweet Me itself.

Before that, I talk about the Just Type metaphor, and the Ubiquity/QuickSilver-ness of the launcher itself.

This has been a good week for the mobile Web. A top featured iPad app is a PhoneGap web app, TItanium apps are getting through too, and I heard that a fairly large technology company made a laaaarge bet on the mobile Web.

Continue reading »

Nathan Weizenbaum promised that Sass will become a superset of CSS back in June 17, 2009.

And we now have version 3 of Sass and Haml available that brings life to the promise:

• The new syntax is known as “SCSS”, for “Sassy CSS”
• SCSS was built from the ground up based on the CSS3 spec, and is 100% CSS3-compatible
• SCSS can do anything Sass can do
• SCSS files can import Sass files, and vice versa
• This means you can use Compass with SCSS right now

Take a look at the release notes to see how SCSS looks, as well as other changes to the library.

Some changes that peak out:

Oh, and it all works nice with FireSass: “A new :debug_info option has been added that emits line-number and filename information to the CSS file in a browser-readable format. This can be used with the new FireSass Firebug extension to report the Sass filename and line number for generated CSS files.”

Continue reading »

The Chromium folk have posted about JavaScript conformance as they release a test runner for Sputnik, that allows you to easily run the complete test suite from within your browser:

Sputnik touches all aspects of the JavaScript language defined in the 3rd edition of the ECMA-262 spec. In many ways it can be seen as a continuation of and a complement to existing browser conformance testing tools, such as the Acid3 test. While we are always focused on improving speed, Sputnik is not about testing how fast your browser executes JavaScript, but rather whether it does so correctly.

Since we released the Sputnik tests as an open source project, the most requested feature has been the ability to run the tests in a browser, and we are excited to launch that functionality today. The new test runner lets you run the tests from a single URL and quickly see the results in your browser. This makes it easier both for users to see how well their browser conforms to the JavaScript spec, as well as for browser makers to find bugs and incompatibilities.

You can also use Sputnik to compare browser conformance.

The dart board shows relative conformance based on the number of tests that hit or miss. Of course, in the real world, all tests are not equal. This has been an issue with Acid tests. The race to 100 is socially interesting, but if you miss a few core tests that could be worse than meeting 10 corner cases in SVG :)

Continue reading »

The Opera team has released 10.50 for Mac and along with it some impressive performance numbers:

• Stabilization Improvements: You will find that this build is much more stable than the pre-alpha build.
• More polished user interface: The whole UI is more polished now. We’re still not done yet, and expect more polishes and improvements in the builds to come.
• Opera Unite: Opera Unite now works with this release. You can browse through and download unite apps through the Unite Apps Repository.
• HTML5 <video>: This beta now supports the html5 <video> tag.
• Widgets as standlone apps: We’ve already talked about widgets as standalone apps, but this functionality was till now, only available in windows builds. Now even in this build of 10.50 beta for mac, you can use widgets as standalone apps. Check out this ODIN post by Patrick Lauke on standalone widgets for more information.
• New Developer Tools Menu: You can go to ‘View->Developer Tools’ Menu to access common and usefull tools for developers, such as Opera Dragonfly, cache information, the error console, the source code of the page, and more.

Gregg Keizer talks about the performance side of things

According to tests run by Computerworld, Opera 10.5 was nearly 15% faster than Safari for Windows and almost 20% faster than Google’s Chrome, the previous No. 1 and No. 2 browsers. Opera’s preview was more than twice as fast as Mozilla’s Firefox 3.6, over eight times faster than Opera 10.10, and 10 times faster than Microsoft’s Internet Explorer 8 (IE8).

We tend to talk a lot about WebKit, Moz, and IE…. congrats to the Opera team on their impressive work.

Continue reading »

Built using the open web standards you know and love, Opera Dragonfly’s source is available to view. Not only that, but it is released on a open source BSD license, meaning it is free as in freedom as well as in beer.

Opera is normally one of the few browsers that isn’t open source, but they are certainly doing more with open source itself. David Storey has announced how Opera Dragonfly has joined the open source ranks.

There is Dragonfly itself, but also the Scope protocol:

Starting today, Opera Dragonfly is a fully open source project, hosted on BitBucket. Since the previous version of Opera Dragonfly, a lot of work has gone on behind the scenes replacing the existing architecture with a modern version of the Scope Protocol – STP-1. Opera Dragonfly has been rewritten to use this faster and more efficient version of Scope. Now that we believe that the underlying protocol is stable and performant, and a public desktop build has been released with this included, it is time to put Opera Dragonfly on a public Mercurial repository.

If you have a Mercurial client you can visit the Opera Dragonfly STP-1 repository and check out the source code. We have provided initial documentation in the Wiki to get you started. This is Opera’s first full open source project, so there will be a learning curve. We ask you to bear with us while we get everything up and running and policies in place. Coming from a closed source background there are some hurdles to overcome, such as the current bug tracking system being on a closed server. We hope to migrate to an open bug tracking system as the project gets on its feet.

As well as the current and previous versions of the Opera Dragonfly source code, we have released a couple of tools to help with Opera Dragonfly development. The first is Dragonkeeper. This is a standalone proxy, which translates STP (Scope Transport Protocol) to HTTP. This can also be useful for remote debugging. The second tool is Hob. Hob is a utility to create code from Protocol Buffer descriptions. Protocol Buffers are one of the formats Scope STP-1 supports along with JSON and XML.

Nice. The question is…. will others implement on STP so we can get cross browser support.

Continue reading »