On Wed, Jan 27, 2010 at 7:38 PM, Ethan <[email protected]> wrote: > > Basically it seems to me to add an unnecessary layer of complexity. Watir > can talk to a browser - firefox, for example - directly through an extension > (JSSH). or it can talk to another piece of software (webdriver) which in > turn talks to firefox through some other piece of software (FirefoxDriver, I > think?). Why is the latter advantageous? > > One argument is that the other piece of software moves browser-specific > implementation stuff out of watir's code. But, really, the DOM is not too > terribly different from browser to browser; if you have the same access to > the DOM, much of the implementation is the same (which is why I have been > able to move so much code from firewatir and ie-watir to commonwatir).
The main advantage to me is the fact that in WebDriver, the technology used to control the various browsers is completely separate from the user-facing client library. The core, browser-specific implementation of the WebDriver API isn't tied to one programming language, which means there's a larger community of clever people who hack on the core parts and solve the browser-specific problems (which are not trivial). Another important benefit is that WebDriver takes a native approach to automating the browsers, which means it can choose the best approach for the particular browser used - not necessarily rely on the JavaScript DOM implementation, which does vary between browsers and also has other constraints (like dealing with prompts or alerts, window switching, cross-domain limitations etc.). WebDriver will also use native, OS-level events where available (Windows and Linux at the moment) - so clicks and key presses will be a lot more realistic than synthesized JS events. The fact that the Selenium project (which is purely JS/DOM-based, and also among the most successful autoamtion tools, despite its unattractive API) has decided to merge with WebDriver, should be a strong indication that the native approach has a lot of validity. In Firefox and Chrome, this means using their extension mechanisms; for IE, the driver is implemented in C++; for Opera, it will (when released) use the same protocol as their built-in developer tools. One can also issue commands using a JSON-over-HTTP interface, which is used to drive browsers on iPhone and Android or on a remote machine. All of this is of course is nothing a Watir user would need to bother with. The WebDriver API is intentionally kept small and concise for exactly this reason, making it the perfect building block for higher-level tools (like Watir). > It seems like a lot of the point of watir itself has been to move > browser-specific implementation stuff to where users don't have to worry > about it; if webdriver does this, why is watir needed at all? (apart from > familiarity with its api and code that it would be a pain to migrate, I > guess.) You're right, it's not needed. You can definitely use WebDriver directly if you're starting from scratch and/or like that API better. As mentioned by Charley (and others), the strength of Watir is really its API and the ease of use - not the underlying tech. So the question is: can I use my favorite API with the best available tech as the backend? That's the main motivation for doing the watir-webdriver project. Of course, instead of building on the work being done by the WebDriver/Selenium team we could try to do it on our own; based on the existing implementation, make a generalized core and write some browser-specific code where needed. That would be valid if our technology, expertise or level of activity was vastly better than theirs. It's not. So consolidating these efforts makes a lot of sense to me. I hope I don't come off as trying to belittle your work - the 1.X code base was in dire need of some refactoring last time I looked, and from what I've seen of your fork (some time back), the design changes make a lot of sense. For me personally though, what route the official Watir project decides to take is honestly not a big concern, I'll be chugging along on the watir-webdriver code until some superior technology comes along. :) _______________________________________________ Wtr-development mailing list [email protected] http://rubyforge.org/mailman/listinfo/wtr-development
