Live reloading the html components should not have to restart the whole server

[maddalax]

Since go is compiled, whenever you want to change html/css, the entire server needs to be recompiled and restarted. This is generally fine for small projects, but as projects get larger and more things get loaded on startup, the live reload speed gets slower.

Look into alternatives to make this better, potentially https://github.com/traefik/yaegi to interpret the code on demand

[gedw99]

This might help a bit...

https://github.com/cogentcore uses yaegi to an extreme level so its a nice reference. I have used cogent for projects that need it and it's been amazing.

It also has code gen like htmgo does: https://github.com/cogentcore/core/tree/main/cli but it's a bit different. its for the type mapping.

https://github.com/search?q=org%3Acogentcore%20yaegi%20&type=code

They use yaegi running Inside the browser ( with WASM ) or native or of course server.

Here is a working example of it using yaegi client side. you can change the golang code at runtime..

https://www.cogentcore.org/core/widgets/basic/buttons

The point is that it can be used on client or server

[gedw99]

Then there is WASM on the server that can use yaegi also if needed.

SQLITE DB as a WASM with no CGO at the golang level.

https://github.com/ncruces/go-sqlite3

you can control the FS and Networking with wazero.

So you end up with a system that does not need Docker also, and can compile each PAGE at a time to WASM, so we have linear compile times at runtime.

[maddalax]

after a bit of research on yaegi, I'm not sure if it will work.

1. it doesn't support go modules

2. seems to be more suited towards smaller scripts with minimal dependencies, whereas using this for htmgo would be difficult because any page would be importing a universe of stuff from htmgo/framework

3. it doesn't seem to support generics fully, it can't infer the type

func print[T any](v ...[]T) {
        fmt.Println(v)
}
print(values) // Works with: print[string](values), but not print(values)

---

WASM doesn't seem like a bad idea overall but I think the issue is we do not control the dependencies that their app may use, and their pages may share memory with the host process, such as global variables.

I'm thinking this might not be a worth pursuing at the moment because go's compilation speed is already very fast. It might be more beneficial to work on improving startup times instead

[gedw99]

Appreciate the feedback. Yep let's optimise later - Good call...

BTW to help non devs I use gobrew, which installs golang at runtime.

https://github.com/kevincobain2000/gobrew

It does NOT interfere with your normal golang.
It automatically selects the right golang based on the go.mod go version.

I have used it for Scientists where they are not so techie and have golang dependencies in the stack. It works very well and gets rid of the "it works on my machine, so no idea why it does not work on your machine" issues with support etc.

I use it because I have lots of sure that are non technical - Scientists, and it reduces lots of support issues about "it works on my machine, but not yours"

[gedw99]

hey all .

I would like to highlight an approach I have used to server golang as WASM.

I run golang pages on Cloudflare.

https://github.com/syumai/workers shows how to do it , and has great examples .

so all that we would be doing in htmgo is running each page as WASM using wazero instead of Cloudflare .

this will mean each page is its own WASM so that we can keep compile time fast no matter how big the project.

[maddalax]

hey all .

I would like to highlight an approach I have used to server golang as WASM.

I run golang pages on Cloudflare.

https://github.com/syumai/workers shows how to do it , and has great examples .

so all that we would be doing in htmgo is running each page as WASM using wazero instead of Cloudflare .

this will mean each page is its own WASM so that we can keep compile time fast no matter how big the project.

My main worry is still

WASM doesn't seem like a bad idea overall but I think the issue is we do not control the dependencies that their app may use, and their pages may share memory with the host process, such as global variables.

and we likely can't just serve the entire app through WASM, as their app likely has dependencies that aren't supported on wasm.

[gedw99]

You’re right about the dependency chain . I have had problems with certain things not compiling to wasm .

in the past I used a bridge to larger third party systems using nats Jetstream or stdio or benthos .

reminds me that my proposal is basically like https://www.vugu.org/, but using htmx .

it all came about because I wanted to decrease the latency between the browser and server but in reality a call needs to be made to the server anyway for the data so it’s roughly the same latency .

Basically when I look at the tradeoffs I ended up proposing WASM to:

• keep the compile time small and quick in the server
• Get a bonus of lower latency for interactions via WASM moving to the browser as needed.

in the end the only way for this to be effective is to have a client side store that is a read only cache only , with mutations going to the server . If 90% of iterations are reads then there would be a payoff at the expense of when a client reconnects for a new session a day later where their local cache will have to catchup. Its classic CQRS

It reminds me of how I used pocketbase with marmot ( nats Jetstream ) so that I can automatically replicate the SQLite db across clouds using basic CDC pattern . Could use it to replicate it to a browser ( with the server staying as Master )

I’m just brain storming it out to see what’s worth it or not :)

[gedw99]

@maddalax

any thoughts on this ?

I am already doing a WASM bridge for other projects using benthos. So each page is its own WASM and the router is a caddy / benthos layer in front .

It works well and scales well for dev time and runtime.

Each page is a WASM.
Each page can run in 3 different places. Browser , CF Workers , on on your Origin server , using Benthos / Caddy .

it does work is my point …

I can share code if you’re curious …

Adapting it to htmgo then might be easier if you see a working system that already does it .

[nicosql]

https://github.com/janpfeifer/gonb

they figured it out. if a jupyter notebook can do it...

[maddalax]

https://github.com/janpfeifer/gonb

they figured it out. if a jupyter notebook can do it...

What did they figure out? From what I can tell from their README, its compiling the go code and running it as normal, relying on the fact that go compilation is extremely fast

[gedw99]

“ Go is a compiled language, but with very fast compilation, that allows one to use it in a REPL (Read-Eval-Print-Loop) fashion, by inserting a "Compile" step in the middle of the loop -- so it's a Read-Compile-Run-Print-Loop — while still feeling very interactive.”

I will try it out ..

I have yet to try it but it looks like it’s creating binaries on the fly and loading them in the loop via some stdio ( or other way ). It’s pretty much what I also on some projects . I use benthos to do a similar thing . I compile to WASM and then benthos is like a router to load it . The benthos is generated on the fly from the compile step . I watch the FS from benthos in order to know what to compile . Just another way o skin this cat.

thanks @nicosql for showing us this !!