[breadchris]

I love this! I have been working on something similar recently [1] and it is exciting to think about the possibility of building full stack components for the web that are not going to break in the foreseeable future. Even if I need to swap languages/frameworks go is easy to parse and transpile!

I dream of a library like ours to take on the likes of React, and to get there the devex needs to have some key features. Most notably, imo, is live reload. You could use air, but I find it still to be too slow to recompile the entire app. I have had some success so far with yaegi to interpret the go at runtime [2]. It isn't perfect, but the full language spec is implemented.

My personal goal is to build the Go equivalent of rails/django. Live reloading is needed in addition to plugins that provide web app primitives (auth, storage, logging, metrics, etc). Additionally, I think the network effect of React is a powerful value driver, so some easy way to include React in an app is also important. Thankfully evanw has made this trivial with esbuild [3]

[1] https://github.com/breadchris/share/blob/master/html2/html.g... [2] https://github.com/traefik/yaegi [3] https://github.com/breadchris/share/blob/master/graph/build....

[maddalax]

Haha we kind of have the same vision. That's eventually what I want to turn htmgo into, something like rails, but as minimal as it can be (essentially plugins, good defaults but you can opt out).

> You could use air, but I find it still to be too slow to recompile the entire app.

At the moment I'm using fsnotify to watch file changes and restart the process immediately, so far it hasn't been too bad for live reloading. I'm hoping as long as precautions are taken to lazy load things on startup, then it would stay fairly quick.

[hilti]

15 years ago I created a web framework for newLISP. It even ran fast on a Nokia N900

Maybe you want to have a look at the code and get some inspiration.

https://github.com/taoeffect/dragonfly-newlisp

[allknowingfrog]

I'm still fairly new to Go, but I've been iterating on the idea of approaching HTML as basic string generation and ditching all of the other complexity. I have a single function that generates HTML tags from name, content and property arguments. Everything else just builds on it. [1]

I'm really curious to do some benchmarking and see how this compares to template-based HTML generation. It seems theoretically possible to accumulate raw data first and then build the document from top to bottom (instead of piecing together a lot of intermediate strings), but I'm not sure the complexity would justify the performance gains.

I also just learned about `gocomponents` [2] in another thread here, which seems to be a similar idea with a substantial headstart. I could probably just switch to it, but I kind of like the idea of following a pattern instead of installing a dependency.

[1] https://gist.github.com/allknowingfrog/951fbaa221a3a504b382f... [2] https://github.com/maragudk/gomponents

[maddalax]

yaegi is very interesting... I'm going to see if I can get it working on htmgo for reloading the views.

[breadchris]

I would take a look at this demo [1]. Pay close attention to what is being interpreted vs bound as a symbol to compiled code. The `yaegi extract` command will not work on exported generics atm.

If you want to collab more, shoot me an email: [e-mail]

[1] https://github.com/DCjanus/yaegi_demo