The Rationale for Awesomium

The Problem

IE, Firefox, Chrome. Small armies of developers have worked for years crafting some of the finest applications that the world has ever used. Millions of lines of code, vast functionality, immense complexity, all wrapped up into a single, standalone application.

As a software developer, that bothered me.

See, I’m prone to breaking things apart to see how they work; I love nothing more than to solve the mystery of complex systems, to re-arrange components, ideas, concepts, into something more beautiful.

I wanted something re-usable, something modularized with a slick API so that I could harness all the functionality of a full-blown browser in my own designs.

The problem was, years ago, nothing quite met my demand.

It all started while I was coding my first 3D Game: the UI technology sucked. Was tough to design something that looked good, the language was very inflexible, and hard to learn.

The UI technology sucked


I was already a halfway-decent web designer at the time, so I thought to myself— why can’t I just use HTML for my in-game UI? It seemed like the perfect solution.

I searched for what seemed months and found: nothing.

I went to various IRC chatrooms and talked up the idea but was largely met with dischord (this was before the HTML5 renaissance):

“HTML is for Web-Pages, UI Tech is for UI! Don’t cross the streams!”

“Browsers just aren’t designed to be used that way!”

The Beginning

Undeterred, I started hacking Mozilla Gecko (the engine behind Firefox) to see if I could get it rendering off-screen to a pixel buffer.

After several weeks of getting nowhere (XPCOM is not for the faint-of-heart), I came across LLMozLib (Linden Labs’ offscreen port of Gecko). It wasn’t perfect (it’s performance left something to be desired) but it was definitely a start. Callum Prentice (the main developer) had been pioneering web-browsing in 3D and had developed the library for use in Second Life and his standalone application, uBrowser:


uBrowser Screenshot, Web-Page on a 3D Plane

This was really awesome, but I still needed to figure out how to turn this into a cogent solution for rendering and scripting my UI. After months of research and work (and with a lot of duck-tape and popsicle sticks) I put a together a proof-of-concept using Ogre3D:

Proof-of-Concept HTML UI in Ogre3D

Each UI element in that screenshot is actually a separate web-page with a hard-coded alpha-mask overlay. To pass data/events from the web-page to the application, I actually had to encode events/parameters into an anchor URL and simulate a click (LLMozLib didn’t support JS callbacks, the only event I could capture was URL clicks). Was primitive but got the job done.

I released the library for free (Navi) to the Ogre3D community and it took off like wildfire. The support I received was overwhelming; a few brave souls even used it in their production builds.

Realizing I was onto something bigger than HTML UIs, I decided to devote myself fully to making a re-usable, off-screen, web-browser framework with ample event callbacks and scripting support.

Coincidentally, Google Chrome (aka, Chromium) was released about the same time and I immediately tore its codebase apart. After about a week of non-stop coding, tracing, refactoring, retrofitting, and hacking, I was done.

It was Awesome, It was Chromium, It was Awesomium.

It was Awesomium!

What is Awesomium?

Awesomium is a flexible, windowless, web-browser framework that is meant to be used in your own applications. Think of it as if I took Chrome, chopped it into smaller, re-usable pieces, and served it to you on a nice shiny 32-bit BGRA pixel-buffer platter.

It is not an application, it is not a web-browser; it is a tool to add web-browser-like capabilities to another application.

It can do so much more than HTML UI: think of radical new browsing interfaces, multi-touch, 3D games, web-page capture, site scraping, automation, and awesome new web-browser mashups.

Awesomium is powerful and easy to use (it takes just 7 lines of code to render a page!) but gives you freedom when you want it.

The framework handles almost all the low-level tasks for you (network stack, HTML parsing, JS engine, layout, rendering etc.) but you can absolutely redefine much of the low-level behavior if you’d like (expose methods and data to Javascript, implement your own resource back-end, modify headers, and more).

I think this balance between ease-of-use and low-level flexibility gives developers the best of both worlds.

About this Blog

Tools aren’t much use without some guidance so we will be using this space to post weekly tutorials, news, and experiments involving Awesomium.

If you have a cool project using Awesomium and want to let the world know, definitely drop us a line at

Research, Iterate, Repeat

A project as ambitious as Awesomium needs to constantly evolve to stay relevant to the needs of its users. We make changes to our framework all the time to support the myriad of environments that it is used in.

If you have a suggestion or comment about something you’d like to see (or would like to see changed) in Awesomium, please let us know in our support forum.

Make sure to also check out our public code repositories on GitHub (fork away!) and follow us on Twitter for new updates.

Also read...

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>