Kyiv Go Meetup May 2018:
Leader: - Hi all! Thank you for being here! Today we have two official speakers - Lyosha and Vanya. There will be two more if we have time. The first speaker is Alexey Grachev, he will tell us about GopherJS.
Alexey Grachev (hereinafter - AG): – I am a Go developer and I write web services in Go. Sometimes you have to deal with the frontend, sometimes you have to climb there with handles. I want to talk about my experience and research on Go on the frontend.
The legend is this: first we'll talk about why we want to run Go on the frontend, then we'll talk about how we can do it. There are two ways - Web Assembly and GopherJS. Let's see what state these decisions are in and what can be done.
What's wrong with frontend?
Everyone agrees that everything is fine with the frontend?
Few tests? Slow build? Ecosystem? Fine.
Regarding the front-end, I like a quote that one of the front-end developers said in his book:
Javascript does not have a type system. Now I will name the problems that I encountered in the course of my work and explain how they are solved.
The type system is generally difficult to call a type system in Javascript - there are lines that indicate the type of an object, but in fact this has nothing to do with types. This problem is solved in TypeScript (Javascript's add-on) and Flow (Javascript's static-checker of types). In fact, the frontend has already gone as far as solving the problem of a bad type system in Javascript.
There is no standard library in the browser as such - there are some built-in objects and "magic" functions in browsers. But I don't have a standard library in Javascript as such. This problem has already been solved by jQuery (everyone used jQuery with all the prototypes, helpers, functions that needed to work). Now everyone uses Lodash:
callback hell. I think everyone saw Javascript code about 5 years ago, and it looked like a “noodle” from an incredible intricacies of callbacks. Now this problem is solved (with the release of ES-15 or ES-16), promises were added to Javascript and everyone began to breathe easier for a while.
Until Promice hell came along... I don't know how the front-end industry manages, but they always drive themselves into some strange jungle. We also managed to make hell on “promises”. Then we solved this problem by adding a new primitive - async / await:
With asynchrony, the problem is solved. Async/await is quite a popular primitive in different languages. Python and others have this approach - it's good enough. Problem solved.
What problem is not solved? The exponentially increasing complexity of frameworks, the complexity of the ecosystem and the programs themselves.
- Javascript's syntax is a little weird. We all know the problems with adding an array and an object and other tricks.
- Javascript is multi-paradigm. Now this is a particularly pressing system when the ecosystem is very large:
- everyone writes in different styles - someone writes structurally, someone writes functionally, different developers write differently;
- from different packages (packages) different paradigms when you use different packages;
- a lot of "fun" with functional programming in Javascript - the rambda library appeared and now no one can read programs written in this library.
- All this makes a big impact on the ecosystem, and it has grown incredibly. The packages are incompatible with each other: some are on promises, some are on async/await, some are on callbacks. They also write in different paradigms!
- This makes the project difficult to maintain. It's hard to find a bug if you can't read the code.
What is Web Assembly?
The brave guys from the Mozilla Foundation and a number of other companies came up with such a thing as Web Assembly. What is this?
- This is a virtual machine built into the browser that supports the binary format.
- Binary programs get there, they are executed almost natively, that is, the browser does not need to parse all the "noodles" of the javascript code every time.
- All browsers have declared support.
- Since this is bytecode, you can write a compiler for any language.
- The four major browsers already ship with Web Assembly support.
- We are expecting native support in Go soon. This new architecture has already been added: GOARCH=wasm GOOS=js (soon). So far, as I understand it, it is not functional, but there is a statement that it will definitely be in Go.
What to do now? GopherJS
While we don't have Web Assembly support, there is a transpiler like GopherJS.
- The Go code is transpiled into "pure" Javascript.
- Runs in all browsers - there are no new features that are only supported by modern browsers (this is Vanilla JS, which runs on anything).
- There is support for almost everything that is in Go, including goroutines and channels ... - everything that we love and know so much.
- Almost the entire standard library is supported, with the exception of those packages that it makes no sense to support in the browser: syscall, net interactions (there is a net / http client, but no server, and the client is emulated via XMLHttpRequest). In general, the entire standard library is available - here it is in the browser, here is the Go stdlib that we love.
- The whole package ecosystem in Go, all third-party solutions (templating, etc.) can be compiled with GopherJS and run in the browser.
Getting GopherJS is very easy - it's just a regular Go package. We do a go get and we have a GopherJS command to build the application:
Here is such a small hello world ...
...A regular Go program, a regular fmt package of the standard library and Binding Js to reach the browser API. Println will eventually be converted to console log and the browser will write "Hello gophers"! It's so simple: we do GopherJS build - we launch it in the browser - everything works!
What is there at the moment? Bindings
There are bindings for all popular js frameworks:
- jquery;
- Angular.js
- D3.js for plotting and working with big data;
- React.js
- VueJS;
- there is even support for Electron (that is, we can already write desktop applications on Electron);
- and the funniest thing is WebGL (we can make full-graphic applications, including games with 3D graphics, music and all the goodies);
- and a lot of other bindings to all popular javascript frameworks and libraries.
Framework
- There is a web framework already developed specifically for GopherJS - Vecty. This is a full-fledged analogue of React.js, but only developed in Go, with the specifics of GopherJS.
- There are game bags (suddenly!). I found two of the most popular:
- engo;
- Ebiten.
I will demonstrate a couple of examples of how it looks and what can already be written in Go:
Or this option (I didn’t find a 3D shooter, but maybe it exists):
What do I suggest?
Now the front-end industry is in such a state that all the languages \uXNUMXb\uXNUMXbthat previously cried from Javascript will rush there. Now everything will compile to "Web Assemblies". What do we need to take a worthy place there as "gophers"?
In Go, it has traditionally gone that it is a System programming language, and there are practically no libraries for working with the UI. There is something, but it is half abandoned, half non-functional.
And now - a good chance to make UI libraries in Go that will run on GopherJS! You can finally write your own framework! The time has come when you can write a framework, and it will be one of the first and get adopted early, and you will be a star (if it is a good framework).
You can adapt a lot of different packages that already exist in the Go ecosystem to the specifics of the browser (for example, the Template engine). They will already work, you can make convenient bindings so that you can easily render content directly in the browser. Plus, you can make, for example, a service that can render the same thing on the server and on the front-end, using the same code - everything that front-end developers like (only now on Go).
You can write a game! Just for fun…
That's all I wanted to say.
Questions
Question (hereinafter referred to as Q): – Am I writing in Go or Js?
AG: – You write routines, channels, structures, embedding – everything in Go… You subscribe to an event, pass a function there.
В: - That is, I write on the "naked" Js?
AG: - No, you write as if in Go and connect to the browser API (the API has not changed). You can write your own bindings so that messages come to the channel - it's not difficult.
В: - What about mobile?
AG: - I saw for sure: there are binders for the Cordova patch that Js launches. In React Native, I don't know; maybe there is, maybe not (not particularly interested). The N-go game engine supports both mobile applications - both iOs and Android.
В: – Web Assembly question. More and more places are being occupied, despite the conciseness, “zipping” ... Will we not kill the world of the frontend even more in this way?
AG: - Web Assembly is a binary format, and the default binary cannot be larger than text in the final release ... You are pulled by runtime, but this is the same as pulling in the Javascript standard library when it is not there, so we use some Lodash . I don't know how long Lodash takes.
В: - Obviously less than runtime ...
AG: - On "pure" Javascript?
В: - Yes. We compress it before sending it ...
AG: - But this is text ... In general, a megabyte is like a lot, but that's all (you have the entire runtime). Next, you write your own business logic that will increase your binary by 1%. So far I don't see it killing the frontend. Moreover, Web Assembly will work faster than Javascript for the obvious reason - it does not need to be parsed.
В: - So far, a controversial point ... There is still no reference implementation of "Wasma" (Web Assembly), so that one can unambiguously judge. Conceptually, yes: we all understand that binary should be faster, but the current implementation of the same V8 is very efficient.
AG: - Yes.
В: - Compilation there works really very cool and it's not a fact that there will be a big advantage.
AG: - Web Assembly is also made by big guys.
В: - So far, it seems to me, it is still difficult to judge Web Assembly. For many years there have been talks, but there are few real achievements that can be felt.
AG: - Maybe. We'll see.
В: – We don’t have problems on the backend… Maybe we should leave these problems in the frontend? Why go there?
AG: - We have to keep the staff of frontliners.
Some ads 🙂
Thank you for staying with us. Do you like our articles? Want to see more interesting content? Support us by placing an order or recommending to friends, , a unique analogue of entry-level servers, which was invented by us for you: (available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
Dell R730xd 2 times cheaper in Equinix Tier IV data center in Amsterdam? Only here in the Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $99! Read about
Source: habr.com