Still Curious About Performance Claims

[fluffywaffles]

Just thinking out loud here, but if your script assumes your bundles are deployed to firebase and assumes that you have already configured the firebase client library in your browser, that's a pretty strong dependency and I wonder how much of the expected performance boost is going to be entirely based on your distance to the nearest firebase redundancy server (is there one in Chicago, for instance? Would performance be as good if you were connecting from Canada?).

And if overwire then caches bundles in LocalStorage after they've been retrieved once, of course your second, third, ... nth loads of the bundles will be really fast, but is your first load really going to be much faster than if you request the bundle over HTTP as normal? Presumably firebase is performing some hocus-pocus to make the scripts load faster? (I mean, at the very least it's streaming over WebSockets, and perhaps that by itself is enough).

Another thing: I don't see how parse is being performed off the render thread, unless that, too, is wrapped up in the firebase library.

Lastly, all code that isn't vendor-bundle or app-bundle is going to load the normal, boring, slow way that code normally loads --- and you aren't even specifying async by default on the <script> tags you use to perform those loads.

If you turn off the browser cache (or rather turn off LocalStorage), all of your performance boost (in this published version of the library at least) appears to be coming solely from the decision to use firebase for your cdn. Is that wrong?

[prescottprue]

@fluffywaffles Totally agree with you out loud thoughts here.

I have asked @sbolel to better explain what the goals are. Have yet to run anything myself.

[sbolel]

All great points, thank you for your input @fluffywaffles, and I agree that all are valid open issues. I'll do my best to respond to them.

Presumably firebase is performing some hocus-pocus

Firebase is black magic.

I mean, at the very least it's streaming over WebSockets, and perhaps that by itself is enough.

It's good, but it's not enough. 😄

One possible next step is progressive enhancement instead of loading an entire bundle at once -- stream neighboring dependencies for each state in a state machine.

you have already configured the firebase client library in your browser, that's a pretty strong dependency

It's a huge dependency. The idea is to replace it with a lightweight WebSocket + DB implementation.

I don't see how parse is being performed off the render thread, unless that, too, is wrapped up in the firebase library.

It is not. We proposed this as a potential feature.

Lastly, all code that isn't vendor-bundle or app-bundle is going to load the normal, boring, slow way that code normally loads

Correct. The idea is to never load anything using HTML tags. We've talked about something like overriding require.

and you aren't even specifying async by default on the Githubissues.

Githubissues is a development platform for aggregating issues.