4 ms·

> If the web was being made form scratch today, it would probably start with a repurposed game engine. I came to the exact same conclusion. Modern browser wor

> If the web was being made form scratch today, it would probably start with a repurposed game engine. I came to the exact same conclusion. Modern browser work anyway like a game engine as that's the only way to be fast with rich interactive content. https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-fps-how-webrender-gets-rid-of-jank/ https://hacks.mozilla.org/2017/10/the-whole-web-at-maximum-f... We would just need to get rid of all the HTML / HTTP baggage (JS as such is OK-isch as scripting engine, but could be any other VM also of course; and CSS has great utility everywhere, so it's not web specific). Than switch to some sane RPC protocol for networking (as all the "RESTfull" stuff today is anyway only badly made RPC in disguise). Such client-server protocols are actually also already available in game engines because a lot of online games need super efficient real time communication. Efficient content distribution and client self-updates are also part of game engines. I start to consider Godot as an application framework, to be honest. A usual (completely self contained) GUI app with networking is only a few MiB, is supper snappy, and does not need much resources at runtime. The engine and it's editor is really nice to work with. You can finally again click together an UI with the editor. Like in the good old days.

rswail 4y ago
> Than switch to some sane RPC protocol for networking (as all the "RESTfull" stuff today is anyway only badly made RPC in disguise). RPC is a dumb protocol because it tries to abstract away the necessary aspects of "remote" as if they don't exist. REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers. RPC doesn't have that.
- dragonwriter 4y ago
  > RPC is a dumb protocol RPC is a broad concept, even farther from a protocol than REST, which is an architectural style. > because it tries to abstract away the necessary aspects of "remote" as if they don't exist. Generally, it does not. There are some languages/frameworks/other technologies that have been promoted on the basis of transparent RPC or distribution across machines, but that’s not the normal case of RPC. > REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers. More accurately HTTP has all that, and REST layered over HTTP gets it for free from HTTP, while many RPC approaches (though this is not inherent on “RPC”) over HTTP would, e.g., tunnel all actions over POST and reinvent distinctions between safe/idempotent/neither operations if handled at all, within the RPC protocol, and would require specialized caching mechanism for things that are cachable, not HTTP caches. Or, worse, do the same thing but tunnel over GET.

rswail 4y ago

> Than switch to some sane RPC protocol for networking (as all the "RESTfull" stuff today is anyway only badly made RPC in disguise). RPC is a dumb protocol because it tries to abstract away the necessary aspects of "remote" as if they don't exist. REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers. RPC doesn't have that.

dragonwriter 4y ago
> RPC is a dumb protocol RPC is a broad concept, even farther from a protocol than REST, which is an architectural style. > because it tries to abstract away the necessary aspects of "remote" as if they don't exist. Generally, it does not. There are some languages/frameworks/other technologies that have been promoted on the basis of transparent RPC or distribution across machines, but that’s not the normal case of RPC. > REST APIs done correctly are great because they expose the possibility of network failures and partitions, allow for idempotency (GET doesn't change stuff), caching and all of the other things that the architectural style offers. More accurately HTTP has all that, and REST layered over HTTP gets it for free from HTTP, while many RPC approaches (though this is not inherent on “RPC”) over HTTP would, e.g., tunnel all actions over POST and reinvent distinctions between safe/idempotent/neither operations if handled at all, within the RPC protocol, and would require specialized caching mechanism for things that are cachable, not HTTP caches. Or, worse, do the same thing but tunnel over GET.