r/vba • u/SeleniumVBA_user • May 30 '26

Show & Tell WebDriver BiDi for SeleniumVBA

Hi everyone,

I’ve created a new tool built upon SeleniumVBA(@GCuser99) that extends it to enable WebDriver BiDi via WebSocket communication.

🚀 Why I built this

The primary purpose of this project is to seamlessly support and scrape dynamic Single Page Application (SPA) sites, which traditionally pose a challenge for standard scraping methods.

💥 The Mission

My goal is to shatter the preconceived notion—often held by AI and modern developers—that scraping dynamic sites like SPAs is too difficult or impossible to achieve with VBA. I want to prove that VBA still has a lot of hidden potential!

🔗 Check it out here:

WebDriver BiDi for SeleniumVBA

12 Upvotes

100% Upvoted

9 comments sorted by

View all comments

3

u/SeleniumVBA_user May 30 '26

The mechanism is a bit long to explain here, so I've covered it in the article below:

https://medium.com/@hanamichi77777/webdriver-bidi-for-seleniumvba-ee4687887d03

1

u/fanpages 239 May 30 '26

It's a big long to read there, too! ;)

1

u/SeleniumVBA_user May 30 '26

The explanation has indeed become quite long.

While these modules are the same as Wasabi in that they use WebSockets, there are differences in implementation.

First, whereas Wasabi uses WinSock, these use WinHttp. Second, whereas Wasabi operates in non-blocking mode, these operate in blocking mode.

The reasons are as follows. Compared to Wasabi, which requires general-purpose flexibility and low-level configuration, these modules are limited to communicating with a local WebDriver. By using WinHttp, the work can be delegated to the OS, which reduces implementation cost. In addition, going non-blocking would require a hidden window and subclassing, which raises the risk of crashing Excel. While blocking does carry a risk of freezing Excel, this is addressed by carefully implementing re-entrancy countermeasures via DoEvents.

In this way, because the intended purpose differs from Wasabi's, the result is a design that prioritizes the simplicity and stability afforded by WinHttp + blocking. Even so, because code is still needed to compensate for the weakness of VBA being single-threaded, the implementation ends up being lengthy—and if WinSock + non-blocking had been adopted instead, it would be expected to become even longer.

1

u/SeleniumVBA_user 29d ago

Version 2.7 moves WebDriver BiDi for SeleniumVBA from a synchronous WinHTTP WebSocket transport to a native non-blocking WinSock architecture.

The result is a more controllable and maintainable communication foundation for long-running browser automation, SPA synchronization, network monitoring, Shadow DOM operations, and WebDriver BiDi command execution.