Tarvitsemmeko vielä JavaScript-kehyksiä?

Verkkokehittäjänä yritän arvioida työkalupakettini säännöllisesti ja selvittää, voinko pärjätä ilman tätä tai muuta työkalua. Viime aikoina olen tutkinut kuinka helppoa on kehittää monimutkainen käyttöliittymäsovellus ilman käyttöliittymäkehystä.

Mikä on JavaScript-kehys?

Yksinkertaisesti sanottuna JavaScript-kehys on työkalu, jonka avulla voit kehittää edistyneitä verkkosovelluksia, erityisesti SPA-alueita.

Päivän aikana web-kehittäjät toteuttaisivat käyttöliittymälogiikan luottamalla vahvasti vanilja JS: ään ja jQueryyn. Mutta kun käyttöliittymäsovellukset tulivat yhä monimutkaisemmiksi, työkalut nousivat vastaamaan tähän monimutkaisuuteen.

Nykyään suosituilla kehyksillä on muutama ydin. Useimmat käyttöliittymäkehykset / kirjastot Vue: sta Reactiin tarjoavat jonkin verran yhdistelmää seuraavista:

  • Tilan ja näkymän synkronointi
  • Reititys
  • Mallijärjestelmä
  • Uudelleenkäytettävät komponentit

Ovatko kehykset edelleen tarpeellisia?

Se riippuu siitä, kuinka korostat välttämätöntä sanaa . Monet väittävät, että käyttöliittymän kehyksiä ei tarvita eikä niitä ole koskaan tarvittu. Ne ovat kuitenkin erittäin hyödyllisiä työkaluja.

Joten kysymys kuuluu: ovatko kehykset nykypäivän jQuery? Otetaanko heidän ratkaisemiinsa ongelmiin muutoksia kuten DOM-sovellusliittymään?

On vaikea sanoa, mutta natiivin JS: n, verkkokomponenttien teknisten ominaisuuksien ja helposti konfiguroitavien rakennustyökalujen kehitys on tehnyt SPA-kehityksen ilman kehystä yhtä helpoksi kuin koskaan.

Tarkastellakseni tätä tarkemmin kehitin yhden sivun sovelluksen, jossa käytettiin vain vanilja JavaScriptiä, alkuperäisiä Web-komponentteja ja Pakettia. Matkan varrella oli kourallinen sudenkuoppia ja vaikeuksia, jotka korostivat JS-kehysten vahvuuksia.

Samaan aikaan, kun läpäisin alkuperäiset esteet, olin yllättynyt siitä, kuinka helppoa oli luoda yhden sivun sovellus vain vanilja-JS: llä.

Yleiskatsaus

Sovellus on yksinkertainen. Se on reseptisovellus, jolla on CRUD-perusominaisuudet. Käyttäjä voi luoda, muokata, poistaa, lisätä suosikkeihin ja suodattaa reseptiluettelon.

Komponentit

Verkkokomponentin luominen on myös suoraviivaista. Luodaan luokan, joka jatkuu HTMLElement(tai HTMLParagraphElementniin edelleen), ja määritä sitten kyseinen luokka mukautetun elementin määrittämiseksi.

Voit myös käyttää elinkaarikoukkuja, kuten connectedCallback, disconnectedCallback, attributeChangedCallback.

Reititys

Reseptisovelluksen reititys on myös melko yksinkertainen. Annoin navigointitapahtuman, asetin sovelluksen sisällön vastaavaan verkkokomponenttiin.

Alun perin käytin Vanilla JS Router -nimistä pakettia. Selainhistorian sovellusliittymän avulla ei ole kovin monimutkaista toteuttaa omia alle 100 koodirivillä! Huomaa: En toteuta todella monimutkaista logiikkaa, kuten reittisuojaa.

Tämä on nopea yhteenveto. Haluan pitää tämän artikkelin kohtuullisen pituisena. Voin kirjoittaa seurantaviestin perusteellisemmalla selityksellä hakemuksesta. Totein joitain hauskoja ominaisuuksia, kuten ääretön vieritys, mukautettu vedä ja pudota -latausohjelma ja paljon muuta!

Retrospektiivinen

Sovelluksen luomisen jälkeen otin jonkin aikaa ajatella koko prosessin etuja ja haittoja alusta loppuun. Aloitan huonoista uutisista.

Haittoja

Tekniset tiedot ovat edelleen muutoksessa

Verkkokomponentin tekniset tiedot ovat sekä vanhoja että uusia. Se on ollut olemassa paljon kauemmin kuin olin alun perin ajatellut. Alex Russell esitteli verkkokomponentit Fronteers-konferenssissa 2011 ensimmäistä kertaa. Verkkokomponenttien takana oleva paine on kuitenkin todella kasvanut viimeisen kahden vuoden aikana. Sellaisena teknisissä tiedoissa on edelleen paljon levottomuutta. Esimerkiksi HTML-tuonti on hylätty, vaikka suurin osa asiakirjoista / resursseista viittaa niihin edelleen.

