Han pasado unos 18 meses desde el lanzamiento interno de Deno, se ha publicado un lanzamiento preliminar, han aparecido varios artículos sobre Habré y Ryan va a conferencias y habla sobre él. Sin embargo, nunca he visto un análisis reflexivo de este proyecto en ninguna parte, por alguna razón, todos están limitados a traducir la documentación ...
Bueno, intentemos hacerlo ahora. Durante los últimos 5 años he estado escribiendo en Node.JS, y la compañía OneTwoTrip, donde estoy trabajando ahora, ha estado escribiendo proyectos en el nodo durante aproximadamente 9 años (sí, escribí la historia aproximadamente 9 años en un monolito en el nodo ). Entonces el análisis debería ser bueno. Además, ya le dije en el Nodo de Moscú. JS Meetup 10 , y fue interesante. Por cierto, si es más conveniente para usted escuchar, no leer, entonces puede escuchar y mirar aquí . Mi segundo discurso, soy un tipo con una camisa rosa.
Por extraño que parezca, para comprender de dónde vino el proyecto y por qué, es necesario caer en el pasado. Así que arrojamos un poco de plutonio, levantamos las puertas de nuestro delorean y nos embarcamos en un viaje: mira los 10 años importantes que hicieron de Node.JS lo que vemos ahora.
Adelante al pasado
2009
Ryan Dahl anuncia Node.JS, aquí está, la primera presentación en JSConf 2009.
2010
Expreso, aparece socket.io: los ladrillos principales en este momento son casi cualquier servicio.
¡Hay personas locas que realmente escriben código de servidor en esto!
2011
Los grandes comienzan a coquetear con Node.JS, incluidos Uber y Linkedin.
Lanzamiento de Npm 1.0.
El nodo comienza a funcionar en Windows.
2012
Ryan se aleja del desarrollo de Node.JS. Recuerda Era 2012 Así que Ryan es ciertamente el creador, y ha hecho mucho por el ecosistema, pero los siguientes 7 años pasaron sin su participación.
2013
Nodo en Paypal, Walmart, eBay.
Aparece Koa: ¿recuerda cuántas copias se rompieron sobre los generadores?
2014
Nodo en Netflix. Los intentos están comenzando a formalizar el proyecto en algo más maduro, con un modelo abierto para administrar una junta asesora. Hay un estancamiento técnico que conduce a la bifurcación de io.js.
2015
Trabaja en los errores. La fusión de io.js y Node en éxtasis bajo los auspicios de Node Foundation y el lanzamiento de Node 4. Debo decir que esta es la versión que considero la primera en la que realmente fue posible desarrollar algo. Si alguien escribió en las versiones 0.xx, entonces recuerda sobre var, callback hell, un montón de bibliotecas diferentes para simplificar el trabajo asincrónico (como step y async. Sí, async no solo es async, sino también una biblioteca npm).
2016
El incidente con el panel izquierdo, que sigue siendo malas lenguas, recuerda el ecosistema. Cuántos artículos y ataques. Bueno, los que odian odiarán. Sin embargo, se han aprendido lecciones importantes de esto.
2017
Año de avance. No mencionaré todas las versiones del nodo y el aumento en el número de instalaciones de módulos con npm, sin embargo, este año el número de servicios en Node.JS superó los 8 millones, y el número de instalaciones fue de 3 mil millones por semana. Figuras absolutamente cósmicas que son difíciles de imaginar.
La N-API también apareció, y Node.JS se bifurcó nuevamente en Ayo.js. Una historia muy divertida e instructiva sobre SJW: vale la pena escribir un artículo por separado, por lo que no me detendré en ello, solo recomiendo leerlo cuando lo desee. Solo para el prospoiler que el tenedor murió con seguridad.
2018
La segunda histeria masiva desde la izquierda, ahora sobre cómo el flujo de eventos roba bitcoins. Cientos de publicaciones sobre inseguridad del ecosistema. Publicaciones de fantasía sobre cómo los paquetes npm roban información de la tarjeta de crédito. La comunidad está rociando barro como una manguera. Debo decir que fue muy útil, y también se sacaron conclusiones sobre ellos un poco más tarde.
Además, Ryan explota de repente las publicaciones de la comunidad sobre el hecho de que vale la pena escribir sobre servicios serios en Go, describe 10 cosas en Node de las que se arrepiente y anuncia a Deno, quien resuelve todos los problemas.
2019
Deno va a la versión de vista previa, aparecen un montón de artículos en el centro y ahora está leyendo uno de ellos.
Volver al presente
Espero que después de esta gira haya quedado más claro qué tipo de puntos dolorosos tenía el ecosistema y cómo se desarrolló. Teniendo este contexto, es mucho más fácil entender lo que está sucediendo ahora.
10 cosas que Ryan Dahl lamenta de Node.JS
Desafortunadamente, no encontré de improviso el artículo con la traducción del informe, por lo que los enumeraré aquí brevemente y aquí comentaré.
- Falta de apoyo a las promesas al comienzo del viaje . Sí, hubiera sido más simple si Ryan no hubiera cortado las promesas, considerándolas una complicación adicional que no despegó al comienzo del desarrollo del nodo. El tiempo perdido para todo este infierno de devolución de llamada es ciertamente una pena, pero en 2019, todas las bibliotecas sensatas tienen promesas como interfaz principal. Además, incluso las bibliotecas del sistema finalmente ofrecen promesas.
- Seguridad de llamadas al sistema y llamadas de red. Por un lado, sí, es bueno cuando todo está seguro. Por otro lado, no está claro cómo a este respecto el nodo resultó ser peor que cualquier otro medio ...
- Construye módulos nativos usando GYP. Sí, probablemente fue superfluo, pero quién podría saber que el cromo la dejaría. De nuevo, si el cromo se ha ido, entonces podemos irnos también ...
- Excesivo package.json. NPM como registro de monopolio. El argumento sobre package.json es un poco extraño. Por ejemplo, Ryan dice que hay basura allí como una licencia. Pero si no estuviera allí, ¿cómo podría averiguar rápidamente las licencias de los módulos utilizados en su proyecto? El argumento sobre NPM es más como la verdad, pero nos detendremos en esto con más detalle más adelante.
- Módulos de nodos. La resolución compleja de dependencias no funciona como en un navegador. Si, eso es correcto. Las dependencias estables comenzaron a ponerse sin ningún milagro solo en la versión 4-5 de npm. Pero el mecanismo funciona y le permite hacer cosas increíbles, por el momento está bien. En cuanto a la compatibilidad con el navegador, no importa lo que haga, todavía habrá etapas de procesamiento del código, como compilar y recopilar paquetes. Por lo tanto, es poco probable que los módulos de nodo tengan algún significado en este contexto.
- Exigir sin extensión y su incertidumbre . Sí, probablemente mal. Pero no lo suficiente como para mencionarlo ...
- index.js como complicación innecesaria. También punto demasiado trivial y aburrido para describir.
Por cierto, ten en cuenta que dije que Ryan lamenta 10 cosas, pero solo 7 puntos. Esto no es un error, revisé su informe varias veces y las revisiones del informe. O era una broma complicada sobre el tema del procesamiento de valores numéricos, o Ryan era demasiado tímido para nombrar 3 puntos más ...
Pero está bien, entendimos los problemas y seguimos adelante. Lógicamente, en Deno, Ryan decidió deshacerse de todos los problemas de Node.JS. Veamos que le pasó.
En que consiste Deno
- Deno está escrito en Rust.
- Como un bucle de eventos, Deno usa Tokio, escrito nuevamente en Rust.
- Deno es compatible con Typecript fuera de la caja.
- Bueno, el código se ejecuta utilizando el mismo V8, que capturó todo el mundo.
A primera vista, suena bien, pero echemos un vistazo más de cerca a estos puntos.
Óxido . No, por favor, entiéndeme correctamente. Creo que Rust and Go son idiomas maravillosos, y estoy sinceramente contento de que lo sean. Permiten escribir código de bajo nivel más rápido y seguro que en C ++. Sin embargo, hay un matiz: en el mejor de los casos, no será más lento que la implementación en C ++. Por lo tanto, personalmente no veo el punto de escribir un análogo completo de los filamentos del sistema y un bucle de eventos; es poco probable que traiga algún beneficio real, ya que estas son cosas que en algún momento simplemente alcanzan el estado óptimo y en realidad no se optimizan aún más.
TypeScript De nuevo, no tengo nada contra TS. Un gran número de empresas y desarrolladores lo usan, y ya ha demostrado su valía. Pero Deno simplemente oculta el transpilador en el binario y el código transpilado en directorios especiales. Es decir, todo es igual bajo el capó, y no hay ningún beneficio en esto, excepto por la estética. Pero hay una desventaja: la versión del transpilador está muy ajustada a la versión de Deno. No estoy seguro de que esto sea bueno; es fácil imaginar una situación en la que desee actualizar el transpiler o el tiempo de ejecución. Pero no ambos a la vez.
Entonces, mientras nada sabroso es visible. Vayamos más lejos, miremos las características principales.
Las principales diferencias entre Deno y Node.JS
Deno no usa npm. No hay registro central. Los módulos se importan por URL. No package.json.
Es decir, el código se ve así:
import { test, runIfMain } from "https://deno.land/std/testing/mod.ts";
import { assertEquals } from "https://deno.land/std/testing/asserts.ts";
test(function t1() {
assertEquals("hello", "hello");
});
, . . , . :
- . , , . . , :
1.1. , , .
1.2. , , , .
1.3. , . 2012 , npm , ? , " "? - , . github, gitlab, , . . . npm , , — , ? — . Entropic, , , — .
. , - ( ) — … … 2019? , , 2012 Node.JS shrinkwrap, lock file? , ?
, URL — , — .
Deno Promise.
, . 2012 — . . - .
Deno Uncaught Errors
. Node.JS . .
ES Modules, require
, , . , Node.JS ES Modules...
Deno , .
! … — allow-read, allow-net, allow-run, allow-env. - :
deno --allow-read=/etc https://deno.land/std/examples/cat.ts /etc/passwd
:
- .
- , --allow-all.
- . . , , . . , — .
- . , , . . , 2019 2012, — ...
. . NPM.
, npm 2012 :
- . .
- Lock file .
- . github, snyk npm.
- .
- .
- — , , .
- .
npm … , . , , … " ", — facebook, google, microsoft, gitlab… , npm .
:
- Rust — .
- TypeScript — .
- URL NPM — .
- — .
- . . . !
Deno. " , " — , , Deno — .
, , , , . Deno , , Moscow Node.JS Meetup — . — , - ?