Kyiv Go Meetup Mayo 2018:
Presentador: – ¡Hola a todos! Gracias por estar aquí. Hoy tenemos dos ponentes oficiales – Alyosha y Vanya. Habrá otros dos, si tenemos tiempo. El primer ponente es Alexey Grachev, que nos hablará sobre GopherJS.
Alexey Grachev (en adelante – AG): – Soy desarrollador de Go y escribo servicios web en Go. A veces, tengo que lidiar con el frontend, y a veces tengo que meterme allí personalmente. Quiero compartir mi experiencia e investigaciones sobre Go en el frontend.
La leyenda es la siguiente: primero hablaremos de por qué queremos ejecutar Go en el frontend, luego veremos cómo se puede hacer. Hay dos enfoques – Web Assembly y GopherJS. Veremos en qué estado se encuentran estas soluciones y qué se puede hacer.
¿Qué pasa con el frontend?
¿Todos están de acuerdo en que todo está bien con el frontend?
¿Hay pocas pruebas? ¿Compilación lenta? ¿Ecosistema? Está bien.
Con respecto al frontend, me gusta una cita que dijo uno de los desarrolladores frontend en su libro:
En Javascript no hay un sistema de tipos. Ahora voy a mencionar los problemas con los que me he encontrado por el camino y explicar cómo se resuelven.
Difícilmente se puede llamar a esto un sistema de tipos en Javascript; hay cadenas que indican el tipo de objeto, pero en realidad no tienen nada que ver con los tipos. Este problema se resuelve en TypeScript (una capa sobre Javascript) y Flow (revisor estático de tipos en Javascript). De hecho, ya se ha avanzado en la resolución del problema de un mal sistema de tipos en Javascript.
No hay una biblioteca estándar en el navegador como tal; hay algunos objetos incorporados y funciones 'mágicas' en los navegadores. Pero en Javascript como tal, la biblioteca estándar está ausente. Este problema fue resuelto alguna vez por jQuery (todos usaban jQuery con todos sus prototipos, helpers, y funciones necesarias para el trabajo). Ahora todos usan Lodash:
Infierno de callbacks. Creo que todos han visto código en Javascript hace unos 5 años, y se parecía a un 'tallarín' de una increíble enredadera de callbacks. Ahora este problema se ha resuelto (con la llegada de ES-15 o ES-16); se añadieron promesas (promises) a Javascript y todos respiraron un poco más tranquilos durante un tiempo.
Hasta que llegó el infierno de las promesas... No sé cómo la industria del frontend se las arregla, pero siempre se meten en algunas extrañas encrucijadas. Lograron crear el infierno de las 'promesas'. Luego resolvieron este problema añadiendo un nuevo primitivo – async/await:
El problema de la asincronía está solucionado. Async/await es un primitivo bastante popular en diferentes lenguajes. En Python y en otros también hay un enfoque así, y es bastante bueno. El problema está resuelto.
¿Qué problema no está resuelto? La creciente complejidad de los frameworks en progresión geométrica, la complejidad del ecosistema y la programación en sí.
- La sintaxis de Javascript es un poco extraña. Todos conocemos los problemas con la suma de arrays y objetos y otros detalles interesantes.
- Javascript es multiparadigma. Actualmente es un sistema especialmente relevante, ya que el ecosistema es muy grande:
- todos escriben de diferentes maneras: algunos escriben de forma estructurada, otros de manera funcional, diferentes desarrolladores escriben de manera diferente;
- de diferentes paquetes (packages) hay diferentes paradigmas, cuando utilizas diferentes paquetes;
- hay mucha 'diversión' con la programación funcional en Javascript: apareció la biblioteca Ramda y ahora nadie puede entender programas escritos con esta biblioteca.
- Todo esto tiene un gran impacto en el ecosistema, y ha crecido increíblemente. Los paquetes son incompatibles entre sí: algunos usan promesas, otros async/await, otros callbacks. ¡También se escribe en diferentes paradigmas!
- Esto lleva a que el proyecto sea difícil de mantener. Es complicado encontrar un bug si no puedes leer el código.
¿Qué es Web Assembly?
Los valientes de la Mozilla Foundation y varias otras compañías han ideado algo llamado Web Assembly. ¿Qué es?
- Es una máquina virtual integrada en el navegador que soporta un formato binario.
- Los programas binarios llegan allí y se ejecutan prácticamente de forma nativa, es decir, el navegador no necesita parsear cada vez todo el 'espagueti' del código javascript.
- Todos los navegadores han declarado su soporte.
- Dado que es bytecode, se puede escribir un compilador para cualquier lenguaje.
- Los cuatro principales navegadores ya vienen con soporte para Web Assembly.
- Pronto esperamos soporte nativo en Go. Una nueva arquitectura ya se ha añadido: GOARCH=wasm GOOS=js (pronto). Hasta ahora, según entiendo, no es funcional, pero hay declaración de que definitivamente estará en Go.
¿Qué hacer ahora? GopherJS
Mientras no tengamos soporte para Web Assembly, hay un transpiler llamado GopherJS.
- El código en Go se transpila a Javascript 'limpio'.
- Se ejecuta en todos los navegadores: no hay nuevas características que solo están soportadas por navegadores modernos (esto es Vanilla JS, que se ejecuta en cualquier cosa).
- Hay soporte para casi todo lo que existe en Go, incluidas las gorutinas y los canales... todo lo que amamos y conocemos.
- Casi toda la biblioteca estándar es compatible, excepto aquellos paquetes que no tienen sentido soportar en el navegador: syscall, interacciones de red (hay un cliente net/http, pero no hay servidor, y el cliente se emula a través de XMLHttpRequest). En general, toda la biblioteca estándar está disponible: aquí está en el navegador, aquí está la stdlib Go que tanto queremos.
- Todo el ecosistema del paquete en Go, todas las soluciones de terceros (templatización y demás) se pueden compilar usando GopherJS y ejecutar en el navegador.
Obtener GopherJS es muy fácil: es un paquete común de Go. Hacemos go get y tenemos el comando GopherJS para construir la aplicación:
Aquí hay un pequeño hello world...
...Una aplicación Go común, el paquete fmt de la biblioteca estándar y Binding Js, para acceder a la API del navegador. Println se transformará en un registro de consola y el navegador mostrará “¡Hola gophers”! Así de simple: hacemos GopherJS build, lo ejecutamos en el navegador y ¡todo funciona!
¿Qué hay en este momento? Bindings
Hay bindings para todos los frameworks de js populares:
- JQuery;
- Angular.js;
- D3.js para crear gráficos y trabajar con grandes datos;
- React.js;
- VueJS;
- incluso hay soporte para Electron (es decir, ya podemos escribir aplicaciones de escritorio en ‘Electron’);
- y lo más divertido es WebGL (podemos hacer aplicaciones poligonales, incluyendo juegos con gráficos 3D, música y todos los extras);
- y muchos otros bindings para todos los frameworks y bibliotecas de javascript populares.
Framework
- Ya existe un framework web desarrollado específicamente para GopherJS: Vecty. Es un análogo completo de React.js, pero diseñado en Go, con las especificaciones de GopherJS.
- Hay motores de juego (sorpresivamente). Encontré los dos más populares:
- Engo;
- Ebiten.
Voy a mostrar un par de ejemplos de cómo se ve esto y qué se puede escribir ahora en Go:
O esta opción (no encontré un shooter 3D, pero quizás exista):
¿Qué propongo?
Ahora la industria del frontend está en un estado en el que todos los lenguajes que antes se quejaban de Javascript van a unirse. Ahora todos se compilarán en ‘Web Assembly’. ¿Qué necesitamos para ocupar un lugar digno allí como ‘gophers’?
En Go, tradicionalmente se considera que es un lenguaje de programación de sistemas, y prácticamente no hay bibliotecas para trabajar con la interfaz de usuario. Hay algo, pero está medio abandonado y medio no funcional.
Y aquí viene una buena oportunidad para crear bibliotecas de interfaz de usuario en Go que se ejecuten en GopherJS. ¡Finalmente, se puede escribir un marco propio! Ha llegado el momento de crear un marco que será uno de los primeros en recibir adopción temprana y te convertirá en una estrella (si es un buen marco).
Se pueden adaptar muchos paquetes diferentes que ya existen en el ecosistema de Go a las especificaciones del navegador (por ejemplo, motores de plantillas). Ya funcionarán, se pueden hacer envolturas convenientes para poder renderizar contenido directamente en el navegador. Además, se puede hacer, por ejemplo, un servicio que pueda renderizar lo mismo en el servidor y en el frontend, usando el mismo código, como a los desarrolladores frontend les gusta (solo que ahora en Go).
¡Se puede escribir un videojuego! Solo por diversión...
Eso es todo.
Preguntas
Pregunta (en adelante - P): – ¿Escribo en Go o en Js?
AG: – Escribes en Go rutinas, canales, estructuras, embedding – todo… Te suscribes a un evento, pasas allí una función.
Q: – ¿Es decir que escribo en «puro» Js?
AG: – No, escribes como si fuera en Go y te conectas a la API del navegador (la API no ha cambiado). Puedes escribir tus envolturas para que los mensajes lleguen al canal – no es difícil.
Q: – ¿Y qué pasa con lo móvil?
AG: – He visto: hay bindings para el parche Cordova que ejecuta Js. En React Native – no lo sé; puede que haya, o puede que no (no me he interesado mucho). El motor de videojuegos N-go admite aplicaciones móviles – tanto iOS como Android.
Q: – Pregunta sobre Web Assembly. El espacio está ocupando cada vez más, a pesar de la compresión, el "zipping"... ¿No arruinaremos así aún más el mundo del frontend?
AG: – Web Assembly es un formato binario, y un binario por defecto no puede ser más grande que texto en la versión final... Te atrae el runtime, pero es lo mismo que tirar de la biblioteca estándar de Javascript cuando no está, así que usamos alguna Lodash. No sé cuánto ocupa Lodash.
Q: Claramente menos que el runtime...
AG: – ¿En Javascript "puro"?
Q: – Sí. Lo comprimimos antes de enviarlo...
AG: – Pero esto es texto... En general, un megabyte parece mucho, pero eso es todo (tienes todo el runtime). Luego, escribes tu lógica de negocio, que incrementará tu binario en un 1%. Hasta ahora no veo que esto mate el frontend. Además, Web Assembly funcionará más rápido que Javascript por una razón obvia: no necesita ser analizado.
Q: – Es un tema discutible... Aún no hay una implementación estándar de 'Wasmer' (Web Assembly) para poder juzgar de manera definitiva. Conceptualmente, sí: todos entendemos que el binario debería ser más rápido, pero la implementación actual de V8 es muy eficiente.
AG: – Sí.
Q: – La compilación allí realmente funciona muy bien y no está claro que haya una gran ventaja.
AG: – También hay grandes jugadores detrás de Web Assembly.
Q: – Hasta ahora, me parece que aún es difícil juzgar Web Assembly. Han pasado años hablando de esto, y hay pocos logros tangibles.
AG: – Tal vez. Tendremos que esperar y ver.
Q: – No tenemos problemas en el backend... ¿Podríamos dejar esos problemas en el frontend? ¿Por qué meterse allí?
AG: – Hay que mantener un equipo de frontenders.
Un poco de publicidad 🙂
Gracias por permanecer con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendando a tus conocidos, , un análogo único de servidores entry-level que hemos diseñado para Ti: (disponibles opciones con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
¿Dell R730xd a mitad de precio en el centro de datos Equinix Tier IV en Ámsterdam? Solo aquí ¡en los Países Bajos! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ¡desde $99! Lee sobre cómo
Fuente: habr.com
