Ryan Dahl, el creador de Node.js. Su informe causó sensación, planteó muchos problemas urgentes y generó un gran revuelo, dejando a casi nadie que esté conectado con la programación del servidor indiferente. En su discusión sobre el backend, los programadores se dividieron en dos bandos: algunos defendieron Node.js, otros predijeron una muerte rápida para él.
Han pasado poco más de dos años desde el discurso de Ryan, y en TI esta es toda una era, durante la cual no todo puede cambiar, luego mucho. Recordemos este informe y tratemos de ver qué ha cambiado desde entonces, quién tenía razón.
Un poco sobre Node.js
Un día, cuando Ryan estaba subiendo fotos a Flickr , notó algo inusual: un indicador que mostraba gráficamente el proceso de subir fotos al servidor. Hoy en día es imposible sorprender a nadie con una barra de progreso, pero entonces tales interfaces aún no estaban muy extendidas y, por lo general, el usuario veía un gif con un reloj de arena banal que simplemente giraba y no daba ninguna información sobre el tiempo restante para la finalización de la operacion.
Luego pensó en el hecho de que un servidor web debería poder procesar varias tareas al mismo tiempo. En ese momento, Ryan estaba desarrollando un módulo para Nginx, donde todo funcionaba de forma asincrónica, y llegó a la conclusión de que la forma más eficiente de implementar un sistema impulsado por eventos, se convirtió en la plataforma Node.js.
Originalmente, el marco se llamaba web.js, pero sus usos resultaron ser mucho más amplios que los de un servidor web normal y, por lo tanto, la plataforma pasó a llamarse Node.js. Ryan presentó el proyecto terminado en JSConf 2009, y la actuación de 45 minutos recibió un aplauso:
El sistema ganó rápidamente aceptación y se volvió increíblemente popular. Además de la asincronía, Node tiene muchas otras ventajas, puede usarse como otra capa de abstracción sobre un backend existente y no reescribir el lado del servidor desde cero. La alta velocidad de trabajo y la buena escalabilidad hicieron posible construir sistemas de alta carga, por ejemplo, aplicaciones para la operación de cadenas de tiendas, que no bajan ni siquiera durante la temporada de ventas, cuando un tiempo de inactividad del sistema puede privar a una parte muy significativa de los ingresos anuales.
Hubo algunos problemas, en particular, no fue fácil encontrar desarrolladores con una formación adecuada. Las razones más comunes son: "¡¡¡ODIO NODE.JS !!! 1111oneone",derivan del hecho de que la aparente simplicidad del lenguaje atrae a programadores que no han realizado previamente desarrollo para servidores. La interfaz generalmente se escribió en JS, y allí se resuelven tareas completamente diferentes. Los desarrolladores de Java también enfrentaron problemas, porque tenían un prejuicio: "¡En un lenguaje llamado Java Script, puedo programar sin problemas!" Resultó que los programadores que trabajaban en la plataforma .Net hacen frente a la tarea de programar en JS bajo Node más fácilmente que otros. Además, en el momento del desarrollo de Node, los trabajadores de dotnet experimentaron algunas dificultades con la demanda, y los programadores de JS para el backend estaban bien pagados.
El propio Ryan, algún tiempo después de la finalización del desarrollo, alrededor de 2012-13, se interesó en el lenguaje Go y durante mucho tiempo se alejó de todo lo relacionado con Node.js, porque este lenguaje se adaptaba completamente a él en términos de capacidades y velocidad. y luego se interesó por las redes neuronales ...
Crítica a Node.js por parte de su creador
Aproximadamente seis meses antes de la conferencia JSConf 2018, Ryan Dahl decidió intentar trabajar con su creación, casi 10 años después de su creación. Esto no quiere decir que estuviera complacido con lo que vio. Sin duda, el proyecto se ha desarrollado mucho, pero durante el desarrollo de Node.js Ryan estaba demasiado obsesionado con resolver problemas de E / S, por lo que cometió algunos errores, que luego se convirtieron en problemas del sistema. Dado que la plataforma se ha vuelto extremadamente popular, ya era demasiado tarde para cambiar algo globalmente sin romper todas las dependencias y la compatibilidad.
Ryan ha sido muy crítico con todo el software en el pasado, no solo con Node.js. En 2011, organizó un pequeño evento de "odio de cinco minutos" en Google+. La red social en sí ha estado cerrada durante mucho tiempo, pero Internet lo recuerda todo. La traducción de sus palabras se puede leer aquí: Odio casi todo el software . Y un año antes de hablar en 2018, dijo que: "Para los servidores, no puedo imaginar otro idioma que no sea Go" . De cara al futuro, empezó a escribir en Go, el "asesino de node.js", pero luego cambió a Rust.
Por ello, el tono crítico de su discurso en 2018 no sorprendió a nadie, y la mirada fresca del creador de la plataforma volvió a plantear la relevancia de algunos problemas.
10 cosas de las que me arrepiento de Node.js
Recordemos los puntos principales que se consideraron en él, y luego comparemos con cómo están las cosas en este momento.
uno.
Falta de promesas que se abandonaron al principio del desarrollo.
2.
Problema de seguridad. Una aplicación Node.js obtiene acceso al disco local, la red y, en general, a todo el sistema a la vez.
3.
Un sistema de construcción complejo y obsoleto que todos han abandonado hace mucho tiempo.
cuatro.
Package.json innecesariamente engorroso.
cinco.
La semántica de la plataforma es incompatible con los navegadores
6.
Repositorio centralizado de módulos.
7.
El comando para conectar el módulo no requiere la indicación obligatoria del tipo de archivo, lo que puede generar confusión.
8.
El uso de index.js, por analogía con index.html, dificultaba la carga de módulos y ya no era necesario después de admitir package.json.
Es curioso que en las discusiones del discurso se mencionó repetidamente que la cantidad de arrepentimientos en el informe no se corresponde con la cantidad de arrepentimientos en el título, pero hay que tener en cuenta que Ryan estaba muy preocupado, estaba notablemente conmocionado. al comienzo del discurso. Además, señaló repetidamente en sus entrevistas que es un programador, no una persona de los medios, lamentó que cada una de sus publicaciones en el bloque “atraiga cientos de comentarios” y “ahora debemos ser más cuidadosos al expresar nuestra opinión”, porque la comunidad a menudo entiende que sus palabras son demasiado literales.
Anuncio Deno
Después de enumerar las desventajas de Node.js, Ryan presentó su propio proyecto de tiempo de ejecución JS en el servidor, enumerando secuencialmente sus ventajas sobre Node:
1.
Una caja de arena segura para ejecutar código, que otorga solo los privilegios necesarios.
2.
Uso simplificado de módulos, cargando por enlaces directos y almacenando en una caché local, que no se actualizará hasta que se dé un comando especial.
3.
Soporte completo de TypeScript.
cuatro.
El único archivo ejecutable sin enlaces innecesarios
5.
Deno te permite ejecutar código de forma nativa en diferentes lenguajes, dependiendo de cuál sea más conveniente para una tarea específica.
6.
La aplicación se bloquea por errores no detectados, las operaciones asincrónicas devolverán promesas, excelente compatibilidad con el navegador.
Además de lo anterior, Deno utilizará módulos ES, que en ese momento no eran compatibles con Node.
Qué ha cambiado en Node.js
El informe salió ambiguo, por lo que generó tanto revuelo en la comunidad. Por un lado, las declaraciones fueron correctas. Por otro lado, no todos son tan críticos como para dejar todo y escribir un nuevo entorno.
Quizás la mención más justa de preocupaciones de seguridad. Node.js no tiene una caja de arena que cierre el servidor desde la aplicación en ejecución. Este problema aún no se ha resuelto por completo. El acceso a la red se puede cerrar con un firewall, el acceso a un disco y otros permisos se pueden restringir al iniciar desde un contenedor, pero estas son soluciones de terceros que pueden no ser convenientes en todas partes.
Los problemas de ejecución de código asincrónico mencionados en el informe están más o menos resueltos por el momento. Por supuesto, hubiera sido mejor si Ryan no hubiera eliminado Promises en 2010, creyendo que eran demasiado complicadas, pero ahora muchas bibliotecas del sistema ya brindan esta funcionalidad, sin mencionar las de terceros. Ahora es posible ejecutar scripts en paralelo con los trabajadores, grandes empresas como Microsoft y Alibaba están desarrollando sus versiones de Node con multiproceso.
GYP nunca ha sido eliminado; este legado permanecerá con Node durante mucho tiempo. Los enlaces URL compatibles con el navegador están fuera de discusión, pero desde hace algún tiempo Node ha admitido módulos ES.
La resolución de dependencias es complicada y funciona de manera diferente que en un navegador, pero funciona, lo más importante, aunque no sin algunos problemas. Y la apariencia del mecanismo package-lock.json los minimiza.
La NPM ha evolucionado mucho desde 2012. Aunque, cabe señalar, la evolución fue dolorosa y fue empujada por problemas como la almohadilla izquierda que puso los dientes en el borde . Pero los paquetes ya no desaparecen, hay varios niveles de auditoría de seguridad y la capacidad de instalar paquetes de diferentes fuentes. Aunque hasta ahora nada impide que el desarrollador cargue el código correcto en github y el código con el exploit en npm.
El problema con index.js parece más artificial que real, al igual que la falta de extensiones al conectar módulos. Uno tiene la impresión de que se apresuró a presentar la mitad de los argumentos. Por cierto, estaba, con más detalle, al final del artículo.
Debe admitirse que casi todos estos problemas se han resuelto y con mucho éxito. El propio Dahl se alejó del desarrollo del proyecto, desde 2012 no tiene nada que ver con Node, y su informe parece bastante subjetivo, donde las deficiencias de la plataforma se exageran a favor de su propia creación. Por lo tanto, este discurso se parece más a un anuncio para su desarrollo, en lugar de exponer Node.js.
En aras de la justicia, debe tenerse en cuenta que el desarrollo activo de Node está fuertemente restringido por la empresa, en la que hay una cantidad tan grande de código heredado que es demasiado costoso deshacerse de él. Esto ha estado causando serios problemas durante mucho tiempo cuando Linux necesita ser actualizado, y todos los módulos no se pueden ensamblar para un nuevo sistema, y tarde o temprano tienes que reescribir una gran cantidad de código, gastando mucho tiempo y dinero en ello. Las grandes corporaciones pueden permitirse dedicar recursos a esto, pero un pequeño proyecto OpenSource para aficionados será abandonado si el desarrollador no tiene tiempo para actualizarlo.
Sin embargo, Node.js tiene una comunidad enorme y ayuda a los programadores a lidiar con muchos problemas, aunque a veces los desarrolladores no establecen prioridades de la manera que la comunidad quisiera y, por lo tanto, el proyecto avanza de manera desigual. Es posible que tarde o temprano Node finalmente se encuentre con las fallas originales que describió Ryan, y será imposible resolverlas. Pero esta no es la primera vez que TI necesita cambiar algo a nivel mundial. Por ejemplo, Flash fue enterrado con éxito sin muchos problemas.
Desarrollo Deno
Poco después de la charla, la comunidad descubrió rápidamente el anagrama Node-Deno. Incluso hubo bromas de que algún día se escribiría un proyecto llamado Done. Pero aparte de las bromas, ¿de dónde vino el desarrollo de Deno?
Durante la charla, Ryan dijo honestamente que Deno es actualmente un prototipo experimental y no se ofrece como alternativa a Node.
Pero desde entonces han pasado más de dos años, en la primavera del año pasado, finalmente, hubo un lanzamiento bajo el número 1.0.0.
Como se mencionó anteriormente, el proyecto comenzó en Go, pero luego se reconstruyó en Rust. Aunque el proyecto dejó de ralentizarse, como al principio, todavía no mostraba ventajas en cuanto a velocidad. Trabajar con TypeScript se volvió más rápido, debido a las optimizaciones realizadas por el equipo, porque en el momento de la presentación, el lanzamiento del traductor de TS tomó un segundo completo. Esto se resolvió, como sugirió Ryan en su informe de 2018, utilizando instantáneas del motor.
La plataforma es completamente incompatible con Node y fue concebida no como un reemplazo absoluto, sino como una alternativa, un proyecto de investigación, un experimento que impulsa a los desarrolladores a desarrollar otras formas de desarrollar tales soluciones.
Por el momento, Deno consta de las siguientes partes: un contenedor de TypeScript / Javascript, sobre el motor V8 , que es una caja de arena, que proporciona una interfaz entre la capa TS / JS y el Rust Backend (el backend que tiene acceso al sistema de archivos). El subproceso múltiple se proporciona usando Tokio , el tiempo de ejecución asincrónico de Rust responsable de crear y manejar eventos, usando las construcciones "Rust Future", que son análogas a "Promise" en JavaScript.
El entorno es intrínsecamente seguro, sin derechos de acceso de forma predeterminada. Para otorgar los privilegios necesarios, debe iniciar la plataforma con ciertas opciones de línea de comando. La solución es ambigua. Tarde o temprano, los desarrolladores pueden cansarse de escribir infinitas opciones en scripts, porque habrá muchas de ellas en proyectos grandes y “--allow-all” se lanzará por defecto.
Si es necesario, Deno le permite llamar a programas en el lenguaje que sea conveniente para realizar algunas tareas computacionales específicas.
***
Por el momento, la versión de lanzamiento ya se lanzó con el número 1.7. Pero todavía no escuchamos a ninguna gran empresa que abandone Node.js en favor de Deno. Incluso hicimos una imagen en el mercado para node.js.
El proyecto Deno se está desarrollando con entusiasmo, mientras que el propio Ryan ahora trabaja en Google y se dedica a establecer tareas para ingenieros involucrados en redes neuronales y aprendizaje profundo.
Alguien piensa que Dahl desarrolló el complejo del primer proyecto que se disparó cuando Node.js, completamente inesperado para Ryan, ganó reconocimiento casi de inmediato y ganó popularidad de manera muy marcada. Pero lo más probable es que sea una de esas personas que no puede sentarse sin nuevas ideas y tolerar las imperfecciones de su propia invención.
Aunque Dahl comenzó a trabajar en Deno mucho antes de hablar en la conferencia de 2018, el tema original para ella era muy diferente. Planeaba dar una charla sobre aprendizaje automático, lo que ha estado haciendo durante los últimos años. Pero no tuvo tiempo para prepararse y el tema de su discurso fue eliminado literalmente un par de días antes de la conferencia. Y como entendió su peso en la comunidad y cómo la audiencia esperaría que actuara, tuvo que trabajar muy duro en uno o dos días para encontrar un nuevo tema digno que cumpliera con las expectativas de la audiencia.
Entonces, tal vez ni siquiera tenía la intención de proclamar "el asesino de Node.js", sino que se apresuró a preparar un nuevo informe. Aunque logró generar bastante ruido, quizás mucho más que el tema del aprendizaje profundo.
