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!

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?

Some people used to have a little putty stuck to the middle their CRTs

My roommate back in the day did this for some FPS games. He had a little crosshair made of string taped to the middle of his monitor.

Have to admit I've never used this code, and didn't know what it was about. Quickly read up about it. So ETag is a hash of the resource. You must provide it with requests that modify the resource. If your hash doesn't match the server hash, then 412 Precondition Failed is returned?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/412

https://www.rfc-editor.org/rfc/rfc9110#status.412

You can provide all sorts of conditions using HTTP headers such as "If-Match", "If-None-Match", "If-Modified-Since", "If-Range", etc. The server can chose an HTTP code to indicate some sort of cache invalidation signal.

304 means "you're good, your cached version satisfies the conditions"

412 means "you're not good, your cached version does not satisfy the conditions"

412 usually applies to modifications, but it could be for reading too, in the case of ranged requests (getting a specific range of bytes from a large representation). See the "Range" header.

These are all interconected. The headers, the codes, etc. They are very useful for caching and can save a lot of bandwidth. Browsers and CDNs use them extensively. Server-to-server communcation could use them as well, but I haven't seen popular implementations (let's say, a web framework that provides abstraction over these mechanisms).

Also, other popular HTTP codes have cache implications.

For example, 404 implies "No indication is given of whether the condition is temporary or permanent". Cache invalidation headers don't apply to this code because a 404 means there's something about the _resource_ and not only the _representation_ that could not be found. That client cannot cache the 404 result, not even for a fraction of a second.

404's brother 410 implies "This condition is expected to be considered permanent.". A client that gets a 410 can cache that result, never needing to reach the server again. It means it's gone forever. That client can decide to never look up that URI again.

Very often, "400 Bad Request" is the best HTTP you can use if you are not sure what to use. Then, describe what the error means using other HTTP components and/or the response body.

HTTP can be very simple. GET (ask for a representation) and POST (send a representation) as methods only. 200 (success), 400 (client error) and 500 (server error) as response codes only. It's the best way to start, then move to more elaborate protocol features as you learn.

I'm working on a server/backend for htmx that's intended to run as a local service beside the browser. In theory you could do this with any server stack that is self host-able. My goal is to produce a single binary with no external service dependancies. I'm using Go, and a lot of the components are readily available, e.g. self updating local service, replicated database, etc. It's easy to cross-compile for different target OS and architectures. As an alternative to building everything into the browser, and assuming you're able to run a separate process, this approach makes a lot of sense to me. It would be great if Go had something similar to Deno's permission management though...

Yes it is, compared to gojq https://github.com/itchyny/gojq/blob/main/go.mod

Been renovating an old house with a large garden for almost ten years now. I tell myself this is better than building something from scratch, but it definitely doesn't always feel more efficient. It helps that I didn't have the option back then, but now maybe I do? Sometimes it's also hard to tell, in the moment, which things to keep and what to rip out.

Touch typing is something I should've invested in much earlier, can't imagine how I ever coped without this ability. Another thing that really helped me is the "Alternative finger positioning" described here: https://typingsoft.com/typing.htm It feel much more natural not having to bend your wrists. Is anyone else also doing this? Whenever people ask me how to learn touch typing I look for native Linux or macOS app that teach this technique, but I haven't found any yet...

Besides the built-in templates/html, there's also this https://github.com/a-h/templ Haven't used it yet, but seems promising

Actually, just remembered why I haven't used it. Although it "Ships with IDE autocompletion", last time I checked that's only on the Go code, not the HTML. Usually I keep my templates as .html files, and find the IDE autocompletion and linter on the HTML more valuable

I applied for a UK visa from South-Africa about a year ago. To start my application I had to submit a form on this domain. The navigation to the form was obscured by a giant banner about the Ukraine invasion and a message about how service levels might be reduced due to refugees... no matter how I resized my browser window I couldn't get to the part of the page behind the banner. Eventually I opened up the Dev Tools and added some CSS to hide the banner. The link was revealed and I could continue with my application

You passed the first test!

how else do you think they were planning on reducing service levels?

Instead of wrapping the application with something like Electron, why not install as a service and connect to a localhost port using your default browser?

I know this is not the same UX as installing an app. But why isn't this technique more standard?

Besides more efficient resource usage, another benefit is that it keeps the client/server architecture.

It’s more obscure for users if they have to open http://localhost:some_port/. You also have to decide on a hopefully free port.

As an aside, if the application isn’t careful, that approach can potentially open up a security hole, because external javascript on a web page in your browser can perform requests to localhost.

CORS policy usually requires that the port must match. This issue potentially applies to all web apps, not only those hosted on localhost

Hrmmm I wonder if you could do this on mobile.

Last time I checked it's not possible on iOS. On Android it's possible with some effort (e.g. you have to use Termux), not something you could expect a user to setup