de James Wright

Va prezentam Type Safety in proiectul dvs JavaScript Mai gandeste te

Vă prezentăm Type Safety în proiectul dvs. JavaScript? Mai gandeste-te

Actualizare – 1 februarie 2017

Am auzit diverse contraargumente cu privire la siguranța tipului în JavaScript de când am publicat acest articol pentru prima dată și, deși cred în continuare că multe proiecte nu necesită utilizarea unui superset JavaScript tastat, recunosc că am fost prea grăbit în publicarea acestui articol. Unele cazuri de utilizare adecvate mi-au atras ulterior atenția:

  • Licărire, motorul de redare de nivel scăzut din spatele Ember, este scris în TypeScript pentru promovare site-uri de apel monomorfe, ajutând performanța atunci când este executat de V8 și potențial alte motoare JavaScript
  • Cod Visual Studio beneficiază de TypeScript datorită dimensiunii ridicate a proiectului; dat fiind faptul că este distribuit ca o aplicație desktop, a avea o bază de cod mai degrabă decât reconcilierea pachetelor individuale la momentul construirii este, în opinia mea, o opțiune sensibilă
  • Sectă (Desigur, un proiect al meu, deci există o potențială prejudecată aici!) este scris în TypeScript, astfel încât consumatorii să poată scrie jocuri mari și modulare pentru web, reducând în același timp în mod fiabil erorile de rulare rezultate din greșeli de ortografie și alte probleme care apar ca urmare a dinamicii JavaScript natură

Mi-am dat seama în plus că scrierea de biblioteci mai mici în TypeScript și publicarea lor cu definițiile de tip generate la timpul de construire simultan permite integrarea lor perfectă cu tipar și proiecte tradiționale JavaScript, oferind astfel dezvoltatorilor o alegere tehnologică mai largă.

Cu toate acestea, de dragul posterității, iată articolul original în întregime.

Astăzi, am întâlnit un articol referitor la lansarea JS ++, care pretinde că „remediază lipsa de siguranță a tipului JavaScript”. Destul de amuzant, avem deja TypeScript, ST-JS, și Scala.js, care îi ajută pe dezvoltatori să atingă în cele din urmă același obiectiv.

Înainte de a mă lansa în această tiradă, permiteți-mi să evidențiez trei puncte importante:

  • Am scris anterior un tutorial pe stabilirea unui proiect TypeScript simplu. Văd ipocrizia, dar opiniile mele s-au schimbat de când am publicat-o acum peste un an
  • Tastarea puternică și tastarea statică sunt paradigme vitale. Primul oferă transparență asupra entităților reprezentate în codul propriu, a relațiilor lor și a funcționalității pe care ar putea să le ofere, în timp ce acesta din urmă este o rețea de siguranță importantă în timp de compilare în sisteme complexe. Provin dintr-un fundal C #, așa că am o experiență directă în acest sens
  • Îmi place, de asemenea, JavaScript, având în vedere defectele sale inerente, dintre care multe au fost abordate cu ECMAScript 6 și 7

Deci, de ce sunt în general împotriva tastării statice în JavaScript?

În mod predominant, ceea ce face ca JavaScript să fie un limbaj atât de puternic este natura sa slab tipizată; este banal să implementați ramuri ale logicii prin constrângere de tip și este atât de ușor să creați instanțe de obiect de tip arbitrar. Mai mult, lipsa de compilare (cu excepția cazului în care se folosește un transpiler sau un instrument de construire, cum ar fi Babel, de exemplu) face dezvoltarea incredibil de rapidă, atâta timp cât codul nu duce la niciun comportament bizar. În opinia mea, acesta este ceea ce îl face atât de puternic pentru frontend și simplu dezvoltare backend (de ex. IoT).

Eu personal cred că dacă cineva dezvoltă un sistem atât de complex încât necesită siguranță de tip, atunci ar trebui să folosești un limbaj care îl susține în centrul său; scrierea unui sistem de ghidare, care implică operații matematice complexe, în JavaScript este nebunie.

Principala mea preocupare cu aceste instrumente JavaScript și superseturi este că acestea se compilează, bine, JavaScript; în consecință, aceste programe rulează într-un context dinamic, astfel încât aceleași efecte secundare ar putea să apară. TypeScript, de exemplu, poate fi tastat static (adică informațiile de tip sunt colectate și analizate la compilare), dar trebuie să aveți deplina încredere că codul rezultat va rula în continuare așa cum era de așteptat. Da, desigur, chiar și limbile tipizate static sunt de obicei compilate într-un limbaj de nivel inferior, care este apoi interpretat în mod obișnuit, dar aceste limbi țintă au fost concepute cu siguranță cu tastarea ca cetățean de primă clasă; ca exemplu, compilatorul Microsoft JIT pentru .NET implementează încă verificarea tipului de rulare a limbajului intermediar înainte de a compila în codul nativ.

Mai mult, atunci când întreprind dezvoltarea frontend-ului, sunt încă în mintea cu care trebuie folosit JavaScript completa Soluții HTML și CSS, de exemplu adăugarea de clase la elemente, efectuarea de apeluri HTTP pentru servicii de backend etc. În timp ce web-ul s-a maturizat în ceea ce privește cadrele pentru crearea unor aplicații mai mari, bazate pe interfața de utilizare (FYI, am scris aplicații mai mari cu React.js și vanilla JS Îmi plac și pe amândoi), prefer să-mi păstrez JS cât mai ușor. Înțeleg că aceasta nu este întotdeauna o posibilitate în realitate, dar dacă sistemele backend servesc drept adevăr sursă pentru logica fundamentală a afacerii, atunci codul frontend devine mai ușor și mai puțin redundant; în acest sens, ce beneficii va aduce un sistem de tip?

Urmărind punctul meu despre dimensiunea software-ului frontend, munca mea actuală presupune scrierea de aplicații web concentrate pentru fiecare preocupare a sistemului general; Spre deosebire de o aplicație mare de o singură pagină pentru magazinul nostru, care conține o vizualizare a listei de produse, o vizualizare a detaliilor produsului și o vizualizare a călătoriei de cumpărare, avem pentru acestea aplicații cu suport Node.js respective. Evident, aceasta este cea mai bună practică în ceea ce privește cuplarea slabă și rezistența, dar din punct de vedere al codului, permite o concentrare mai ușoară asupra implementării unei zone a frontend-ului nostru.

Argumentul meu final este acesta; JavaScript este chiar atât de dificil de învățat? După cum am mai spus, ECMAScript 5 în sine este un limbaj defect; diferitele modele de invocare a funcțiilor și modul în care acestea afectează cuvântul cheie `this` și lipsa de definire a blocului, de exemplu, pot face dificilă pentru începători. Cu toate acestea, cu ECMAScript 6, plus pletora de resurse uimitoare, este ușor de depășit și de a fi conștient de aceste probleme. De ce nu sari peste omul de mijloc și să înveți limba direct?

Voi încheia spunând că sunt fan al tuturor abordărilor de tastare, dar unele se potrivesc mai mult anumitor scenarii decât altele. Dacă JavaScript funcționează cel mai bine pentru majoritatea software-urilor frontend, având în vedere omniprezența sa în cadrul echipelor de dezvoltare și a proiectelor lor, atunci cu siguranță nu are nevoie de un superset. În plus, există o mulțime de limbi care sunt în mod inerent sigure, așa că nu mai reinventați roata!