Hacker News Reader

Comment by curiously | Hacker News Reader

Take headless browsers with a pinch of salt. They are not a replacement for a real browser. Don't be surprised when it renders or behaves differently from a real browser.

Did they fix the memory leak issues in PhantomJS? Take a look at the issues and consistently you will find people having trouble rendering a complete site.

Creating a headless browser is really taking a real browser on Xvfb. You have the support of a billion dollar company supporting and updating their browser, you reap the benefits of being able to run it headlessly. The drawbacks of this method is often overstated, 'oh my run a fat browser process AND X display? ok grandpa' but the real hidden problem with PhantomJS is understated 'why does my phantomjs process balloon in memory and cpu usage and crash, I can render the website fine in my browser'.

Standalone headless browsers are good for hacks but I wouldn't rely on it.

View on HN

afaik the worst of the memory leaks were fixed with the 2.0 release, and they also upgraded QtWebKit to 5.3 which fixed some pretty egregiously outdated constraints (like not having access to Function.prototype.bind) present in the previous version. Sadly this tool utilizes phantomjs 1.9 which means the memory leaks are still present and major WebKit features are still missing.

One great use for headless is to separate non-UI framework/platform tests from UI tests - at my previous gig we wrote all the tests for the runtime platform against phantomjs to avoid the unneeded overhead of a full browser for things like data validation or mocking service calls, but used selenium to do the visual/interaction tests for the application UI itself. it's also a nice separation of concerns, though of course we hit all the same problems you mentioned as we were also pinned to 1.9.

https://github.com/ariya/phantomjs/issues

1470 open issues

the first one is about phantomjs crashing and many many other scary sounding issues you wouldn't have if you've used just a regular browser with Xvfb.

you can't really be sure unless you've literally run a test on the colorful variety of websites in the wild. You need a huge development and quality assurance team. You also need a way for a large crowd of people to test your browser and send back useful reports automatically whenever it crashes.

Open issues is a pretty bad metric, especially considering the other major open source browsers would make PhantomJS look downright perfect.

Chrome: https://code.google.com/p/chromium/issues/list

73,025 open issues

Firefox: https://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIR...

10,000 open issues.

apples and oranges. chrome and firefox is used by millions of people. of course its going to have more eyes on it but when was the last time you couldn't render something in your browser?

phantomjs is used mainly by developers. you can't seriously compare it to chrome or firefox.

quick scan shows that most of the bugs showing up in chrome and firefox are very platform centric or esoteric issues while phantomjs is concerning because they are literally about being unable to render a webpage without crashing.

> 1470 open issues

That's a really weak argument. Here's 5000 Firefox bugs:

    https://bugzilla.mozilla.org/buglist.cgi?component=General&product=Firefox&query_format=advanced&resolution=---&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&limit=0

considering firefox userbase is many many times those of phantomjs it shouldn't be of surprise to you. especially when most of phantomjs issues revolve around the same issues, unable to render a website that you can browse fine with firefox or chrome. this is a consistent issue that has haunted the project since the beginning.

Reply on news.ycombinator.com