Πλαίσια εμπρός-άκρου: Λύσεις ή φουσκωμένα προβλήματα;

Τα σύγχρονα πλαίσια front-end απαιτούν από εσάς να κατεβάσετε ένα περιβάλλον ανάπτυξης, πλήρες με εξαρτήσεις και να μεταγλωττίσετε τον κώδικά σας πριν προσπαθήσετε να τον προβάλετε στο πρόγραμμα περιήγησης. Είναι καλό; Είναι το πρόβλημα που δημιουργούμε πιο περίπλοκους ιστότοπους ή μήπως τα πλαίσια είναι από μόνα τους περίπλοκα, εισάγοντας ένα περιττό επίπεδο πολυπλοκότητας;

Η ανάπτυξη Ιστού σήμερα έχει εξελιχθεί πολύ από τη δεκαετία του '90. είμαστε σε θέση να δημιουργήσουμε ολόκληρες εμπειρίες που είναι πολύ κοντά σε αυτό που μπορεί να κάνει οποιαδήποτε εγγενής εφαρμογή και η διαδικασία ανάπτυξης έχει επίσης αλλάξει. Πηγαίνουν οι μέρες που ήταν ένας προγραμματιστής web front-end ήταν θέμα ανοίγματος του Notepad, πληκτρολογώντας μερικές γραμμές κώδικα, ελέγχοντας το στο πρόγραμμα περιήγησης και μεταφορτώνοντάς το σε ένα φάκελο FTP.

Η ανάπτυξη διαδικτύου Front-end του παρελθόντος

Πρέπει να ξεκινήσω δηλώνοντας το προφανές: Ο κόσμος δεν είναι όπως ήταν πριν από 10 χρόνια. (Σοκαριστικό, ξέρω.) Το μόνο πράγμα που παραμένει σταθερό είναι η αλλαγή. Πίσω στην ημέρα, είχαμε πολύ λίγα προγράμματα περιήγησης, αλλά υπήρχαν πολλά προβλήματα συμβατότητας. Σήμερα, δεν βλέπετε πολλά πράγματα όπως η 'καλύτερη προβολή στο Chrome 43.4.1', αλλά τότε ήταν πολύ κοινό. Έχουμε περισσότερα προγράμματα περιήγησης τώρα, αλλά λιγότερα προβλήματα συμβατότητας. Γιατί; Εξαιτίας jQuery . Το jQuery ικανοποίησε την ανάγκη να υπάρχει μια τυπική, κοινή βιβλιοθήκη που θα σας επέτρεπε να γράψετε κώδικα JavaScript που χειρίζεται το DOM χωρίς να χρειάζεται να ανησυχείτε για το πώς επρόκειτο να εκτελεστεί σε κάθε πρόγραμμα περιήγησης και σε κάθε έκδοση κάθε προγράμματος περιήγησης - ένας πραγματικός εφιάλτης στη δεκαετία του 2000 .

Τα σύγχρονα προγράμματα περιήγησης μπορούν να χειριστούν το DOM ως πρότυπο, επομένως η ανάγκη για μια τέτοια βιβλιοθήκη έχει μειωθεί σημαντικά τα τελευταία χρόνια. Το jQuery δεν είναι απαιτείται πια, αλλά μπορούμε ακόμα να βρούμε μια σειρά από εξαιρετικά χρήσιμα πρόσθετα που εξαρτώνται από αυτό. Με άλλα λόγια, τα διαδικτυακά πλαίσια μπορεί να μην είναι απαραίτητα, αλλά εξακολουθούν να είναι αρκετά χρήσιμα για να είναι δημοφιλή και ευρέως χρησιμοποιούμενα. Αυτό είναι ένα χαρακτηριστικό γνώρισμα των περισσότερων από τα δημοφιλή πλαίσια ιστού εκεί έξω, από React, Angular, Vue και Ember μέχρι στυλ και μορφοποίηση μοντέλων όπως το Bootstrap.

Γιατί οι άνθρωποι χρησιμοποιούν τα πλαίσια

