Webfejlesztőként megpróbálom rendszeresen felmérni az eszköztáramat, és meg tudom állapítani, hogy tudok-e nélkülözni ezt vagy azt az eszközt. A közelmúltban azt vizsgáltam, hogy milyen egyszerű fejleszteni egy komplex kezelőfelületet egy kezelőfelület nélkül.
Mi az a JavaScript keretrendszer?
Leegyszerűsítve: a JavaScript keretrendszer olyan eszköz, amellyel fejlett webes alkalmazásokat, különösen a SPA-kat fejleszthet ki.
A nap folyamán a webfejlesztők a kezelőfelület logikáját valósítanák meg a vanília JS-re és a jQuery-re támaszkodva. De ahogy az elülső alkalmazások egyre bonyolultabbak lettek, az eszközök emelkedtek, hogy megfeleljenek ennek a bonyolultságnak.
A ma népszerű kereteknek néhány alapvető közös vonása van. A legtöbb kezelői keretrendszer / könyvtár, a Vue-tól a React-ig, a következők valamilyen kombinációját kínálja:
- Az állapot és a nézet szinkronizálása
- útvonalválasztás
- Sablonrendszer
- Újrafelhasználható alkatrészek
Szükség van-e még a keretrendszerekre?
Attól függ, hogyan hangsúlyozza a szükséges szót . Sokan azt állítják, hogy a front end keretrendszerekre nincs és soha nem is volt szükség. Pedig nagyon hasznos eszközök.
Tehát kérdés: a mai JQuery a keretrendszer? Megoldják-e az általuk megoldott problémákat a DOM API-hoz hasonló változtatások?
Nehéz megmondani, de a natív JS fejlesztései, a webkomponensek specifikációi és a könnyen konfigurálható építőeszközök miatt a keretrendszer nélküli SPA fejlesztése olyan egyszerűvé vált, mint valaha.
Ennek további vizsgálatához kifejlesztettem egyoldalas alkalmazást, amely csak vanília JavaScriptet, natív web-összetevőket és Parcel-t használt. Egy maroknyi buktató és nehézség volt az út során, amelyek rávilágítottak a JS keretrendszerének erősségeire.
Ugyanakkor, miután túlléptem a kezdeti akadályokat, meglepett, hogy milyen egyszerű volt egyoldalas alkalmazást létrehozni csak vanília JS-sel.
Áttekintés
Az alkalmazás egyszerű. Ez egy receptalkalmazás, amely alapvető CRUD képességekkel rendelkezik. A felhasználó létrehozhat, szerkeszthet, törölhet, kedvenceket és szűrhet egy receptlistát.
Alkatrészek
Webkomponens létrehozása szintén egyszerű. Létrehoz egy kiterjesztő osztályt HTMLElement(vagy HTMLParagraphElementígy tovább), majd az adott osztály segítségével meghatározhat egy egyéni elemet.
Használhatja az életciklus-kampókat is, mint például a connectedCallback, disconnectedCallback, attributeChangedCallback.
útvonalválasztás
A receptek alkalmazásának útvonala is meglehetősen egyszerű. Adott egy navigációs esemény, az alkalmazás tartalmát a megfelelő webkomponensre állítottam.
Kezdetben egy Vanilla JS Router nevű npm csomagot használtam. A böngésző előzményeinek API-jával nem olyan bonyolult a sajátját 100-nál kevesebb kódsorban megvalósítani! Megjegyzés: Nem igazán komplex logikát valósítok meg, például útvonalvédőket.
Ez egy gyors összefoglaló. Ezt a cikket ésszerûen szeretném tartani. Lehet, hogy írok egy utólagos bejegyzést, alaposabb magyarázattal a pályázatról. Néhány olyan szórakoztató funkciót valósítottam meg, mint a végtelen görgetés, az egyedi drag and drop feltöltő és még sok más!
Visszatekintő
Az alkalmazás létrehozása után szántam egy kis időt arra, hogy az elejétől a végéig végiggondoljam az egész folyamat előnyeit és hátrányait. Kezdem a rossz hírrel.
Hátrányok
A specifikáció még mindig folyik
A webkomponens specifikációja régi és új. Sokkal hosszabb ideig létezik, mint azt eredetileg gondoltam. A webkomponenseket Alex Russell mutatta be először a Fronteers Conference 2011 konferencián. A webkomponensek mögötti nyomás azonban valóban növekedett az elmúlt egy-két évben. Mint ilyen, még mindig sok a zűrzavar a specifikációban. Például felhagytak a HTML-importálással, bár a legtöbb dokumentáció / erőforrás még mindig hivatkozik rájuk.
Tesztelés
A natív web-összetevők teszteléséhez nincs sok dedikált erőforrás. Van néhány ígéretes eszköz, mint például a skatejs ssr és a Polymer webkomponens-tesztelője. De ezek az eszközök valóban a saját könyvtárukkal való használatra készültek. Ez bizonyos nehézségeket okoz a natív web-összetevők használatakor.
Változásészlelés
Hihetetlen olyan alaprendszer, amely automatikusan szinkronban tartja a nézetet az adatmodellel. Ez vonzott sokakat elsősorban a szögletes és más keretek közé.
Az állapot szinkronban tartása a nézettel nem olyan nehéz kis méretben. De nagyon gyorsan kikerülhet az irányításból, és azon kapja magát, hogy rengeteg eseményhallgatót és lekérdezőt ad hozzá.
Az árnyék DOM
Nagyon el vagyok tépve az árnyék DOM-tól. Egyrészt szeretem a beágyazás gondolatát. Ez egy ésszerű tervezési minta, könnyebben kezelhetővé teszi a stílus kaszkádját, leegyszerűsíti az aggodalmait stb. Ugyanakkor problémákat is felvet, ha azt akarja, hogy bizonyos dolgok behatoljanak ebbe a beágyazásba (például egy megosztott stíluslapba), és folyamatban vannak a viták a legjobb módszerről.
DOM struktúrák létrehozása
Az olyan keretek / könyvtárak nagyszerűségének része, mint az Angular és a React, hogy ők uralják DOMain-jukat. Vagyis kiválóan alkalmasak a DOM struktúráinak hatékony renderelésére és újrarenderelésére. Az Angular University blogból:
Az Angular nem generál HTML-t, majd továbbítja a böngészőnek, hogy elemezze azt, ehelyett az Angular közvetlenül a DOM adatstruktúrákat generálja!A szögletes például a jQuery-vel ellentétben közvetlenül alakítja a DOM adatstruktúrákat. Vagyis ahelyett, hogy HTML-t adna át a böngészőnek, hogy elemezze, majd megjelenítse a DOM adatstruktúráiban. Ez jobban teljesít, mivel kiküszöböli ezt az elemzési lépést. A Virtuális DOM szintén elég hasznos, mivel megakadályozzák, hogy minden újból megjelenítsen minden alkalommal, amikor frissíteni kell a nézetet.
Előnyök
Másrészt vannak tagadhatatlan előnyei az alkalmazások ilyen módon történő fejlesztésének:
Csomag mérete
A végtermék (hangsúlyozva a kannát ) lehet sokkal kisebb és kompaktabb, mint bármi, amit modern keretrendszerrel fejlesztettek ki. Például a teljes funkcionalitású receptek alkalmazásának utolsó összeállítása kevesebb, mint a fele akkora volt, mint egy friss Angular build.
Megjegyzés: Ezek a frissített, optimalizált csomagméretek.
Megértés
Ha csak egy keretrendszerrel és annak CLI-jével fejlesztettél ki, akkor nagyszerű gyakorlat lehet webes alkalmazás készítése extra eszközök nélkül. Mint olyan ember, aki el akarja érni a webfejlesztés bizonyos mértékű elsajátítását (amennyire lehetséges), elengedhetetlen volt számomra, hogy minél több gyakorlati tapasztalatot szerezzek az építõeszközökkel, a böngészõ API-kkal, a tervezési mintákkal stb.
Teljesítmény
Elképesztő, hogy mit csinálnak ezek a kezelői keretrendszerek és könyvtárak a színfalak mögött. Teljesítményárat azonban fizethet, ha bármelyik alkalmazása mellett dönt; nem létezik ingyenes ebéd. Számos potenciális teljesítményhúzás létezik: legyen szó elpazarolt újrarendezésről, redundáns hallgatókról, mély objektum-összehasonlításról, vagy szükségtelen és nagy DOM-manipulációkról. Itt sok bonyolultságot vághat ki a dolgok nulláról történő végrehajtásával.
Úgy tűnik, hogy az Angular és a React csapata ismeri ezeket a buktatókat, és olyan dolgokat biztosítottak, mint például a shouldUpdate metódus felülbírálása és az onPush ChangeDetection, a teljesítmény további optimalizálásának eszközeként.
Egyszerűség és kódtulajdonság
Kockázatot vállal, amikor harmadik fél kódját beviszi. Ezt a kockázatot kipróbált könyvtárak / keretrendszerek csökkentik, de soha nem szüntetik meg. Ha megúszhatja a kódírást maga vagy a csapata, csökkentheti ezt a kockázatot, és fenntarthatja a be- és kimenő kódbázist.
Jegyzetek és érdekes apróságok
Robbanásom volt a Parcellel. Időnként kissé korlátozottabbnak tűnt, mint a Webpack, amikor megpróbáltam megkerülni bizonyos éles eseteket, de úgy találtam, hogy a „nulla konfiguráció” tagsor többnyire igaz.
Számomra az is világos, hogy sokan a React könyvtárat, a Vue pedig progresszív keretet jelölnek. Bár megértem ennek okait, úgy gondolom, hogy a React, a Vue és a Angular megoldja ugyanazokat a problémákat. Így mindet együtt vizsgálom a „keretek” kifejezés alatt.
Miért ne használná a Stencilt vagy a Polymert? Szerettem volna minél jobban elkerülni a csomagok, könyvtárak és keretek használatát. Meg akartam nézni, milyen messze emelkedtek a webes szabványok, hogy megfeleljenek a modern fejlesztéseknek (kivéve a build eszközöket).
Biztos vagyok benne, hogy számos más módja van a SPA vagy a front end alkalmazás fejlesztésének nagy keretrendszer vagy könyvtár nélkül, itt kipróbáltam egy utat, és szívesen hallanék másokról!
Összegzés
A keretrendszer használatának vagy használatának eldöntésére vonatkozó nagyszerű heurisztika az, amit én „csúcspontnak” nevezek. Az alkalmazás növekedésével eljön az a pont, ahol végül saját keretrendszert hoz létre a funkcionalitás és a struktúra újrafelhasználása érdekében. Például van egy csomó űrlap, és újrafelhasználható logikát szeretne létrehozni a reaktív ellenőrzéshez.
Ha erre a pontra jut, el kell döntenie, érdemes-e időt fektetnie a rendszerek létrehozásába, hogy megvalósítsa azt, amit gyorsan megvalósíthat egy keretrendszer vagy egy könyvtár segítségével. Különböző billenési pontok lesznek attól függően, hogy milyen időbeli vagy költségvetési korlátok vannak, de a keretrendszerek továbbra is nagyon relevánsak a megfelelő forgatókönyvek alapján.
Ez azt jelenti, hogy a keretek nagy részét valószínűleg könnyebb megtenni kisebb könyvtárakkal és / vagy natív kódokkal az idő múlásával. Vegyük példának a jelentkezésemet. Ugyanakkor, ha a nagy keretek és könyvtárak sokoldalúak maradnak, morfondírozhatnak, alkalmazkodhatnak és megmaradhatnak. Ha nem, akkor a jQuery-ként végződhetnek - a múlt eszköze többnyire.
Következtetés
Összegzésképpen elmondható, hogy ígéretes módszerek vannak a komplex front end alkalmazások keretrendszer nélküli fejlesztésére. A web-összetevők, például a web-összetevők specifikációja azonban még mindig fejlődik, és vannak olyan kinkek, amelyeket ki kell dolgozni. A keretek még mindig sok elképesztő dolgot csinálnak, és sokkal gördülékenyebbé tehetik a fejlődést.
Ebben az időben, amennyire meg tudom mondani, a keretrendszer használatának előnyei gyakran felülmúlják a hátrányokat. Ha azonban a keretrendszerek nem kezdenek új problémákat megoldani és tovább fejlődni, akkor ezek végül elhalványulnak.
Erőforrások
Szögletes kezdőknek szóló útmutató: Miért szögletes? A legfőbb előnyök
Megjegyzés: Ez a bejegyzés a folyamatban lévő Angular for Beginners sorozat része, itt van a teljes sorozat: Angular For Beginners… blog.angular-university.io Összehasonlítás más keretrendszerekkel - Vue.js
Vue.js - A Progressive JavaScript Framework vuejs.org Teljesítmény optimalizálása - React
Belsőleg, válaszolnak felhasználása több ügyes technikát, hogy minél kevesebb költséges DOM kezeléséhez szükséges frissíteni a ... reactjs.org Web Components
Fejlesztőként mindannyian tudjuk, hogy a kód lehető legnagyobb mértékű újrafelhasználása jó ötlet. Ez hagyományosan nem így volt ... developer.mozilla.org A modern JavaScript-keretek legmélyebb oka
Sok-sok embert láttam olyan modern keretrendszert használni, mint a React, Angular vagy a Vue.js vakon. Ezek a keretrendszerek biztosítják ... medium.com A webkomponensek stílusának megosztott stíluslap használatával
A webkomponensek a web csodálatos új funkciói, amelyek lehetővé teszik a fejlesztők számára, hogy meghatározzák saját HTML elemeiket ... www.smashingmagazine.com