In a previous version, I was using HTML, but it was written as strings. This allowed interaction with Go, but debugging was challenging since the Go compiler does not check the content inside strings, and no editor provides syntax highlighting for HTML embedded in a Go string.
With the current approach, the compiler can validate the written code, making it easier to use other Go code and enabling auto-completion in editors since everything is defined in Go.
Additionally, it eliminates the need to parse HTML, as every node state is represented in a Go-based virtual DOM, with only updates being pushed directly to the actual HTML nodes.
The key point here is that the UI can integrate background mechanisms written in Go, making them easy to use within the interface.
> Additionally, it eliminates the need to parse HTML, as every node state is represented in a Go-based virtual DOM, with only updates being pushed directly to the actual HTML nodes.
That looks really interesting. I'm curious, are there any performance drawbacks to updating DOM via WebAssembly or is it negligible? I.e. let's say you are building an editor of some kind. If the entire app is in Go, that means sending the keydown event to the WASM module and having it update HTML back. Is it not better (from performance perspective) to just use JavaScript all the way?
With the current approach, the compiler can validate the written code, making it easier to use other Go code and enabling auto-completion in editors since everything is defined in Go.
Additionally, it eliminates the need to parse HTML, as every node state is represented in a Go-based virtual DOM, with only updates being pushed directly to the actual HTML nodes.
The key point here is that the UI can integrate background mechanisms written in Go, making them easy to use within the interface.