I generally use the command line tool to upgrade from Fedora 27 to Fedora 28. The first upgrade went without a hitch. On a second machine, I ran into a dependency problem requiring that I install the Fedora 28 version of the nss-pem package before starting the upgrade
Fedora 28 has the latest version of Go (version 1.10) which is very nice. I haven't paid attention to what the previous versions of Go Fedora comes with since I also install the latest version that is released on golang.org.
WebAssembly (WASM) is the most exciting technology in web development in a long time from my perspective. It represents the first true steps in breaking the monopoly of Javascript as the language for the browser even though the WASM folks emphasize that isn't the intention. In my previous post, I mention that Go will support compiling to WebAssembly in version 1.11. This post shares some of my experimentation with Go's WASM support and to see what might be possible. Let me emphasize that the code is very hacky. I wrote them quickly mainly so I can try out WASM.
There are multiple ways to use WASM for web applications:
Optimization for JavaScript-driven applications - This is the scenario most emphasized for the current level functionality provided by the initial (MVP) release of WASM. Instead of writing everything in pre-compiled Javascript, optimized WASM modules are called by JavaScript. These modules can be written in JavaScript or other languages that can compile to WASM.
Porting existing code bases over to the browser - This is most often demonstrated with porting existing C/C++ code bases over to WASM through Emscripten and running what might previously been an exclusively desktop/native app (e.g. Autocad, games, etc.).
Writing an web app completely in a non-Javascript language - This is what I'm most excited about! Instead of having Javascript be the primary language, the application is completely written in another language such as Go. At the time of this writing, this isn't completely possible since WASM doesn't support WASM modules from directly calling the browser APIs (e.g. DOM APIs, XHR, etc.). This will be coming and is currently covered under the Host Binding proposal for WASM. Until then, the Javascript can be abstracted away in a language-specific binding.
The current state of Go WASM doesn't fit the first scenario very well. There doesn't seem to be a way to expose methods individually for Javascript to call directly. The Javascript code can execute each Go program's main function and when main() is done the module is done running. Given that each WASM module has the complete Go runtime including garbage collection, I'm not sure how practical it is to have a bunch of Go programs that are essentially meant to be single methods to the Javascript code.
Go WASM does provide the ability to define callback methods and attach callbacks to browser events. This requires that the module is running because once it exists it's not longer available to the browser call call. Because of this, Go WASM is currently most appropriate for scenarios 2 & 3.
The browser executes Javascript and WASM in a single threaded manner. When the WASM module is running, the browser's front end will block until it is completed. This will appear to the end user as if the browser is frozen: no way to type input, click button, etc. With Go WASM, control is given back to the browser when using time.Sleep or when the Go code is blocked. This has to be done manually by the developer so it's important to keep it in mind. Unless the apps expect to have completely control of everything in the browser while it is running developers need to remember to periodically sleep itself to give some control back to the browser. I hope this gets improved in the future because it makes the code ugly, error prone and honestly isn't something developers should need to do in a multi-tasking environment.
This is a very basic example of writing a Go WASM module that defines a method that gets attached to a HTML button's click event, change some attributes of the document's elements, waits a few seconds then executes a Go routine that draws to the canvas in the browser. The keepalive() function prevents the module from quitting until it gets a quit signal that happens when the Quit button is clicked and the cbQuit method is invoked because the button click event is triggered. Also note that when the browser's Alert dialog is triggered, it blocks everything until it is dismissed whether it's called by JavaScript or by the Go code.
The keepalive() can also simply be
select {}
if the intention is just not let the module exit.
---
---
The basics of having Go drive the web page (rather then it being Javascript) is all there.
This example was inspired by what was presented at GopherCon by Hana Kim when gomobile was first announced.
Instead of re-writing Rob Pike's Ivy Interpreter for Android/iOS/command-line the example showed that the existing Go library was reused. Just like her example, this example shows that existing Go libraries can be used in WASM.
---
---
The resulting WASM module is about 4MB but when compressed, the whole web app was only about 1 MB.
This example really doesn't show anything that the previous example didn't already show. I wanted to try against a larger code base and didn't want to write it myself. It mainly just demonstrates an existing Go library being used with no changes needed to make it work.
The Ivy code is easy to port but if something is expecting to access a file system or make HTTP calls then the browser environment doesn't match. There isn't any standard file system and outbound calls uses XHRHttpRequest rather then the current HTTP package.
Conclusions
It is possible to use Go to write web applications even though it currently still needs to rely on JavaScript to access the brower's APIs. Things like Go routines work but developers have to handle sleeping themselves in order to not block the UI. However, the possibility of ending JavaScript's monopoly for being the browser's language is definitely there!
Browsers themselves still need to do some optimizations. Each WASM module's byte code still has to be compiled so there's always a delay before the module starts running. It still starts faster then JavaScript but it'd be much better if the browsers caches the compiled WASM the first time. My understanding that it'll likely come in the near future but not there yet.
I'm very excited to see this land in Go 1.11 and look forward to see what other developers use it for!
