Kyiv Go Meetup May 2018:
Host: – Hello everyone! Thank you for gathering here! Today we have two official speakers – Alex and Vanya. There will be two more if we have enough time. The first speaker is Alexey Grachev, who will tell us about GopherJS.
Alexey Grachev (hereafter – AG): – I am a Go developer, and I write web services in Go. Sometimes I have to deal with the frontend, and I occasionally dive into it hands-on. I want to share my experience and research on Go in the frontend.
The legend goes: first, we'll talk about why we want to run Go on the frontend, then we'll discuss how to do it. There are two paths – Web Assembly and GopherJS. Let's see the state of these solutions and what can be done.
What's wrong with the frontend?
Does everyone agree that everything is fine with the frontend?
Not enough tests? Slow builds? Ecosystem? Good.
Regarding the frontend, I like a quote from one of the frontend developers in his book:
Javascript lacks a type system. Now I will name the problems I encountered along the way and explain how they are solved.
The type system can hardly be called a type system in Javascript – there are strings that denote the type of an object, but in reality, it has nothing to do with types. This problem is addressed in TypeScript (a superset of Javascript) and Flow (a static type checker in Javascript). In fact, the frontend has already reached a solution to the problem of poor type systems in Javascript.
There is no standard library in the browser as such – there are some built-in objects and 'magical' functions in browsers. But as for standard libraries, they are absent in Javascript itself. This problem was once solved by jQuery (everyone used jQuery with all the prototypes, helpers, and functions needed for work). Now everyone uses Lodash:
Callback hell. I think everyone has seen Javascript code from about 5 years ago, and it looked like a 'noodle' of incredibly tangled callbacks. This problem is now resolved (with the release of ES-15 or ES-16), promises were added to Javascript, and for a while, it became easier to breathe.
Until Promise hell came... I don't know how the frontend industry manages, but they keep digging themselves into strange pits. They even managed to create hell with 'promises'. Then they decided this issue by adding a new primitive – async/await:
The problem with asynchronicity is solved. Async/await is a fairly popular primitive in different languages. In Python and others, there is such an approach – it's quite effective. The problem is resolved.
What problem remains unsolved? The exponentially increasing complexity of frameworks, the complexity of the ecosystem, and the programs themselves.
- The syntax of JavaScript is somewhat peculiar. We all know the issues with adding arrays and objects and other quirks.
- JavaScript is multi-paradigm. Right now, this is particularly pressing since the ecosystem is very large:
- everyone writes in different styles – some write structurally, others functionally; different developers have different approaches;
- from different packages, there are varying paradigms when you use different libraries;
- there's a lot of 'fun' with functional programming in JavaScript – a library called Ramda emerged, and now no one can read programs written with this library.
- All this significantly impacts the ecosystem, and it has grown immensely. Packages are incompatible with each other: some use promises, some use async/await, others rely on callbacks. They also write in different paradigms!
- This leads to the project being difficult to maintain. It's hard to find bugs if you can't read the code.
What is Web Assembly?
The brave folks from the Mozilla Foundation and several other companies came up with something called Web Assembly. What is it?
- It's a virtual machine built into the browser that supports a binary format.
- Binary programs enter it and are executed almost natively, meaning the browser doesn't need to parse the entire 'noodle' of JavaScript code each time.
- All browsers have announced support.
- Since this is bytecode, a compiler can be written for any language.
- The four main browsers already come with support for Web Assembly.
- We expect native support in Go soon. This new architecture has already been added: GOARCH=wasm GOOS=js (soon). For now, as I understand, it is not functional; however, there is a statement that this will definitely be in Go.
What to do now? GopherJS.
While we don't have support for Web Assembly, there is a transpiler called GopherJS.
- Code in Go transpiles to 'pure' JavaScript.
- It runs in all browsers – there are no new features that are only supported by modern browsers (it's Vanilla JS, which can run on anything).
- There is support for almost everything that exists in Go, including goroutines and channels... everything we love and know.
- Almost the entire standard library is supported, except for those packages that make no sense to support in the browser: syscall, net interactions (there is a net/http client, but no server, and the client is emulated through XMLHttpRequest). Overall, the entire standard library is available – here it is in the browser, here is the Go stdlib that we love.
- The entire ecosystem of Go packages, all third-party solutions (templating, etc.) can be compiled using GopherJS and run in the browser.
Getting GopherJS is very easy – it’s a regular Go package. Just do go get, and we have the GopherJS command to build the application:
Here’s a simple hello world...
...A regular Go program, a regular fmt package from the standard library, and Binding Js to access the browser API. Println will eventually be converted to console log, and the browser will print 'Hello gophers'! It's that simple: we do GopherJS build – run it in the browser – and everything works!
What is available at the moment? Bindings
There are bindings to all popular js frameworks:
- JQuery;
- Angular.js;
- D3.js for graphing and working with big data;
- React.js;
- VueJS;
- there’s even support for Electron (meaning we can already write desktop applications in 'Electron');
- and the funniest part is WebGL (we can create photorealistic applications, including games with 3D graphics, music, and all the bells and whistles);
- and many other bindings to all popular JavaScript frameworks and libraries.
Framework
- There is already a web framework developed specifically for GopherJS – Vecty. It is a full-fledged analogue of React.js, but developed in Go, with GopherJS specifics.
- There are game engines (surprisingly!). I found the two most popular ones:
- Engo;
- Ebiten.
I will demonstrate a couple of examples of what this looks like and what can already be written in Go:
Or this option (couldn't find a 3D shooter, but perhaps it exists):
What do I propose?
The frontend industry is currently in a state where all languages that have previously suffered because of JavaScript will now rush in. Now everyone will be compiled into 'Web Assembly'. What do we need to secure a worthy place there as 'gophers'?
In Go, it has traditionally been thought of as a System programming language, and there are practically no libraries for working with the UI. There are some, but they are half-abandoned and half-nonfunctional.
And here’s a great opportunity to create UI libraries in Go that will run on GopherJS! Finally, you can write your own framework! It’s time to write a framework, and it will be one of the first and gain early adoption, and you'll be a star (if it's a good framework).
You can adapt a ton of different packages that already exist in the Go ecosystem to the specifics of the browser (for example, a Template engine). They will already work; you can create convenient wrappers so that content can be easily rendered right in the browser. Plus, you can make a service that can render the same thing on the server and on the frontend using the same code – just like frontend developers love (only now in Go).
You can write a game! Just for fun…
That's all from me.
Questions
Question (hereafter – Q): – Am I writing in Go or Js?
AG: – You are writing Go routines, channels, structures, embedding – everything... You subscribe to an event, passing a function there.
Q: – So I’m writing in ‘bare’ Js?
AG: – No, you’re writing as if in Go and connecting to the browser API (the API hasn’t changed). You can write your wrappers so that messages come to the channel – it's not hard.
Q: – What about mobile?
AG: – I definitely saw: there are bindings for the Cordova patch that Js runs. As for React Native – I don't know; there might be, or there might not be (I haven't really looked into it). The N-go game engine supports both mobile applications – iOS and Android.
Q: – A question about Web Assembly. It takes up more and more space, despite compression and being ‘zipped’... Will we not destroy the world of frontend even further this way?
AG: – Web Assembly is a binary format, and a binary by default cannot be larger than text in the final release… You’re tempted by the runtime, but it’s the same as pulling in the standard Javascript library when it’s not there, which is why we use something like Lodash. I don’t know how much Lodash takes up.
Q: – Definitely less than the runtime…
AG: – On ‘pure’ Javascript?
Q: – Yes. We compress it before sending…
AG: – But this is just text… In general, a megabyte seems like a lot, but that's it (you have all the runtime). Then you write your business logic which will increase your binary by 1%. So far, I don't see this as a detriment to the frontend. Moreover, Web Assembly will run faster than JavaScript for the obvious reason—it doesn't need to be parsed.
Q: – That's still a contentious point… There isn't a standard implementation of "Wasm" (Web Assembly) yet that allows for a definitive judgment. Conceptually, yes: we all understand that the binary should be faster, but the current implementation of V8 is very efficient.
AG: – Yes.
Q: – The compilation there works really well, and it's not certain there will be a significant advantage.
AG: – Big players are also working on Web Assembly.
Q: – For now, I think it's still hard to judge Web Assembly. There have been discussions for so many years, but tangible achievements are few.
AG: – Perhaps. We'll see.
Q: – We have no issues on the backend… Why not leave those issues to the frontend? Why interfere?
AG: – We have to keep a staff of frontend developers.
A little advertisement 🙂
Thank you for staying with us. Do you enjoy our articles? Want to see more interesting content? Support us by placing an order or recommending us to your friends, , a unique entry-level server alternative that we have created for you: (options available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd at half the price in the Equinix Tier IV data center in Amsterdam? Only with us in the Netherlands! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — from $99! Read about how
Source: habr.com
