> WASM is (currently) not able to be a compilation target for an efficient GC implementation. Even if it was, there are other problems that mean the dream of b

> WASM is (currently) not able to be a compilation target for an efficient GC implementation. Even if it was, there are other problems that mean the dream of being able to use alternative languages and runtimes on the web is far off, if it even ever happens at all. As a hobby I'm writing a design doc for an alternative non-web system design. It enumerates some of those problems and proposes solutions, along with other dissatisfying aspects of the web (e.g. the unimplementably large size of the web specs). https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI4J5AbxVWKEeYr6hscT8/edit?usp=sharing https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI... It's designed to be a very lightweight set of layered specs and projects that are way cheaper to implement than HTML5, can be developed and deployed incrementally whilst providing value from the start and which places other runtimes on a level playing field vs HTML. It also addresses many of the details you need to tackle for any serious web-like system such as transiency, sandboxing, tabbed WM, cache privacy, portability and hyperlinking. I sent it to Ian Hixson who found it interesting, but of course the sticking point is funding models. Being way cheaper to implement than the web doesn't mean it costs nothing to implement. The web benefits from the largesse of rich patrons, any alternatives would need to either find a patron or find some business model that let it grow in quiet corners until it was strong enough to be fully competitive.