“A zene hangja” talán azt hirdeti: “Kezdjük a legelején, egy nagyon jó helyen”. De szinte minden fejlesztő tudja, hogy ez egy ostoba terv. A megfelelő hely a kezdéshez egy szilárd alap, amelyet egy nagyszerű nyílt forráskódú fejlesztőcsapat épít. Klónozd a kemény munkájukat, majd csak annyi kódot adj hozzá, hogy a sajátoddá tedd. Nem kell megismételni azt, amit mindenki csinált már korábban.
Ez egy egyszerű terv – ha egyszer úgy döntesz. Sajnos ennek az alapnak a kiválasztása majdnem olyan nehéz lehet, mint a legelején kezdeni. A webes keretrendszerek világa nagyon aktív fejlesztési terület, és több tucatnyi jó nyílt forráskódú projekt létezhet, amelyek remek kiindulópontjai lennének a projektednek.
A helyzetet tovább rontja, hogy a különböző projekteket létrehozó különböző csapatok azért indultak el más-más úton, mert komoly filozófiai nézeteltéréseik voltak a többi lehetőséggel. Megnézték a többi keretrendszert, és úgy döntöttek, hogy ők jobbat tudnak. Más szóval, okkal tették, és lehet, hogy egyetértesz a döntésükkel, de az is lehet, hogy nem.
Az alábbi jó helyek listája szándékosan kihagyja a piacvezető Reactot, Angular-t és Vue-t, csak hogy kicsit egyszerűbbé tegye a dolgokat. Ez nem jelenti azt, hogy a három nagy rossz. Még mindig lehet, hogy ők a megfelelőek számodra. Csak arról van szó, hogy állandóan róluk beszélnek, és ezek a viták kihagynak néhány nagyon jó más lehetőséget.
Egy csomó jó ok van arra, hogy a legnépszerűbbet válasszuk. Sokan a te helyedben körülnéztek, és sokan közülük jó okkal választották a Reactot, az Angular-t vagy a Vue-t. De ez akkoriban volt. Időközben néhány okos ember újabb keretrendszereket hozott létre, amelyek gyorsabbak, egyszerűbbek, erősebbek, vagy a szuperlatívuszok nagy halmazának bármelyikét.
A legtöbb alábbi esetben a csapatok a keretrendszer természetének újragondolásával hoztak létre valami érdekes és erős dolgot. Ez egy díszes kifejezés arra, hogy végül töröltek egy funkciót, ezáltal hatékonyabbá tették a keretrendszert, és így csökkentették a memóriaigényét, felgyorsították az indítási időt, vagy általában véve fürgébbé tették. Vagy néhány esetben olyan új ötleteket adtak hozzá, amelyek a jövőben szabványossá válhatnak.
Ha van időd befektetni, itt van egy lista a többi érdekes választásról. Nem feltétlenül megfelelőek néhány ember számára, és biztosan nem mindenki számára a legjobb választás, de lehet, hogy az Ön számára jobb választás lehet. Az Ön feladata, ha úgy dönt, hogy elfogadja, hogy készítsen egy szilárd leírást a webes alkalmazásáról, írja le viszonylag határozottan a különböző felhasználási eseteket, majd ennek figyelembevételével értékelje ezeket az eszközöket.
Talán kedveli a kódtervezés egy bizonyos megközelítését. Talán az alkalmazásodnak nincs szüksége a vastagabb, népszerűbb keretrendszerek néhány funkciójára. Tucatnyi oka lehet annak, hogy beruházzon valamelyik másik útra. Lehet, hogy valamelyik csodát tesz az alkalmazásoddal.
Petit DOM
Ha szereted a virtuális DOM ötletét, de nem akarsz minden olyan korlátozást, ami a React, a Vue vagy a többi nagynevű keretrendszer embereinek gondolkodásmódjának elfogadásával jár, akkor a Petit DOM a megfelelő út. Kapsz egy apró kódot, amellyel manipulálhatod a címkék virtuális gyűjteményét, majd migrálhatod őket a valódi DOM-ba. Minden más a komponensek szerkezetével és a rendereléssel kapcsolatban csak rajtad múlik. Ha a komponenseid egyszerűek, vagy ha valami szuperkomplex renderelési hierarchiát akarsz létrehozni, ami csak a tiéd lesz, akkor ez lehet az alapod, mert csak egy eszközt biztosít a DOM virtualizálásához.
Surplus
A virtuális DOM talán nem mindenkinek való. Helyet foglal, így ha a manipulációid nem túl bonyolultak, akkor akár át is vezetheted az utasításaidat egyenesen a hivatalos DOM-ba. A Surplus könyvtár pontosan ezt teszi. Fogja mindenki kedvenc jelölő JSX-ét, és lefordítja néhány olyan kóddá, amely manipulálja a valódi DOM-ot. Ahogy a reklámszakmában mondják, kivágja a közvetítőt. Nincs különbségtétel. Nincs titkos extra réteg. Csak a valódi DOM tiszta manipulációja. Ha a kódod elég egyszerű és közvetlen ahhoz, hogy csak néhány dolgot csinálj a DOM-mal, akkor miért bajlódnál a virtuális eltereléssel?
RE:DOM
Egy másik lehetőség azok számára, akik nem akarnak memóriát fektetni egy virtuális Domba, egy aprócska könyvtár (2KB), a RE:DOM. A RE:DOM tartalmaz néhány alapvető rutint, amelyek segítségével néhány egyszerű JavaScript hívással létrehozhatjuk az összes taget és komponenst. A szintaxis sokkal közelebb áll a CSS-hez, így néhány billentyűleütéssel meglehetősen bonyolult címkéket adhatsz meg azonosítókkal és osztályokkal. A “kisebb, mint” (<) és a “nagyobb, mint” (>) billentyűk hálásak lesznek.
Mithril
Nem minden alternatíva apró és minimalista. A Mithril ebben a kontextusban talán “közepes méretű” keretrendszernek nevezhető, bár csak körülbelül 8 KB-ot nyom. Mindez a kód a többihez hasonlóan egy virtuális DOM-ot épít egy hatékony frissítési mechanizmussal, de egy szabványosított eszközkészletet is tartalmaz, amely számos szabványos kihívást, például az útválasztást és az XMLHttpRequest-hívásokat kezeli. A projekt tervezői azt szeretnék, hogy a Mithril-projektek viszonylag szabványosak legyenek, és úgy érzik, hogy ennek a kódnak a fő könyvtárhoz való hozzáadása növeli a szabványosítást. Ha ez nem lenne elég, néhány szabványos formázást és idiomatikus struktúrát is erőltetnek.
Bobril
Ha szereted a React virtuális DOM-ját és állapotfüggő komponenseit, és szeretsz TypeScriptben programozni, akkor a Bobril vagy annak Angular-barát unokatestvére, az ngBobril pont megfelelő lehet. A keretrendszer néhány benchmarkban következetesen sokkal gyorsabb, mint a React vagy az Angular, talán a gyorsabb diff algoritmusok és az izomorf JavaScript támogatásának hiánya miatt. Vannak továbbá rövidített függvények a CSS-manipulációhoz és egy teljes állapotkezelő réteg, a BobX, ha szükséged van rá.
Marko
Ha töltöttél már időt Pez-adagolókra vagy más gyűjteményekre licitálva, akkor már megtapasztaltad a Marko erejét, egy karcsú, gyors keretrendszerét, amelyet az eBay nyílt forráskódú licenc alapján oszt meg. A legszebb része talán a nagyon könnyű templating szintaxis, amely okosan eltávolítja a legtöbb felesleges zsírt a HTML-ből, így a szerkezetet a behúzás határozza meg, és nem sok minden más. A renderelőmotor pedig nagyon gyors, képes 60fps-nél gyorsabban frissülő, táncoló DIV-ek bonyolult konstellációinak meghajtására.
Svelte
A szabványos webes keretrendszeredhez tartozik egy fordító és egy letöltött könyvtár, amely futásidőben kezeli azt, amit a fordító produkál. A kétlépcsős folyamat nagyon bonyolult kódot tesz lehetővé azon az áron, hogy az oldal megnyitásakor minden alkalommal várni kell a futásidejű könyvtár letöltésére és elemzésére. A Svelte fordító megszabadul ettől a bonyolultságtól azáltal, hogy közel tiszta JavaScriptet köp ki, amely szinte magától is futtatható, bár csak néhány újabb böngészőben (pl. Chrome, Firefox, Opera és IE10). Ez egy okos építészeti fogás, amely nagyon könnyű, kevés memóriát igénylő weboldalakat eredményez.
Inferno
Az Inferno egy másik keretrendszer, amelyet azért hoztak létre, hogy sok mindent tudjon abból, amit a React, de kisebb letöltési és gyorsabb futási idővel. Ennek nagy részét úgy éri el, hogy kidobja a bonyolult szintetikus eseménymechanizmust, és csak a legfontosabbakra koncentrál, mint például az onClick. Az API sok más része hasonló, ha nem is ugyanaz, így viszonylag egyszerűen áthelyezhető a kód, ha nincs szüksége az eseményoptimalizáló rétegre.
Preact
A React leszármazottak közül az egyik legkisebb a Preact, egy hommage, amely a legtöbb értékes funkciót, például virtuális DOM-ot és kifinomult komponenseket kínál, de levetkőzi a szintetikus eseménykezelőket és a kellékek egy részét az öröklésből. Míg az Inferno csak a legfontosabb eseményeket próbálja implementálni, mint például a onClick, addig a Preact meg sem próbál semmit kezdeni az eseményekkel, hagyva, hogy a böngésző natív addEventListener-jára hagyatkozzunk. Az olyan funkciók elhagyásával, amelyek (szerintük) nem adnak hozzá sokat, még kisebbé teszik a letöltésüket. Ez egy kicsit kompromisszumos, mert a benchmarkok azt mutatják, hogy a Preact egy kicsit lassabb, mint az Inferno. Természetesen az Ön alkalmazása eltérő lehet, és az Ön mérföldszámai eltérőek lehetnek. Ha tényleg tiszta kompatibilitásra van szükséged a React-tal, akkor van még egy könyvtár is (preact-compat), ami a legtöbb problémát kijavítja a build során.
Hapi
Sok keretrendszer érkezik egyetlen csomagban. A Hapi inkább bővítmények gyűjteménye, több tucatnyi kóddarab konstellációja, amelyeket tetszés szerint keverhetsz a stackedbe. A hitelesítés, az engedélyezés és a naplózás olyan házimunkák, amelyeket tetszőleges számú opcióval lehet megoldani. Ha egy API-kkal teli mikroszolgáltatási architektúrát épít, a szabványosított Swagger plug-in automatikusan generálja a Swagger dokumentációt az alapkódból.
Koa
Néha meglehetősen összetett rutinok gyűjteményére van szükség, amelyek zsonglőrködnek a bejövő kérésekkel, és több, részben bonyolult változtatásra fordítják azokat. A Koa arra hivatott, hogy mindezen munka megszervezését egy kicsit egyszerűbbé tegye. A titka az, hogy a JavaScriptet általában uraló callback függvényeket aszinkron függvények halmazává alakítja, amelyek akkor tüzelnek, amikor a megfelelő idő van. Az egymásba ágyazott spagetti callback-halmokat egy kicsit tisztábbá alakítja.
Nest
A másik lehetőség a szerver komplexitásának megszelídítésére a Nest csapatától származik, akik egy vezérlőkkel, csövekkel és szolgáltatókkal teli architektúrát kínálnak, néhány őrzővel, elfogóval és kivételszűrővel kiegészítve a rend fenntartása érdekében. A keretrendszer modern és már a kezdetektől fogva készen áll a GraphQL- és mikroszolgáltatási kérések kezelésére.
Drupal, WordPress és Rails
A JavaScriptre épülő és a Node.js tetején futó keretrendszerek manapság a webfejlesztés világának pszichológiai központját töltik ki. De hiba lehet figyelmen kívül hagyni az előző generációt, amely PHP-ra épül, egy olyan alapot, amely gyorsabb, mint valaha, most, hogy a JavaScripthez hasonlóan just-in-time fordítóval is rendelkezik. A Ruby és a hozzá tartozó Rails keretrendszer pedig továbbra is a sziklaszilárd weboldalak sarokköveként szolgál.
Az előző generáció több mint egy évtizedes folyamatos fejlesztéssel és munkával harcedzett és jól bevált. Vannak kifinomult tervezők, akik témákat és skineket tudnak készíteni az alkalmazásokhoz. Jó eséllyel valaki már megépítette a szükséges funkciókkal rendelkező modulokat. Mielőtt tehát felfedeznél egy okos Node.js keretrendszert, fontold meg, hogy az egyik régies már sok mindent, ha nem mindent meg tud-e csinálni abból, amire szükséged van.
Vanilla JS
Elképzelhető, hogy gonosz áskálódásnak vagy talán “A császár új ruhái” szintű szatírának tartod, de nehéz vitatkozni a sikerével. A Vanilla JS egy olyan weboldal, amely azzal henceg, hogy keretrendszerét több weboldalon használják, mint “a jQuery, Prototype JS, MooTools, YUI és Google Web Toolkit együttvéve”. Ez a jQuery elterjedtségét tekintve lehet, hogy igaz, lehet, hogy nem, de nevessünk a burnuszon. Az oldalhoz tartozik egy aranyos kis szelektor is, amellyel különböző komponensekből, például Math, DOM, closures vagy reguláris kifejezésekből álló egyéni archívumot lehet összecsomagolni. Mindegy, mit választasz, az eredmény észbontóan nulla bájt hosszú. Próbáld meg legyőzni ezt!
A vicc lényege, hogy néha van értelme csak néhány szabványos elemet használni a JavaScriptben, és kihagyni az extrákat. Az olyan könyvtárak és keretrendszerek, mint a jQuery vagy a React részben a böngészők közötti őrjítő különbségek miatt indultak el. Ezek közül a különbségek közül sok eltűnt a szabványosításnak köszönhetően.
A Vanilla JS hívei persze nem néznek szembe azzal a ténnyel, hogy az olyan rövidített függvények, mint a $() nemcsak kényelmesek, hanem helyet is spórolnak a saját kódunkban. De ha csak alkalmanként fogjuk használni a document.getElementById-t, akkor ez talán nem is számít. Ha csak néhány függvényt fogsz hozzáadni a weboldaladhoz, és ezek a függvények néhány alapvető dolgot fognak elvégezni, a sima vanília JavaScript lehet a leggyorsabb keretrendszer számodra.