Reunión de Kyiv Go, mayo de 2018:
Moderador: - ¡Hola a todos! ¡Gracias por estar aquí! Hoy tenemos dos oradores oficiales: Lyosha y Vanya. Habrá dos más si tenemos tiempo. El primer ponente es Alexey Grachev, nos hablará de GopherJS.
Alexey Grachev (en adelante - AG): – Soy desarrollador de Go y escribo servicios web en Go. A veces tienes que lidiar con la parte delantera, a veces tienes que escalar allí con manijas. Quiero hablar sobre mi experiencia e investigación sobre Go en la interfaz.
La leyenda es esta: primero hablaremos sobre por qué queremos ejecutar Go en la interfaz, luego hablaremos sobre cómo podemos hacerlo. Hay dos formas: Web Assembly y GopherJS. Veamos en qué estado se encuentran estas decisiones y qué se puede hacer.
¿Qué tiene de malo la interfaz?
¿Todos están de acuerdo en que todo está bien con la interfaz?
¿Pocas pruebas? ¿Construcción lenta? ¿Ecosistema? Bien.
Con respecto al front-end, me gusta una cita que uno de los desarrolladores de front-end dijo en su libro:
Javascript no tiene un sistema de tipos. Ahora nombraré los problemas que encontré en el curso de mi trabajo y explicaré cómo se resuelven.
El sistema de tipos es generalmente difícil de llamar un sistema de tipos en Javascript: hay líneas que indican el tipo de un objeto, pero de hecho esto no tiene nada que ver con los tipos. Este problema se resuelve en TypeScript (complemento de Javascript) y Flow (comprobador estático de tipos de Javascript). De hecho, la interfaz ya ha ido tan lejos como para resolver el problema de un sistema de tipo 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 ya ha sido resuelto por jQuery (todos usaban jQuery con todos los prototipos, ayudantes, funciones que necesitaban para funcionar). Ahora todos usan Lodash:
infierno de devolución de llamada. Creo que todos vieron el código Javascript hace unos 5 años, y parecía un "fideo" de una increíble complejidad de devoluciones de llamada. Ahora este problema está resuelto (con el lanzamiento de ES-15 o ES-16), se agregaron promesas a Javascript y todos comenzaron a respirar más tranquilos por un tiempo.
Hasta que llegó el infierno de Promice... No sé cómo se las arregla la industria del front-end, pero siempre se adentran en una jungla extraña. También logramos hacer un infierno en "promesas". Luego resolvimos este problema agregando una nueva primitiva - async / await:
Con la asincronía, el problema está resuelto. Async/await es una primitiva bastante popular en diferentes idiomas. Python y otros tienen este enfoque: es lo suficientemente bueno. Problema resuelto.
¿Qué problema no se resuelve? La complejidad exponencialmente creciente de los marcos, la complejidad del ecosistema y los programas mismos.
- La sintaxis de Javascript es un poco rara. Todos conocemos los problemas de agregar una matriz y un objeto y otros trucos.
- Javascript es multi-paradigma. Ahora bien, este es un sistema particularmente apremiante 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 (paquetes) diferentes paradigmas cuando usa diferentes paquetes;
- mucha "diversión" con la programación funcional en Javascript: apareció 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í: algunos están en promesas, algunos están en asíncrono/espera, algunos están en 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 el ensamblaje web?
Los valientes muchachos de la Fundación Mozilla y varias otras compañías idearon algo como Web Assembly. ¿Qué es esto?
- 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.
- Los cuatro navegadores principales ya se envían con compatibilidad con Web Assembly.
- Esperamos soporte nativo en Go pronto. Esta nueva arquitectura ya se ha agregado: GOARCH=wasm GOOS=js (próximamente). 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 compatibilidad con Web Assembly, hay un transpilador como GopherJS.
- El código de Go se transpila a Javascript "puro".
- Se ejecuta en todos los navegadores: no hay funciones nuevas que solo sean compatibles con los navegadores modernos (esto es Vanilla JS, que se ejecuta en cualquier cosa).
- Hay soporte para casi todo lo que está en Go, incluidas las rutinas y los canales... todo lo que amamos y conocemos tanto.
- Se admite casi toda la biblioteca estándar, con la excepción de aquellos paquetes que no tiene sentido admitir en el navegador: syscall, interacciones de red (hay un cliente net / http, pero no un servidor, y el cliente se emula a través de XMLHttpRequest) . En general, la biblioteca estándar completa está disponible: aquí está en el navegador, aquí está Go stdlib que amamos.
- Todo el ecosistema de paquetes en Go, todas las soluciones de terceros (plantillas, etc.) se pueden compilar con GopherJS y ejecutar en el navegador.
Obtener GopherJS es muy fácil: es solo un paquete Go normal. Hacemos un go get y tenemos un comando GopherJS para construir la aplicación:
Aquí hay un hola 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 topos". Es muy simple: creamos GopherJS, lo lanzamos en el navegador, ¡todo funciona!
¿Qué hay en este momento? Encuadernaciones
Hay enlaces para todos los marcos js populares:
- jquery;
- Angular.js
- D3.js para trazar y trabajar con big data;
- Reaccionar.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 full-graphic, incluyendo juegos con gráficos 3D, música y todo lo bueno);
- y muchos otros enlaces a todos los marcos y bibliotecas populares de javascript.
Marco conceptual
- Ya existe un marco web desarrollado específicamente para GopherJS - Vecty. Este es un análogo completo de React.js, pero solo desarrollado en Go, con las especificaciones de GopherJS.
- Hay bolsas de juego (¡de repente!). Encontré dos de los más populares:
- engó;
- Ebiten.
Demostraré un par de ejemplos de cómo se ve y lo que ya se puede escribir en Go:
O esta opción (no encontré un tirador 3D, pero tal vez exista):
¿Qué sugiero?
Ahora, la industria del front-end está en tal estado que todos los lenguajes que antes gritaban desde Javascript se precipitarán allí. Ahora todo se compilará en "ensamblajes web". ¿Qué necesitamos para ocupar un lugar digno allí como "tuzas"?
En Go, tradicionalmente se ha dicho que es un lenguaje de programación del sistema, y prácticamente no hay bibliotecas para trabajar con la interfaz de usuario. Hay algo, pero está medio abandonado, medio no funcional.
Y ahora, ¡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 puede escribir un marco, y será uno de los primeros y se adoptará temprano, y será una estrella (si es un buen marco).
Puede adaptar muchos paquetes diferentes que ya existen en el ecosistema de Go a las especificaciones 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 el front-end, usando el mismo código: todo lo que les gusta a los desarrolladores de front-end (solo ahora en Go).
¡Puedes escribir un juego! Solo por diversión…
Lo tengo todo
preguntas
Pregunta (en lo sucesivo, Q): – ¿Estoy escribiendo en Go o Js?
AG: – Escribes rutinas, canales, estructuras, incrustaciones – todo en Go… Te suscribes a un evento, pasas una función allí.
A: - Es decir, ¿escribo en los Js "desnudos"?
AG: - No, escribes como si estuvieras en Go y te conectas a la API del navegador (la API no ha cambiado). Puede escribir sus propios enlaces para que los mensajes lleguen al canal, no es difícil.
A: - ¿Qué pasa con el móvil?
AG: - Lo vi seguro: hay carpetas para el parche Cordova que lanza Js. En React Native, no lo sé; tal vez lo haya, tal vez no (no particularmente interesado). El motor de juego N-go es compatible con ambas aplicaciones móviles, tanto iOs como Android.
A: – Una pregunta sobre Web Assembly. Cada vez se van ocupando más lugares, a pesar de la concisión, “zipping”… ¿No mataremos aún más el mundo del frontend de esta forma?
AG: - Web Assembly es un formato binario, y el binario predeterminado no puede ser más grande que el texto en la versión final... El tiempo de ejecución lo extrae, pero esto es lo mismo que extraer la biblioteca estándar de Javascript cuando no está allí, por lo que Usa un poco de Lodash. No sé cuánto tarda Lodash.
A: - Obviamente menos tiempo de ejecución ...
AG: - ¿En Javascript "puro"?
A: - Sí. Lo comprimimos antes de enviarlo...
AG: - Pero esto es texto... En general, un megabyte es como mucho, pero eso es todo (tienes todo el tiempo de ejecución). Luego, escribe su propia lógica comercial que aumentará su binario en un 1%. Hasta ahora no lo veo matando la interfaz. Además, Web Assembly funcionará más rápido que Javascript por la razón obvia: no es necesario analizarlo.
A: - Hasta ahora, un punto controvertido ... Todavía no hay una implementación de referencia de "Wasma" (Web Assembly), por lo que uno puede juzgar sin ambigüedades. Conceptualmente sí: todos entendemos que el binario debería ser más rápido, pero la implementación actual del mismo V8 es muy eficiente.
AG: - Sí.
A: - La compilación allí funciona realmente muy bien y no es un hecho que haya una gran ventaja.
AG: - El ensamblaje web también lo hacen los grandes.
A: - Hasta ahora, me parece, todavía es difícil juzgar a Web Assembly. Durante muchos años ha habido conversaciones, pero son pocos los logros reales que se pueden sentir.
AG: - Tal vez. Ya veremos.
A: – No tenemos problemas en el backend… ¿Quizás deberíamos dejar estos problemas en el frontend? ¿Por qué ir allí?
AG: - Tenemos que mantener el personal de primera línea.
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible 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 aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com