Super simple replacement of text/template

[oderwat]

I wanted to test what happens when text/template gets removed in regard to compilation using TinyGo.

[maxence-charriere]

What benefit you got with this?

[oderwat]

It's even closer to making it compiling with TinyGo. But as I wrote in #679 it is still not fully possible.

[maxence-charriere]

I'm not sure about this. Here, the use of text/html brings a layer of error check about whether the file is correctly formatted.

I'm wondering about the gain in terms of binary size. It may also require improving the unit tests for Handler functions since we would lose an error check.

I want to avoid spending time on strings bug hunting when I'm making changes to those templates.

[maxence-charriere]

I changed CI in the repo but I don't see why checks are not launched on this branch. Might require that you update from master 🤔.

[oderwat]

This is not a PR meant to be merged (yet). This just replaces the text/template dependency to hopefully be able to compile a go-app application WASM part with Tiny-Go which would decrease the WASM size most likely by a lot (100 times is possible). Currently, it can't compile because of the dependencies to the reflection code used by text/template. Getting rid of these it seems to be possible to compile. I did not check what else needs to be done. As mentioned it complains about a missing routine in os right now. Besides that it really does not need the template from my perspective :)

[maxence-charriere]

Yes, just trying to evaluate the pros and what it would take. Could definitely accept this if it is for binary size improvements. Tinygo is not on my priority list for now but anything that can improve the current binary size is.

[oderwat]

TinyGo actually should be one. It is like the current WASM uses 8 MB. The TinyGo version most likely about 400 KB.

See this. I am not at work so I can't grab my number: https://dev.bitolog.com/minimizing-go-webassembly-binary-size/

[maxence-charriere]

Since TinyGo does not aim to compile any possible Go program, it lacks some language and packages support. In other words, this means that you might need to modify your code in order for it to be compiled by TinyGo.

This is the exact reason why it is not on my priority list.

[oderwat]

It is on mine. And for a reason: All WASM stuff just fails to be used in production if the code is like 13 MB download upfront. We can compress it down to 3,5 MB but that is still a lot. So when I can compile it with TinyGo and shrink it to just some hundred kilobytes, it becomes a reasonable replacement for javascript.

[maxence-charriere]

Ok. Well, I'm not against this PR then but want to see if we can do better testing.

[mar1n3r0]

This is not a PR meant to be merged (yet). This just replaces the text/template dependency to hopefully be able to compile a go-app application WASM part with Tiny-Go which would decrease the WASM size most likely by a lot (100 times is possible). Currently, it can't compile because of the dependencies to the reflection code used by text/template. Getting rid of these it seems to be possible to compile. I did not check what else needs to be done. As mentioned it complains about a missing routine in os right now. Besides that it really does not need the template from my perspective :)

Rather than completely getting rid of text/template we can use https://github.com/valyala/fasttemplate which does not rely on reflection and is a faster direct drop-in replacement for text/template.

[oderwat]

@mar1n3r0 I personally would not use any (external) extension (dependency) for the use case in go-app which is just replacing some strings. But as I said. This PR was just made to see if I compile afterward with TinyGo and it does not (even though it may be closer).

[mar1n3r0]

@mar1n3r0 I personally would not use any (external) extension (dependency) for the use case in go-app which is just replacing some strings. But as I said. This PR was just made to see if I compile afterward with TinyGo and it does not (even though it may be closer).

@maxence-charriere is right about integrity and type safety when compiling the templates. Anyway I got to the SetEnv error you have reached. I guess we can keep on digging in the main issue until we figure it out. It's very close to working now.

You are also right that for the sake of testing Tinygo twe can skip the templates for now until we get it working.

@oderwat os.Setenv seems to be implemented now on dev branch but not yet released in master: tinygo-org/tinygo#2350

I have tried commenting out the whole setenv block for the sake of successful compilation only to check the final size. It's 6.3MB not as impressive as we were hoping I think. Wondering why it's only a fraction smaller when we were expecting a result in the range of KB.

My results so far:

Go compiler: 9.5MB
Tinygo compiler: 6.3MB

For comparison:
https://github.com/hexops/vecty#near-zero-dependencies

It should reduce the size by the magnitude of 10 or so. I think we are all after the sub MB numbers after gzipped. As an example - a large 20 MB app should go down to 2-3 MB when compiled with Tinygo and down to 500-800 KB served gzipped.

[oderwat]

So is the app you compiled splitting out the server part by using another build tag? And does it use net/http or not?

I am going to test our apps later on. But to me a difference of 3 MB is already pretty cool.

[mar1n3r0]

It's the original hello example without any changes except commenting out the SetEnv part. 3MB is way less than we expected based on vecty where the reduction was 10 times. It was supposed to go down from 10-12 MB to 1 - 1.2 MB while in practice it's 6.3 MB and I suspect it's the net/http lib that can't get squashed much.

[maxence-charriere]

@oderwat, just a bit out of subject, I try to make my CI work for PR like yours. Is your branch up to date with master?

[oderwat]

Yes. Just double-checked.

[maxence-charriere]

Okay folks, so I gave a try to support tinygo...
Good new is that I was able to make it compile.
Bad new is that it does not load in the browser.

Can have a look there => #682