So here’s what you need toÂ know:
A headless browser means you don’t see it open when you start it, it’s all in memoryâ€Š–â€Šand it also implies user actions are automated.
Uses of automation:
- QA tests
- Pre-rendering single-page apps.
Uses of headless:
- Less resource intensive.
- Great for build-systems running tests before a deploy.
- Can run in many more server environments, like Lambda.
Is this the first headless automated browser? No, phantomJS has been the goto browser like this, but the main contributor almost immediately stepped down when he heard about Chrome’s new headless featureÂ . Turns out its hard to maintain an ENTIRE browser.
- running the executable like this:
chromeâ€Š–â€Šheadlessâ€Š–â€Šdisable-gpuâ€Š–â€Šremote-debugging-port=9222which opens it without a visible window.
- then sending commands to the above port… closest to the metal node library is this oneÂ .
- the above commands give you ability to do almost anything a user would do… so you can scrape data or make tests.
The community has decided that we need a pretty wrapper around this “low level stuff, and have started making these:
- Chromeless (a combination of the words “Chrome and “Headless and maybe even “Serverless”).
- Puppeteer (Googles very own “lightweight wrapper”)
- Simple-headless-chrome (another wrapper) Probably many more to come!
What’s the state of each of these frameworks? Let’s find out in a couple months once they’ve grown up a bit. Comparing and contrasting right now would be a practice in futility.