Move Socket.IO initialization all the way to head + Pre-Mount Message Queueing

[evnchn]

This PR is a more heavy-handed approach in making sure we establish Socket.IO initialization as soon as possible. It is benchmarked to be at least 50% faster than the current implementation, with higher performance gains under more adverse network connection.

Before PR:

"Connected in" time > DOMContentLoaded, since we only establish Socket.IO connection after mounted

After PR:

"Connected in" time < DOMContentLoaded, since we establish Socket.IO connection as early as possible, and that occurs before Vue was loaded in at all.

Explainer:

Currently, NiceGUI loads like this:

• Load in the CSS files in head
• Load in the JS files in body
• createApp
• When the app is mounted, setup Socket.IO
• The triple handshake (Engine.IO, Socket.IO, then NiceGUI)
• await ui.context.client.connected() finishes

My PR change it to be like this

• Load in the CSS files in head
• Load in just enough JS to setup Socket.IO with a pre-mount message queue
• The triple handshake (Engine.IO, Socket.IO, then NiceGUI)
• await ui.context.client.connected() finishes
• Load in the JS files in body
• createApp
• When the app is mounted, execute the messages stored in the message queue and re-setup Socket.IO

Since we begin talking to Socket.IO earlier, we:

• Complete the triple-handshake earlier
• await ui.context.client.connected() finishes earlier
• Obtain the messages to be ran after mounted earlier

To-do items:

• Heard pytest wasn't too happy about this. Let's fix either pytest or my code! (likely former)
• Remove debugging console.log prints.

---

PS: #4755 change it to be like this

• Load in the CSS files in head
• Load in the JS files in body
• createApp
• When the app is beforeCreate, setup Socket.IO
• The triple handshake occurs from here (Engine.IO, Socket.IO, then NiceGUI)
• Assign mounted_app = this; when app is mounted only
• await ui.context.client.connected() finishes

[evnchn]

Using Slow 3G to show it more clearly

Before PR:

After PR:

Speed advantage widens when more components are loaded in:

Before PR:

After PR:

Benchmarking script:

from nicegui import ui
import time


async def show_connection_speed():
    ui.label('Testing connection speed...')
    time_begin = time.perf_counter()
    await ui.context.client.connected(timeout=30)
    time_end = time.perf_counter()
    ui.label('Connected in {:.6f} seconds'.format(time_end - time_begin))


@ui.page('/test_connection_speed')
async def test_connection_speed():
    await show_connection_speed()


@ui.page('/test_connection_speed2')
async def test_connection_speed2():
    ui.mermaid('''
    graph TD;
        A[Start] --> B{Is it working?};
        B -- Yes --> C[Great!];
        B -- No --> D[Try again];
        D --> B;
    ''')
    ui.select([1, 2, 3], value=2)
    await show_connection_speed()

ui.run()

---

However, we are re-defining what await ui.context.client.connected(timeout=30) entails.

It used to be "when the app is mounted and thus the Socket.IO is ready". Now it is "when the Socket.IO is ready, which the app may be still mounting".

Matters less since we have a pre-mount message queue which stops things like run_javascript when the DOM is empty, but user's code expectations may be changed.

Perhaps we need to introduce a flag in ui.context.client.connected to wait for the app to be mounted, which is default-True in 2.x for backwards-compatible behaviour, but potentially default-False in 3.x to encourage users sending message to the Outbox ASAP.

[evnchn]

Tests also completed slightly faster.

Before

After

But not by much, since everything should be cached.

[evnchn]

Got some Git issues going on but I believe up to commit c5160b4 this PR contains #4754

If not I'd be sad...

[evnchn]

Perhaps we need to introduce a flag in ui.context.client.connected to wait for the app to be mounted, which is default-True in 2.x for backwards-compatible behaviour, but potentially default-False in 3.x to encourage users sending message to the Outbox ASAP.

No. This is because our new behavior is in-principle "impossible to distinguish from a browser which just so happens to suffer a network lag shortly after load". The transport layer is in NiceGUI's hands. We can do whatever we want.

If they need to time exactly from when the browser is fully loaded, they need await ui.context.client.connected() then await ui.run_javascript('blah') to guage when did the JavaScript actually get ran (since receiving a result is an indication that the message is not in premountMessageQueue but actually ran)

[falkoschindler]

Ok, you say this PR is 50% faster and this is basically the time it takes to await ui.context.client.connected(). But at the same time you're changing what connected() means. So I'm not yet convinced that we're getting any noticeable improvement. The client might be connected, but still can't process messages because the client is still busy loading dependencies and mounting the app. The timelines in your screenshots look pretty similar, indicating both pages being ready almost at the same time. So what is the actual benefit for the user?

[evnchn]

The page does indeed get load in faster, since you are in essence parallelizing your network requests instead of one-by-one.

Since Socket.IO handshake is actually 3 handshakes (Engine-IO, Socket-IO, and NiceGUI, check #4754 if you'd like a refresher), we incur time penalty of 3x the round-trip network latency, so it can be quite a lot, if your network is bad enough.

So, sorry but I can't agree that "timelines in your screenshots look pretty similar", and there is definitely noticeable improvement.

But my simplified timeline also shows the change: await ui.context.client.connected() will return earlier, and earlier than the browser Vue actually being ready, so messages sent after the orange block but before the yellow block will be held in a queue.

[evnchn]

I have an analogy.

Imagine Socket.IO is the engine in a gasoline vehicle.

#4755 is tuning the engine start sequence so that when you turn the key, the engine spins up a bit faster.

#4756 is getting someone to go downstairs and start the car for you ahead-of-time.

If that doesn't make things clear, I don't know what will...