Yeah I’ve already implemented both, it’s pretty straight forward. One drawback of the Resource Provider I had to work around: you can’t pass any more parameters in than a sub-path when you’re calling it from the JS frontend. Is there a possibility to have the Resource provider call the getResource function not with a string, but an URL object instead, which we could attach POST data and/or parameters to on the front end?
Either way, I realized (I think?) that neither approach is suitable for what I’m trying to do.
I’m trying to push(/poll) fully rendered frames for complex UI components to the frontend at framerate and I think it’s not possible with either solution due to the constraints of http calls (please correct my dangerous half-knowledge if I’m wrong).
So now, I’m 90% done implementing a WebSocket with juce::StreamingSocket to see if that works better, which all my research points to that it should…
//Edit: yes, that did it 
![[video-to-gif output image]](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/0/8/0809fd957af2200c0eb9b287bec0bf4ecd83d61d.gif)
This is a juce::Image rendered on a background thread using juce::Graphics (just counting the frames) at 30fps in JUCE, 800x600 pixels and then transmitted via websocket as raw pixel data to the browser frontend, directly displayed on a canvas in a Vue app. Can’t feel a thing handling buttons/knobs on the same, single-threaded frontend.
//Edit 2: now - transmitting an actually moving image - i can unfortunately see that it’s super janky albeit the transfer IS really fast… I’m not sure yet that this can be done well, I’ll report findings when/if I should get them… don’t follow my lead just yet if you read this and get excited by that gif up there, writing a websocket server suuuuuucks 