31–40 of 99 posts
Go binaries, being static and embedding the whole go runtime, tend to be quite big. Now, I don't care about it because 5 or 10MO on my server filesystem is nothing. If I ask every visitor to download 10MO before running my webpage, that will be a problem, though.
Is this something we will have to deal with? Or will this be a lesser featured go implementation?
Hey so question - WebAssembly can't access the DOM right? What's the whole point then, avoid Javascript? If we can't just swap out all the gnarly JS garbage whole-hog, I don't see where the business value is, given that there's plenty of language-to-js libraries.
Essentially, from the developer perspective WebAssembly is like embedding native code as a scripting language in the browser.
Only primitive data types can be passed back and forth between the foreign function interface between the two.
Will the binaries be compiled for size optimization, or will they be the same size as usual golang bins? Go binaries, being static and embedding the whole go runtime, tend to be quite big. Now, I don't care about it because 5 or 10MO on my server filesystem is nothing. If I ask every visitor to download 10MO before running my webpage, that will be a problem, though. Is this something we will have to deal with? Or wil…
How are features like go routines and channels etc going to be supported? or they are not?
Mentions:
> Currently WebAssembly has no threads, but they are on the roadmap. Most Go code can run fine on a single thread. The only drawback is that “sysmon” is not available, thus there is no preemption of goroutines.
Could this be used to get native gRPC support for the browser?
WebAssembly doesn't provide any functional capabilities that aren't already accessible to JavaScript. This change does not really enable a browser to do anything more "natively" than it already could, other than run code that's written in Go.
Can this be used with CGO_ENABLED=1 if CC is emscripten?
I really wish WebAssembly did not use the word "Assembly". It doesn't really resemble any actual assembly language. And if you look at the comments in this thread, for example, a lot of people think it's letting you have something like arbitrary machine code.
I really wish WebAssembly didn’t use the word “Web”. Its best usecase is for the server. It just happens to also be great for challenging JavaScript in the browser.
So, I'm assuming you have something else in mind, and I'm wondering what it is.
Hey so question - WebAssembly can't access the DOM right? What's the whole point then, avoid Javascript? If we can't just swap out all the gnarly JS garbage whole-hog, I don't see where the business value is, given that there's plenty of language-to-js libraries.