SWSwitchLink·Sep 26, 2015
> I wouldn't worry about V8 vulnerabilities, there are many node servers running in production today, in general, and they are doing fine.
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 communic
Read the rest
ation 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://apimatic.io/
- 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.