The problem is your concept is more than just another server running V8.
It's a server running V8 with code, which is nearly identical to the code running on my client (it gives me a peak at the server code structure), and which accepts a quite wide range of events allowing me to model an attack that would trigger a V8 vulnerability on the server.
It would be much easier to do compared to a server which exposes a minimal API in a completely opaque way.
> Perhaps the example shows too little, but for many developers, writing server side code and all the necessary communication is a road block.
I'm not every developer, so I wouldn't know, but I think you overestimate the hurdles of server-client communication that developers encounter.
A server-side API has to be written one way or another, as it's a key asset to a company and it encapsulates its business logic in a platform neutral way. This means I can have web site running off of it, I can have an iOS app running off of it, a desktop app, and also a cron job that runs every night and generates reports, for example.
None of this would be possible if you tightly couple the app business logic with a browser emulator.
Recreating the business logic with every client will be a gigantic waste of time and money and a very rich source of bugs. No one would do it that way. There has to be a central API.
Also there are many libraries that would generate the necessary client code (wrapping AJAX calls) for you from an API definition, here are some random examples I just googled up:
- https://github.com/pksunkara/alpaca
- https://github.com/ttezel/unio
Given the task is relatively trivial, and tools exist to automate it, I think a "road block" is too strong of a phrase to use here.