”Sound of Music” saattaa saarnata: ”Aloitetaan aivan alusta, erittäin hyvästä paikasta aloittaa.” Mutta lähes jokainen kehittäjä tietää, että se on typerä suunnitelma. Oikea paikka aloittaa on vankka perusta, jonka loistava avoimen lähdekoodin kehittäjien tiimi on rakentanut. Kloonaa heidän kova työnsä ja lisää sitten juuri sen verran koodia, että teet siitä oman. Ei tarvitse toistaa sitä, mitä kaikki ovat tehneet ennenkin.
Se on helppo suunnitelma – kunhan vain valitset. Valitettavasti tuon perustan valitseminen voi olla melkein yhtä vaikeaa kuin aivan alusta aloittaminen. Verkkokehysten maailma on hyvin aktiivinen kehitysalue, ja siellä saattaa olla kymmeniä hyviä avoimen lähdekoodin projekteja, jotka olisivat loistavia lähtökohtia projektillesi.
Pahimmaksi asian tekee se, että eri tiimit, jotka ovat luoneet näitä eri projekteja, ovat lähteneet eri tielle, koska heillä oli vakavia filosofisia erimielisyyksiä muiden vaihtoehtojen kanssa. He katsoivat muita kehyksiä ja päättivät, että he pystyisivät parempaan. Toisin sanoen, he tekivät sen syystä, ja voit olla tai olla eri mieltä heidän päätöksestään.
Alla olevasta hyvien aloituspaikkojen luettelosta jätetään tarkoituksella pois markkinajohtajat React, Angular ja Vue, jotta asiat olisivat hieman yksinkertaisempia. Se ei tarkoita, että kolme suurta olisivat huonoja. Ne saattavat silti olla sinulle sopiva vaihtoehto. Niistä vain puhutaan jatkuvasti, ja näissä keskusteluissa jätetään pois joitakin melko hyviä muita vaihtoehtoja.
On paljon hyviä syitä valita suosituimmat. Monet ihmiset sinun asemassasi katsoivat ympärilleen ja monet heistä valitsivat Reactin, Angularin tai Vuen hyvästä syystä. Mutta se oli silloin. Sillä välin jotkut fiksut ihmiset ovat luoneet uudempia kehyksiä, jotka ovat nopeampia, yksinkertaisempia, vahvempia tai mitä tahansa isosta joukosta superlatiiveja.
Useimmissa alla olevissa tapauksissa tiimit loivat jotain kiehtovaa ja voimakasta keksimällä kehyksen luonteen uudelleen. Tämä on hieno tapa sanoa, että he päätyivät poistamaan jonkin ominaisuuden, mikä tekee kehyksestä tehokkaamman ja siten vähentää sen tarvitseman muistin määrää, nopeuttaa käynnistymisaikaa tai tekee siitä yleisesti ottaen ketterämmän. Tai muutamissa tapauksissa he lisäsivät uusia ideoita, joista voi tulevaisuudessa tulla standardeja.
Jos sinulla on aikaa investoida, tässä on luettelo muista mielenkiintoisista vaihtoehdoista. Ne eivät välttämättä sovi joillekin, eivätkä ne varmasti ole paras valinta kaikille, mutta ne saattavat olla sinulle parempi valinta. Sinun tehtäväsi, jos päätät ottaa sen vastaan, on laatia vankka kuvaus web-sovelluksestasi, kirjoittaa suhteellisen vankka kuvaus eri käyttötapauksista ja arvioida sitten näitä työkaluja tätä silmällä pitäen.
Ehkä pidät tietystä lähestymistavasta koodin suunnitteluun. Ehkä sovelluksesi ei tarvitse joitakin paksumpien, suositumpien kehysten ominaisuuksia. On kymmeniä syitä investoida johonkin näistä muista poluista. Saatat vain huomata, että jokin niistä tekee ihmeitä sovelluksellesi.
Petit DOM
Jos pidät virtuaalisen DOM:n ideasta, mutta et halua kaikkia niitä rajoituksia, jotka liittyvät Reactin, Vuen tai muun ison nimikkokehyksen porukan ajattelutavan omaksumiseen, Petit DOM on oikea tapa toimia. Saat pienen määrän koodia, jonka avulla voit käsitellä virtuaalista kokoelmaa tunnisteita ja siirtää ne sitten todelliseen DOMiin. Kaikki muu komponenttien rakenteesta ja renderöinnistä on sinun päätettävissäsi. Jos komponenttisi ovat yksinkertaisia tai jos aiot luoda jonkin superkompleksisen renderointihierarkian, joka on vain sinun, tämä voi olla perustasi, koska se tarjoaa vain työkalun DOM:n virtualisointiin.
Ylimääräinen
Virtuaalinen DOM ei ehkä sovi kaikille. Se vie tilaa, joten jos manipulointisi ei ole liian monimutkaista, voit yhtä hyvin johtaa ohjeesi suoraan viralliseen DOM:iin. Surplus-kirjasto tekee juuri niin. Se ottaa kaikkien suosikkimerkinnän JSX:n ja kääntää sen koodiksi, joka manipuloi todellista DOM:ia. Kuten mainosalalla sanotaan, se poistaa välikädet. Ei eriyttämistä. Ei salaisia ylimääräisiä kerroksia. Vain todellisen DOM:n puhdasta manipulointia. Jos koodisi on tarpeeksi yksinkertaista ja suoraa tehdäkseen vain muutamia asioita DOM:lle, miksi vaivautua virtuaalisen häirinnän kanssa?
RE:DOM
Toinen vaihtoehto niille, jotka eivät halua sijoittaa yhtään muistia virtuaaliseen DOM:iin, on pieni kirjasto (2KB) nimeltä RE:DOM. RE:DOM sisältää joitakin perusrutiineja, joiden avulla voit luoda kaikki tagit ja komponentit muutamalla yksinkertaisella JavaScript-kutsulla. Syntaksi on paljon lähempänä CSS:ää, joten voit määrittää melko monimutkaisia tageja tunnuksineen ja luokkineen muutamalla näppäinpainalluksella. ”Pienempi kuin” (<) ja ”suurempi kuin” (>) -näppäimet kiittävät sinua.
Mithril
Eivät kaikki vaihtoehdot ole pieniä ja minimalistisia. Mithriliä voisi tässä yhteydessä kutsua ”keskikokoiseksi” kehykseksi, vaikka se painaa vain noin 8KB. Kaikki tämä koodi rakentaa virtuaalisen DOM:n, jossa on tehokas päivitysmekanismi, kuten muissakin, mutta mukana on myös standardoitu joukko työkaluja, joilla voidaan käsitellä monia vakiohaasteita, kuten reititystä ja XMLHttpRequest-kutsuja. Projektin suunnittelijat haluavat Mithril-projektien olevan suhteellisen standardoituja, ja heidän mielestään tämän koodin lisääminen pääkirjastoon lisää standardointia. Jos tämä ei riitä, he ajavat myös joitakin vakiomuotoiluja ja idiomaattisia rakenteita.
Bobril
Jos pidät Reactin virtuaalisesta DOM:sta ja tilallisista komponenteista ja haluat ohjelmoida TypeScriptillä, Bobril tai sen Angular-ystävällinen serkku ngBobril voi olla juuri sopiva. Kehys on johdonmukaisesti paljon nopeampi kuin React tai Angular joissakin vertailuarvoissa, ehkä nopeampien diff-algoritmien ja isomorfisen JavaScriptin tuen puuttumisen vuoksi. Tarjolla on myös pätkäfunktioita CSS-käsittelyyn ja täydellinen tilanhallintakerros, BobX, jos tarvitset sitä.
Marko
Jos olet viettänyt aikaa huutokauppaillessasi Pez-annostelijoita tai muita keräilyesineitä, olet kokenut Markon tehon, ohuen ja nopean kehyksen, jonka eBay jakaa avoimen lähdekoodin lisenssin kautta. Kaikkein hienointa on ehkä erittäin kevyt templating-syntaksi, joka poistaa HTML:stä fiksusti suurimman osan ylimääräisestä rasvasta niin, että rakenne määritellään sisennyksillä eikä juuri muulla. Ja renderöintimoottori on erittäin nopea, sillä se pystyy ajamaan taidokkaita tanssivien DIV:ien tähtikuvioita, jotka päivittyvät nopeammin kuin 60 kuvaa sekunnissa.
Svelte
Vakiomuotoinen web-kehys sisältää kääntäjän ja ladattavan kirjaston, joka käsittelee ajonaikana sen, mitä kääntäjä tuottaa. Kaksivaiheinen prosessi mahdollistaa hyvin monimutkaisen koodin sillä hinnalla, että joutuu odottamaan, että ajonaikainen kirjasto ladataan ja jäsennetään joka kerta, kun sivu avataan. Svelte-kääntäjä poistaa tämän monimutkaisuuden sylkemällä ulos lähes puhdasta JavaScriptiä, joka on lähes valmis toimimaan itsenäisesti, vaikkakin vain joissakin uudemmissa selaimissa (esim. Chrome, Firefox, Opera ja IE10). Se on nokkela arkkitehtuurikikkailu, joka tuottaa hyvin kevyitä verkkosivuja, jotka vievät vain vähän muistia.
Inferno
Inferno on toinen kehys, joka on luotu tekemään paljon samaa kuin React, mutta pienemmällä latausmäärällä ja nopeammalla suoritusajalla. Se saavuttaa suuren osan tästä heittämällä pois monimutkaisen synteettisen tapahtumamekanismin ja keskittymällä vain olennaisimpiin, kuten onClickiin. Monet muut API:n osat ovat samankaltaisia, elleivät peräti samoja, joten koodisi on suhteellisen helppo siirtää siihen, jos se ei tarvitse tapahtumaoptimointikerrosta.
Preact
Yksi pienimmistä Reactin jälkeläisistä on Preact, kunnianosoitus, joka tarjoaa suurimman osan arvokkaimmista ominaisuuksista, kuten virtuaalisen DOM:n ja hienostuneet komponentit, mutta poistaa synteettiset tapahtumankäsittelijät ja osan rekvisiitan periytymisestä. Kun Inferno yrittää toteuttaa vain tärkeimmät tapahtumat, kuten onClick, Preact ei vaivaudu yrittämään tehdä tapahtumille mitään, vaan jättää sinut luottamaan selaimen natiiviin addEventListener:een. Jättämällä pois ominaisuuksia, jotka eivät tuo paljon lisäarvoa (heidän mielestään), he tekevät latauksestaan vieläkin pienemmän. Tämä on hieman kompromissi, koska vertailuarvot osoittavat, että Preact on hieman hitaampi kuin Inferno. Sovelluksesi voi tietysti olla erilainen, ja mittarilukema voi vaihdella. Jos todella tarvitset puhdasta yhteensopivuutta Reactin kanssa, on olemassa jopa kirjasto (preact-compat), joka korjaa useimmat ongelmat rakentamisen aikana.
Hapi
Monet kehykset saapuvat yhdellä palasella. Hapi on enemmänkin kokoelma lisäosia, kymmenien koodinpätkien muodostama tähtikuvio, joita voit sekoittaa pinoosi sopivaksi katsomallasi tavalla. Autentikointi, valtuuttaminen ja kirjaaminen ovat askareita, jotka voidaan ratkaista millä tahansa vaihtoehdolla. Jos olet rakentamassa mikropalveluarkkitehtuuria, joka on täynnä API:ita, standardoitu Swagger-lisäosa luo automaattisesti Swagger-dokumentaation peruskoodistasi.
Koa
Joskus tarvitset melko monimutkaisen kokoelman rutiineja, jotka jongleeraavat saapuvia pyyntöjä ja kääntävät ne useiksi muutoksiksi, joista osa on monimutkaisia. Koa on suunniteltu tekemään kaiken tämän työn organisoinnista hieman yksinkertaisempaa. Sen salaisuus on se, että se muuttaa tavallisesti JavaScriptiä hallitsevat callback-funktiot joukoksi asynkronisia funktioita, jotka laukeavat, kun aika on oikea. Sisäkkäiset spagettimaiset callback-pinot muutetaan joksikin vähän siistimmäksi.
Nest
Toinen vaihtoehto palvelimen monimutkaisuuden taltuttamiseen tulee Nest-tiimiltä, joka tarjoaa arkkitehtuuria, joka on täynnä kontrollereita, putkia ja palveluntarjoajia, joiden sekaan on heitetty joitakin vartijoita (guards), sieppareita (interceptors) ja poikkeussuodattimia (exception filters) pitämään järjestystä. Kehys on moderni ja valmis käsittelemään GraphQL- ja mikropalvelupyyntöjä heti alusta alkaen.
Drupal, WordPress ja Rails
Javaskriptillä rakennetut ja Node.js:n päällä toimivat kehykset täyttävät nykyään web-kehitysmaailman psykologisen keskuksen. Voi kuitenkin olla virhe jättää huomiotta edellinen sukupolvi, joka on rakennettu PHP:lle, joka on nyt entistä nopeampi perusta, koska siinä on myös JavaScriptin kaltainen just-in-time-kääntäjä. Ja Ruby ja sen Rails-kehys toimivat edelleen kivikovien verkkosivujen kulmakivinä.
Edellinen sukupolvi on taistelujen runtelema ja yli vuosikymmenen jatkuvan kehityksen ja työn hyvin testaama. On olemassa hienostuneita suunnittelijoita, jotka osaavat sorvata sovelluksiin teemoja ja nahkoja. On hyvin mahdollista, että joku on jo rakentanut moduulit, joissa on tarvitsemasi toiminnallisuus. Joten ennen kuin tutkit nokkelaa Node.js-kehystä, harkitse, voiko joku vanhoista tehdä jo paljon, ellei jopa kaiken tarvitsemasi.
Vanilla JS
Voit pitää sitä ilkeänä diggailuna tai kenties satiirina ”Keisarin uudet vaatteet” -tasolla, mutta sen menestystä on vaikea kiistää. Vanilla JS on verkkosivusto, joka kehuskelee, että sen kehystä käytetään useammalla verkkosivustolla kuin ”jQuery, Prototype JS, MooTools, YUI ja Google Web Toolkit yhteensä”. Tämä voi olla totta tai sitten ei, kun otetaan huomioon jQueryn yleistyminen, mutta nauretaanpa polttamiselle. Sivustolla on myös söpö pieni valitsin, jonka avulla voit niputtaa yhteen mukautetun arkiston eri komponenteista, kuten Math, DOM, closures tai säännölliset lausekkeet. Riippumatta siitä, mitä valitset, tulos on älyttömän nolla tavua pitkä. Yritä päihittää se!
Vitsin pointti on, että joskus on järkevää käyttää vain muutamia JavaScriptin vakioelementtejä ja jättää ylimääräiset pois. Kirjastot ja kehykset, kuten jQuery tai React, saivat alkunsa osittain selainten välisten mielettömien erojen vuoksi. Monet näistä eroista ovat hävinneet standardoinnin ansiosta.
Vanilla JS:n kannattajat eivät tietenkään kohtaa sitä tosiasiaa, että $():n kaltaiset pätkäfunktiot eivät ole vain käteviä, vaan ne myös säästävät tilaa omassa koodissamme. Mutta jos aiot käyttää document.getElementById vain satunnaisesti, sillä ei välttämättä ole väliä. Jos aiot lisätä verkkosivullesi vain muutamia funktioita ja nämä funktiot tekevät muutamia perusasioita, tavallinen vanilja-Javaskripti saattaa olla sinulle nopein kehys.