[Maxence]

Hey, I’m the creator of go-app. What a surprise to come across this post on HN! I’m really happy to see you folks built something that fits your needs with it. Wishing you continued success with your product!

[mozey]

What is the benefit of writing Go to generate HTML?

1. With go-app

  func (h *hello) Render() app.UI { 
    return app.Div().Body(app.Text(fmt.Sprintf("Hello %s", h.name))) 
  }

2. Compared to using templ

  templ Hello(name string) { 
    <div>Hello, { name }</div> 
  }

For me personally, the latter seems nicer

- I can see at a glance the structure of the HTML

- Completion on the HTML tags, attributes, etc

- Completion on CSS (TailwindCSS LSP for VSCode)

- Logic can still be shared with other types of UIs (e.g. CLI, Native Apps, Webkit, gRPC)

If what you want is option 1, isn't this solution incomplete. That is, the fully realised vision would be a native component / widgets API (e.g. Fyne, QT, GTK), and then generate HTML from the components?

However, "since Dagger Cloud is built as a PWA, it can be installed as a desktop or a mobile application. This makes it possible to launch Dagger Cloud like a native application and get a full-screen experience without needing to open a browser first, or just have a dedicated icon in your desktop taskbar/dock", so it sounds like the "Native App" is using a Webkit (e.g. Wails, Tauri, Electron)

Anyway, congrats on having commercial users building stuff with your project!

[Maxence]

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.

[mckravchyk]

> 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?