[mike_hearn]

I don't quite understand what you mean by UI being in a separate thread. You could have background threads in VB from what I recall (it's been a while...). The only difference is that Electron/JS forces you to do your own IPC messages whereas Windows would abstract that out.

[wkat4242]

What I mean was that if you ran a large function that would take a few seconds, any UI redraw would be blocked completely for that time. So resizing a window would not cause a redraw of the UI until it came out of the function, pressing a button would not visually reflect the button status, basically it would seem like the application was hanging.

You could avoid this by peppering DoEvents in your loop. However, this was not always possible like if you were calling an external DLL function. I had an application that would talk to a Kodak digital camera by using their DLL and that would take considerable time.

It's really what separates a serious programming language from a toy, or at most a prototyping tool. Like Fisher Price, you can make something quick but it's not capable of actual use.

I think people have this rose-colored view because back in those days UX standards sucked and many apps had a lot of quirkiness. But times were changing and even a few years later this was unacceptable.

There were no official background threads, you could use the Win32 Threads API but it would cause instability due to not having memory protection.

But this "hanging" behaviour was really not suitable for a general purpose application. Electron doesn't have this issue because the renderer is independent from the javascript code.

[mike_hearn]

I thought there were JS style worker threads:

https://learn.microsoft.com/en-us/previous-versions/visualst...

but from looking it seems like people were doing it by writing VB that ran in a separate EXE and then indeed, COM would let you do RPCs between the different processes. So multi-processing rather than multi-threading.