Testaus

Natiivien verkkokomponenttien testaamiseen ei ole paljon omistettuja resursseja. On joitain lupaavia työkaluja, kuten skatejs ssr ja Web-komponenttitesteri Polymeriltä. Mutta nämä työkalut on todella tarkoitettu käytettäviksi vastaavien kirjastojen kanssa. Tämä aiheuttaa joitain vaikeuksia natiivien verkkokomponenttien kanssa.

Muutosten tunnistus

On uskomatonta, että sinulla on taustalla oleva järjestelmä, joka pitää näkymän automaattisesti synkronoituna tietomallin kanssa. Se vetää monia ensinnäkin kulma- ja muihin kehyksiin.

Tilan pitäminen synkronoituna näkymän kanssa ei ole niin vaikeaa pienessä mittakaavassa. Mutta se voi päästä hallinnan ulkopuolelle hyvin nopeasti, ja huomaat lisäävänne tonnia tapahtumakuuntelijoita ja kyselynvalitsimia.

Varjo DOM

Olen todella revitty varjo-DOM: sta. Toisaalta rakastan kapseloinnin ideaa. Se on järkevä suunnittelumalli, tekee tyylisi kaskadista hallittavamman, yksinkertaistaa huolenaiheitasi ja niin edelleen. Se aiheuttaa kuitenkin myös ongelmia, kun haluat tiettyjen asioiden tunkeutuvan kyseiseen kapselointiin (kuten jaettu tyyliarkki), ja parhaita tapoja tehdä tämä käydään parhaillaan.

DOM-rakenteiden luominen

Osa Angularin ja Reactin kaltaisten kehysten / kirjastojen upeudesta on, että he ovat DOMaininsa mestareita. Toisin sanoen, ne pystyvät erinomaisesti renderoimaan ja uudelleentoimimaan rakenteita DOM: ssä. Angular University -blogista:

Angular ei luo HTML: ää ja välittää sen sitten selaimelle sen jäsentämiseksi, vaan Angular luo DOM-tietorakenteet suoraan!

Esimerkiksi kulma, toisin kuin jQuery, renderöi DOM-tietorakenteet suoraan. Toisin sanoen HTML: n siirtämisen sijaan selaimeen jäsennettäväksi ja sitten renderoiduksi DOM-tietorakenteiksi. Tämä on suorituskykyisempi, koska se eliminoi kyseisen jäsennysvaiheen. Virtuaalinen DOM on myös varsin hyödyllinen, koska ne estävät sinua renderöimästä kaikkea uudelleen aina, kun haluat päivittää näkymääsi.

Plussat

Toisaalta sovellusten kehittämisellä tällä tavalla on kiistattomia etuja:

Nipun koko

Lopputuote voi olla (painottaen CAN ) niin paljon pienempi ja kompaktimpi kuin mitään kehitetty nykyaikaisen kehyksen. Esimerkiksi täysin varustellun reseptisovelluksen viimeinen koontiversio oli alle puolet tuoreen kulmarakenteen koosta.

Huomaa: Nämä ovat päivitetyt, optimoidut pakettikoot.

Ymmärtäminen

Jos olet todella kehittynyt vain kehyksen ja sen CLI: n avulla, voi olla hyvä harjoitus tehdä verkkosovellus ilman ylimääräisiä työkaluja. Kuten joku, joka haluaa saavuttaa tietyn hallinnan tason (siinä määrin kuin se on mahdollista) verkkokehityksestä, minulle on ollut välttämätöntä saada enemmän käytännön kokemusta rakennustyökaluista, selainohjelmointirajapinnoista, suunnittelumalleista jne.

Esitys

Se, mitä nämä käyttöliittymäkehykset ja kirjastot tekevät kulissien takana, on hämmästyttävää. Voit kuitenkin maksaa suoritushinnan, jos päätät käyttää jotain niistä; ilmaista lounasta ei ole olemassa. Mahdollisia suorituskyvyn vetoja on paljon: olkoon kyse hukkaavista uudelleentoiminnoista, tarpeettomista kuuntelijoista, syvistä esineiden vertailusta tai turhista ja suurista DOM-manipulaatioista. Voit leikata paljon monimutkaisuutta toteuttamalla asioita tyhjästä.

Angular- ja React-tiimit näyttävät olevan tietoisia näistä ongelmista , ja he ovat tarjonneet asioita, kuten shouldUpdate- menetelmän ohitukset ja onPush ChangeDetection, keinona edelleen optimoida suorituskykyä.

Yksinkertaisuus ja koodin omistus

Otat riskin, kun tuot kolmannen osapuolen koodin. Tämä riski pienenee kokeiltujen kirjastojen / kehysten avulla, mutta sitä ei koskaan poisteta. Jos pääset selviytymään koodin kirjoittamisesta itse tai tiimisi kanssa, voit vähentää riskiä ja ylläpitää koodipohjaa, jonka tunnet sisään ja ulos.

