For all practical purposes, VBA are not available in a web database. To do any kind of coding, you would use macros (which I should hasten to add that they're quite different from what we know about them in 2003 or 2007).
Certain macros such as RunCode wouldn't be available in a Web Macros, though there is a IsClient() function that enables one to branch a web macro out into a regular macro or VBA but _only_ when we're running Access, not in a web browser.
Currently, there is no access to client-code inside the Access web, though two things are possible right now:
1) Use Visual Studio to manipulate the Sharepoint Object Model. One would access the model by triggering for instance, list's event.
2) Use Access 2010's new web browser control and point it to a Sharepoint web part that can then execute a custom ASP.NET code.
But back inside Access environment, we would use macros.
Note that with 2010, we have 3 classes of macros:
1) Data macros... That's basically our stored procedures & triggers. The cool thing is that they're also available even in regular Access environment so for many VBA workarounds using form events is no longer needed - we can use those and thus associate the business logic with the tables instead of forms which had their own problems (e.g. ensuring users go through the form and not by some other avenues)
2) UI Macros... When published, those are what get translated into Javascript and thus run client-side in a web browser.
3) Client Macros... Basically same as #2 but run only in Access environment and isn't available in Web browser.
Also, you should be aware that the web objects are quite different from client objects. For example, web reports have NO events at all and no subreports. Web form has reduced numbers of events available. Thus, I would not expect a seamless or even easy conversion. At this stage, since web database is basically "version 1.0", the most probable use of web database is well, of course, hybrid application where some content are made available on web while the bulk of application continue to function in native Access environment.
When you think about it, it's probably what most clients are going to do - they usually don't have wad of cash laying around to pay for overnight conversion of a complex application so they would want to do it in staged process. Also, as pointed out, conversion would do some disservice to the new functionalities - we've for long time used form's BeforeUpdate event to do validation of our data but that should now be done in the Before Change event attached to the table, enabling us to code validation logic only in one place and thus not for every form's BeforeUpdate that happens to use the same table but in different contexts.
With that in mind, you would want to take a look at
Access team blog which lists few good blogs on web macros/databases. They also list a company offering conversion service to convert your database to web database.
HTH.