Remote/cloud-based web workers

[josephrocca]

The breakdown of Dennard scaling and the transition to small/mobile computing devices has led to a situation where certain classes of modern applications cannot be built as client-side web apps if they are expected to run on most devices.

The natural solution is to move toward heavy backends, where the user pays the service to (amongst other things) provision compute on their behalf. This approach is recently gaining popularity in certain types of applications which could have otherwise been client-side applications, including video game streaming and AI-heavy software, for example.

The heavy backend model certainly has its place, however it does come with problems in certain situations:

• Maintaining backend infrastructure often has significant fixed costs which must be amortised over a large-enough userbase for the application to continue to exist. Backend-heavy services are forced to shut down if the user base becomes too small, which results in an unfortunate "chopping" of the long-tail of applications that could have otherwise existed on the web.
• A client-side app can be published with Github Pages (or similar) and still be working in a couple of decades from now. If it has a backend, it would typically require maintenance - which discourages the developer from keeping the application online. The size of the "digital garden" that is the web is fundamentally limited by the average maintenance burden of a website. If that burden is halved, then the garden can be twice the size before exhausting all available developer-hours.
• Friction is unnecessarily introduced during onboarding when a user needs to supply payment for a service that would have otherwise been able to run completely on the client by simply loading the page.
• Large tech companies have an "unfair" advantage in the heavy backend world insofar as they can "eat" the up-front costs associated with providing the required compute for free while the user tries the app and considers signing up for the paid version.
• If the only option for a particular type of application is a heavy backend one, then this may tend to produce centralisation. For example, an indie developer whose game cannot run reliably on most client devices may be forced to distribute their game via a platform like Stadia, rather than hosting it on their own website.

To be clear, there is a large class of applications that require a heavy backend by their very nature, and so my intention here is not to try to convince you that they should be eliminated. Rather, I'm arguing that there certain applications are well suited to the heavy-client model, and that they may not be able to "survive" with the existing capabilities of the web platform with the current trend RE Dennard scaling and the increasing compute requirements of modern applications.

I'd also argue that developer/entrepreneur creativity is constrained by their appreciation of the amount of compute available on client devices, so it seems likely that our imaginations are limiting ourselves when we try to ask "but what would you actually do with if you had 10x the currently-available compute on the client?" A website that requires a lot of compute currently needs to convince people to pull out their credit card, even if it could have otherwise been a client-side application. So I think it's likely we're missing out on many applications that are viable and interesting, but which don't have a near-term plausible business model attached. An example of this is the recent CLIP+VQGAN experimentation which relies on Google Colab to provide the free compute, since it would require too much compute for the vast majority of regular devices to run in-browser.

So, with that said, what would a solution look like? One approach, as suggested by the title of this issue, would be to have the browser manage a remote machine (or several, perhaps on-demand) which extends the compute capabilities of the client device via a worker-like API. The remote machine could be another device owned by the user, or a "cloud" machine which is managed by the browser. A website would perhaps request permission to provision a remote machine, and the browser would handle the interface with cloud services (including payment on behalf of the user).

Obviously the devil would be in the many, many details of this feature, and standardising something like this would be a colossal undertaking, but I'm just wondering whether there has been any discussion around this sort of idea?

[Yay295]

Remote/cloud-based web workers

That's called a server.

have the browser manage a remote machine a "cloud" machine which is managed by the browser the browser would handle the interface

That's a lot of stuff for a browser to handle. Why do you think any browser would want to write all of that code when other solutions (a server) already exist?

 

If you have a problem that requires more resources than a client can supply, you need a server. There's no way around that. In your situation where the author of the code does not have the resources to manage a backend for all of their users, the solution is to either raise the price for the service of using a managed backed, or to provide the backend code so that anyone can set up their own server.

Take Minecraft for example. You can of course play by yourself, or you can open your single-player world to your local network, or you can run a local server with the included executable. All of these options run on your current device. Then you also have the ability to run a Minecraft server on a server you own or rent, or you can rent an already set up server for Minecraft from one of various sites online, or you can use Minecraft Realms to essentially rent a server from Mojang themselves.

