Johnson's purpose however is to shed light on what goes behind the scenes and make automated AJAX testing possible. John's take on it:
Johnson got created for a couple of reasons. First, Aaron Patterson -- who created Mechanize -- has been getting more and more requests from people who would like to interact with highly dynamic websites‚ we'd like Mechanize to behave as much like a server-side browser as possible, including dynamic page behaviors and DOM manipulation, and Johnson is a stepping-stone on the way to that functionality. Secondly it was the geeky desire to see how smoothly we could get objects and metaphors moving between the two languages.
However Johnson is not just another screen scraping utility like Mechanize, it is more a browser like component without a real browser behind it. It allows for testing across a multitude of browsers, and automation of those tests. John commented on this:
Of course having a tool like Johnson is not enough, eventually real browser testing will be needed, but a big part of automated repetitive testing can be taken care of with little effort.
So it is clear that was not the purpose of the tool, but someone could fork it in that direction, and actually this has happened already [GitHub link to fork] here.
On the Chrome theme John had some good news to share:
Another concern is how to use Johnson in an everyday development shop. For John it is ideal for continuous integration testing and autotest sessions of AJAX functionality.
While there is no tool ready yet that behaves like a programmable or scriptable Mechanize, it could eventually be developed. In the meantime the team is concentrating on providing a viable server-side DOM implementation. They are pursuing several alternatives; the good news is that it seems a solution will be found. John comments on the subject:
We're pursuing a couple of avenues there. We're working with John Resig on env.js, which is looking to provide a JS implementation of the DOM, with minimal runtime-specific portions for XML/HTML parsing, threading, and network requests. We're also looking at a solution that uses libxml's HTML parser, I think we'll probably end up with a libxml based solution.
On the subject of automation and the ability to see values AJAX delivers; FirePHP is a tool that integrates with Firebug's console. Asked whether something like that could be implemented using Johnson for the Ruby world, John said:
Ah, very cool. Johnson's probably to the point where you could get that going as a Rails plugin pretty easily‚ One of us should write that!
Another strength of Johnson as a project is the quality of the team behind it, besides Mr. Barnette they have Yehuda Katz, Aaron Peterson and Matthew Draper.
Finally, when asked about the future and what a 1.0 of Johnson will bring us, John says:
The big non-negotiable for 1.0 is being able to provide a viable browser-less DOM!
A correction regarding Mechanize
I don't think that's correct. I believe Ruby's Mechanize was created by Michael Neumann, and was based off a Perl library of the same name. (I was submitting patches for Mechanize to Michael before Aaron took over the project.)
How Can We Use Our Creative Power and Technological Opportunity to Address the Challenges of the 21st Century?
Gyorgyi Galik Feb 26, 2015