I have been building applications using the GOOS=js/GOARCH=wasm for around 
two years. I really like being able to write both client and server code in 
Go. I have four questions that I have not yet found a clear answer for:

(1) The syscall/js package is marked EXPERIMENTAL. Is there any consensus 
as to when this package might become stable?

(2) The rules surrounding Go routines are different from the expectations 
of Go itself. There is a comment in src/syscall/js/func.go concerning this:

// As a consequence, if one wrapped function blocks, JavaScript's event loop 
// is blocked until that function returns. Hence, calling any async 
JavaScript 
// API, which requires the event loop, like fetch (http.Client), will cause 
an 
// immediate deadlock. Therefore a blocking function should explicitly 
start a 
// new goroutine. 

Is this the expected behavior in the long term? I often get caught up in 
the rules here.

(3) I have not yet found a clean way to read a file from the browser (i.e., 
in response to a file HTML input). I presently use a JavaScript function 
that uses a FileReader to read the file into a global variable data before 
setting another global Boolean done to true. On the Go side, I poll the 
global Boolean done, waiting for it to become true before pulling the file 
out of the global data. Does anyone have an example of a better way to do 
this?

(4) I have a Wasm Go routine that updates a progress bar as it executes. 
However, the progress bar does not update until the Go routine completes. I 
suspect this is related to (2). Is there a pattern for getting this to work?

--
Mike

:wq

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e568cb0c-c9a9-4155-ae30-ea29fb7f2ea9n%40googlegroups.com.

Reply via email to