As an altenative you can flip the order of control and let an Excel VBA control QlikView instead. An Excel VBA will be a much better environment to develop your code anyway by giving you full debugging and intellisense for the entire QlikView object model too.
To be precise: WebView and Ajax client mode are two different things. So essentially you have four clients for QlikView:
1) QlikView Desktop: using normal Windows Forms mode
2) QlikView Desktop using WebView: using Internet Explorer as web client
3) Internet Explorer plug-in: using the ActiveX object
4) Ajax: using only native functionality of each browser by using the light-weight Ajax library
to enable a full QlikView client experience in all the popular browsers
Option 1 and 2 can be used both directly with local QVW-files and as clients for running a server application.
Option 3 and 4 needs a server and can't use local QVW-files. So you will connect via the AccessPoint or directly
to a URL that still use the AccessPoint but allow you to skip the menu system of the AccessPoint.
It is only option 1 that gives you the full spectrum of VBScript (or JScript) macros. There are several limitations - most quite natural - when you use the other options and especially when you run on a server. All options allow some macro code to work. Qlik and Qlik employees strongly discourage any use of macros and to a certain extent I agree with them. But macros can solve real pressing needs for a developer - but should be avoided for end-user performance heavy calculations. Macros are not supported in any form in Qlik Sense. Automation and VBScript / VBA is very slow when it comes to massive data manipulation by its very nature and shouldn't be used for that.