Mapping WASM Fork

[thomas992]

---

name: WebAssembly Future
about: Exploration of native exportable user interface future and WASM client
title: 'WebAssembly Client'
labels: enhancement
assignees: tommhnsn

---

Is your feature request related to a problem? Please describe.
Native level performance is expected for any flagship application. <100 MS launch time is expected on all platforms with native export possibility for Android/iOS/Windows/BSD/Linux/Macintosh

Describe the solution you'd like
I would use the zig-gamedev project for core libraries. There is a zgpu project with WebGPU export for WASM which would parity current Etherpad functionality. This inherently is not as fast as Vulkan, or Metal. If you were to export to iOS with WebGPU it would have about a second of shader compilation at startup or even more compared to Metal so we would eventually want to target every platform natively. To support this I want to make a project to compile my type of GPU assisted application using a monorepo containing the folders needed to create parity. This repo is going to be the backbone of how I export all my apps I call it Stella and I been building the plans for it for months now. Notably we do not call the zgpu project directly but use our client-core to plugin the right rendering library.

 /stella/
-   /client-core/ (!)
-   /client-gui/ (!)
-   /platform-web/ (!)
-   /render-webgpu/ (!)
-   /orbit/ (!) (my compiler library)
...
-   /platform-windows/
-   /platform-apple/
-   /platform-android/
-   /platform-unix/
-   /render-metal/
-   /render-dx/
-   /render-glfw/

The way the user interface works and is written should be similar to SwiftUI but written in EDN files to make an approachable way to modify functionality, at runtime within iOS app store permissions.

{:view/id :login :layout {:type :col :gap 12 :pad 24} :children [{:type :text :text "Stella" :class :h1} {:type :input :id :email :label "Email" :keyboard :email} {:type :input :id :password :label "Password" :secure true} {:type :button :text "Sign in" :class :primary :on-press {:action :auth/login :payload {:email [:bind :email] :password [:bind :password]}}}]}

Notably the EDN files cannot include scripting, just identifiers. We want to be able to allow iPad users to modify their user interface more than other text editors. Allowing them to edit the entire user interface should not introduce security vulnerabilities for client or server. It should be possible albeit with a lot of patchwork to export our SwiftUI to an HTML compatible output but the amount of people who cannot run WebAssembly compared to EtherPad as it is, should be negligible, SEO functionality is not needed for a text editor either so that undertaking is a waste of time for Etherpad specifically in my opinion.

Describe alternatives you've considered

Zig offers minimal WebAssembly overhead, particularly having dramatically lower file size compared to Rust, Swift, Go, so much so that I think it is considerably wasteful to not use Zig. I do not think C, C#, C++, would be memory safe or very nice to read. Java does not export to iOS.

I considered a Clojure server but I do not see any tangible improvement other than developer experience over Go.

Additional context
There is no current zandroid library, I am not sure how BSD/Linux exports would work. I am using Macintosh and plan on exporting with zgpu (webgpu) initially. I plan on creating a zapple library for iOS/iPad/Mac in the future if no one else takes it up. I also have a rather complex future for displaying tabs, title bar that I think is superior to traditional setups seen in web browsers and text editors that I will explain more after I draw out what I been thinking about doing there.

I just want to say I really like the project. I think it is great that you got off of Node JS I think Javascript should be phased out of web browsers entirely I rather just an internet where people used WebAssembly with low overhead instead of expecting people to adhere to HTML/CSS/JS not originally designed for megabytes of complex logic.

I am just in the planning stage right now but I plan to start making Stella into a reality over the next few weeks and I plan to start making this Ether pad rebuild in it as my first application. I might want to license Stella in a certain way in the future, something that would not affect most people trying to profit off of it unless it includes an interactive 3d game which Etherpad is not. Thank you for your time! I am a former Garry's Mod developer my big projects were Winter Survival and Pirate Ship Wars, I just want to make an easier path for developers to support all the platforms natively. I am not interested in bridging Zig to Typescript I think the better option is to just start from scratch, using AI to help reconstruct from the original Typescript.

[SamTV12345]

Hi thanks for the open issue. The first goal of this project is to get it to feature parity. I still have to implement some API endpoints from Etherpad and a big chunk will be the plugin system. There are like hundreds of them and I need to statically somehow integrate that into Etherpad. I'll also need to work on the hook system which is also a big point to work on. That said. If you'd like to you can start working on the frontend in a fork. I am still not settled what I do there. Maybe I can use wasm with Go, maybe not. Maybe I use webcomponents to have at least some capsulation.

[thomas992]

WASM with Go works but there is substantial overhead compared to running it natively, I think like 25% drop in performance that is not as dramatic with Zig. The compiler determines how much overhead Go needs to attach for WASM I would expect close to a handful of megabytes with Go which is more than the whole WASM file should be with Zig. WASM is obviously inferior to native in many ways but compared to the HTML DOM, WASM has the potential to be far superior in performance and overhead. If my plan unfolds as I expect, in a few weeks I will have some user interface functioning and have started on rebuilding sections of the typescript. There will be some core logic that can be shared between the client and server and I can help integrate that Zig code into the Go server if you think it would be performant. Integrating code from a different language creates like a 15% overhead I believe but Zig is about that much faster, if not more. --edit-- There is also that option of creating a daemon service.

[SamTV12345]

Yes I can understand that. I also heard Go is not perfect for WASM. Feel free to rewrite the frontend in Zig. I'd be also interested in that language. I always heard about it but only used Go or Rust in my work :)