🦋 👃🏾 🧛🏼 Alexey Grachev: Ir Frontend 👨🏻‍💼 ⭕️ 🧚🏿

Kyiv Go Meetup Mayo 2018:

Anfitrión: - ¡Hola a todos! ¡Gracias por venir! Hoy tenemos dos oradores oficiales: Lesha y Vanya. Habrá dos más si tenemos suficiente tiempo. El primer orador es Alexey Grachev, nos contará sobre GopherJS.

Alexey Grachev (en adelante, AG): - Soy un desarrollador de Go y escribo servicios web en Go. A veces tienes que lidiar con el front-end, a veces tienes que subir allí con plumas. Quiero hablar sobre mi experiencia e investigación Ir al frente.

La leyenda es esta: primero hablaremos sobre por qué queremos ejecutar Go en el front-end, luego hablaremos sobre cómo se puede hacer esto. Hay dos formas: Web Assembly y GopherJS. Veamos en qué estado están estas decisiones y qué se puede hacer.

¿Qué le pasa a la interfaz?

¿Están todos de acuerdo en que todo está bien con la interfaz?

¿Hay pocas pruebas? Ensamblaje lento? ¿Ecosistema? Bueno.

Con respecto al frontend, me gusta la cita que uno de los desarrolladores frontend dijo en su libro:

No hay un sistema de tipos en Javascript. Ahora nombraré los problemas que encontré en el curso de mi trabajo y explicaré cómo se resuelven.

En general, es difícil llamar a un sistema de tipos un sistema de tipos en Javasript: hay líneas que indican el tipo de un objeto, pero en realidad no tiene nada que ver con los tipos. Este problema se resuelve en TypeScript (un complemento para Javasript) y Flow (tipos de comprobador estático en Javascript). En realidad, la interfaz ya ha llegado a la solución al problema de un sistema de tipos incorrecto en Javascript.

No existe una biblioteca estándar en el navegador como tal: hay algunos objetos integrados y funciones "mágicas" en los navegadores. Pero no tengo una biblioteca estándar en Javascript como tal. Este problema fue resuelto una vez por jQuery (todos usaban jQuery con todos los prototipos, ayudantes, funciones necesarias para trabajar). Ahora todos están usando Lodash:

Callback hell. Creo que todos vieron el código Javascript hace unos 5 años, y parecía "fideos" de las increíbles complejidades de las devoluciones de llamada. Ahora que este problema está resuelto (con el lanzamiento de ES-15 o ES-16), agregaron promesas a Javascript y todos comenzaron a respirar mejor por un tiempo.

Hasta que llegó el infierno de Promice ... No sé cómo se las arregla la industria de front-end, pero constantemente se conducen a algunos extraños salvajes. También lograron hacer el infierno con las "promesas". Luego resolvieron este problema agregando una nueva primitiva: async / await:

el problema se resuelve con asincronía. Async / await es una primitiva bastante popular en diferentes idiomas. En "Python" y en otros hay un enfoque de este tipo: es lo suficientemente bueno. El problema esta resuelto.

¿Qué problema no se resuelve? La complejidad de los marcos que crece exponencialmente, la complejidad del ecosistema y los propios programas.

La sintaxis de Javasript es un poco extraña. Todos conocemos los problemas al agregar una matriz y un objeto y otros chistes.
Javascript es multi-paradigma. Ahora es un sistema particularmente urgente cuando el ecosistema es muy grande:
- todos escriben en diferentes estilos: alguien escribe estructuralmente, alguien escribe funcionalmente, diferentes desarrolladores escriben de manera diferente;
- de diferentes paquetes, diferentes paradigmas cuando usa diferentes paquetes;
- hay mucha "diversión" con la programación funcional en Javasript: ha aparecido la biblioteca rambda y ahora nadie puede leer los programas escritos en esta biblioteca.
Todo esto tiene un gran impacto en el ecosistema, y ha crecido increíblemente. Los paquetes son incompatibles entre sí: alguien con promesas, alguien con sincronización / espera, alguien con devoluciones de llamada. ¡También escriben en diferentes paradigmas!
Esto hace que el proyecto sea difícil de mantener. Es difícil encontrar un error si no puede leer el código.