Muistiinpanoja ja mielenkiintoisia juttuja

Minulla oli räjähdys työskennellessäni Paketin kanssa. Se tuntui hieman rajoitetumalta kuin Webpack toisinaan yrittäessäsi kiertää tiettyjä reunatapauksia, mutta huomasin, että nolla konfiguraation tagirivi pitää paikkansa.

Minulle on myös selvää, että monet antavat Reactille 'kirjaston' ja Vue 'progressiivisen' kehyksen. Vaikka ymmärrän tämän syyt, mielestäni React, Vue ja Angular ratkaisevat monet samat ongelmat. Tarkastelen siis niitä kaikkia yhdessä termillä "puitteet".

Miksi et käytä kaavainta tai polymeeriä? Halusin välttää pakettien, kirjastojen ja kehysten käyttöä mahdollisimman paljon. Halusin nähdä, kuinka pitkälle verkkostandardit olivat nousseet vastaamaan nykyaikaista kehitystä (lukuun ottamatta rakennustyökaluja).

On varma, että monia muita tapoja kehittää SPA tai käyttöliittymäsovellus yleensä ilman suurta kehystä tai kirjastoa, kokeilin yhtä tapaa täällä ja haluaisin kuulla mielelläni muista!

Yhteenveto

Kutsun "käännekohdaksi" suurta heuristista päätöstä käyttää tai käyttää kehyksiä. Sovelluksen kasvaessa tulee kohta, jossa päädyt luomaan oman kehyksen toiminnallisuuden ja rakenteen uudelleenkäyttöä varten. Esimerkiksi sinulla on joukko lomakkeita ja haluat luoda uudelleenkäytettävän logiikan reaktiivista vahvistusta varten.

Jos päädyt tähän kohtaan, sinun on päätettävä, kannattaako aika sijoittaa aika järjestelmien luomiseen saavuttaaksesi sen, mitä voit nopeasti saavuttaa kehyksellä tai kirjastolla. Kääntöpisteitä on erilaisia ​​riippuen aikarajoitteistasi tai budjettirajoitteistasi, mutta kehykset ovat silti erittäin merkityksellisiä oikeiden skenaarioiden vuoksi.

Siitä huolimatta suurin osa kehysten tekemisestä tulee todennäköisesti helpommaksi tehdä pienempien kirjastojen ja / tai alkuperäisen koodin kanssa ajan myötä. Otetaan esimerkiksi hakemukseni. Samaan aikaan, jos suuret kehykset ja kirjastot pysyvät monipuolisina, ne voivat morfoitua, sopeutua ja pysyä kiinni. Jos ei, he voivat päätyä kuin jQuery - menneisyyden työkalu suurimmaksi osaksi.

Johtopäätös

Lopuksi on lupaavia tapoja kehittää monimutkaisia ​​käyttöliittymäsovelluksia ilman kehyksiä. Verkkokomponenttien kaltaisten ominaisuuksien tekniset tiedot ovat kuitenkin edelleen kehittymässä, ja on olemassa kehityksiä. Kehykset tekevät edelleen paljon upeita asioita ja voivat tehdä kehityksestä paljon sujuvampaa.

Tällä hetkellä, sikäli kuin voin kertoa, kehyksen käytön edut ovat usein suurempia kuin haitat. Jos puitteet eivät kuitenkaan aloita uusien ongelmien ratkaisemista ja kehittymisen jatkamista, ne lopulta häviävät.

Resurssit

Kulmaopas aloittelijoille: Miksi kulmikas? Suurimmat edut

Huomaa: Tämä viesti on osa meneillään olevaa Angular for Beginners -sarjaa, tässä on täydellinen sarja: Angular For Beginners… blog.angular-university.io Vertailu muihin kehyksiin - Vue.js

Vue.js - Progressive JavaScript Framework vuejs.org Suorituskyvyn optimointi - React

Sisäisesti React käyttää useita älykkäitä tekniikoita minimoidakseen kalliiden DOM-operaatioiden määrän, joka tarvitaan… reakjs.org- verkkokomponenttien päivittämiseen

Kehittäjinä tiedämme kaikki, että koodin uudelleenkäyttö mahdollisimman paljon on hyvä idea. Tämä ei ole perinteisesti ollut niin ... developer.mozilla.org Syvin syy miksi nykyaikaiset JavaScript-kehykset ovat olemassa

Olen nähnyt monia, monia ihmisiä käyttävän sokeasti modernia kehystä, kuten React, Angular tai Vue.js. Nämä kehykset tarjoavat… medium.com Verkkokomponenttien muotoilu käyttämällä jaettua tyylisivua

Verkkokomponentit ovat hämmästyttävä uusi ominaisuus verkossa, jonka avulla kehittäjät voivat määrittää omat HTML-elementit ... www.smashingmagazine.com