Wow. Congrats on finally going completely headless on Linux. That's a big deal.
This makes it the first modern browser replacement for our old moz-headless-screenshot branch, which is effectively Firefox 3.6. It's really a shame no-one's picked up that work for modern FF builds. Couldn't even find someone to hire for it...
As previous comments state, you don't need a display, which is a bit of a half truth. Some instances, like running headless Selenium testing with Firefox, would still require
a virtual screen to draw to. We do some our browser testing this way, on servers that don't have a screen.
While it does kinda suck if your usecase needs Flash, I think the reasoning was solid. Being able to truly run headless in a barebones command line environment is more important than supporting Flash, in its waning years.
Then, of course, there's also this:
Issues are reported but nobody volunteers to analyze or fix them
I use to get a daily overview of ads on a bunch of publisher's sites, fortunately the older version with flash support will continue to work just fine for this case.
The main advantage of Selenium is that it allows you to test cross-platform compatibility, since it can be configured to run on pretty much every major browser/OS combo.
For everything other than that, though, PhantomJS is fantastic. It's infinitely more pleasant to deal with than Selenium.
If you are currently using Rhino to run Javascript then PhantomJS makes for an excellent and more functional replacement.
In addition to running library unit tests in a 'real' browser environment it can also be used to test apis and visual components, and then save results as files and screenshots for use with other systems such as Hudson.
I use it extensively for our web app build and test cycle at work (Causata.com) and to save time for anyone interested in rolling their own have made the code available on Github at https://github.com/metafeather/phantomjs-yuitest
I have been surprised that this project has seemed to fly under the radar for so long. It's extremely useful in a variety of scenarios, and as far as I know, it is unique in its capabilities.
I've used it to allow modern applications to interface with legacy systems that have no mechanism of extension, and no API other than their web interfaces. Just about anything you can control via a web interface, you (or your software) can control using PhantomJS.
We're currently using it to generate static map images for a powerpoint export feature we introduced a little while ago. We initially were going to use Google's static maps API but quickly ran into limits (only 5 custom markers, needing a different set of code to actually generate the maps) and decided to take screenshots of the map in our existing application. Besides actually being able to generate maps the way we want them, the other big advantage is that since it's sharing the same code base as our web product it's much easier to catch issues if they crop up. Being able to run headless on linux is amazing (on OS X you download the binary and it just works, getting 1.4 to run cleanly took a little bit of playing around to get Xvfb to play nice).
One example is a company I worked with that has this ancient legacy groupware system. Shared calendar, reporting, workflow, etc. The UI is based on tables and frames, the backend is some kind of compiled perl modules or something, and it has no API. And it uses some kind of weird database format, maybe intentionally obfuscated.
The system does not work well with iPads, which were being deployed to sales. A new modern iPad-savvy reporting UI for sales staff was wanted, but the data had to end up in the legacy system during the multi-year transition that would phase it out.
We wrote a Rails app for the backend, and a native iOS client that ran on the iPads. Real straightfoward, the client app sends JSON to the rails backend. Upon submission of a report, the rails app then used PhantomJS to log into the legacy system as the user in question, navigate throught the multiple-page process, manipulating the popups and checkboxes and textfields, and input the data into the legacy system just as if the user had sat down at a PC and done it themselves.
Kludgetastic, definitely, but without something like PhantomJS there'd be no way at all to get data into this legacy system programatically.
For the superior completely headless qualities? There was a post on HN almost 400 days ago where someone claimed wkhtmltopdf's PDF output quality was superior to phantomjs - anyone know if that's changed with this release?
In my experience, using jsdom (and other similar node.js DOM libraries) is fine for scraping static content, but tends to fall down when you're dealing with anything that requires executing client-side JS. That's a big deal if you're scraping sites that load in content via XHR, or manipulate CSRF tokens in JS specifically to throw off static scrapers. Both of these are use cases that PhantomJS has handled beautifully for me in the past.
Those are just scraping tools. phantom is a browser, what your scripts see are exactly what the user would see. Makes it great for test automation. Casperjs is a fork focusing on testing.
I built a scraper that was nodejs and nowjs that sent instructions to a javascript bot I injected into the page rendered by phantomjs, the bot then scraped and sent snippets back to the server again via nowjs. The real win for me was it was a comet + ajax target which is usually hard to scrape efficiently but I just synced the bot with the comet updates and away we go. Also being headless I could just spin up 20 instances without any performance problems on a cheap rack server.
For example, if you need to scrape the DOM content for content loaded dynamically by JavaScript, PhantomJS will allow you to do the job. Or take snapshots of Web sites as they appear to users.
After having read the installation guide on Windows for Phantom.js and WebServer, that is embedded in it, apparently installing the first to use the second is a lot simpler!
Yeah. That's how I have used it. But it would be great if phantomjs can be launched as a daemon and then you pass a script for it to process. Or launch it with a script which runs forever and accepts input (phantomjs has an inbuilt web server).
I think it ay be possible but wanted to know for sure.
Yes, it uses xmlrpc (node-xmlrpc) for communication between RobotFramework and Node, and websockets (socket.io) for communication between Node and PhantomJS (which didn't bundle http-server when I started).
I'm sorry to not have a separate websockets-example, but there's really nothing special in using websockets with phantom.
This makes it the first modern browser replacement for our old moz-headless-screenshot branch, which is effectively Firefox 3.6. It's really a shame no-one's picked up that work for modern FF builds. Couldn't even find someone to hire for it...