Παρουσιάζετε τον τύπο ασφάλειας στο έργο σας JavaScript; Ξανασκέψου το

Παρουσιάζετε τον τύπο ασφάλειας στο έργο σας JavaScript; Ξανασκέψου το

Ενημέρωση - 1η Φεβρουαρίου 2017

Έχω ακούσει διάφορα αντίθετα επιχειρήματα σχετικά με την ασφάλεια τύπου στο JavaScript από την πρώτη δημοσίευση αυτού του άρθρου και, ενώ εξακολουθώ να πιστεύω ότι πολλά έργα δεν απαιτούν τη χρήση ενός υπερσύνολου JavaScript που πληκτρολογείται, παραδέχομαι ότι ήμουν πολύ βιαστικός κατά τη δημοσίευση αυτού του άρθρου. άρθρο. Μερικές κατάλληλες περιπτώσεις χρήσης στη συνέχεια τράβηξαν την προσοχή μου:

  • Το Glimmer, η μηχανή απόδοσης χαμηλού επιπέδου πίσω από το Ember, είναι γραμμένο σε TypeScript για την προώθηση μονομορφικών ιστότοπων κλήσεων, βοηθώντας την απόδοση όταν εκτελείται από το V8 και ενδεχομένως άλλους κινητήρες JavaScript
  • Το Visual Studio Code επωφελείται από το TypeScript λόγω του μεγάλου μεγέθους του έργου. Δεδομένου ότι διανέμεται ως εφαρμογή για επιτραπέζιους υπολογιστές, η ύπαρξη μίας βάσης κώδικα αντί να συνδυάζει μεμονωμένα πακέτα κατά το χρόνο κατασκευής είναι, κατά τη γνώμη μου, μια λογική επιλογή
  • Το Sect (ομολογουμένως ένα δικό μου έργο, οπότε υπάρχει πιθανή μεροληψία εδώ!) Είναι γραμμένο στο TypeScript, έτσι ώστε οι καταναλωτές να μπορούν να γράφουν μεγάλα, αρθρωτά παιχνίδια για τον Ιστό, μειώνοντας αξιόπιστα τα σφάλματα χρόνου εκτέλεσης που προκύπτουν από ορθογραφικά λάθη και άλλα ζητήματα που προκύπτουν ως αποτέλεσμα της JavaScript δυναμική φύση

Έχω επίσης συνειδητοποιήσει ότι η συγγραφή μικρότερων βιβλιοθηκών στο TypeScript και η δημοσίευσή τους με τους ορισμούς τύπων που δημιουργούνται κατά το χρόνο κατασκευής ταυτόχρονα επιτρέπει την απρόσκοπτη ενσωμάτωσή τους με δακτυλογραφημένα και παραδοσιακά έργα JavaScript, δίνοντας έτσι στους προγραμματιστές μια ευρύτερη τεχνολογική επιλογή.

Ωστόσο, για χάρη των γενεών, εδώ είναι το αρχικό άρθρο στο σύνολό του.

Σήμερα, συνάντησα ένα άρθρο σχετικά με την κυκλοφορία του JS ++, το οποίο ισχυρίζεται ότι "διορθώνει την έλλειψη ασφάλειας τύπου JavaScript". Αστεία, έχουμε ήδη TypeScript, ST-JS και Scala.js, που βοηθούν τους προγραμματιστές να επιτύχουν τελικά τον ίδιο στόχο.

Πριν ξεκινήσω σε αυτήν την αίσθηση, επιτρέψτε μου να επισημάνω τρία σημαντικά σημεία:

  • Έχω γράψει προηγουμένως ένα σεμινάριο για τη δημιουργία ενός απλού έργου TypeScript. Βλέπω την υποκρισία, αλλά οι απόψεις μου έχουν αλλάξει από τότε που τη δημοσίευσα πριν από ένα χρόνο
  • Η ισχυρή πληκτρολόγηση και η στατική πληκτρολόγηση είναι ζωτικής σημασίας παραδείγματα. Το πρώτο παρέχει διαφάνεια έναντι των οντοτήτων που εκπροσωπούνται στον κώδικα κάποιου, των σχέσεών του και της λειτουργικότητας που μπορεί να αναμένεται να προσφέρει, ενώ το δεύτερο είναι ένα σημαντικό δίχτυ ασφαλείας χρόνου σύνθεσης σε πολύπλοκα συστήματα. Προέρχομαι από φόντο C #, οπότε έχω εμπειρία από πρώτο χέρι σε αυτό
  • Λατρεύω επίσης τη JavaScript, δεδομένων των εγγενών ελαττωμάτων της, πολλές από τις οποίες έχουν αντιμετωπιστεί με το ECMAScript 6 και 7

Γιατί λοιπόν γενικά δεν είμαι ενάντια στη στατική πληκτρολόγηση σε JavaScript;

Κυρίως, αυτό που κάνει τη JavaScript μια τόσο ισχυρή γλώσσα είναι η αδύναμα τυποποιημένη φύση της. Είναι ασήμαντο να εφαρμόζουμε κλάδους λογικής μέσω εξαναγκασμού τύπου και είναι τόσο εύκολο να δημιουργείς εμφανίσεις αντικειμένου αυθαίρετου τύπου. Επιπλέον, η έλλειψη συλλογής (εκτός αν κάποιος χρησιμοποιεί transpiler ή εργαλείο κατασκευής όπως το Babel, για παράδειγμα) κάνει την ανάπτυξη απίστευτα γρήγορη, εφόσον ο κώδικας δεν οδηγεί σε παράξενες συμπεριφορές. Κατά τη γνώμη μου, αυτό το καθιστά τόσο ισχυρό για την ανάπτυξη frontend και απλού backend (π.χ. IoT).

