Get best of the week

Alexey Grachev: Go Frontend

Kyiv Go Meetup May 2018:



Host: - Hello everyone! Thank you for coming here! Today we have two official speakers - Lesha and Vanya. There will be two more if we have enough 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 on Go. Sometimes you have to deal with the front-end, sometimes you have to climb there with pens. I want to talk about my experience and research Go on the front end.

The legend is this: first we will talk about why we want to run Go on the front-end, then we'll talk about how this can be done. There are two ways - Web Assembly and GopherJS. Let's see in what state these decisions are and what can be done.

What is wrong with the frontend?


Does everyone agree that everything is fine with the frontend?



Are there few tests? Slow assembly? Ecosystem? Good.

Regarding the frontend, I like the quote one of the frontend developers said in his book:



There is no type system in Javascript. Now I will name the problems that I encountered in the course of my work and explain how they are solved.

It is generally difficult to call a type system a type system in Javasript - there are lines that indicate the type of an object, but in reality it has nothing to do with types. This issue is resolved in TypeScript (an add-on for Javasript) and Flow (static-checker types in Javascript). Actually, the frontend has already reached the solution to 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 do not have a standard library in Javascript as such. This problem was once solved by jQuery (everyone used jQuery with all the prototypes, helpers, functions that are needed to work). Now everyone is using Lodash:



Callback hell. I think everyone saw the Javascript code some 5 years ago, and it looked like “noodles” from the incredible intricacies of callbacks. Now this problem is solved (with the release of ES-15 or ES-16), they added promises to Javascript and everyone began to breathe easier for a while.



Until Promice hell came ... I don’t know how the front-end industry manages, but they constantly drive themselves into some strange wilds. They also managed to make hell on the “promises”. Then they solved this problem by adding a new primitive - async / await:



The problem is solved with asynchrony. Async / await is a fairly popular primitive in different languages. In "Python" and in others there is such an approach - it is good enough. The problem is resolved.

What problem is not resolved? The complexity of frameworks that grows exponentially, the complexity of the ecosystem and the programs themselves.



  • The Javasript syntax is a bit weird. We all know the problems with adding an array and an object and other jokes.
  • Javascript is multi-paradigm. Now it is a particularly urgent 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, different paradigms when you use different packages;
    • there is a lot of “fun” with functional programming in Javasript - the rambda library has appeared and now no one can read programs written in this library.

  • This all makes a big impact on the ecosystem, and it has grown incredibly. Packages are incompatible with each other: someone on promises, someone on async / await, someone on callbacks. They also write in different paradigms!
  • This makes the project difficult to maintain. It's hard to find a bug if you cannot read the code.

What is Web Assemly?


The brave guys from the Mozilla Foundation and several other companies came up with such a thing as Web Assembly. What is it?



  • 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 javascript code every time.
  • All browsers have declared support.
  • Since this is a bytecode, you can write a compiler for any language.
  • Four major browsers already come with Web Assembly support.
  • Soon we are waiting for native support in Go. Such a 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 do not have Web Assembly support, there is a transporter such as GopherJS.



  • Go code transpiles to pure Javascript.
  • – , ( Vanilla JS, ).
  • , Go, … – , .
  • , , : syscall, net- ( net/http-, , XMLHttpRequest). – , stdlib Go, .
  • Go, ( .) GopherJS .

GopherJS is very easy to get - this is a regular Go package. We make go get, and we have the GopherJS team 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 that simple: we do GopherJS build - run it in a browser - everything works!

What is there at the moment? Bindings




There are binders to all popular js frameworks:

  • JQuery
  • Angular.js;
  • D3.js for graphing and working with big data;
  • React.js;
  • VueJS;
  • there is even Electron support (that is, we can now write desktop applications on Electron);
  • and the funniest thing is WebGL (we can make full-graphical applications, including games with 3D graphics, music and all the goodies);
  • and a lot of other binders to all popular javascript frameworks and libraries.

Framework


  1. There is already a web framework specially developed for GopherJS - Vecty. This is a full-fledged analogue of React.js, but only developed on Go, with the specifics of GopherJS.
  2. There are game bags (all of a sudden!). I found two of the most popular:

    • Engo;
    • Ebiten.

I’ll demonstrate a couple of examples of how this looks and what you can write on Go now:



Or such an option (I didn’t find a 3D shooter, but maybe it is):



What do I suggest?


Now the front-end industry is in such a state that all languages ​​that cried from Javascript before this will rush there. Now everyone will be compiled into Web Assemblies. What do we need to take a worthy place there as “gophers”?



Go has traditionally gone that it is a System programming language, and there are practically no libraries for working with UI. Something is there, but it is half abandoned, half non-functional.

And here is a good chance to make UI libraries on 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 will receive early adaptation, and you will be a star (if it is a good framework).

You can adapt a lot of different packages that are already in the Go ecosystem to the specifics of the browser (for example, Template engine). They’ll 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 frontend using the same code - everything is what front-end developers like (only now on Go).

You can write a game! Just for fun ...

I have it.



Questions


Question (hereinafter - Q): - Do I write in Go or in Js?

AG: - You write routines, channels, structures, embedding on Go - that's it ... You subscribe to an event, pass a function there.

Q: - That is, I write on the “bare” Js?

AG: - No, you write as if on Go and connect to the browser API (the API has not changed at the same time). You can write your bindings so that messages come to the channel - it’s easy.

Q: - What about the mobile?

AG: - I definitely saw: there are binders for the Cordova patch that Js launches. In React Native, I don’t know; maybe there is, maybe not (not really interested). The N-go game engine also supports mobile applications - both iOs and Android.

AT:- Question on Web Assembly. More and more places are occupied, despite the tightness, “zipping” ... Could we kill the front-end world in this way even more?

AG: - Web Assembly is a binary format, and the binary by default cannot be in the final release more than the text ... runtime pulls you, but it's the same as delaying the standard Javascript library when it is not, so we use some kind of someday lodash. I do not know how much Lodash takes.

Q: - Explicitly less than runtime ...

AG: - On the "pure" Javascript?

Q: - Yes. We squeeze it before sending it ...

AG:- But this is the text ... In general, megabytes are a lot, but that's all (you have all the runtime). Next, you write your business logic, which will increase your binary by 1%. Until I see this kill the frontend. Moreover, Web Assembly will run faster than Javascript for the obvious reason - it does not need to be parsed.

Q: - So far, a controversial moment ... There is still no reference implementation of “Vasma” (Web Assembly), so that you can clearly judge. Conceptually - yes: we all understand that binary should be faster, but the current implementation of the same V8 is very effective.

AG: - Yes.

Q: - Compilation works really cool there and it’s not a fact that there will be a big advantage.

AG: - Web Assembly is also doing great guys.

AT:- So far, it seems to me, it is still difficult to judge Web Assembly. Talk has been going on for many years, and there are few real achievements that can be felt.

AG: - Perhaps. We will see.

Q: - We have no problems on the backend ... Maybe leave these problems in the frontend? Why climb there?

AG: - We have to keep the staff of the front-lineers.


A bit of advertising :)


Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to your friends cloud-based VPS for developers from $ 4.99 , a unique analog of entry-level servers that was invented by us for you: The whole truth about VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps from $ 19 or how to divide the server? (options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).

Dell R730xd 2 times cheaper at the Equinix Tier IV data center in Amsterdam? Only we have 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV from $ 199 in the Netherlands!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - from $ 99! Read about How to Build Infrastructure Bldg. class c using Dell R730xd E5-2650 v4 servers costing 9,000 euros for a penny?

More articles:


All Articles