Closed shaban closed 2 weeks ago
I concluded my testing I was able to hack some ugly but functional solution by duplicating the runtime files with build constraints for JS and non JS environments.
But in the end the binary was 9.5MB and no way to get it much smaller. ;tldr templ is an awesome batteries included template language with excellent tooling but not a good wasm target. So I am closing this issue.
I wouldn't expect you to need .txt
files for this purpose. This suggests you aren't generating the the templates in "production mode".
If you are using templ generate --watch
it will store HTML code in a txt file to allow for runtime updates. (We are thinking of ways to avoid this).
But if you run templ generate
without the --watch
flag, it should delete the txt files and regenerate to _templ.go
files so that they no longer depend on the files.
Templ should work great with wasm as it generates pure Go code.
The odd thing is I only used the .go files when building the wasm module since the go compiler won't do anything with txt files anyway.
But I had this in the runtime. I also found that the runtime caching depends on it when looking at the source files. So I used a map with a reader and the txt file name as key in the map to work around that.
But as I said while working through the dependencies I saw so many glorious things that add to the majestic 9.5MB wasm file that I probably deserve to get teared and feathered if I strip it down to a barebones thing :D
I might revisit that in the future I am at the moment using Jade to do some tests since it is already a very barebones library and got it down to 46KB without even zipping it.
Especially if one would want to use templ in a localhost environment like a wails app or such it would make a mighty impressive development environment without JS tooling (tailwindcss has also a standalone executable).
I experiment with using templ as a wasm module and the problem so far is that wasm can't access the _templ.txt file on disk because that is off limits to wasm.
The only workaround i could think of would be setting some variable in window object to persist for as long as needed for caching.
The basic idea of my experiment is finding out if i can either use JS reactivity or even some reflection API to trigger updates by having components subscribe to variables and thus getting notified of changes in the observed variables to trigger rerender, or copy - if the component is not "dirty" to rebuild the component tree's output.