¿Qué es Web Assemly?

A los valientes de la Fundación Mozilla y a otras compañías se les ocurrió Web Assembly. ¿Qué es?

Esta es una máquina virtual integrada en el navegador que admite el formato binario.
Los programas binarios llegan allí, se ejecutan casi de forma nativa, es decir, el navegador no necesita analizar todos los "fideos" del código javascript cada vez.
Todos los navegadores han declarado soporte.
Como se trata de un código de bytes, puede escribir un compilador para cualquier idioma.
Cuatro navegadores principales ya vienen con soporte de Web Assembly.
Pronto estamos esperando soporte nativo en Go. Esta nueva arquitectura ya se ha agregado: GOARCH = wasm GOOS = js (pronto). Hasta ahora, según tengo entendido, no es funcional, pero hay una declaración de que definitivamente estará en Go.

¿Qué hacer ahora? Gopherjs

Si bien no tenemos soporte para Web Assembly, hay un transportador como GopherJS.

Ir código transpiles a Javascript puro.
– , ( Vanilla JS, ).
, Go, … – , .
, , : syscall, net- ( net/http-, , XMLHttpRequest). – , stdlib Go, .
Go, ( .) GopherJS .

GopherJS es muy fácil de obtener: este es un paquete Go normal. Hacemos que vaya, y tenemos el equipo de GopherJS para construir la aplicación:

Aquí hay un mundo tan pequeño ...

... un programa Go regular, un paquete fmt regular de la biblioteca estándar y Binding Js para llegar a la API del navegador. Println finalmente se convertirá en el registro de la consola y el navegador escribirá "¡Hola, Gophers!" Es así de simple: construimos GopherJS, lo ejecutamos en un navegador, ¡todo funciona!

¿Qué hay en este momento? Fijaciones

Hay carpetas para todos los frameworks js populares:

JQuery
Angular.js;
D3.js para graficar y trabajar con big data;
React.js;
VueJS;
incluso hay soporte para Electron (es decir, ahora podemos escribir aplicaciones de escritorio en Electron);
y lo más divertido es WebGL (podemos hacer aplicaciones gráficas completas, incluidos juegos con gráficos en 3D, música y todas las cosas buenas);
y muchos otros enlazadores a todos los marcos y bibliotecas javascript populares.

Marco de referencia

Ya existe un marco web especialmente desarrollado para GopherJS - Vecty. Este es un análogo completo de React.js, pero solo desarrollado en Go, con los detalles de GopherJS.
Hay bolsas de juegos (¡de repente!). Encontré dos de los más populares:
- Engo
- Ebiten

Demostraré un par de ejemplos de cómo se ve esto y qué puedes escribir en Go ahora:

O tal opción (no encontré un tirador 3D, pero tal vez lo sea):

¿Qué sugiero?

Ahora la industria front-end está en tal estado que todos los idiomas que lloraron desde Javascript antes de esto se apresurarán allí. Ahora todos serán compilados en Web Assemblies. ¿Qué necesitamos para ocupar un lugar digno allí como "gophers"?

Go ha dicho tradicionalmente que es un lenguaje de programación del sistema, y prácticamente no hay bibliotecas para trabajar con la interfaz de usuario. Algo está allí, pero está medio abandonado, medio no funcional.

¡Y aquí hay una buena oportunidad para crear bibliotecas de interfaz de usuario en Go que se ejecutarán en GopherJS! ¡Finalmente puedes escribir tu propio marco! Ha llegado el momento en que puedes escribir un marco, y será uno de los primeros y recibirá una adaptación temprana, y serás una estrella (si es un buen marco).

