eValid™ -- Automated Web Quality Solution Browser-Based, Client-Side, Functional Testing & Validation, Load & Performance Tuning, Page Timing, Website Analysis, and Rich Internet Application Monitoring. © Copyright 2000-2011 by Software Research, Inc.

Summary
There are several systems available that use JavaScript (equivalently, VBscript) based methods for "in-the-browser" test script playback. Here are some of the reasons why that approach is less effective than the eValid solution, which accomplishes test script playback directly in the browser without use of the internal JavaScript engine:

• Page Timing
  The timing data you collect during playback will be affected by the overhead associated with JavaScript function execution, which is done interpretively within the browser. Our estimates are that measured times could be off by as much as ~500%.
    >> eValid's timing values, which measured are via C++ calls to Windows system timing resources, are collected INSIDE the eValid browser. Consequently there is a very low overhead, and eValid times are very accurate, e.g. < 0.1% error.
• Component Timing
  Timing details cannot include page components because there is no access within JavaScript to details of individual constituent URLs.
    >> eValid automatically times each separate thread used to download URLs.
• Navigation Synchronization
  Playback navigation synchronization using the JavaScript interpreter usually is based on waiting for the "on document complete" signal. In many cases this will be ineffective because this single signal method may indicate "complete" inaccurately, and let playback proceed erroneously.
    >> eValid uses a combination of several different signals and events detected inside the eValid browser to conclude that a page download is complete and playback can continue. Most of these signals are NOT available to the JavaScript interpreter. eValid's playback synchronization is thus very reliable.
• AJAX Synchronization
  Playback synchronization functions that are dependent on waiting for specified element properties to take on present values will work in most cases, but have a very high JavaScript engine execution time overhead. In addition, perhaps even more troublesome, as a user you have to rewrite the program doing the synchronization each time.
    >> eValid reads DOM status information directly with C++ function calls inside the browser, with very low overhead. The result is that the synchronization is very quick and accurate. This work is most often done with a single SyncOnSelectedDocumentProperty command.
• Browser Face Access
  JavaScript functions have no access to the face of the browser.
    >> eValid provides for image synchronization when necessary, a method that is unavailable except within the browser. Tests that only require the browser face can actually run in minimized mode, i.e. not requiring ANY desktop land area.
• Desktop Access
  Likewise, there is no access to the desktop outside the browser face.
    >> eValid has full access to both the browser face and the desktop on which is resides. Tests that only require the browser face can actually run in minimized mode, i.e. not requiring ANY desktop land area.
• Opaque Objects
  Applets, ActiveX controls, Flash elements, and other opaque objects cannot be accessed by JavaScript
    >> eValid handles such objects directly by accessing their properties via the desktop.
• Single Threaded
  JavaScript programs run in the JavaScript interpreter, which is single-threaded. This means that the overhead for most actions done in test playback have to share the CPU with the browser, creating unnecessary interference. Perhaps even worse is that a "wait" command implemented in JavaScript ties up the JavaScript engine for the entire time of the wait.
    >> eValid, being a standard Windows application, exploits threads in a variety of ways: timer alarm functions, measuring page component download size and time, manipulating the cache, etc.
• Can't Write Data
  JavaScript programs can't write data to the local machine, only to the server. This creates validation data problems because a second machine has to be involved.
    >> eValid programs can write local files, so eValid can save data directly to the local machine. E.g. the SaveVisibleText command is one way to do this.
• Cross-Site Scripting Limitation
  Cross-site scripting security is built into the JavaScript engine in all browsers. Because of this you can't edit (modify) the content that originates from a different domain from the one where your browser resides. Playback engines in JavaScript necessarily must operate on the domain from which they draw pages.
    >> eValid, being a local self-contained browser, can edit pages that it browses to, independent of where they originate.
• Mixed Protocol Sites
  A web application that uses pages from http://mydomain.com AND from https://mydomain.com will encounter a Permission Denied error when you try to command actions on both domains from JavaScript. This is because of the cross-site scripting security constraint.
    >> eValid, indistinguishable from any other browser, has no difficulty with these kinds of pages.
• Other Security Issues
  JavaScript processes cannot access $name=value pairs that appear in modifiers in the current URL, and cannot manipulate [nor delete] persistent cookies (those stored in the browser). Both of these security issues have to be handled externally to the JavaScript engine. For details please see this article on JavaScript Security.
    >> eValid, itself being a browser, handles all kinds of HTTP/S, persistent cookies, and session cookie situations without difficulty.
• Memory Leaks
  As a program in JavaScript runs it accumulates allocated memory very quickly. If there are programming failures in the JavaScript the size growth can consume resources so rapidly that the browser will crash.
    >> eValid operations are handled direct to the operating system and rapid growth due to JavaScript "spinning" is not a problem.
• Batch Interface
  There is no explicitly batch (command line) interface, which will make it difficult to use these kinds of playbacks in a regression testing or monitoring activity.
  >> eValid has a complete batch (command line) interface, and the associated eV.Manager engine is able to run scripts automatically and unattended.