Goja

[jimafisk]

Revisiting Goja a JS interpreter written in pure Go. If viable it would allow us to remove CGO which would simplify our cross-compile builds and finally allow native windows support. Reasons for revisiting:

• Most ES6 features have been implemented: https://github.com/dop251/goja/milestone/1?closed=1
• Performance has improved: Remove nodejs dependency #3 (comment)

However trying to add the Svelte compiler to a goja vm throws a lot of errors:

errs.go:57: Could not add svelte compiler: SyntaxError: SyntaxError: compile_svelte: Line 22:2 Unexpected reserved word (and 1620 more errors) /home/jimafisk/Projects/jantcu/plentico/plenti/cmd/build/client.go on line 66


SyntaxError: SyntaxError: compile_svelte: Line 22:2 Unexpected reserved word (and 1620 more errors) (File: /home/jimafisk/Projects/jantcu/plentico/plenti/cmd/build.go, Line: 134)

The first being line 22 of svelte/compiler.js: class Stats {. That's because classes are not yet supported in Goja but it appears that's being worked on currently: dop251/goja#167 (comment)

[jimafisk]

Just found that there is also some NodeJS support for Goja: https://github.com/dop251/goja_nodejs. Being able to support things like require would help eliminate some of the preprocessing we're currently doing to remove problematic syntax.

[jimafisk]

I stumbled across an issue from @matthewmueller looking for Goja class support to run Svelte server-side: dop251/goja#349

I reached out to him on twitter because it seems like we're trying to solve the same problem. He's tried some of the same stuff we've thought about for this project and covered some interesting new ground as well.

Things Matt has tried/considered

1. Migrate evaling to goja. This isn't possible yet due to the issue you linked (there might be other issues after this one)

2. ESBuild transpiling down to ES3. If ESBuild could translate the SSR code to something Goja could understand, that'd work too.

3. Compile quickjs to WASM. Use a WASM runtime within the Go webserver. This actually works, but is quite slow. I think this could be improved, but figuring out how to pass data from host to WASM plugin was challenging. Just would take more time to figure out. Also doesn't seem to currently solve the cgo problem since the most popular wasm vm uses C.

4. Compile Svelte to Go Templates(!). This one was a bit crazy, but if you're able to evaluate basic JS expressions in Go, it could work most of the time. I decided against this because I didn't want a situation where valid svelte code doesn't work in SSR.

5. Translate quickjs to Go using ccgo. https://gitlab.com/cznic/ccgo/-/issues/22. This one seems really promising, but I just don't know enough about C to make it happen.

6. Hand-translate the quickjs VM to Go. QuickJS has 2 parts: parsing and evaluating. One of the cool things about QuickJS is that you can emit bytecode from the parsing step. You can half the work of the translation step, by just porting over the VM that reads bytecode and returns results. This would require translating about 25k of C code.

To me (Matt), the most promising solutions are either bringing Goja compatibility up, or translating the QuickJS VM (possibly automating some of it with ccgo).

I also mentioned that I had some trouble running go routines with v8go (#26 (comment)) and he said:

I haven't noticed any problems running V8 isolates inside HTTP handlers (where each request is within a goroutine). I went pretty deep awhile back and I can't say I fully understand it yet, but in case helpful, I wrote this issue on the topic: rogchap/v8go#144.

[jimafisk]

Goja has class support now: dop251/goja@0b5d210

Testing ground for Goja Svelte compiler: https://github.com/matthewmueller/goja-svelte