Nu am găsit alți dezvoltatori pe YouTube cu un canal de dimensiunea lui codedamn (100.000 de abonați) care nu sunt „super încântați” de lansarea lui Deno.

Săptămâna trecută, am lansat un videoclip pe canalul meu care indica câteva motive (care mi-au fost destul de clare) pentru care cred că nu avem nevoie de Deno – un alt mediu de rulare pentru JavaScript construit pe partea de sus a V8 și Node.

Cu un articol ca acesta, pot adăuga mai multe gânduri și le pot grupa într-un mod mai bun decât un videoclip. Dar oricum, dacă vă interesează, iată ce am postat:

Pentru a demonstra doar că nu sunt împotriva „Deno” și JavaScript în general, aș dori să spun ceva. Îmi place JavaScript mai mult decât orice. Stiva mea tehnică principală nu implică altceva decât JavaScript – Node / React / MongoDB / React Native / NativeScript / Ionic / tu îl numești.

Am construit un Canal YouTube de 100 de abonați și a platforma dezvoltatorului mai ales pe un singur limbaj de programare – JavaScript.

Dar, în același timp, este important să rămâi practic și să păstrezi un cap clar pentru a vedea ambele fețe ale monedei. Deno are o latură bună, precum și o latură despre care oamenii nu văd / scriu încă. Voi scrie părerile mele pe partea a doua. Sa mergem!

Notă: Acesta va fi un articol controversat. Să-l păstrăm civil și să ne controlăm emoțiile. Mi-ar plăcea dacă ați citi articolul complet până la sfârșit și poate apoi decideți ce credeți.

Am link-urile mele de socializare în partea de jos a articolului și mi-ar plăcea să am o discuție sănătoasă pe acest subiect acolo.

Deno vs Node – există de fapt concurență

O mulțime de oameni din industrie spun „bine, nu există nicio concurență între Deno și Node, există multe care pot învăța unul de la celălalt”.

Într-o anumită măsură, sunt de acord, există multe Node și Deno pot învăța unul de la celălalt. Dar nu există concurență? Nu sunt complet de acord cu asta.

Să ne uităm la caracteristicile comune ale lui Deno și Node:

  1. Ambele sunt medii de rulare pentru JavaScript
  2. Ambii rulează pe orice computer pe care puteți rula V8
  3. Amândoi au suport standard ECMAScript
  4. Amândoi sunt întreținuți activ

Dacă deveniți fan „Deno” la 2 ani de drum, nu veți alege niciodată Node pentru următorul dvs. proiect. Pur și simplu nu este posibil.

În mod similar, dacă nu ați mai lucrat niciodată cu TypeScript și credeți că doriți să încercați Deno, dar poate doriți să aveți niște module NPM, nu ați alege Deno.

Așa este: există o divizie de dezvoltatori în Deno și Node – aș spune că este un exemplu foarte bun de spațiu competitiv.

De ce să încerci Deno?

În primul rând, aș dori să enumăr câteva avantaje ale lui Deno – ce este și de ce se prezintă ca un timp de rulare mai bun:

  1. Depășește unele neajunsuri ale Node
  2. Este un mediu sigur de rulare în mod implicit
  3. Are suport TypeScript pregătit
  4. Folosește promisiuni până la capăt
  5. Este construit pe Rust (vs C ++ pentru nod)

În secțiunea următoare, voi alege toate aceste puncte unul câte unul și voi menționa ce poate învăța Node de la ele. De asemenea, voi discuta, ori de câte ori este necesar, de ce Deno nu are prea mult sens.

Unde a depășit Deno?

Să luăm USP-urile lui Deno și să le descompunem pe rând:

Securitate mediu de rulare în mod implicit

Aceasta este cea mai celebrată caracteristică a lui Deno și sunt surprins de ea. Deno rulează codul JavaScript într-un sandbox sigur în mod implicit – împiedicând accesul la sistemul de fișiere și la rețea, cu excepția cazului în care vă înscrieți în mod explicit.

Deno face asta pentru că vrea să imite browserul. Dar de ce? De ce ați dori să imitați browserul în primul rând? Deno respectă standardul ECMAScript, ceea ce este minunat! Dar ce-i cu dragostea nebună a browserelor?

Înțeleg, vrei să păstrezi compatibilitatea între codul scris pe clienți și servere. Dar a fost atât de puternic susținut de Deno până la punctul în care cred că Deno tocmai a greșit.