Στην ανάπτυξη ιστού όπως στη ζωή, η γρήγορη λύση είναι πάντα βολική. Έχετε κάνει ποτέ έναν δρομολογητή στο JavaScript; Γιατί να περάσετε από την οδυνηρή διαδικασία μάθησης όταν μπορείτε να εγκαταστήσετε npm ένα front-end πλαίσιο για να ξεπεράσετε το πρόβλημα; Ο χρόνος είναι μια πολυτέλεια όταν ο πελάτης θέλει τα πράγματα να γίνουν εχθές ή κληρονομείτε κώδικα από άλλον προγραμματιστή που έχει σχεδιαστεί για ένα συγκεκριμένο πλαίσιο ή εάν ενσωματώνεστε με μια ομάδα που χρησιμοποιεί ήδη ένα συγκεκριμένο πλαίσιο. Ας το παραδεχτούμε - τα πλαίσια υπάρχουν για κάποιο λόγο. Εάν δεν υπήρχαν οφέλη σε αυτούς, κανείς δεν θα τα χρησιμοποιούσε.

Λοιπόν, ποια είναι μερικά από τα οφέλη και τις μοναδικές ιδιότητες της χρήσης ενός πλαισίου ανάπτυξης ιστού;

Ο χρόνος είναι χρήμα. Όταν αναπτύσσετε ένα έργο και ο πελάτης δεν ενδιαφέρεται για το πλαίσιο που χρησιμοποιείτε - πράγματι, μάλλον δεν γνωρίζει καν τι χρησιμοποιείτε - ενδιαφέρεται μόνο για τη λήψη αποτελεσμάτων και όσο γρηγορότερα είναι το καλύτερο. Τα καθιερωμένα πλαίσια σάς επιτρέπουν να δημιουργήσετε μια άμεση αίσθηση προόδου από την αρχή, την οποία ο πελάτης λαχταρά από την 1η ημέρα. Επιπλέον, όσο πιο γρήγορα αναπτύσσετε, τόσο περισσότερα χρήματα κερδίζετε, καθώς ο χρόνος που ελευθερώνεται από το πλαίσιο μπορεί να μεταφερθεί στην ανάληψη περισσότερων έργα.

Είναι όλα σχετικά με την κοινότητα. Όταν επιλέγετε ένα πλαίσιο, αυτό είναι ένα πολύ σημαντικό σημείο - ποιος θα σας βοηθήσει όταν κολλήσετε σε ένα ζήτημα; Εσείς και εγώ ξέρουμε ότι πρόκειται να συμβεί κάποια στιγμή. Θα φτάσετε σε ένα σημείο όπου πρέπει να κάνετε κάτι που το πλαίσιο δεν προοριζόταν να κάνει ή ότι το πλαίσιο δεν σχεδιάστηκε ποτέ για να σας δώσει πρόσβαση, επομένως είναι απαραίτητο να έχετε μια κοινότητα που να σας υποστηρίζει. Η ανάπτυξη - ειδικά ανεξάρτητη - μπορεί να είναι δύσκολη, καθώς βυθίζεστε σε έναν εικονικό κόσμο και εάν είστε ο μοναδικός προγραμματιστής διαδικτύου διεπαφής σε μια ομάδα, αυτό σημαίνει ότι είστε ο μόνος με την εμπειρία και την εξειδίκευση που βρίσκετε μια λύση. Αλλά αν το πλαίσιο front-end που χρησιμοποιείτε έχει σταθερή υποστήριξη, θα υπάρχει κάποιος από την άλλη πλευρά του κόσμου που αντιμετώπισε το ίδιο πρόβλημα και μπορεί να μπορεί να σας βοηθήσει.

