Microsoft's built-in WebBrowser control exposes a set of strong typed .NET wrapper classes that are mirrored after the standard DOM (Document Object Model) interface. For example, one can use the following code to click a button with .NET's WebBrowser control:

//Get the window object
EO.WebBrowser.DOM.Window window = webView.GetDOMWindow();

//Get the document
EO.WebBrowser.DOM.Document doc = window.document;

//Get the button
EO.WebBrowser.DOM.Element button = doc.getElementById("Button1");

//Click the button
button.InvokeFunction("click");

'Get the window object
Dim window As EO.WebBrowser.DOM.Window = webView.GetDOMWindow()

'Get the document
Dim doc As EO.WebBrowser.DOM.Document = window.document

'Get the button
Dim button As EO.WebBrowser.DOM.Element = doc.getElementById("Button1")

'Click the button
button.InvokeFunction("click")

Here the EO.WebBrowser.DOM.Window, EO.WebBrowser.DOM.Document and EO.WebBrowser.DOM.Element class are .NET wrapper classes for DOM Window, Document and Element object respectively. EO.WebBrowser does not encourage such code. On the other hand, it recommends using JavaScript code together with EvalScript. The above code can be rewritten as the following with EO.WebBrowser:

//Simulate click on "Button1"
WebView1.EvalScript("document.getElementById('Button1').click();");

'Simulate click on "Button1"
WebView1.EvalScript("document.getElementById('Button1').click();")

You may notice that the key difference is for EO.WebBrowser all the logic are in the JavaScript code instead of in .NET code. This has several advantages:

• Versatile. JavaScript is the Web's programming language. By using JavaScript directly, you are not limited by what the .NET wrapper classes exposes and does not expose. Instead you can use everything that is available from the browser engine. This is especially important nowadays since browser engines update very quickly and new features/standards are constantly being added. A fixed interface will not reflect any changes/new features added to the underlying browser engine;
• Performance. Using JavaScript directly greatly increases performance not only because JavaScript engine is highly optimized in a modern browser engine such as the Chromium browser engine used by the EO.WebBrowser, but it also reduces the number of "round trips" between .NET code and the browser engine. For the strong typed wrapper class based code, almost each line would involves one or even multiple round trips to the browser engine. For example, to execute doc.GetElementById("Button1"), the control must temporarily leave the .NET code, enter the browser engine to have the browser engine to find an element with ID "Button1", and then return control back to the .NET code. The next line InvokeMember("click") would result another round trip in similar fashion. The more complex the logic is, the more round trips are needed. On the contrary, using JavaScript code with EO.WebBrowser requires just a single round trip to the browser engine ---- sending the code to the browser engine to run and return the result.
• Usability and Maintainability. Since JavaScript is the Web's programming language, why learn another set of .NET objects/classes to do the same job? This can only introduce additional overhead and unnecessary confusion, especially considering that the two interfaces are similar but not the same.

EvalScript not only submits the JavaScript to the browser engine to run, it also returns the result of the JavaScript code if available. See here for more details and sample code on this.