Nodul nu acceptă „runtime sigur” – și, după multă gândire, cred că nu există niciun motiv pentru a-l susține.

  1. Este un fapt cunoscut că nu ar trebui să rulați coduri / executabile de încredere pe sistemele dvs. Acesta este întregul punct de a opta mereu pentru biblioteci, cum ar fi expres pentru Node, în loc de un modul umbrit npm care spune că funcționează de 100 de ori mai repede decât expres. Încrederea provine din utilizarea comunității.
  2. Nu știu nici un limbaj de programare care să susțină un astfel de sandbox în centrul său. Deși poate fi fantezist, pare doar ceva care ar trebui făcut de un mediu container, cum ar fi Docker. Aș avea încredere într-o configurare bună a configurației Docker care rulează codul de nod neacredibil toată ziua mai sus, rulând codul de nod neacredit într-un mediu Deno cu sandbox. De ce? Deoarece Docker este o companie de miliarde de dolari construită în jurul unui singur scop – sandboxing.
  3. Sandbox-ul este greu – nu sunt un guru al securității cibernetice, dar cu cât are mai multe caracteristici, cu atât suprafața de atac este mai mare. Deno promite un mediu de rulare sigur și nu aș spune în niciun fel că ar putea fi compromis imediat. Dar afirm doar un fapt aici – Securitatea este greu de implementat corect. Deno își asumă o responsabilitate masivă aici. Cele mai mari corporații din lume își desfășoară programele Whitehat și achită sute de milioane de dolari în fiecare an către indivizi independenți și firme de securitate. Unde se află Deno în ceea ce privește mediul său cu adevărat sigur? Timpul va spune.

Deci, ce poate învăța Node de la Deno despre asta? Aș spune că nu prea multe. Nodul * ar putea * dori să aducă câteva steaguri de mediu securizate de la concurenții lor, dar pur și simplu nu văd un punct. Dacă rulați în mod aleatoriu coduri arbitrare pe sistemele dvs., ar putea la fel de bine să clonați un repo C / C ++ și să rulați o comandă make peste acesta și să vă compromiteți întregul sistem.

Din câte știu, nu puteți „accesa” sistemul de fișiere sau accesul la rețea în astfel de limbaje de nivel scăzut precum C / C ++ – pur și simplu nu este eficient.

Notă: Recent am descoperit că puteți face totul cu Deno cu --allow-run pavilion activat. Acest videoclip se scufundă în detalii:

Suport TypeScript gătit în

Ura pentru TypeScript. Sunt cu adevărat fericit că Deno îl susține din cutie.

NOTĂ: Vă mulțumim @lilasquared pentru că ați subliniat deno runs .js fișiere scoase din cutie. Vă rugăm să citiți următoarele paragrafe, ținând cont de faptul că suntem în codare .ts fișiere. Deno funcționează bine cu .js de asemenea, fișiere.

Dar hai să ne întoarcem puțin. Știți de ce JavaScript (și Node) are un trilion de dezvoltatori pe tot globul? Deoarece bariera de intrare este aproape nulă. JavaScript este flexibil și iartă o mulțime de greșeli – în timp ce aduce unele dintre cele mai ciudate comportamente la care te-ai aștepta de la un computer determinist.

Acest lucru este foarte rău pentru aplicațiile la nivel de producție în care nu doriți să circule lucruri funky. Și pentru cei care învață, este iertător – ceea ce uneori te poate frustra cu bug-uri urâte. Dar, de asemenea, le permite oamenilor să scape inițial de greșelile lor. Le permite „să se miște repede și să rupă lucrurile”, dacă pot cita.

Cu începători, mă tem că, dacă optează pentru Deno (care impune utilizarea TypeScript), vom vedea o mulțime de coduri de genul acesta, deoarece nu înțeleg încă TypeScript și vor doar să ruleze JavaScript pe server :

const httpResponse: any = await getAPIResponse<any>({ myParams })
// ...
const someOtherVariable = something() as any
// ...
any, any, any

TypeScript este un superset de JavaScript. Puteți scrie și un cod TypeScript rău – doar utilizarea acestuia nu vă face JavaScript să fie antiglonț.

Este totul distractiv și bun până când îți dai seama că poți scrie codul nodului în TypeScript. Sunt sigur că fiecare companie majoră care folosește Node în producție scrie Node în TypeScript – zero excepții. JavaScript nu este scalabil la un moment dat când aveți de-a face cu mai multe fișiere, dependențe multiple și o mulțime de coduri.

TypeScript este un set de instrumente revoluționar în ecosistemul JavaScript și permite utilizarea celor mai bune din ambele lumi – limbaj static și dinamic.

În acest scop, Deno susține că suportul TypeScript ar trebui să fie încorporat. Aș întreba de ce? Sigur, s-ar putea să aveți nevoie de babel și webpack pentru a face treaba, dar nu este acesta doar scopul de a avea seturi de instrumente în jur? Nu vrem să îmbunătățim DX-ul?

JavaScript va rămâne JavaScript și, dacă Deno ar rula TypeScript (sau un limbaj ca TypeScript) direct, nu aș fi avut nicio problemă. Dar nici nu rulează TypeScript, vă convertește codul TypeScript în JavaScript și apoi îl rulează.