Προσωπικά πιστεύω ότι εάν κάποιος αναπτύσσει ένα σύστημα τόσο περίπλοκο που απαιτεί ασφάλεια τύπου, τότε θα πρέπει να χρησιμοποιεί μια γλώσσα που το υποστηρίζει στον πυρήνα του. η σύνταξη ενός συστήματος καθοδήγησης, το οποίο περιλαμβάνει πολύπλοκες μαθηματικές λειτουργίες, σε JavaScript είναι παράλογο.

Το κύριο μέλημά μου με αυτά τα εργαλεία και υπερσύνολα JavaScript είναι ότι μεταγλωττίζονται, επίσης, σε JavaScript Αυτά τα προγράμματα εκτελούνται συνεπώς σε ένα δυναμικό περιβάλλον, επομένως θα μπορούσαν να εμφανιστούν οι ίδιες παρενέργειες. Το TypeScript, για παράδειγμα, μπορεί να είναι στατικά δακτυλογραφημένο (δηλ. Πληροφορίες τύπου συλλέγονται και αναλύονται κατά το χρόνο μεταγλώττισης), αλλά κάποιος πρέπει να έχει πλήρη σιγουριά ότι ο κωδικός που προκύπτει θα συνεχίσει να λειτουργεί όπως αναμένεται. Ναι, βέβαια, ακόμη και γλώσσες με στατικά δακτυλογράφηση συνήθως συντάσσονται σε μια γλώσσα χαμηλότερου επιπέδου, η οποία στη συνέχεια τυπικά ερμηνεύεται, αλλά αυτές οι γλώσσες-στόχοι σίγουρα σχεδιάστηκαν με την πληκτρολόγηση ως πολίτης πρώτης κατηγορίας Για παράδειγμα, ο μεταγλωττιστής JIT της Microsoft για το .NET εξακολουθεί να εφαρμόζει τον έλεγχο τύπου χρόνου εκτέλεσης της ενδιάμεσης γλώσσας του πριν μεταγλωττίσει στον εγγενή κώδικα.

Επιπλέον, όταν αναλαμβάνω ανάπτυξη frontend, είμαι ακόμα της νοοτροπίας ότι το JavaScript πρέπει να χρησιμοποιηθεί για να συμπληρώσει λύσεις HTML και CSS, π.χ. προσθήκη τάξεων σε στοιχεία, πραγματοποίηση κλήσεων HTTP σε υπηρεσίες backend κ.λπ. μεγαλύτερες εφαρμογές που βασίζονται σε περιβάλλον χρήστη (FYI, έχω γράψει μεγαλύτερες εφαρμογές με το React.js και τη βανίλια JS. Αγαπώ και τα δύο), προτιμώ να διατηρήσω το JS μου όσο πιο ελαφρύ γίνεται. Καταλαβαίνω ότι αυτό δεν είναι πάντα μια πιθανότητα στην πραγματικότητα, αλλά εάν τα συστήματα backend χρησιμεύουν ως η αλήθεια πηγής για τη θεμελιώδη επιχειρηματική λογική, τότε ο κωδικός frontend γίνεται ελαφρύτερος και λιγότερο περιττός. από αυτή την άποψη, ποια οφέλη θα προσφέρει ένα σύστημα τύπου;

Ακολουθώντας την άποψή μου για το μέγεθος του λογισμικού frontend, η τρέχουσα δουλειά μου συνεπάγεται τη σύνταξη συγκεντρωμένων εφαρμογών Ιστού για κάθε ανησυχία του γενικού συστήματος. Σε αντίθεση με μια μεγάλη εφαρμογή μίας σελίδας για το κατάστημά μας, η οποία περιέχει μια προβολή λίστας προϊόντων, μια προβολή λεπτομερειών προϊόντος και μια προβολή ταξιδιού αγοράς, έχουμε αντίστοιχες εφαρμογές που υποστηρίζονται από το Node.js. Προφανώς, αυτή είναι μια βέλτιστη πρακτική από την άποψη της χαλαρής σύζευξης και της ανθεκτικότητας, αλλά από άποψη κώδικα, επιτρέπει μια εστίαση ευκολότερα στην υλοποίηση μιας περιοχής του frontend μας.

Το τελευταίο επιχείρημά μου είναι αυτό. είναι πολύ δύσκολο να μάθεις το JavaScript; Όπως έχω ήδη πει, το ίδιο το ECMAScript 5 είναι μια ελαττωματική γλώσσα. τα διαφορετικά μοτίβα επίκλησης συναρτήσεων και πώς επηρεάζουν τη λέξη-κλειδί «αυτή» και η έλλειψη αποκλεισμού, για παράδειγμα, μπορεί να δυσκολέψει τους αρχάριους. Ωστόσο, με το ECMAScript 6, καθώς και την πληθώρα καταπληκτικών πόρων, είναι εύκολο να ξεπεραστούν και να γνωρίζετε αυτά τα ζητήματα. Γιατί να μην παραλείψετε απλά τον μεσαίο άνθρωπο και να μάθετε τη γλώσσα απευθείας;

Θα κλείσω λέγοντας ότι είμαι οπαδός όλων των προσεγγίσεων πληκτρολόγησης, αλλά μερικά ταιριάζουν σε ορισμένα σενάρια περισσότερο από άλλα. Εάν το JavaScript λειτουργεί καλύτερα για την πλειονότητα του λογισμικού frontend, δεδομένης της πανταχού παρουσίας του στις ομάδες ανάπτυξης και στα έργα τους, τότε σίγουρα δεν χρειάζεται ένα υπερσύνολο. Επιπλέον, υπάρχει ένα φορτίο γλωσσών που είναι εγγενώς ασφαλείς τύπου, οπότε σταματήστε να ανακαλύπτετε ξανά τον τροχό!