All of these options would also be available to your website as well, without any changes to the current ecosystem. You just have to write the code to make it possible.

[josephrocca]

@Yay295

That's called a server.

At a higher level of abstraction it is, yes. But if you drop down a bit, you can of course see there are differences. I've listed some of them in my original comment.

I'll admit I'm cringing in anticipation of you attempting to argue this point given the mild snark of your comment, but it's not an interesting/useful line of discussion. Better to talk more concretely about the benefits/drawbacks of a feature/model like this rather than to argue "via the semantics". Saying "I don't think it provides any extra/significant benefits" is better than "it means the same thing [subtext: because I don't think it provides any extra/significant benefits]".

That's a lot of stuff for a browser to handle. Why do you think any browser would want to write all of that code

Yeah, I agree, and I think this is the crux of the issue. It's probably not enough of a problem at the moment for it to be a worthwhile exploration given how much work it'd be to standardise, and the danger in landing on and implementing a solution that turns out to have been a bad choice.

I don't think your other points are very relevant given that I did outline some significant disadvantages of maintaining a backend when it otherwise wouldn't have been required (i.e. when the backend only exists to provide compute - conceptually it's part of the frontend). Your Minecraft example only works because it's a popular application. I'd have thought it would be clear from my original post that the applications that suffer here are in the "long tail". The popular ones with big companies behind them are fine. The company can easily afford to maintain their own servers, and the community is large enough to give rise to online services that people can use to rent a backend, as you said. This is not the case for the average website. Also, as a side note, I think your Minecraft example kind of misses the whole point here: AFAIK the reason people run Minecraft servers on remote compute is so that they can play multiplayer (with a persistent always-online world) - not because their local device doesn't have enough compute resources to run the game.

Asking the average user to signup for an AWS account so they can run a niche game/app is very optimistic. And saying that the developer should just charge more (to cover the fixed costs) misses the fact that most websites on the internet can't get people to pull out their credit card at all. Hence advertisements. And that funding strategy only works if the service is cheap enough to run (i.e. light backend, heavy client situations). Your CPM/RPM needs to cover the compute costs and those values are capped by the value of your visitors' attention. There's a category of websites which cannot exist because of this conundrum, and the size of this category will likely keep growing because modern applications are using more compute, and the amount of heat that you can dissipate from a mobile client device is finite.

But again, I think you're right that this would be very hard to convince browsers to implement at this stage, and it's certainly not clear what the correct solution here is. I'm hoping that with new developments like the Web Payments API, and with more people using services like Google Pay, there'll be less friction around payment and that'll make it easier for smaller sites to survive. There's still the problem of this causing certain websites (that could have just been heavy-client app) to unnecessarily "die" sooner due to their increased maintenence burden, but this is probably a price worth paying to delay a standardisation of "remote client compute" until we have more information (and perhaps not standardising something like this at all if another solution comes along).

Maybe "streaming" will win and we'll all end up using something roughly like a dynamically scalable version of Mighty's cloud browser at some point 🤷 That's a weird/undesirable future from my perspective, but I guess it is one potential solution for the problem of mobile client devices slowly becoming basically useless in terms of compute power. I'd certainly prefer that over the "all-backends-are-heavy" future (mainly for the dot-point reasons I listed in my original comment). Perhaps another future is where the operating systems make the first move on this and allow the user to sign up for a cloud service which boosts their device's compute power (well, for the apps that use the API, that is). A browser API could then sit on top of that.

[josephrocca]

Just discovered a startup taking a shot at a "personal cloud" kind of idea: https://deta.space/

Example of an app's install page: https://deta.space/discovery/berowra

It makes sense for a centralised company to have a crack and this and try to prove out the general idea before it has any chance of becoming decentralised/open (e.g. remote web workers managed by the browser, running on the user's cloud-compute platform of choice, as described in original issue comment).