Pentru acest punct, se pare că Deno este o versiune monolitică a Nodului care include un set de instrumente de testare, un formatator de cod și TypeScript, dintr-o dată. Nu pot vorbi pentru toți dezvoltatorii, dar aș dori ca miezul limbajului meu de programare să fie slab și să adaug alte utilități, dacă și când vreau.

De ce aș avea nevoie de un instrument încorporat pentru formatarea codului atunci când există mai frumos și are singurul scop de formatare a codului? De ce să rezolvăm lucruri care nu sunt sparte?

Deși este adevărat că arhitectura monolitică oferă multe instrumente în același loc, este de asemenea adevărat că este voluminoasă, iar un nucleu slab este mult mai ușor de întreținut și de scalat.

Promite până la capăt

Acest punct din versiunea Deno 1.0 nu prea avea sens pentru mine ca o distincție. Am tot respectul pentru creatorii Node și Deno. Dar Node are ceva ce Deno nu are – experiență și sprijin de la o mare varietate de dezvoltatori din întreaga lume.

Nodul este contribuit de aproape 3000 de persoane și este pionierul în manipularea I / O asincronă. Sigur, Deno este construit pe Rust și expune o abstracție asemănătoare unei promisiuni. Dar Node are C ++ și 3000 de dezvoltatori și 10 ani de muncă + rezultate ale experimentelor.

Modelul asincron al nodului nu este defect, promisiunile și modelele de ascultător de evenimente nu sunt defecte, așa că nu sunt sigur cum Deno poate remedia ceea ce nu este defect.

hasta la vista, npm

Lucru uriaș. Deno nu acceptă NPM. La fel de mult ca Ryan, creatorul sau Node and Deno promovează limbajul „Go” în acest punct, aș dori să menționez câțiva manageri de pachete:

  1. npm pentru JS (evident)
  2. apt-get
  3. compozitor (PHP)
  4. preparare (macOS)
  5. cargo (Rugină! – Limba în care este codat Deno)

Cred doar că este o mișcare greșită să nu folosești un manager de pachete. Ei fac o mulțime de lucruri – versiuni, rularea de scripturi, gestionarea actualizărilor de dependență etc. De ce Deno nu va folosi npm? Nu știu. Dar iată la ce mă pot gândi:

  1. În primul rând, pentru că sunt JavaScript – iar Deno are nevoie de TypeScript. CORECŢIE: Deno poate sa lucrați și cu fișiere .js.
  2. Apoi, multe dintre aceste module npm ar necesita sistem de fișiere / rețea / alte permisiuni – pe care Deno le restricționează în mod implicit. Deci, trebuie să vă deranjați cu câmpul nou „permisiuni” din package.json. Hopa, Deno nu funcționează cu npm, deci nu există package.json, haideți să vedem cum gestionează sistemul modulului atunci.
  3. Modulele NPM sunt umflate și există o mulțime de ele, dar în același timp, aceasta este puterea ecosistemului Node. Doriți un pachet pentru a extrage fișierele tar într-un flux? Ai luat-o (tar-stream). Doriți un pachet de validare a datelor? Ai luat-o (joi). Doriți să lucrați cu JWT? Ai primit (jsonwebtoken). Mă întreb cât timp va dura dezvoltatorii să-și porteze pachetele pe un sistem compatibil cu Deno?

Deno are o abordare diferită a sistemelor de module. Dacă, în orice caz, încearcă să „patch-in” modulele NPM existente cumva, nu văd rostul de a folosi Deno în afară de doar hacking în jurul unui proiect TS + Node într-un container Docker oricum.

Conform celor aflate până acum despre Deno, iată cum arată:

Deno = (mai ales) [TypeScript + Node + Correctly configured docker container + single executable binaries + <some more little tooling here and there> – NPM]

Bine! Haideți să răcorim puțin lucrurile și permiteți-mi să închei acest articol.

Concluzie

Sunt la fel de entuziasmat de Deno ca toți ceilalți. Dar când există o rescriere completă în runtime JavaScript, mă aștept la schimbări mari.

Deno include o grămadă de caracteristici frumoase, cum ar fi documentația automată TypeScript, pe care nu am menționat-o, deoarece acest post își propune să arate cealaltă față a monedei. Veți găsi avantajele lui Deno în aproape toate celelalte articole, dar cred că este ceva ce trebuia spus.

Pentru a fi sincer, Deno pare o mare întreprindere pentru un mic beneficiu, cu o datorie imensă de a transfera module npm existente și baze de cod. Ești de acord sau nu cu mine? Aș vrea să vă cunosc părerile. Tweet / urmează-mă: @mehulmpt și pe Instagram de asemenea!

Pace!