Google Chrome and .NET - Almost, But Not Quite

I've been working on a browser for people who are easily-distracted. My theory is that most of html, instead of providing user value, is actually put in to drive "engagement" or "site stickiness", which are just fancy words for me spending too much time doing things that serve little practical value, like clicking up or down voting buttons, playing a flash game, signing up for some subscription, or engaging in a conversation with somebody else who is wrong on the internet.

The working name is "Magic Brick", and basically it works like one of those old-fashioned Star Trek tablets. Big lights, simple screen, plain text. Nothing else.

Over the last two weeks, however, I've realized that plain text has its limitations. You can't put a table easily into plain text, for instance. As my oldest son pointed out, some articles center around a central picture -- a infographic, an unusual photo, or a movie. While I could custom-code up all of that, it seemed like reinventing the wheel. Why not just create html that looks mostly like plain text and display it in a browser? That way if I just have to have 3-D models, I can easily send it out to the browser and let it handle it.

Ah so, but not so simple, grasshopper.

First up, IE is a huge pig. Love you Microsoft guys, but it has been time for a refactor/re-inventing of that code for a long, long time. I'm really not tying my project to something that is big, unwieldy, slow, and so far behind everybody else. It's going to have to be the most HTML5 compliant browser I can find.

So I started googling around. Can I use Google Chrome as a browser control? I have some pretty good Google-Fu, but searching for this -- embedding Chrome in a .NET winforms application -- was like trying to find the body of Jimmy Hoffa (look it up kids). It just wasn't happening. Google don't want you putting Chrome in .NET apps. After all, that defeats their entire business model! They want us to be the Borg. They store all of our data, provide it on demand, and tell us what to do. The Queen Borg, as it were. If we had full creative capability over what to do what our browser we might start doing stupid and crazy things, like keeping our data locally, using the same algorithms they use but keeping our personal life to ourself, skipping ads, or telling ourselves what to do. All sorts of nonsense. Can't have that.

But there was a ray of hope! Turns out Google created Chrome Frame, an Active-X control that sits inside of IE and basically turns it into some kind of it-came-from-hell hybrid of Chrome and IE. Part of the world domination plan, yes, but a part I can use.

So the new strategy -- much as I didn't like it -- was to embed IE (webbrowser control) in a form, then use Chrome Frame to display the html.

That didn't work.

Problem is, I'm using Microsoft's cool new whiz-bang functional language, F#. So I'm doing all the cool functional stuff -- immutable data, threading, asynchronous callbacks, currying and hurrying. IE don't play nice in that world. IE's threading model is STA, which, to make it short and sweet, means it doesn't play ball with the big kids. It just kind of sits over on the sideline and whines a lot.

That sucks.

So no IE, no Chrome. But wait! Isn't Chrome built on the open-source webkit engine? Perhaps I can use Chrome without really using Chrome.

Sure enough, I found a guy who is writing a C# wrapper around webkit. A few minutes of clicking and downloading, and I had a beautiful C# project on my desktop. A project which didn't work, either.

Something about COM interfaces. For those of you who have not experienced the joys of COM programming, to get an idea of the pain involved just pinch your bottom lip real hard. Now pull your lip over your head.

Never fear! I am not giving up this easily. Programming is an odd mix of skills -- it's part chessmaster, part puzzlemaster, and part stubborn jackass.

As much as I've slammed Microsoft over the years, you have to hand it to .NET and the CLR, I honestly think it's the best thing they've done in the last decade. I brought up the source code (in C#, not F#), then ran my f# project while it tried to use the control. A little bit of looking around and there -- some new COM interfaces that the original programmer had not implemented. Pretty cool to program in one language and debug in another.

At first, I just commented out everything that broke. Open source is awesome! Having problems? Find the offending lines and comment them out. Suddenly no more problems! Function failing and needs to return a string? Make it the return value "weasel". I'm sure some code somewhere will know what to do with it.

So after commenting out about five errors, the control ran well. Only it didn't do anything except display an empty box. In the business this is technically known as "sub-optimal performance"

But there's a method to the madness. By doing my hacking exercise, I realized that the scope of the problem is around 5 methods. This allowed me to make the decision whether or not to actually fix the problem or continue searching for answers. I decided to fix the problem.

A couple hours later, and voila, webkit running as a threaded control inside a F# project. All the html5 goodness I could want.

But it gets better. With the initial wrapper code in place, I could easily start getting the nightly builds of webkit and just updating the wrapper code in my project. As such, I'd always have the latest html5 deployment, even ahead of Google Chrome.

But that's heading down another road entirely, and for the easily-distracted, probably worth putting off until another day.