Chrome and Firefox gaining headless modes is the ultimate goal Phantom could've achieved.<p>So I consider it a complete success.<p>Kudos to all contributors.
This project has been effectively dead since April 2017, when Vitallium stepped down as maintainer as soon as Headless Chrome was announced [1]:<p>> Headless Chrome is coming [...] I think people will switch to it, eventually. Chrome is faster and more stable than PhantomJS. And it doesn't eat memory like crazy. [...] I don't see any future in developing PhantomJS. Developing PhantomJS 2 and 2.5 as a single developer is a bloody hell.<p>One potential path forward could have been to have PhantomJS support Headless Chrome as a runtime [2], which Paul Irish (of Google Chrome team) reached out to PhantomJS about. However, it seems there hasn't been enough interest/resources to ever make this happen.<p>[1] <a href="https://groups.google.com/d/msg/phantomjs/9aI5d-LDuNE/5Z3SMZrqAQAJ" rel="nofollow">https://groups.google.com/d/msg/phantomjs/9aI5d-LDuNE/5Z3SMZ...</a><p>[2] <a href="https://github.com/ariya/phantomjs/issues/14954" rel="nofollow">https://github.com/ariya/phantomjs/issues/14954</a>
Timeline of what lead to this, from what I could gather:<p>• phantomjs is 7 years old, @pixiuPL has been contributing for about 2 months<p>• @ariya didn't respond to his requests for <i>owner</i> level permissions<p>• @pixiuPL published an open letter to <i>the main page of phantomjs.org</i> <a href="https://github.com/ariya/phantomjs/issues/15345" rel="nofollow">https://github.com/ariya/phantomjs/issues/15345</a><p>• the stress leads @ariya to close the repo.<p>• @pixiuPL intends to continue development on a fork<p>This is a good reminder of why non-technical skills are so important in OS and in general.
Some people are mentioning headless Chromium, so I wanna mention another tool I've used to replace some of phantomjs' functionality: jsdom [0].<p>It's much more lightweight than a real browser, and it doesn't require large extra binaries.<p>I don't do any complex scrapping, but occasionally I want to pull down and aggregate a site's data. For most pages, it's as simple as making a request and passing the response into a new jsdom instance. You can then query the DOM using the same built-in browser APIs you're already familiar with.<p>I've previously used jsdom to run a large web app's tests on node, which provided a huge performance boost and drastically lowered our build times. As long as you maintain a good architecture (i.e. isolating browser specific bits from your business logic) you're unlikely to encounter any pitfalls. Our testing strategy was to use node and jsdom during local testing and on each commit. IMO, you should generally only need to run tests on an actual browser before each release (as a safety net), and possibly on a regular schedule (if your release cycle is long).<p>[0] <a href="https://www.npmjs.com/package/jsdom" rel="nofollow">https://www.npmjs.com/package/jsdom</a>
For those who haven't looked at some of the commits by @pixiuPL, the list is here : <a href="https://github.com/ariya/phantomjs/commits?author=pixiuPL" rel="nofollow">https://github.com/ariya/phantomjs/commits?author=pixiuPL</a>.<p>To summarize: It does not look like the guy has done a single commit with any meaning. His commits are basically the following:<p>1. Adding his own name in package.json
2. Adding and deleting whitespace.
3. Deleting the entire project and commiting.
4. Adding the entire project back again and commiting.<p>Just out of curiosity: How likely is that someone may be able to use a large number of such non functional commits(adding and removing whitespace) to a popular open source repository to boost their career ambitions.(e,g. Claiming that they made 50 commits to a popular project might sound impressive in an interview.)
Two alternatives:<p>Headless Chrome with Puppeteer: <a href="https://github.com/GoogleChrome/puppeteer" rel="nofollow">https://github.com/GoogleChrome/puppeteer</a><p>Firefox-based Slimer.js: <a href="https://github.com/laurentj/slimerjs" rel="nofollow">https://github.com/laurentj/slimerjs</a> (same API as Phantom which is useful if using a higher level library like <a href="http://casperjs.org/" rel="nofollow">http://casperjs.org/</a>)
As has been said, this point was somewhat inevitable with the advent of Chrome and Firefox's headless modes. However, as the project slips into the mists of history, let's not forget the vital stepping stone it provided in having access to a real headless browser environment vs a simulated one. I for one will remain grateful to Ariya, Vitallium and all the team for their efforts.
I’m super biased in this, having spend considerable time programming against PhantomJs, Selenium and now Headless Chrome / Puppeteer for my startup <a href="https://checklyhq.com" rel="nofollow">https://checklyhq.com</a>. This whole area of automating browser interactions is an extremely hard thing to get stable. In my experience, the recent Puppeteer library takes the cake but PhantomJs is the spiritual father here. I will not talk about Selenium for blood pressure reasons
Within the issue @pixiuPL created, I listed some of the things that he has shown incompetence on: <a href="https://github.com/ariya/phantomjs/issues/15345#issuecomment-370269460" rel="nofollow">https://github.com/ariya/phantomjs/issues/15345#issuecomment...</a>
Ariya wrote a bit about his reasoning here: <a href="https://mobile.twitter.com/AriyaHidayat/status/970173001701367808" rel="nofollow">https://mobile.twitter.com/AriyaHidayat/status/9701730017013...</a>
also mentioning an old post in <a href="https://github.com/ariya/phantomjs/issues/14541" rel="nofollow">https://github.com/ariya/phantomjs/issues/14541</a>
I still think it's premature. There is still couple of fields PhantomJS is better than Headless Chrome. Notably proxy support, and API aviability.
There is one thing about this that saddens me: PhantomJS still starts up much faster than headless Firefox or Chrome, at least for me, which makes some of our integration tests take a long longer than they should.<p>Has anyone here figured out any tricks to get headless Chrome booted fast?
End of an era! Congratulation to team for all their hard work and excellent contribution to help teams build better software.<p>All the best to everybody!
Somehow I am having issue to use both headless FireFox|Chrome. Unlike PhantomJS where all I had to do is to drop the binary and set the path, both FF and Chrome are not following same route thus I am happy to use PhantomJS for a while
I would think PhantomJS is still quite heavily used so having some kind of migrator to puppeteer would be useful. I’m sure people would pay $$$ for it.
Does anyone here know if there's a way to set SSL client certs with Headless Chrome? With PhantomJS I could use<p><pre><code> --ssl-client-certificate-file and --ssl-client-key-file</code></pre>
I do lightweight web automation via Chromiums "Snippets". It is super nice to work that way because you see on screen what happens and can check everything realtime in the console. Only problem is that they dont survive page loads. So when my snippet navigates to a new url I have to trigger it again manually. What would be a good way to progress from here so I can automate across pages?
One of the guys working on P-JS just linked from a GH issue to his open letter... He isn't very happy with the owner blah blah blah and is going to fork the master branch to make phantom great again, I'll just put this here:<p>"Will do as advised, as I really think PhantomJS is good project, it just needs good, devoted leader."
Shoot, I was just planning to use this for generating PDFs out of a URL on nodejs. Does anyone know of any other library / module out there that is good at this?