Jim Evans is one of the committers for the Selenium project. He works a lot with the .Net bindings and the support for Internet Explorer. He sent out a post today to the selenium-developers mailing list about work he’s done investigating headless browser options. He then commented in the #selenium IRC channel that it perhaps would have been better served as a blog post. Since he doesn’t have a blog, I offered to let him post as a guest author here and he accepted. You can find Jim on Twitter at @jimevansmusic or contact him via email at james.h.evans.jr@gmail.com. The remainder of this post was written by Jim. Thanks, Jim!

There was recently a post to one of the Selenium mailing lists about accepting a .NET version (via IKVM) of the HtmlUnit driver to use a so-called “native” .NET implementation rather than relying on the Java Selenium server and the RemoteWebDriver class. There’s really nothing quite like HtmlUnit in the .NET space. I understand the impulse not to want to introduce non-.NET stuff into a .NET shop’s development environment. At one time I had many of the same concerns, but I’ve come around to Simon Stewart’s points of “it’s Just Another Binary” and “nobody actually browses the web with a headless browser”. However, I also realize that using a Java .jar isn’t just an xcopy deployment if you don’t already have the Java runtime installed, and in a “pure” (whatever that means) .NET shop, you may not.

Because of that institutional resistance to Java at some places, I’ve spent some time looking into alternative “headless” projects. Here’s a summary of what I’ve found:

XBrowser – I actually started a headless .NET browser called Crane, but abandoned it when Nathan Ridley contacted me about his XBrowser project. At one time, he was still using my .NET HTML parser. Good chap, but very busy, and the .NET JavaScript implementations up to this point haven’t been up to the task, so no JS engine yet, and no activity on the project in 6 months. One thing I learned while working on the project is that creating a web browser is bloody *hard*. The project is pretty much lying fallow at this point, so feel free to fork it and run with it if you’d like to pick up the ball with this one.

WebKitDriver – This project is referenced on the Selenium project Google Code home page, and uses a headless WebKit implementation. That means it uses a “real” browser engine implementation as WebKit is used by Safari and Chrome. The bad news is that it only has Java bindings, and there seems to be little response to pressure from outside the project to change that.

Envjs – This is a JavaScript implementation, originally started by John Resig (of jQuery fame). Needs a .NET JavaScript REPL and some custom JavaScript work to be accessible from .NET.

Phantom.js – Another headless WebKit implementation, but with a JavaScript API, implemented as a C++ executable, compiled for specific platforms. It’s downside is that it doesn’t act as a resident process that you can communicate with and control. Rather, it runs a single JavaScript script, then exits. Having said that, there is an issue in their issue list to create a WebDriver-compliant driver, and the project is under active development. Built statically, this would amount to an xcopy-deployable project in a Windows environment.

webdriver-zombie – This is a WebDriver implementation built to drive the Zombie.js headless browser. This project is brand-new. Like the first commit was yesterday. It’s based on node.js, which is getting lots of pub lately. That doesn’t help Windows users in the slightest at present, but the node project has a stated goal of native Windows support (experimental in 0.5, stable in 0.6), so there’s potential there. When (if) the native Windows support materializes for node, this would also amount to an xcopy-deployable project.

So if you work in a .NET-only shop, and an xcopy-deployable binary solution is okay with your development team, there are a couple of options under development that show promise, even if they’re not yet available. Contacting the owners of those projects and getting involved would probably speed up the process of getting WebDriver-compliant drivers built and available. If you can talk your development department into an installable solution, you can use HtmlUnit via RemoteWebDriver today. If they’re going to insist on a .NET-only binary, you can continue down the path of an IKVM solution, or you can write your own headless browser, maybe building on the foundation of Crane/XBrowser. In any case, I wouldn’t expect any of these solutions to land in the WebDriver trunk anytime soon, but I suspect the Selenium ecosystem is large enough to encompass other projects that provide different implementations of the Selenium WebDriver APIs, even as independent OSS projects.