While PhantomJS is far from perfect, there are still some misconceptions out there. This blog post attempts to clarify some of them.
PhantomJS on Linux is not truly headless, I still need to run X11 or Xvfb.
That is not true anymore since for quite some time (I spare you the details, but it is involving the Lighthouse project). In fact, it works like a charm that it is now the standard setup if you build PhantomJS Linux from source. Pure headless, pure possibilities.
Read also the blog post”) where I describe the workflow when I finalized and tested the X11-less version PhantomJS. In short, install a barebone Ubuntu server with no GUI (i.e. no KDE, no GNOME, no X server at all) and you can use PhantomJS just fine. That’s as minimalistic as it can get, perfect for continuous integration (Jenkins, TeamCity, etc). Want to run on Amazon EC2? Be my guest, PhantomJS goes to the cloud already.
Installing PhantomJS is really slow.
That’s only true if you do it via a tool which compiles PhantomJS from source, e.g. old MacPorts or Homebrew. I mean, when did the last time you compile your web browser from source?
As this blog post mentions, the most recommended way to install PhantomJS on Mac is by using its binary package which weighs at just 10 MB. The entire process might take just 5 minutes of your time. Even the updated Homebrew formula for PhantomJS does that exactly, brew install phantomjs is fast and efficient.
I don’t like/want the binary because I still need to install Qt manually.
If you actually read the wiki page carefully, it mentions e.g. “fresh install of Snow Leopard or Lion…” for Mac OS X. In other words, the binary is stand-alone. It does not require you to install anything else beforehand. No prerequisites. Zero dependency. The same applies for the Windows version.
The situation is slightly different for Linux. Even though PhantomJS is completely headless”) there, text rendering still requires the de-facto Freetype and Fontconfig libraries (which does make sense since we don’t want to duplicate the functionalities). They are very simple to install. In fact, if a barebone minimalistic Ubuntu Lucid server sans GUI can run PhantomJS binary package just fine, most likely it would work well on your target host as well.
How is it possible? The build workflow of PhantomJS takes care of integrating Qt into the build, even optionally compress the final result so that at the end all you have to do is download + unzip + have fun. Let us handle all the trouble, you don’t need to.
It’s a PITA to install PhantomJS.
This is borderline. As of now, installation is not most trivial step to do. It might be a minor hassle, but it is definitely not PITA. Since PhantomJS project is driven by the community, unless someone volunteers to create a single-click installer, it will not happen. If you are ready to help, there is an open ticket (issue 466) for that!
If unzipping a package and playing with PATH are too complicated for you, well, now there’s an excuse to learn a thing or two. Think about it, unless you are Chuck Norris, what is likely chance that you become a Grand Master just by flipping two or three chess books?
PhantomJS is too complicated, it’s difficult to use.
Again, it depends on your skills, experience, and expectation. Many people use PhantomJS directly, as evidenced from tons of reports out there. Others use PhantomJS in conjunction with other tools, for example Guard::Jasmine to drive Jasmine-based unit tests, Poltergeist as a driver for Capybara, GhostDriver to complement Selenium Web Driver scenario, and many others. There are even higher-level convenience libraries, notable here is CasperJS, which facilitate easy sequential navigation testing (among others). PhantomJS was designed from the ground-up to promote a healthy ecosystem and thus make sure you explore it.
Some notable and popular frameworks, such as Ember.js, Modernizr, Zepto.js, and BrowserID, are already leveraging PhantomJS to conveniently run the automated tests. You may learn a thing or two from the way these projects use PhantomJS!