Τα πρότυπα είναι όμορφα. Έχετε παρατηρήσει ποτέ ότι, όταν εξετάζετε ένα παλιό κομμάτι του δικού σας κώδικα, μπορείτε να το περιηγηθείτε αρκετά εύκολα; Ή τουλάχιστον, πιο εύκολα από ένα κομμάτι κώδικα γραμμένο από κάποιον άλλο; Σκέφτεστε με έναν συγκεκριμένο τρόπο, και έχετε τον δικό σας τρόπο να ονομάσετε πράγματα και να οργανώσετε τον κώδικα. Αυτό είναι ένα πρότυπο. Όλοι τους ακολουθούμε, ακόμα κι αν είναι μόνο για εμάς. Τείνουμε να τρώμε παρόμοια πράγματα για πρωινό, να ξυπνάμε σε μια συγκεκριμένη ώρα και να τοποθετούμε τα κλειδιά μας στο ίδιο μέρος κάθε μέρα. Και όντως, αν αλλάζαμε τις ρουτίνες μας κάθε μέρα, η ζωή θα ήταν πολύ πιο δύσκολη απλώς από το γενικότερο να καταλάβουμε πώς να κάνουμε πράγματα. Χάσατε ποτέ τα κλειδιά σας επειδή τα τοποθετήσατε σε διαφορετικό μέρος από το κανονικό; Τα πρότυπα διευκολύνουν τη ζωή. Όταν εργάζεστε ως μέρος μιας ομάδας ή μιας κοινότητας προγραμματιστών, γίνονται απολύτως απαραίτητα.

ανάπτυξη εφαρμογών visual studio ios

Τα πλαίσια παρέχουν ένα πρότυπο από τη στιγμή που τα εγκαθιστάτε, καθοδηγώντας σας να σκέφτεστε και να κωδικοποιείτε με συγκεκριμένο τρόπο. Δεν χρειάζεται να αφιερώσετε χρόνο δημιουργώντας ένα πρότυπο με την ομάδα σας. μπορείτε απλώς να ακολουθήσετε πώς γίνονται τα πράγματα στο πλαίσιο. Αυτό καθιστά ευκολότερη την εργασία. Είναι πιο εύκολο να αναζητήσετε μια συνάρτηση όταν γνωρίζετε ότι η συνάρτηση πρέπει να βρίσκεται σε ένα συγκεκριμένο αρχείο, επειδή έχει δημιουργηθεί για την προσθήκη μιας διαδρομής σε ένα SPA και στο πλαίσιο σας, όλες οι διαδρομές τοποθετούνται σε ένα αρχείο με αυτό το όνομα. Άτομα με διαφορετικά επίπεδα δεξιοτήτων μπορούν να συνεργαστούν αν έχετε αυτό το επίπεδο τυποποίησης, γιατί ενώ οι προηγμένοι κωδικοποιητές γνωρίζουν Γιατί τα πράγματα γίνονται με αυτόν τον τρόπο, ακόμη και οι νέοι προγραμματιστές μπορούν να ακολουθήσουν το ίδιο το πρότυπο.

Όταν αποτυγχάνουν τα πλαίσια

Πριν από λίγα χρόνια, λέγοντας κάτι σαν 'Δεν χρησιμοποιώ πλαίσια - δεν βλέπω κανένα πραγματικό όφελος από αυτά' θα έφερνε άτομα με φακούς και περόνες στην πόρτα σας. Αλλά σήμερα, όλο και περισσότεροι άνθρωποι αναρωτιούνται: «Γιατί να χρησιμοποιήσω καθόλου ένα πλαίσιο; Τα χρειάζομαι πραγματικά; Είναι ότι δύσκολο να κωδικοποιήσετε χωρίς αυτά; '

Είμαι σίγουρα ένας από αυτούς - δεν ήμουν ποτέ οπαδός οποιουδήποτε συγκεκριμένου πλαισίου και έχω κωδικοποιήσει χωρίς αυτά για ολόκληρη την καριέρα μου. Αν έχω μια επιλογή στο θέμα, η επιλογή μου είναι πάντα, 'Όχι, ευχαριστώ.' Αναπτύσσω σε JavaScript εδώ και χρόνια και στο ActionScript πριν από αυτό. Κωδικοποιώ στο Flash όταν οι περισσότεροι το θεωρούσαν ήδη νεκρό. (Ξέρω, το ξέρω ... αλλά έκανα πολλά κινούμενα σχέδια και το κινούμενο σχέδιο σε απλό HTML είναι δύσκολο.) Επομένως, εάν είστε ένας από τους πολλούς που δεν σκέφτονται ποτέ την κωδικοποίηση χωρίς πλαίσια, επιτρέψτε μου να σας δείξω μερικούς λόγους για τους οποίους μπορεί να δυσκολεύεστε.

