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 email@example.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:
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.
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.