So what can we do with wait in NetLogo Web? The best thing that we can do is honestly something that a web developer really shouldn't ever do, which is to just keep our browser tab's lone thread busy with pointless work for the amount of time that we were told to wait. Instead, they only give tools for saying, "After this much time has elapsed, and then once you don't have anything else to do, run this code." Unfortunately, that sort of execution model is incompatible with how wait is used in desktop NetLogo. The thing is, since there aren't multiple threads in the browser, browsers don't give tools for blocking execution and waiting for a certain amount of time to pass before going on (which is essentially the definition of wait). But it also causes problems for wait directly. Well, first, because wait is most frequently used in conjunction with display, so if you can't use display, you're missing out on most of the usefulness of wait.
This poses major problems for display, but it might not be apparent how it's a problem for wait.
NETLOGO MOD UPDATE
Instead, the visualization update from display can only happen after all queued NetLogo procedures have temporarily finished running (which defeats the entire purpose of using display, anyway, because a "when the browser gets around to it" visualization update is going to happen whether display had been called or not). Since there's only one thread and don't really have the ability to suspend our current thread, switch to a different task, and come back at will, primitives like display cannot work as expected. In the browser, there's just one thread for everything (caveat: that's not strictly true, but multi-threaded browser-based programs are unacceptably slow, for the time being, at least). This is allows a program to have one thread for running heavy computations (like executing NetLogo code) and another thread that works to update what you see on your screen, to reflect the computations that have been done by the other thread (while that hard-working thread is still doing other hard work).
NETLOGO MOD CODE
Normal desktop applications allow programs to have multiple "threads" of code running at the same time. Wait is a primitive that functions significantly differently in NetLogo Web. What this translates to is that, in the uncommon case that your procedure relies on an import-* primitive executing before that procedure has ended, NetLogo Web will behave differently than desktop NetLogo, and your model might need to be re-architected a bit in order to get the two models running in the same way on both platforms. Once those lines have been run and the browser doesn't have anything else to do, then it will import the file. Instead, they are always read asynchronously, with line 10 of the aforementioned, hypothetical 20-line procedure now telling the browser that it should import the file whenever the browser is ready, followed by the browser immediately running lines 11-20 before actually importing that file.
In browser-based applications, though, files cannot be read synchronously. In desktop NetLogo, importing a file happens "synchronously", which is to say that, if your model says to run import-world on line 10 of a 20-line procedure, NetLogo will not run lines 11-20 until after import-world has completed. Secondly, these primitives behave differently in a way that, under particular circumstances, can be surprising. Instead, NetLogo Web will open up a file dialog and ask you to manually select the to-be-imported file from your file system, regardless of the value of the string argument. For one, when importing a file in NetLogo Web, the string argument to the import-* primitive is accepted (out of a need for compatibility with desktop NetLogo) but ignored (due to the fact that browser-based applications cannot automatically read files directly from your computer). Here in NetLogo Web, import-* primitives work a bit differently from how they work in desktop NetLogo.