Tinygo is just one package away

[mar1n3r0]

Good news, I know that a lot of people are waiting for this.

The net/http and encoding/json packages are now implemented in tinygo.

The only package left for it to compile successfully is text/template: https://tinygo.org/docs/reference/lang-support/stdlib/#texttemplate https://github.com/tinygo-org/tinygo/issues/752

text/template relies heavily on reflect which is one of tinygo's weak points. You might be better off looking for a code-generation template library if possible. ?

@maxence-charriere Could this be an easy to bypass stumble block?

Maybe this: https://github.com/valyala/fasttemplate

Let's keep that issue open and track progress here.

[oderwat]

Very good indeed! I made a quick replacement for the usage of text/template (see: #680)

Compilation now fails with a missing function in os. I did not follow up changing more code yet.

>$ tinygo build -o tiny.wasm -target wasm cmd/app/main.go
# github.com/maxence-charriere/go-app/v9/pkg/app
../go-app/pkg/app/http.go:334:16: Setenv not declared by package os

[dkegel-fastly]

The dev branch of tinygo has supported os.Setenv for about a month now.

Try building the dev branch from source... or wait a week or so for the 0.22 release.

[oderwat]

@dkegel-fastly os.Setenv is just a minor problem. The missing timers is much more serious, see https://github.com/maxence-charriere/go-app/pull/682

The title of this issue is misleading, as it will be always "one package" away till all of them are supported :-)

[dkegel-fastly]

Thanks. That's https://github.com/tinygo-org/tinygo/issues/1037

[justinfx]

Tiny-go says they just released the support for timers.

[mar1n3r0]

Depends on WASI support in Go. See: https://github.com/tinygo-org/tinygo/issues/2910

[gedw99]

Hey all

I gave github.com/maxence-charriere/go-app/v10 a try today and the only bug is

# github.com/maxence-charriere/go-app/v10/pkg/app
../../../../../../../../../../../pkg/mod/github.com/maxence-charriere/go-app/v10@v10.0.0-20240312064243-fd8d583dcdfa/pkg/app/node.go:784:13: v.Equal undefined (type reflect.Value has no field or method Equal)
../../../../../../../../../../../pkg/mod/github.com/maxence-charriere/go-app/v10@v10.0.0-20240312064243-fd8d583dcdfa/pkg/app/node.go:789:14: v.Equal undefined (type reflect.Value has no field or method Equal)

from https://github.com/mlctrez/mlctrez.github.io/issues/1 where the test code is.

[oderwat]

I just saw the headline of this issued and can't resist commenting that this is like: Fusion, General AI and Half-Life 3. It may also end up like "Duke Nukem Forever", which was not very pleasing.

I gave github.com/maxence-charriere/go-app/v10 a try today and the only bug is

Well, this is not the only problem (not a bug at all) but just the current "first" problem.

As far as I remember it was not even bringing the expected gains when it was getting compiled with TinyGo in a "cheated" fashion. So it may not even worth the effort.

To not only leave a basically useless comment, I want to point out some things:

• We had some success to use wasm-opt from https://github.com/WebAssembly/binaryen to reduce WASM file sizes for the original Go compiler results. This was not battle tested through.
• Even when you separate frontend code from backend code, you should check on the included packages. The Go compiler has a tendency to include stuff you do not expect. We once had megabytes wasted, because it was including a CLI argument parsing library that was used in another package and somehow (I think because of a global variable they use) stuck in the WASM result.
• I believe it is better to utilize web workers (!= service workers) to load/swap WASM modules when needed and gain real parallel processing that way. Such modules can be compiled with TinyGo. This even works without having a web worker. But you are very limited in what that can do. Still can make sense for business logic that needs to run in the frontend.

Sorry for being off-topic. I just can't see how TinyGo can be used and wanted to share some experience we made in the topic of cutting down the size of the (main) WASM module.