Το 'ένα μέγεθος ταιριάζει σε όλους' είναι ένα ψέμα. Θα μπορούσατε να φανταστείτε να γράψετε ένα μόνο λογισμικό που μπορεί να κάνει ό, τι έχετε επιτύχει στην καριέρα σας; Αυτό είναι ένα από τα κύρια προβλήματα με τα πλαίσια ανάπτυξης ιστού. Το έργο σας έχει πολύ συγκεκριμένες ανάγκες, τις οποίες έχουμε την τάση να επιλύουμε προσθέτοντας βιβλιοθήκες, προσθήκες ή πρόσθετα για να επεκτείνουμε το πεδίο εφαρμογής του πλαισίου. Κανένα πλαίσιο δεν προσφέρει το 100% όσων χρειάζεστε και κανένα πλαίσιο δεν αποτελείται 100% από πράγματα που θα βρείτε χρήσιμα.

Η ύπαρξη υπερβολικού κώδικα που δεν χρησιμοποιείτε μπορεί να οδηγήσει σε καθυστέρηση χρόνου φόρτωσης για τον ιστότοπό σας, η οποία καθίσταται πιο σημαντική με κάθε επιπλέον χρήστη. Ένα άλλο ζήτημα είναι ότι η νοοτροπία «ένα μέγεθος ταιριάζει σε όλους» οδηγεί σε αναποτελεσματικό κώδικα. Πάρτε, για παράδειγμα, $(‘sku-product').html('SKU 909090');, που είναι ο κώδικας jQuery που, στο τέλος, όλοι γνωρίζουμε ότι θα μεταφραστεί σε κάτι σαν document.getElementById('sku-product').innerHTML = 'SKU 909090';.

Αυτό το είδος διαφοράς σε μία γραμμή μπορεί να φαίνεται ασήμαντο, αλλά η αλλαγή του περιεχομένου ενός συγκεκριμένου στοιχείου της σελίδας είναι ακριβώς η αρετή του React. Τώρα, το React περνά τη διαδικασία δημιουργίας μιας αναπαράστασης του DOM και ανάλυσης των διαφορών σε αυτό που προσπαθείτε να αποδώσετε. Δεν θα ήταν ευκολότερο να στοχεύσετε απλώς το περιεχόμενο που θέλετε να αλλάξετε από την αρχή;

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

Το να συμβαδίζεις με το Joneses είναι πράγματι. Εργάσατε ποτέ σε ένα έργο στο AngularJS μόνο για να ανακαλύψετε ότι χρειάζεστε κάτι που δεν εμφανίστηκε μέχρι την κυκλοφορία του Angular 4; Γνωρίζατε καν ότι κυκλοφόρησε το Angular 5; Αυτό είναι ένα άλλο τεράστιο ζήτημα. Ακόμα κι αν κολλάτε σε ένα ενιαίο πλαίσιο front-end, όταν συμβαίνει μια νέα μεγάλη κυκλοφορία, τα πράγματα μπορούν να αλλάξουν τόσο πολύ ώστε ο κώδικας που δουλέψατε τόσο σκληρά να δημιουργήσετε δεν θα εκτελεστεί καν στη νέα έκδοση. Αυτό θα μπορούσε να οδηγήσει σε οτιδήποτε, από ενοχλητικές μικρές αλλαγές που πρέπει να γίνουν σε πολλά αρχεία έως την πλήρη επανεγγραφή του κώδικα σας.

Η παρακολούθηση των τελευταίων εκδόσεων ενός πλαισίου είναι δύσκολη, αλλά στο ίδιο σημείο, άλλα πλαίσια υποφέρουν όταν οι ενημερώσεις σταματούν εντελώς και δεν μπορούν να συμβαδίσουν με την υπόλοιπη τεχνολογία. Το 2010, και οι δύο AngularJS και Backbone κυκλοφόρησαν για πρώτη φορά. Σήμερα, το Angular βρίσκεται στην πέμπτη μεγάλη έκδοση και το Backbone δεν είναι εντελώς γνωστό. Τα επτά χρόνια μοιάζουν πολύ. Εάν δημιουργείτε ιστότοπους, πιθανότατα έχουν αλλάξει εντελώς στην αισθητική και τη λειτουργία. Εάν δημιουργείτε μια εφαρμογή, το στοίχημα σε λάθος πλαίσιο μπορεί να βάλει την εταιρεία σε μια δύσκολη - και δαπανηρή - κατάσταση αργότερα, όταν τα πράγματα πρέπει να ξαναγραφούν.

Όταν το μόνο που έχετε είναι ένα σφυρί, όλα μοιάζουν με καρφί. Εάν χρησιμοποιείτε συχνά πλαίσια ανάπτυξης ιστού, αυτό πιθανότατα συνέβη σε εσάς, όπου μια μεμονωμένη βάση κώδικα καθορίζει το σχήμα του κώδικα που χρησιμοποιείτε στο μέλλον, ακόμα κι αν σχετίζεται μόνο περιφερειακά. Ας υποθέσουμε ότι πρόκειται να δημιουργήσετε μια πλατφόρμα όπως το YouTube και θέλετε να χρησιμοποιήσετε το Framework X. Μπορεί να υπάρχει ένα σημείο όπου, ακόμα κι αν ακούγεται γελοίο σε αυτήν την ημέρα και την ηλικία, αποφασίζετε να χρησιμοποιήσετε το Flash για τα βίντεο γιατί αυτό έρχεται ενσωματωμένο με το πλαίσιο.

Τα πλαίσια έχουν απόψεις και είναι ισχυρές. Η αντίδραση, για παράδειγμα, σας αναγκάζει να χρησιμοποιήσετε το JSX με συγκεκριμένο τρόπο. Μπορείτε να δείτε τον κώδικα να χρησιμοποιείται με αυτόν τον τρόπο παντού. Υπάρχει εναλλακτική λύση; Ναί. Αλλά ποιος το χρησιμοποιεί; Αυτό δεν είναι πάντα κακό, αλλά αν πρέπει να εκτελέσετε πολύπλοκες κινούμενες εικόνες, ίσως χρειαστείτε μόνο ένα πλαίσιο για κινούμενη εικόνα και όχι το σύνολο του React. Έχω δει ανθρώπους να κάνουν τρελά πράγματα όπως να προσθέσουν το jQuery σε μια σελίδα μόνο για να προσθέσουν έναν κόμβο σε ένα στοιχείο, κάτι που θα μπορούσε να επιτευχθεί στη βανίλια JS με document.getElementById('id_of_node').appendChild(node);.

Το Eval είναι κακό, αλλά .innerHTML Είναι Machiavellian

Θέλω να αφιερώσω χρόνο για να εξερευνήσω αυτό το σημείο ξεχωριστά, γιατί νομίζω ότι αυτός είναι ένας από τους λόγους για τους οποίους περισσότεροι άνθρωποι δεν κωδικοποιούν χωρίς πλαίσια. Όταν δείτε πώς λειτουργεί ο περισσότερος κώδικας όταν προσπαθείτε να προσθέσετε κάτι στο DOM, θα βρείτε μια δέσμη HTML που εισάγεται από το .innerHTML ιδιοκτησία. Όλοι φαίνεται να συμφωνούμε ότι eval είναι κακό για την εκτέλεση κώδικα JavaScript, αλλά θέλω να βάλω .innerHTML στο προσκήνιο εδώ. Όταν εισάγετε κώδικα HTML ως απλή συμβολοσειρά, χάνετε οποιαδήποτε αναφορά που μπορεί να είχατε σε οποιονδήποτε από τους κόμβους που δημιουργήσατε. Είναι αλήθεια ότι μπορείτε να τα επαναφέρετε χρησιμοποιώντας το getElementsByClassName ή να τους αναθέσετε ένα id, αλλά αυτό είναι λιγότερο από πρακτικό. Όταν προσπαθείτε να αλλάξετε την τιμή ενός από τους κόμβους, θα βρείτε τον εαυτό σας να αποδίδει ξανά ολόκληρο το HTML.

Αυτό είναι καλό όταν ξεκινάτε την κωδικοποίηση. Μπορείτε να κάνετε πολλά απλά πράγματα εύκολα χωρίς μεγάλη εμπειρία. Το πρόβλημα συμβαίνει με την πολυπλοκότητα των σύγχρονων ιστότοπων, οι οποίοι τείνουν να μοιάζουν περισσότερο με εφαρμογές - αυτό σημαίνει ότι πρέπει να αλλάζουμε συνεχώς τις τιμές των κόμβων μας, η οποία είναι μια λειτουργία υψηλού κόστους, αν το κάνετε επανατοποθετώντας ολόκληρη τη δομή μέσω .innerHTML. Το React επιλύει αυτό το πρόβλημα αποτελεσματικά μέσω ενός σκιώδους DOM και το Angular το αντιμετωπίζει χρησιμοποιώντας δέσμευση ως έναν εύκολο τρόπο τροποποίησης μιας τιμής που εμφανίζεται σε μια σελίδα. Ωστόσο, μπορεί επίσης να επιλυθεί αρκετά εύκολα παρακολουθώντας τους κόμβους που δημιουργείτε και αποθηκεύοντας αυτούς που θα επαναχρησιμοποιηθούν ή θα ενημερωθούν σε μεταβλητές. Υπάρχουν επίσης άλλοι λόγοι για να μείνετε μακριά από .innerHTML γενικά.

Οι μεγαλύτεροι μύθοι για την κωδικοποίηση χωρίς πλαίσια

Ο χρόνος είναι χρήμα. Ναι, επαναφέρω αυτήν την ιδέα από νωρίτερα. Πολλοί άνθρωποι αισθάνονται σαν να σταματήσουν να χρησιμοποιούν ένα δημοφιλές πλαίσιο ιστού, θα αφιερωθούμε αμέσως στο Διαδίκτυο της δεκαετίας του '90, όταν η αγαπημένη ετικέτα όλων, τα περιστρεφόμενα GIF σε έναν ιστότοπο Geocities ήταν ισχίο και νευρικό, η Alta Vista ήταν η αναζήτηση για αναζητήσεις στον Ιστό , και οι μετρητές επιτυχίας ήταν πανταχού παρόντες.

χακαρισμένοι αριθμοί πιστωτικών καρτών που λειτουργούν

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

Ο κωδικός μου θα είναι μεγαλύτερος από το Σινικό Τείχος. Το γράψιμο χωρίς πλαίσιο είναι σαν να αγοράζετε μια ταινία αντί να εγγραφείτε σε μια υπηρεσία ροής. Δεν έχετε άμεση πρόσβαση σε εκατοντάδες ταινίες που θέλετε να παρακολουθήσετε, αλλά δεν χρειάζεται επίσης να ξοδέψετε χρήματα σε χιλιάδες άλλες ταινίες που ποτέ δεν θα σκεφτόσασταν να πραγματοποιήσετε λήψη από το κατάστημα. Μπορείτε απλά να γράψετε ό, τι χρειάζεστε.

Είναι ο μεσάζων χρήσιμος; Σίγουρος. Αλλά δεν είναι συνήθως απαραίτητη . Κάθε γραμμή κώδικα που γράφετε έχει μεγαλύτερη σημασία, καθώς δεν χρειάζεται να προσαρμοστείτε στις απαιτήσεις ενός πλαισίου. Μπορεί να αισθάνεστε σαν να γράφετε περισσότερο κώδικα με καθαρή JavaScript επειδή ο τρόπος δημιουργίας των στοιχείων DOM παίρνει γραμμές για να δημιουργήσει ένα στοιχείο, να το συνδέσει στο DOM και ίσως να προσθέσει μια τάξη για στυλ, σε αντίθεση με την κλήση μιας γραμμής κωδικός στο JSX. Αλλά εάν συγκρίνετε τον κώδικα χρησιμοποιώντας μια βιβλιοθήκη όπως το jQuery ή το React, το vanilla JS μπορεί να είναι αρκετά παρόμοιο σε μήκος. Μερικές φορές είναι μεγαλύτερη, αλλά μερικές φορές είναι επίσης μικρότερη.

Δεν χρειάζεται να ανακαλύψετε ξανά τον τροχό. Το μάντρα των καθηγητών πληροφορικής παντού. Και είναι αλήθεια - απλά δεν χρειάζεται να σημαίνει συγκεκριμένα πλαίσια. Η αποστολή ενός αιτήματος Ajax για φόρτωση ή αποθήκευση δεδομένων είναι απαίτηση σε σχεδόν κάθε εφαρμογή ιστού, για παράδειγμα, αλλά το να μην έχετε πλαίσιο δεν σημαίνει ότι πρέπει να γράφετε ξανά τον κώδικα κάθε φορά. Μπορείτε να δημιουργήσετε τη δική σας βιβλιοθήκη ή βάση κώδικα ή μπορείτε να εξαγάγετε κώδικα από άλλους. Όσο μικρότερο είναι, τόσο πιο εύκολο είναι να τροποποιήσετε ή να προσαρμόσετε ανάλογα με τις ανάγκες, οπότε είναι χρήσιμο όταν χρειάζεστε κάτι συγκεκριμένο για ένα έργο. Είναι πιο εύκολο να τροποποιήσετε 100-200 γραμμές κώδικα από την πλοήγηση στο βουνό των αρχείων που ενδέχεται να περιέχει μια βιβλιοθήκη ή ένα πλαίσιο τρίτων.

σε τι γράφεται ο κόμβος js

Θα λειτουργήσει μόνο για μικρά έργα. Αυτός είναι ένας πολύ κοινός μύθος, αλλά δεν ισχύει καθόλου. Προς το παρόν, εργάζομαι σε ένα ολόκληρο σύστημα για τη διαχείριση όλων των πτυχών μιας εταιρείας στο διαδίκτυο σε ένα μόνο μέρος, συμπεριλαμβανομένης μιας ενότητας που μοιάζει με το Google Drive. Είτε με πλαίσια είτε χωρίς αυτά, περνάω πολύ παρόμοια βήματα και αντιμετωπίζω παρόμοια προβλήματα. Η διαφορά είναι αμελητέα. Ωστόσο, χωρίς πλαίσια, ολόκληρος ο κώδικάς μου είναι μικρότερος και πιο εύκολα διαχειρίσιμος.

ΘΕΛΩ ΑΠΟΔΕΙΞΗ

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

Ο παρακάτω κώδικας χρησιμοποιεί το ισοδύναμο jQuery .innerHTML:

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

var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById('brand-images'); for (var iBrand = 0; iBrand

Ο αρχικός κώδικας jQuery είχε μήκος έξι γραμμών, ενώ η λύση vanilla JS χρειάστηκε δώδεκα. Για την επίλυση του προβλήματος, η απόκρυψη κάθε εικόνας έως ότου φορτωθεί, χρειάζεται κωδικοποίηση δύο φορές περισσότερο. Ας δούμε λοιπόν την εναλλακτική λύση. Μπορεί να λυθεί και στο jQuery; Τσέκαρέ το:

img_out += ' '; function showImage(image){ image.parentNode.style.display = ''; }

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

Ας ρίξουμε μια ματιά στο React:

function BrandLink(props) { var url = 'images/' + props.brand + '.png'; return ( ); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (); }); return ( {links} ); } } ReactDOM.render(, document.getElementById('root'));

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

Για κάθε παράδειγμα, τα αποτελέσματα θα είναι διαφορετικά. Μερικές φορές, το jQuery θα είναι μικρότερο. Μερικές φορές, το React θα κερδίσει. Υπάρχουν στιγμές που η βανίλια JS μπορεί να είναι μικρότερη από τις δύο. Σε κάθε περίπτωση, ο στόχος εδώ δεν ήταν να αποδείξει ότι το ένα ήταν εγγενώς ανώτερο από το άλλο, αλλά να δείξει ότι δεν υπάρχει σημαντική διαφορά μεταξύ της χρήσης vanilla JS και της χρήσης ενός πλαισίου όσον αφορά το μήκος κώδικα.

συμπέρασμα

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

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

Σχετίζεται με: Τα πλεονεκτήματα και τα οφέλη των Micro Frontends