5 ms·

I'm doing something that while not the same thing, it let you control the web infrastructure with native languages. The first SDK is in Swift. But im sure that

I'm doing something that while not the same thing, it let you control the web infrastructure with native languages. The first SDK is in Swift. But im sure that with enough work a Rust Sdk could be created as most of the core functionality is exposed as a C interface. The product i'm finishing is more of a answer to the question of if there's something between the browsers and mobile application platforms that could also work in a more distributed fashion.

The_rationalist 6y ago
So what about working on integrating graalVM into chromium so that e.g Kotlin can interoperrate with javascript and the web apis? That would be the best solution and support for swift could be added as graalvm supports llvm.
- oscargrouch 6y ago
  If you can create a binary that links with a C api, its possible. The access to DOM apis are going over the C, so its just a matter of wrapping all up in the target language. Im using the Chrome multi-process architecture, but instead of a renderer process what gets called is a application executable that binds to Webkit and acts as the renderer process do to Chrome now. So this gives the application much more control over the client rendering, hooking over every event WebKit triggers, something that is not even possible with Javascript now. So its much more powerful. You also have a "service" process which runs as a service, that is actually the one that receive every request and can launch the application process or do something else. The requests are over GRPC, so the service process serve not only the UI requests for routes but also the RPC method calls to the API it defined according to what the app does. The API for both are in Swift, but the core runtime and system is on C++ and in a multi-process architecture, so any native app that can compile into a standalone binary and interface with a C api can also use the facilities. The applications and resource distributions are over torrent so anyone can serve the application without any intermediaries or shipping on servers. If a app want to talk to the cloud, its just a matter of doing so when processing the routes or the RPC method calls, but it can work offline or eventually online/offline given its design. I've heard Kotlin can produce standalone binaries, so that means its possible (and no WebASM shenanigans with direct access to Webkit and with the real native boost) Unfortunately i cannot ship with another SDK right now because i'm doing too much already, but i intend to create interfaces for other languages once things are more stable, and people understand better what is it's place in the game. But is more a application and window manager as Chrome is more-less and less as Electron or Flutter, where it wraps a standalone app. With this design together with the RPC api's exposed by each application, you end forming a local network of apps, where they can work with each-other. And with the Api's working as a social contract, you can replace the application to serve the same things without losing everything (effectively real data ownership) But my goal is that you can just call "./pacman" and the thing pops, even being managed by a core process as in chrome. The user dont need to deal or know anything about it.

The_rationalist 6y ago

So what about working on integrating graalVM into chromium so that e.g Kotlin can interoperrate with javascript and the web apis? That would be the best solution and support for swift could be added as graalvm supports llvm.

oscargrouch 6y ago
If you can create a binary that links with a C api, its possible. The access to DOM apis are going over the C, so its just a matter of wrapping all up in the target language. Im using the Chrome multi-process architecture, but instead of a renderer process what gets called is a application executable that binds to Webkit and acts as the renderer process do to Chrome now. So this gives the application much more control over the client rendering, hooking over every event WebKit triggers, something that is not even possible with Javascript now. So its much more powerful. You also have a "service" process which runs as a service, that is actually the one that receive every request and can launch the application process or do something else. The requests are over GRPC, so the service process serve not only the UI requests for routes but also the RPC method calls to the API it defined according to what the app does. The API for both are in Swift, but the core runtime and system is on C++ and in a multi-process architecture, so any native app that can compile into a standalone binary and interface with a C api can also use the facilities. The applications and resource distributions are over torrent so anyone can serve the application without any intermediaries or shipping on servers. If a app want to talk to the cloud, its just a matter of doing so when processing the routes or the RPC method calls, but it can work offline or eventually online/offline given its design. I've heard Kotlin can produce standalone binaries, so that means its possible (and no WebASM shenanigans with direct access to Webkit and with the real native boost) Unfortunately i cannot ship with another SDK right now because i'm doing too much already, but i intend to create interfaces for other languages once things are more stable, and people understand better what is it's place in the game. But is more a application and window manager as Chrome is more-less and less as Electron or Flutter, where it wraps a standalone app. With this design together with the RPC api's exposed by each application, you end forming a local network of apps, where they can work with each-other. And with the Api's working as a social contract, you can replace the application to serve the same things without losing everything (effectively real data ownership) But my goal is that you can just call "./pacman" and the thing pops, even being managed by a core process as in chrome. The user dont need to deal or know anything about it.