Chromeless, Chrominator, Chromy, Navalia, Lambdium, GhostJS, AutoGCD and Friends
Headless Chrome is shaking up traditional approaches to test automation
The Chromeless project was released publicly yesterday and within a day it has attracted over 2000 stars from GitHub users. This is a rare event, and why is this happening?
List of new entrants in browser automation space
Chromeless — https://github.com/graphcool/chromeless
Works with AWS Lambda to deploy parallel testing in a serverless setup. Compared to incumbents, API is basic for now but it’s trending like a rocket now. Contributors and maintainers can shape it into a great tool.
Chrominator — https://github.com/jesg/chrominator
Made by PhantomJS GhostDriver maintainer so the API is extensive. It covers many edge cases that users expect from mature headless browsers frameworks such as NightmareJS/Electron/Xvfb or CasperJS/PhantomJS.
Chromy — https://github.com/OnetapInc/chromy
Possibly the earliest that shipped to market, releasing in early May a thoughtful set of high-level API that works with headless Chrome. Rapid improvements since then and actively explored by BackstopJS maintainer.
Navalia — https://github.com/joelgriffith/navalia
Pretty refreshing approach by supporting the popular GraphQL language, which is normally meant for querying API endpoints. Looks to have a mature API set and most importantly it is well-documented!
Lambdium — https://github.com/smithclay/lambdium
Deployments on AWS Lambda using Selenium WebDriver. This is a very interesting proposition, because for the existing large Selenium code base in market, it has the potential for very easy migration to this tool.
GhostJS — https://github.com/KevinGrandon/ghostjs
Interesting project base on modern JavaScript that works on a multitude of browsers such as Chrome, Firefox, PhantomJS, plus expressive API. Released some time back, and development seems to be picking up speed.
AutoGCD — https://github.com/wirepair/autogcd
For Go language lovers, this project is a wrapper around the gcd library to perform automation of Chrome. Interesting project alongside the usual JavaScript/Node.js/Chrome-Remote-Interface based projects.
Quick history and context of browser automation
Few months back, Google announced the upcoming release of headless Chrome. In software development terms, headless means invisible. Decades ago, websites and webapps used to be tested manually. Then came Mercury (company later acquired by HP) and Selenium (open-source) which offer an automated approach to testing. In fact, Selenium was named because its creator casually said that element selenium is a cure for mercury poisoning.
Few years ago, headless browsers started to appear. They address the use scenario where you can run test automation without a physical screen, for example on your server or in the background on your laptop. In many cases, running in invisible mode also puts less resource strain on the system. PhantomJS is a notable headless browser based on WebKit (distant cousin of Chrome) which changes everything. Then came NightmareJS which is based on the popular Electron browser (base on Chromium, again cousin of Chrome, but newer and more similar), and usually used with Xvfb.
When headless Chrome comes into the picture, you can say it kinda changes everything again in this space. Since Chrome is the dominant browser in the market, having headless testing abilities directly on Chrome is a blessing to software developers. If your tests work on Chrome or headless Chrome, you’ll have the confidence that your web app will work for your users, at least for the majority of your users. This is a big improvement over testing on browsers which are cousins or brothers or sisters of Chrome.
Headless Chrome has recently entered stable public release and within a few months since the insider word got out, we have seen many new approaches that leverage on headless Chrome. Web browser automation as it is today, is primarily used for test automation of websites. Another popular use case is data-scraping for retrieving information from websites (Python-based tools such as Scrapy are leaders for that area, I believe). The other much smaller use case is web automation in general, such as automating some process that you would normally do manually on websites.
The upside of Chrome automation is apparent. The downside mainly relates to the fact that Chrome DevTools Protocol (the way to talk to Chrome) was primarily designed for debugging the web browser, not for automation. Of course, if Google decides to embrace this community, things can be rapidly improved and Chrome-based approaches can give developers more choices other than the mature incumbents with established ecosystems.
Lastly, it’s worth noting that most of the new tools are based on the Chrome-Remote-Interface project, which handles the communication to visible and headless Chrome. The project uses Chrome DevTools Protocol and is officially recommended for use by Chrome devs.