Puede adaptar muchos paquetes diferentes que ya están en el ecosistema Go a los detalles del navegador (por ejemplo, el motor de plantillas). Ya funcionarán, puede realizar enlaces convenientes para que pueda representar fácilmente el contenido directamente en el navegador. Además, puede crear, por ejemplo, un servicio que pueda representar lo mismo en el servidor y en la interfaz utilizando el mismo código: todo es lo que les gusta a los desarrolladores de front-end (solo ahora en Go).

¡Puedes escribir un juego! Solo por diversión ...

lo tengo.

Preguntas

Pregunta (en adelante - P): - ¿Escribo en Go o en Js?

AG: - Escribes rutinas, canales, estructuras, incrustaciones en Go - eso es todo ... Te suscribes al evento, pasas la función allí.

P: - ¿Es decir, escribo sobre las Js "desnudas"?

AG: - No, escribes como si estuvieras en Go y te conectas a la API del navegador (la API no ha cambiado al mismo tiempo). Puede escribir sus enlaces para que los mensajes lleguen al canal, es fácil.

P: - ¿Qué pasa con el móvil?

AG: Definitivamente vi: hay carpetas para el parche Cordova que lanza Js. En React Native, no lo sé; tal vez hay, tal vez no (no realmente interesado). El motor de juego N-go también es compatible con aplicaciones móviles, tanto iOs como Android.

A:- Pregunta sobre Web Assembly. Cada vez hay más lugares ocupados, a pesar de la estrechez, el "zipeo" ... ¿Podríamos matar al mundo front-end de esta manera aún más?

AG: - Web Assembly es un formato binario, y el binario por defecto no puede estar en la versión final más que el texto ... el tiempo de ejecución lo atrae, pero es lo mismo que la biblioteca Javascript estándar, cuando no está allí, así que usamos algunos Algún día lodash. No sé cuánto lleva Lodash.

P: - Explícitamente menos que el tiempo de ejecución ...

AG: - ¿En el Javascript "puro"?

P: Sí. Lo exprimimos antes de enviarlo ...

AG:- Pero este es el texto ... En general, los megabytes son muchos, pero eso es todo (tienes todo el tiempo de ejecución). Luego, escribe su lógica de negocios, que aumentará su binario en un 1%. Hasta que vea esto matar a la interfaz. Además, Web Assembly se ejecutará más rápido que Javascript por la razón obvia: no es necesario analizarlo.

P: - Hasta ahora, un momento controvertido ... Todavía no hay una implementación de referencia de "Vasma" (Web Assembly), por lo que puede juzgar claramente. Conceptualmente, sí: todos entendemos que el binario debería ser más rápido, pero la implementación actual del mismo V8 es muy efectiva.

AG: Sí.

P: - La compilación funciona muy bien allí y no es un hecho que habrá una gran ventaja.

AG: - Web Assembly también lo está haciendo muy bien.

A:- Hasta ahora, me parece, todavía es difícil juzgar Web Assembly. Se ha estado hablando durante muchos años, y hay pocos logros reales que se puedan sentir.

AG: - Quizás. Veremos.

P: - No tenemos problemas en el backend ... ¿Quizás dejar estos problemas en la interfaz? ¿Por qué escalar allí?

AG: - Tenemos que mantener al personal de primera línea.

Un poco de publicidad :)

Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más materiales interesantes? Apóyenos haciendo un pedido o recomendando a sus amigos, VPS en la nube para desarrolladores desde $ 4.99 , un análogo único de servidores de nivel básico que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2697 v3 (6 núcleos) 10GB DDR4 480GB SSD 1Gbps desde $ 19 o cómo dividir el servidor? (las opciones están disponibles con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).

Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo tenemos 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV desde $ 199 en los Países Bajos.Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $ 99! Lea sobre Cómo construir un edificio de infraestructura. clase c con servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?

Alexey Grachev: Ir Frontend