2 pi�ce(s) jointe(s)
Le runtime pour ex�cuter JavaScript et TypeScript en dehors du navigateur Web Deno passe en version 1.0
Deno passe en version 1.0. Le runtime pour ex�cuter JavaScript et TypeScript,
tente de fournir un outil autonome pour l'�criture rapide de fonctionnalit�s complexes
Les langages dynamiques sont des outils utiles. Les scripts permettent aux utilisateurs de lier rapidement et succinctement des syst�mes complexes et d'exprimer des id�es sans se soucier de d�tails tels que la gestion de la m�moire ou les builds syst�mes. Ces derni�res ann�es, des langages de programmation comme Rust et Go ont rendu beaucoup plus facile la production de code machine natif sophistiqu�; ces projets sont des d�veloppements incroyablement importants dans l'infrastructure informatique.
Mais pour les ing�nieurs Ryan Dahl, Bert Belder et Bartek Iwańczuk cependant, il est toujours important d'avoir un environnement de script puissant qui peut traiter un large �ventail de domaines probl�matiques.
JavaScript est le langage dynamique le plus utilis�, fonctionnant sur tous les appareils dot�s d'un navigateur Web. Un grand nombre de d�veloppeurs � parlent � couramment le JavaScript et beaucoup d'efforts ont �t� d�ploy�s pour optimiser son ex�cution. Gr�ce � des organismes de normalisation comme ECMA International, le langage a �t� soigneusement et continuellement am�lior�.
Aussi, les ing�nieurs Ryan Dahl, Bert Belder et Bartek Iwańczuk pensent que JavaScript est le choix naturel pour l'outillage de langage dynamique; que ce soit dans un environnement de navigateur ou en tant que processus autonomes.
� Notre vecteur d'origine dans ce domaine, Node.js, s'est av�r� �tre une plateforme logicielle tr�s r�ussie. Les gens l'ont trouv� utile pour cr�er des outils de d�veloppement Web, cr�er des serveurs Web autonomes et pour une myriade d'autres cas d'utilisation. Node, cependant, a �t� con�u en 2009 lorsque JavaScript �tait un langage tr�s diff�rent. Par n�cessit�, Node a d� inventer des concepts qui ont ensuite �t� repris par les organismes de normalisation et ajout�s au langage diff�remment. Dans la pr�sentation Erreurs de conception dans Node, ceci est discut� plus en d�tail. En raison du grand nombre d'utilisateurs de Node, il est difficile et lent de faire �voluer le syst�me.
� Avec l'�volution du langage JavaScript et de nouveaux ajouts comme TypeScript, la cr�ation de projets Node peut devenir une t�che ardue, impliquant la gestion de syst�mes de g�n�ration et d'autres outils lourds qui enl�vent le plaisir des scripts de langage dynamique. De plus, le m�canisme de liaison � des biblioth�ques externes est fondamentalement centralis� via le r�f�rentiel NPM, qui n'est pas conforme aux id�aux du Web.
� Nous pensons que le paysage de JavaScript et de l'infrastructure logicielle environnante a suffisamment chang� pour qu'il soit utile de le simplifier. Nous recherchons un environnement de script amusant et productif qui peut �tre utilis� pour un large �ventail de t�ches �.
Vient alors Deno 1.0
Deno est un nouveau runtime pour ex�cuter JavaScript et TypeScript en dehors du navigateur Web.
Deno tente de fournir un outil autonome pour l'�criture rapide de fonctionnalit�s complexes. Deno est un seul fichier ex�cutable. Comme un navigateur Web, il sait r�cup�rer du code externe. Dans Deno, un seul fichier peut d�finir un comportement arbitrairement complexe sans aucun autre outil.
Code:
1
2
3
4
| import { serve } from "https://deno.land/[email protected]/http/server.ts";
for await (const req of serve({ port: 8000 })) {
req.respond({ body: "Hello World\n" });
} |
Ici, un module serveur HTTP complet est ajout� en tant que d�pendance sur une seule ligne. Il n'y a pas de fichiers de configuration suppl�mentaires, il n'y a pas d'installation � faire au pr�alable, il suffit de faire deno run example.js.
Comme pour les navigateurs, le code est ex�cut� par d�faut dans un sandbox s�curis�. Les scripts ne peuvent pas acc�der au disque dur, ouvrir des connexions r�seau ou effectuer d'autres actions potentiellement malveillantes sans autorisation. Le navigateur fournit des API pour acc�der aux cam�ras et aux microphones, mais les utilisateurs doivent d'abord donner leur autorisation. Deno fournit un comportement analogue dans le terminal. L'exemple ci-dessus �chouera sauf si l'indicateur de ligne de commande --allow-net est fourni.
Deno veille � ne pas s'�carter des API JavaScript standardis�es du navigateur. Bien s�r, toutes les API de navigateur ne sont pas pertinentes pour Deno, mais pour celles dont c�est le cas, Deno ne s'�carte pas de la norme.
Prise en charge de TypeScript de premi�re classe
� Nous voulons que Deno soit applicable � un large �ventail de domaines probl�matiques: des petits scripts unifilaires � la logique m�tier complexe c�t� serveur �, indiquent les ing�nieurs. � mesure que les programmes deviennent plus complexes, il est de plus en plus important d'avoir une certaine forme de v�rification de type. TypeScript est une extension du langage JavaScript qui permet aux utilisateurs de fournir �ventuellement des informations de type.
Deno prend en charge TypeScript sans outils suppl�mentaires. Le runtime est con�u avec TypeScript � l'esprit. La commande deno types fournit des d�clarations de type pour tout ce qui est fourni par Deno. Les modules standard de Deno sont tous �crits en TypeScript.
Les Promises arrivent
Node a �t� con�u avant que JavaScript ne dispose du concept Promises ou async / await. L'�quivalent de Node aux Promises �tait l'EventEmitter, sur lequel reposent d'importantes API, � savoir les sockets et HTTP. Mis � part les avantages ergonomiques de async / await , le mod�le EventEmitter a un probl�me de contre-pression. Prenez un socket TCP, par exemple. Le socket �mettrait des �v�nements de � data � lorsqu'il recevait des paquets entrants. Ces callback � data � seraient �mis de mani�re non contrainte, inondant le processus d'�v�nements. �tant donn� que Node continue de recevoir de nouveaux �v�nements data, le socket TCP sous-jacent n'a pas de contre-pression appropri�e, l'exp�diteur distant n'ayant aucune id�e que le serveur est surcharg� et continuant d'envoyer des donn�es. Pour att�nuer ce probl�me, une m�thode pause() a �t� ajout�e. Cela pourrait r�soudre le probl�me, mais cela n�cessitait du code suppl�mentaire; et comme le probl�me d'inondation ne se pr�sente que lorsque le processus est tr�s charg�, de nombreux programmes Node peuvent �tre inond�s de donn�es. Le r�sultat est un syst�me avec une mauvaise latence de queue.
Dans Deno, les sockets sont toujours asynchrones, mais pour recevoir de nouvelles donn�es, les utilisateurs doivent explicitement utiliser read(). Aucune s�mantique de pause suppl�mentaire n'est n�cessaire pour structurer correctement un socket de r�ception. Ce n'est pas unique aux sockets TCP. La couche de liaison de niveau le plus bas du syst�me est fondamentalement li�e aux Promises (que les ing�nieurs appellent liaisons � ops �). Tous les callback Deno sous une forme ou une autre d�coulent de Promises.
Rust a sa propre abstraction Promises, appel�e Futures. Gr�ce � l'abstraction � op �, Deno facilite la liaison des Futures API de Rust aux promesses JavaScript.
API Rust
Le composant principal qui est propos� est l'interface de ligne de commande (CLI) Deno. La CLI est l��l�ment qui est en version 1.0 actuellement. Cependant, Deno n'est pas un programme monolithique, mais con�u comme une collection de crates Rust pour permettre l'int�gration � diff�rentes couches.
Le crate deno_core est une version tr�s d�nud�e de Deno. Il n'a pas de d�pendances sur TypeScript ni sur Tokio. Il fournit simplement une infrastructure op�rationnelle et de ressources. Autrement dit, il fournit un moyen organis� de lier les Futures de Rust aux Promises JavaScript. La CLI est bien s�r enti�rement construite sur deno_core.
Le crate rusty_v8 fournit des fixations Rust de haute qualit� � l'API C ++ de V8. L'API essaie de faire correspondre le plus �troitement possible l'API C ++ d'origine. C'est une liaison � co�t nul - les objets expos�s dans Rust sont exactement l'objet que vous manipulez en C ++. (Les tentatives pr�c�dentes de liaisons Rust V8 ont forc� l'utilisation de poign�es persistantes, par exemple.) Le crate fournit des binaires qui sont construits dans les actions Github CI, mais elle permet �galement aux utilisateurs de compiler V8 � partir de z�ro et d'ajuster ses nombreuses configurations de construction. Tout le code source V8 est distribu� dans le crate lui-m�me.
Enfin, rusty_v8 tente d'�tre une interface s�re. � Elle n'est pas encore s�re � 100%, mais nous nous en approchons. Pouvoir interagir avec une VM aussi complexe que V8 de mani�re s�re est assez �tonnant et nous a permis de d�couvrir de nombreux bogues difficiles dans Deno lui-m�me �.
Limites
Les ing�nieurs rappellent qu'il est important de comprendre que Deno n'est pas un fork de Node - c'est une impl�mentation compl�tement nouvelle. Deno est en cours de d�veloppement depuis seulement deux ans, tandis que Node est en cours de d�veloppement depuis plus d'une d�cennie. �tant donn� le montant de l'int�r�t pour Deno, ils pr�voient qu'il continuera d'�voluer et de m�rir.
� Pour certaines applications, Deno peut �tre un bon choix aujourd'hui, pour d'autres pas encore. Cela d�pendra des exigences. Nous voulons �tre transparents sur ces limitations pour aider les gens � prendre des d�cisions �clair�es lorsqu'ils envisagent d'utiliser Deno �.
Compatibilit�
Malheureusement, de nombreux utilisateurs trouveront un manque frustrant de compatibilit� avec les outils JavaScript existants. Deno n'est pas compatible, en g�n�ral, avec les packages Node (NPM). Une couche de compatibilit� naissante est en cours de cr�ation ici mais elle est loin d'�tre termin�e.
Bien que Deno ait adopt� une approche stricte pour simplifier le syst�me de modules, Deno et Node sont finalement des syst�mes assez similaires avec des objectifs similaires. Au fil du temps, les auteurs s'attendent � ce que Deno puisse ex�cuter de plus en plus de programmes Node pr�ts � l'emploi.
Performances du serveur HTTP
� Nous suivons en permanence les performances du serveur HTTP de Deno. Un serveur HTTP hello-world Deno fait environ 25 000 requ�tes par seconde avec une latence maximale de 1,3 milliseconde. Un programme Node comparable fait 34k requ�tes par seconde avec une latence max plut�t erratique entre 2 et 300 millisecondes.
� Le serveur HTTP de Deno est impl�ment� en TypeScript au-dessus des sockets TCP natifs. Le serveur HTTP de Node est �crit en C et expos� en tant que liaisons de haut niveau � JavaScript. Nous avons r�sist� � l'envie d'ajouter des liaisons de serveur HTTP natif � Deno, car nous voulons optimiser la couche socket TCP, et plus g�n�ralement l'interface op.
� Deno est un bon serveur asynchrone et 25 000 requ�tes par seconde sont largement suffisantes pour la plupart des applications. (Si ce n'est pas le cas, JavaScript n'est probablement pas le meilleur choix.) En outre, nous nous attendons � ce que Deno pr�sente g�n�ralement une meilleure latence de queue en raison de l'utilisation omnipr�sente des Promises. Cela dit, nous pensons qu'il y a plus de gains de performances � gagner dans le syst�me, et nous esp�rons y parvenir dans les prochaines versions �.
Source : Deno 1.0
Et vous ?
:fleche: Avez-vous d�j� entendu parler de Deno ?
:fleche: L'avez-vous d�j� utilis� ? Si oui, qu�en pensez-vous ? Si non, �tes-vous int�ress� ?
:fleche: Quelle utilit� pourriez-vous lui trouver ?
:fleche: Que pensez-vous des limites de Deno ?
