Macil

You can use Electron or Tauri to make an executable out of a web page.

If you have a content-centric site, or a site with some interactivity but not much, you want a static site generator, or SSR. But in that case, a template engine with some smaller client side libraries (jQuery or AlpineJS or idk what all is out there).

React works well in this role too because it supports SSR. This part seems to assume that React SSR is inferior to other classic backend HTML SSR solutions, which is not my experience. Even for static non-interactive content, the way React has you organize your code into components is a much better setup than most classic HTML template systems I've used. And then React makes it very easy to sprinkle in interactivity where you want, without requiring you to bridge unrelated server-side html templates and front-end code (which can often blow up in complexity and require work to be re-done separately on each side of the codebase). The same React components can be used in server-side rendering and client-side code, so whenever some new page interactivity requires the client to render something that was previously only server-side rendered, you don't need to rewrite the component's code in a new system and maintain two versions of it.

Deno is an example of a language runtime (based on Javascript+Typescript) that's been built with capabilities in mind. By default, programs aren't allowed to touch the filesystem or network (except to allow static imports to run; fallible dynamic import calls that could be used to determine something about the filesystem or network are restricted like other IO). Programs can start up worker threads that have further permission restrictions than the main program.

This looks like how React components are written if you make the weird choice of not using the JSX syntax extension for React elements. I wonder if you could make a JSX-like DSL with Rust macros. JSX really helps for making this kind of stuff bearable.