PhantomJS: Archiving the project, suspending development
51–60 of 138 posts
Re: PhantomJS: Archiving the project, suspending development
#52Earlier quoted context omitted.
I really hope Microsoft offers a headless IE / Edge at some point. It would be amazing to be able to use all 3 major browsers like this. Heck, get Safari in there too (though I feel like it should be doable with WebKit already).
they have webdriver support. Is that enough? I'm not sure what's the difference between headless and webdriver (if any) https://blogs.windows.com/msedgedev/2015/07/23/bringing-auto...
Re: PhantomJS: Archiving the project, suspending development
#53"Will do as advised, as I really think PhantomJS is good project, it just needs good, devoted leader."
Re: PhantomJS: Archiving the project, suspending development
#54Well with Chrome going headless there isn't a whole lot of place for PhantomJS anyway. Or is there? What is it still good for?
Legacy systems for one. The Cooperative Patent Classification group releases their classifications en masse as HTML (single zip download, which is great). I built a parser for a PHP project that could parse all several hundred thousand records from the HTML in a few minutes. In 2017, they switched to a system that loads in the data from JSON stored in Javascript in the HTML (it is every bit as terrible as you imagine…
https://www.cooperativepatentclassification.org/Archive.html
Re: PhantomJS: Archiving the project, suspending development
#55Earlier quoted context omitted.
Legacy systems for one. The Cooperative Patent Classification group releases their classifications en masse as HTML (single zip download, which is great). I built a parser for a PHP project that could parse all several hundred thousand records from the HTML in a few minutes. In 2017, they switched to a system that loads in the data from JSON stored in Javascript in the HTML (it is every bit as terrible as you imagine…
Why would you need PhantomJS for that? Can't you just parse the HTML files with Nokogiri and be done with it? That would be orders of magnitude faster anyway
>In 2017, they switched to a system that loads in the data from JSON stored in Javascript in the HTML
Re: PhantomJS: Archiving the project, suspending development
#56There 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. Has anyone here figured out any tricks to get headless Chrome booted fast?
Also PhantomJS was a single statically linked binary with no dependencies that you could literally drop into a server and run scripts at once.
godet is the lib I use for chrome piloting, replace with your favorite one.
Re: PhantomJS: Archiving the project, suspending development
#57Re: PhantomJS: Archiving the project, suspending development
#58Earlier quoted context omitted.
OK, obviously the stuff you see on your screen not matching the HTML delivered makes sense, but explain the HTML source not matching what's sent via the HTTP response. DOM can be modified, of course, JS can introduce more dynamic HTML, but view-source should always represent any non-redirected HTTP response. What is Nokogiri getting that the browser isn't (or vice versa)?
> JS can introduce more dynamic HTML, but view-source should always represent any non-redirected HTTP response That is both true and false. Because the JS can introduce dynamic content, the source returned by the HTTP response often doesn't match the source that is rendered by the browser itself. In many cases, a site will return a skeleton (just HTML) and then make an Ajax request to populate it. In my case, it was…
The post replied to claims that Nokogiri doesn't see this however so I'm puzzled.
Re: PhantomJS: Archiving the project, suspending development
#59Earlier quoted context omitted.
OK, obviously the stuff you see on your screen not matching the HTML delivered makes sense, but explain the HTML source not matching what's sent via the HTTP response. DOM can be modified, of course, JS can introduce more dynamic HTML, but view-source should always represent any non-redirected HTTP response. What is Nokogiri getting that the browser isn't (or vice versa)?
> view-source should always represent any non-redirected HTTP response Not the grandfather, but generally in browsers you have two versions of HTML "source" - the canonical source, the stuff pulled down over HTTP, and the repaired source, the version that actually gets rendered. I'm unfamiliar with Nokogiri, but I suspect that from context, it doesn't repair HTML in the same way that browsers do.