Ei ole nopeampaa tapaa hidastaa verkkosivustoa (tarkoitettu sanaleima) kuin käyttää siinä joukkoa JavaScript-koodia. JavaScriptiä käytettäessä joudut maksamaan siitä projektien suorituksella vähintään neljä kertaa. Näin sivuston JavaScript-koodi lataa käyttäjien järjestelmiä:
- Tiedoston lataaminen verkon kautta.
- Pakkaamattoman lähdekoodin jäsentäminen ja kääntäminen latauksen jälkeen.
- JavaScript-koodin suorittaminen.
- Muistin kulutus.
Tämä yhdistelmä selviää .
Ja lisäämme projekteihimme yhä enemmän JS-koodia. Organisaatioiden siirtyessä kohti sivustoja, jotka toimivat kehyksillä ja kirjastoilla, kuten React, Vue ja muut, teemme sivustojen ydintoiminnot erittäin riippuvaiseksi JavaScriptistä.
Olen nähnyt monia erittäin painavia sivustoja, jotka käyttävät JavaScript-kehystä. Mutta näkemykseni asiasta on hyvin puolueellinen. Tosiasia on, että yritykset, joiden kanssa työskentelen, kääntyvät puoleeni juuri siksi, että he kohtaavat monimutkaisia ongelmia sivuston suorituskyvyn alalla. Tämän seurauksena minua alkoi kiinnostaa kuinka yleinen tämä ongelma on ja millaisia "sakkoja" maksamme, kun valitsemme tietyn sivuston perustaksi yhden tai toisen kehyksen.
Projekti auttoi minua ymmärtämään tämän. .
Tiedot
HTTP-arkistoprojekti seuraa kaikkiaan 4308655 5484239 XNUMX linkkiä tavallisille työpöytäsivustoille ja XNUMX XNUMX XNUMX linkkiä mobiilisivustoille. Näihin linkkeihin liittyvien lukuisten mittareiden joukossa on luettelo vastaavilta sivustoilta löytyvistä teknologioista. Tämä tarkoittaa, että voimme ottaa näytteitä tuhansista sivustoista, jotka käyttävät erilaisia kehyksiä ja kirjastoja, ja oppia kuinka paljon koodia ne lähettävät asiakkaille ja kuinka paljon kuormitusta tämä koodi luo käyttäjien järjestelmiin.
Keräsin maaliskuun 2020 tiedot, jotka olivat viimeisimmät tiedot, joihin minulla oli pääsy.
Päätin verrata kaikkien sivustojen koottuja HTTP-arkiston tietoja Reactin, Vuen ja Angularin avulla löydettyjen sivustojen tietoihin, vaikka harkitsin myös muun lähdemateriaalin käyttöä.
Kiinnostaakseni lisäsin myös jQueryä käyttävät sivustot lähdetietojoukkoon. Tämä kirjasto on edelleen erittäin suosittu. Se esittelee myös erilaisen lähestymistavan verkkokehitykseen kuin Reactin, Vuen ja Angularin tarjoama Single Page Application (SPA) -malli.
HTTP-arkiston linkit, jotka edustavat sivustoja, joiden on havaittu käyttävän kiinnostavia teknologioita
Kehys tai kirjasto
Linkkejä mobiilisivustoille
Linkit tavallisille sivustoille
jQuery
4615474
3714643
suhtautua
489827
241023
Näkymä
85649
43691
Kulma-
19423
18088
Toiveet ja unelmat
Ennen kuin siirrymme data-analyysiin, haluan puhua siitä, mitä haluaisin toivoa.
Uskon, että ihanteellisessa maailmassa kehysten pitäisi mennä kehittäjien tarpeita pidemmälle ja tarjota tiettyjä etuja keskivertokäyttäjälle, joka työskentelee sivustojemme parissa. Suorituskyky on vain yksi näistä eduista. Tässä saavutettavuus ja turvallisuus tulevat esiin. Mutta tämä on vain tärkein.
Joten ihanteellisessa maailmassa jonkinlaisen kehyksen pitäisi helpottaa tehokkaan sivuston luomista. Tämä tulisi tehdä joko siitä syystä, että kehys antaa kehittäjälle kunnollisen pohjan projektin rakentamiselle, tai siksi, että se asettaa rajoituksia kehitykselle, asettaa sille vaatimuksia, jotka vaikeuttavat jonkin kääntyvän kehittämistä. olla hidas.
Parhaiden puitteiden tulisi tehdä molemmat: antaa hyvä perusta ja asettaa rajoituksia työlle, jotta voit saavuttaa kunnollisen tuloksen.
Tietojen mediaaniarvojen analysointi ei anna meille tarvitsemaamme tietoa. Ja itse asiassa tämä lähestymistapa jää huomiomme ulkopuolelle . Sen sijaan johdin prosenttiosuudet omistamistani tiedoista. Nämä ovat 10, 25, 50 (mediaani), 75, 90 prosenttipisteet.
Olen erityisen kiinnostunut 10. ja 90. prosenttipisteistä. 10. prosenttipiste edustaa tietyn kehyksen parasta suorituskykyä (tai ainakin enemmän tai vähemmän lähellä parasta). Toisin sanoen tämä tarkoittaa, että vain 10 % tiettyä kehystä käyttävistä sivustoista pääsee tälle tai korkeammalle tasolle. Toisaalta 90. prosenttipiste on kolikon toinen puoli - se näyttää meille, kuinka huonosti asiat voivat mennä. 90. prosenttipiste on perässä olevat sivustot – alimmillaan 10 % sivustoista, joilla on eniten JS-koodia tai pisin aika käsitellä koodiaan pääsäikeessä.
JavaScript-koodin määrä
Aluksi on järkevää analysoida eri sivustojen verkon kautta lähettämän JavaScript-koodin kokoa.
Mobiililaitteisiin siirretyn JavaScript-koodin määrä (Kb).
Persentiilit
10
25
50
75
90
Kaikki sivustot
93.4
196.6
413.5
746.8
1201.6
jQuery-sivustot
110.3
219.8
430.4
748.6
1162.3
Vue-sivustot
244.7
409.3
692.1
1065.5
1570.7
Kulmaiset sivustot
445.1
675.6
1066.4
1761.5
2893.2
Reaktiosivustot
345.8
441.6
690.3
1238.5
1893.6
Mobiililaitteisiin lähetetyn JavaScript-koodin määrä
Pöytälaitteisiin siirretyn JavaScript-koodin määrä (Kb).
Persentiilit
10
25
50
75
90
Kaikki sivustot
105.5
226.6
450.4
808.8
1267.3
jQuery-sivustot
121.7
242.2
458.3
803.4
1235.3
Vue-sivustot
248.0
420.1
718.0
1122.5
1643.1
Kulmaiset sivustot
468.8
716.9
1144.2
1930.0
3283.1
Reaktiosivustot
308.6
469.0
841.9
1472.2
2197.8
Pöytälaitteisiin lähetetyn JavaScript-koodin määrä
Jos puhumme vain JS-koodin koosta, jonka sivustot lähettävät laitteille, kaikki näyttää siltä, kuin voit odottaa. Nimittäin jos jokin viitekehys on käytössä, se tarkoittaa, että ihannetilanteessakin sivuston JavaScript-koodin määrä kasvaa. Tämä ei ole yllättävää - JavaScript-kehystä ei voi tehdä sivuston perustaksi ja odottaa, että projektin JS-koodin määrä on hyvin pieni.
Merkittävää tässä tiedossa on se, että joitain puitteita ja kirjastoja voidaan pitää parempana lähtökohtana projektille kuin toisia. Sivustot, joissa on jQuery, näyttävät parhailta. Sivustojen työpöytäversioissa ne sisältävät 15 % enemmän JavaScriptiä kuin kaikki sivustot ja mobiililaitteilla 18 % enemmän. (Tässä on tosin jonkin verran tietojen korruptiota. Tosiasia on, että jQuery on läsnä monilla sivustoilla, joten on vain luonnollista, että tällaiset sivustot liittyvät tiiviimmin kuin toiset sivustojen kokonaismäärään. Tämä ei kuitenkaan vaikuta raaka-arvoon. tiedot tulostetaan jokaiselle kehykselle.)
Vaikka koodimäärän 15-18 %:n lisäys on huomattava luku, kun tätä verrataan muihin kehyksiin ja kirjastoihin, voidaan päätellä, että jQueryn perimä "vero" on erittäin alhainen. Kulmikkaat sivustot 10. prosenttipisteen sisällä lähettävät 344 % enemmän dataa pöytäkoneille kuin kaikki sivustot ja 377 % enemmän mobiililaitteille. React-sivustot ovat seuraavaksi painavimpia, ja ne lähettävät 193 % enemmän koodia työpöydälle kuin kaikki sivustot ja 270 % enemmän mobiililaitteille.
Aiemmin mainitsin, että vaikka kehyksen käyttö tarkoittaa, että tietty määrä koodia sisällytetään projektiin, toivon heti työn alussa, että kehys pystyy jotenkin rajoittamaan kehittäjää. Erityisesti puhumme koodin enimmäismäärän rajoittamisesta.
Mielenkiintoista on, että jQuery-sivustot noudattavat tätä ajatusta. Vaikka ne ovat hieman raskaampia kuin kaikki sivustot 10. prosenttipisteellä (15–18 %), ne ovat hieman kevyempiä 90. prosenttipisteen kohdalla, noin 3 % sekä pöytäkoneilla että mobiililaitteilla. Tämä ei tarkoita, että tämä olisi erittäin merkittävä etu, mutta voidaan sanoa, että jQuery-sivustoilla ei ainakaan ole valtavia JavaScript-koodikokoja, edes niiden suurimmissa versioissa.
Mutta samaa ei voi sanoa muista kehyksistä.
Aivan kuten 10. prosenttipisteen tapauksessa, Angularin ja Reactin 90. prosenttipisteen kohdat eroavat muista kohdista, mutta ne eroavat valitettavasti huonommin.
90. prosenttipisteessä Angular-sivustot lähettävät 141 % enemmän dataa mobiililaitteille kuin kaikki sivustot ja 159 % enemmän pöytäkoneille. React-sivustot lähettävät 73 % enemmän pöytäkoneille kuin kaikki muut sivustot ja 58 % enemmän mobiililaitteille. React-sivustojen koodikoko 90. prosenttipisteellä on 2197.8 kt. Tämä tarkoittaa, että tällaiset sivustot lähettävät 322.9 kilotavua enemmän dataa mobiililaitteisiin kuin niiden lähimmät Vue-pohjaiset kilpailijat. Angular and React -pohjaisten työpöytäsivustojen ja muiden sivustojen välinen ero on vielä suurempi. Esimerkiksi työpöydän React-sivustot lähettävät 554.7 kt enemmän JS-koodia laitteisiin kuin vastaavat Vue-sivustot.
Pääsäikeen JavaScript-koodin käsittelyyn kulunut aika
Yllä olevat tiedot osoittavat selvästi, että tutkittavia kehyksiä ja kirjastoja käyttävät sivustot sisältävät suuria määriä JavaScript-koodia. Mutta tietysti se on vain yksi osa yhtälöämme.
Kun JavaScript-koodi on saapunut selaimeen, se on saatettava toimivaan tilaan. Erityisen paljon ongelmia aiheuttavat ne toimet, jotka on suoritettava selaimen pääsäikeen koodilla. Pääsäike vastaa käyttäjien toimien käsittelystä, tyylien laskemisesta, sivun asettelun rakentamisesta ja näyttämisestä. Jos ylität pääsäikeen JavaScript-tehtävillä, sillä ei ole mahdollisuutta suorittaa muita tehtäviä ajoissa. Tämä johtaa viiveisiin ja "jarruihin" sivujen työssä.
HTTP-arkistotietokanta sisältää tietoja siitä, kuinka kauan JavaScript-koodin käsittely kestää V8-moottorin pääsäikeessä. Tämä tarkoittaa, että voimme kerätä nämä tiedot ja selvittää, kuinka kauan pääsäikeellä kuluu aikaa käsitellä eri sivustojen JavaScriptiä.
Prosessorin aika (millisekunteina), joka liittyy käsikirjoituksen käsittelyyn mobiililaitteissa
Persentiilit
10
25
50
75
90
Kaikki sivustot
356.4
959.7
2372.1
5367.3
10485.8
jQuery-sivustot
575.3
1147.4
2555.9
5511.0
10349.4
Vue-sivustot
1130.0
2087.9
4100.4
7676.1
12849.4
Kulmaiset sivustot
1471.3
2380.1
4118.6
7450.8
13296.4
Reaktiosivustot
2700.1
5090.3
9287.6
14509.6
20813.3
Mobiililaitteiden komentosarjojen käsittelyyn liittyvä prosessoriaika
Prosessoriaika (millisekunteina), joka liittyy pöytätietokoneiden komentosarjan käsittelyyn
Persentiilit
10
25
50
75
90
Kaikki sivustot
146.0
351.8
831.0
1739.8
3236.8
jQuery-sivustot
199.6
399.2
877.5
1779.9
3215.5
Vue-sivustot
350.4
650.8
1280.7
2388.5
4010.8
Kulmaiset sivustot
482.2
777.9
1365.5
2400.6
4171.8
Reaktiosivustot
508.0
1045.6
2121.1
4235.1
7444.3
Prosessoriaika, joka liittyy komentosarjan käsittelyyn pöytätietokoneissa
Täällä voit nähdä jotain hyvin tuttua.
Ensinnäkin sivustot, joissa on jQuery, kuluttavat huomattavasti vähemmän JavaScript-käsittelyyn pääsäikeessä kuin muut sivustot. 10. prosenttipisteessä verrattuna kaikkiin sivustoihin jQuery-sivustot mobiililaitteilla käyttävät 61 % enemmän aikaa JS-koodin käsittelyyn pääsäikeessä. Pöytätietokoneiden jQuery-sivustojen tapauksessa käsittelyaika kasvaa 37 %. 90. prosenttipisteen kohdalla jQuery-sivustot ovat hyvin lähellä kokonaispisteitä. Erityisesti mobiililaitteiden jQuery-sivustot viettävät pääsäikeessä 1.3 % vähemmän aikaa kuin kaikki sivustot ja 0.7 % vähemmän aikaa pöytätietokoneissa.
Luokituksemme toisella puolella ovat rungot, joille on ominaista suurin päälangan kuormitus. Tämä taas on Angular and React. Ainoa ero näiden kahden välillä on, että vaikka Angular-sivustot lähettävät enemmän koodia selaimille kuin React-sivustot, Angular-sivustot vievät vähemmän CPU-aikaa koodin käsittelemiseen. Paljon vähemmän.
10. prosenttipisteen Angular-työpöytäsivustot käyttävät 230 % enemmän aikaa JS-koodin käsittelyyn pääsäikeessä kuin kaikki sivustot. Mobiilisivustoilla tämä luku on 313 %. React-sivustot menestyvät huonoimmin. Pöytäkoneilla he käyttävät 248 % enemmän aikaa koodin käsittelyyn kuin kaikilla sivustoilla ja 658 % enemmän mobiililaitteilla. 658% ei ole kirjoitusvirhe. 10. prosenttipisteessä React-sivustot käyttävät 2.7 sekuntia pääketjun ajasta koodinsa käsittelyyn.
Näihin valtaviin lukuihin verrattuna 90. prosenttipiste näyttää ainakin hieman paremmalta. Verrattuna kaikkiin sivustoihin Angular-projektit viettävät 29 % enemmän aikaa pöytäkoneissa pääsäikeessä ja 27 % enemmän aikaa mobiililaitteissa. React-sivustojen tapauksessa samat luvut näyttävät olevan 130 % ja 98 %.
90. prosenttipisteen prosenttipoikkeamat näyttävät paremmilta kuin vastaavat 10. prosenttipisteen arvot. Mutta tässä on syytä muistaa, että kellonaikaa osoittavat numerot vaikuttavat melko pelottavilta. Oletetaan 20.8 sekuntia Reactilla rakennetun verkkosivuston päämobiilisäikeessä. (Mielestäni tarina siitä, mitä tänä aikana todella tapahtuu, on erillisen artikkelin arvoinen).
Tässä on yksi mahdollinen komplikaatio (kiitos että kiinnitin huomioni tähän ominaisuuteen ja harkitsin tietoja huolellisesti tästä näkökulmasta). Tosiasia on, että monet sivustot käyttävät useita käyttöliittymätyökaluja. Erityisesti olen nähnyt paljon sivustoja, jotka käyttävät jQuerya Reactin tai Vuen rinnalla, koska kyseiset sivustot siirtyvät jQuerysta muihin kehyksiin tai kirjastoihin. Tämän seurauksena osuin tietokantaan uudelleen ja valitsin tällä kertaa vain ne linkit, jotka vastaavat sivustoja, jotka käyttävät vain Reactia, jQueryä, Angular- tai Vuea, mutta en mitään niiden yhdistelmää. Tässä on mitä sain.
Mobiililaitteiden komentosarjojen käsittelyyn liittyvä prosessoriaika (millisekunteina) tilanteessa, jossa sivustot käyttävät vain yhtä kehystä tai vain yhtä kirjastoa
Persentiilit
10
25
50
75
90
Sivustot, jotka käyttävät vain jQueryä
542.9
1062.2
2297.4
4769.7
8718.2
Sivustot, jotka käyttävät vain Vuea
944.0
1716.3
3194.7
5959.6
9843.8
Sivustot, jotka käyttävät vain Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Sivustot, jotka käyttävät vain Reactia
2443.2
4620.5
10061.4
17074.3
24956.3
Mobiililaitteiden komentosarjojen käsittelyyn liittyvä prosessoriaika tilanteessa, jossa sivustot käyttävät vain yhtä kehystä tai vain yhtä kirjastoa
Ensinnäkin jotain, mikä ei ole yllättävää: kun sivusto käyttää vain yhtä kehystä tai yhtä kirjastoa, tällaisen sivuston suorituskyky paranee useammin kuin ei. Jokainen instrumentti toimii paremmin 10. ja 25. prosenttipisteillä. Se on järkevää. Sivuston, joka on tehty käyttämällä yhtä kehystä, tulisi toimia paremmin kuin sivuston, joka on tehty käyttämällä kahta tai useampaa kehystä tai kirjastoa.
Itse asiassa jokaisen tutkitun käyttöliittymätyökalun suorituskyky näyttää paremmalta kaikissa tapauksissa yhtä omituista poikkeusta lukuun ottamatta. Minua yllätti se, että 50. prosenttipisteellä ja sitä korkeammalla Reactia käyttävät sivustot toimivat huonommin, kun React on ainoa niiden käyttämä kirjasto. Tämä oli muuten syy, miksi esitin nämä tiedot täällä.
Tämä on hieman outoa, mutta yritän silti etsiä selitystä tälle oudolle.
Jos projekti käyttää sekä Reactia että jQueryä, kyseinen projekti on todennäköisesti jossain jQuerysta Reactiin siirtymisen puolivälissä. Ehkä sillä on koodikanta, jossa nämä kirjastot sekoitetaan. Koska olemme jo nähneet, että jQuery-sivustot viettävät vähemmän aikaa pääsäikeessä kuin React-sivustot, tämä saattaa kertoa meille, että joidenkin toimintojen käyttöönotto jQueryssa auttaa sivustoa toimimaan hieman paremmin.
Mutta kun projekti siirtyy jQuerysta Reactiin ja luottaa enemmän Reactiin, asiat muuttuvat. Jos sivusto on todella korkealaatuinen ja sivuston kehittäjät käyttävät Reactia huolellisesti, kaikki on kunnossa tällaisella sivustolla. Mutta keskimääräiselle React-sivustolle Reactin laaja käyttö tarkoittaa, että päälanka on raskaan kuormituksen alainen.
Mobiililaitteiden ja pöytätietokoneiden välinen kuilu
Toinen näkökulma, josta tarkastelin tutkittua dataa, oli tutkia, kuinka suuri ero on mobiili- ja pöytätietokoneilla työskentelyn välillä. Jos puhumme JavaScript-koodin määrien vertaamisesta, tällainen vertailu ei paljasta mitään kauheaa. Tietysti olisi mukava nähdä pienempiä määriä ladattavaa koodia, mutta mobiili- ja työpöytäkoodin määrässä ei ole paljon eroa.
Mutta jos analysoimme koodin käsittelyyn tarvittavaa aikaa, havaitaan erittäin suuri ero mobiililaitteiden ja pöytätietokoneiden välillä.
Mobiililaitteiden komentosarjojen käsittelyyn liittyvä ajan lisäys (prosenttiosuus) verrattuna pöytäkoneisiin
Persentiilit
10
25
50
75
90
Kaikki sivustot
144.1
172.8
185.5
208.5
224.0
jQuery-sivustot
188.2
187.4
191.3
209.6
221.9
Vue-sivustot
222.5
220.8
220.2
221.4
220.4
Kulmaiset sivustot
205.1
206.0
201.6
210.4
218.7
Reaktiosivustot
431.5
386.8
337.9
242.6
179.6
Vaikka puhelimen ja kannettavan tietokoneen koodinkäsittelyn nopeudessa on odotettavissa jonkin verran eroa, niin suuret luvut kertovat minulle, että nykyaikaiset kehykset eivät ole riittävästi kohdistettu pienitehoisiin laitteisiin ja että ne pyrkivät kuromaan umpeen havaitsemaansa aukkoa. Jopa 10. prosenttipisteessä React-sivustot viettävät 431.5 % enemmän aikaa mobiilipääsäikeessä kuin työpöydän pääsäikeessä. jQueryssä on pienin ero, mutta täälläkin vastaava luku on 188.2 %. Kun verkkosivustojen kehittäjät tekevät projektejaan siten, että niiden käsittely vaatii enemmän prosessoriaikaa (ja niin tapahtuu, ja se vain pahenee ajan myötä), pienitehoisten laitteiden omistajien on maksettava siitä.
Tulokset
Hyvien kehysten pitäisi antaa kehittäjille hyvä perusta verkkoprojektien rakentamiselle (turvallisuuden, saavutettavuuden, suorituskyvyn osalta), tai niissä pitäisi olla sisäänrakennettuja rajoituksia, jotka vaikeuttavat näiden rajoitusten vastaisen sisällön rakentamista.
Tämä ei näytä koskevan verkkoprojektien suorituskykyä (eikä oletettavasti myös niiden ).
On syytä huomata, että vain siksi, että React- tai Angular-sivustot käyttävät enemmän prosessoriaikaa koodin valmisteluun kuin muut, ei välttämättä tarkoita, että React-sivustot olisivat suoritinintensiivisempiä kuin Vue-sivustot. Itse asiassa tarkastelemamme tiedot kertovat hyvin vähän kehysten ja kirjastojen toimivuudesta. He puhuvat enemmän kehityslähestymistapoista, jotka tietoisesti tai ei, nämä puitteet voivat työntää ohjelmoijia. Puhumme kehysten dokumentoinnista, niiden ekosysteemistä, yleisistä kehitystekniikoista.
On myös syytä mainita asia, jota emme tässä analysoineet, eli kuinka paljon aikaa laite käyttää JavaScript-koodin suorittamiseen navigoidessaan sivuston sivujen välillä. SPA-argumentti on se, että kun yksisivuinen sovellus on ladattu selaimeen, käyttäjä voi teoriassa avata sivuston sivut nopeammin. Oma kokemukseni kertoo, että tämä on kaukana tosiasiasta. Mutta meillä ei ole tietoja tämän asian selventämiseksi.
On selvää, että jos käytät kehystä tai kirjastoa verkkosivuston luomiseen, teet kompromissin projektin lataamisen ja valmistelemisen suhteen. Tämä pätee myös kaikkein positiivisimpiin skenaarioihin.
On täysin mahdollista tehdä kompromisseja sopivissa tilanteissa, mutta on tärkeää, että kehittäjät tekevät tällaisia kompromisseja tietoisesti.
Mutta meillä on myös syytä optimismiin. Olen innoissani nähdessäni, kuinka tiiviisti Chrome-kehittäjät tekevät yhteistyötä joidenkin tarkastelemiemme käyttöliittymätyökalujen kehittäjien kanssa auttaaksemme parantamaan näiden työkalujen suorituskykyä.
Olen kuitenkin pragmaattinen ihminen. Uudet arkkitehtuurit luovat suorituskykyongelmia niin usein kuin ne ratkaisevat ne. Ja virheiden korjaaminen vie aikaa. Aivan kuten meidän ei pitäisi odottaa ratkaisee kaikki suorituskykyongelmat, sinun ei pitäisi odottaa tätä suosikkikehystemme uusilta versioilta.
Jos haluat käyttää jotakin tässä artikkelissa käsitellyistä käyttöliittymätyökaluista, sinun on ponnisteltava ylimääräisesti, jotta et vahingoittaisi projektisi suorituskykyä sillä välin. Tässä on muutamia huomioitavia seikkoja ennen uuden kehyksen aloittamista:
- Testaa itsesi terveellä järjellä. Tarvitseeko sinun todella käyttää valittua kehystä? Puhdas JavaScript pystyy nykyään paljon.
- Onko valitulle kehykselle olemassa kevyempää vaihtoehtoa (kuten Preact, Svelte tai jokin muu), joka voi tarjota sinulle 90 % tämän kehyksen ominaisuuksista?
- Jos käytät jo viitekehystä, harkitse, tarjoaako jotain parempia, konservatiivisempia vakiovaihtoehtoja (esim. Nuxt.js Vuen sijaan, Next.js Reactin sijaan ja niin edelleen).
- Mitä sinun tulee JavaScriptin suorituskyky?
- Kuinka sinä voit kehitysprosessi, joka vaikeuttaa enemmän JavaScript-koodin lisäämistä projektiin kuin on ehdottoman välttämätöntä?
- Jos käytät kehystä kehityksen helpottamiseksi, harkitse lähettää kehyskoodin asiakkaille. Ehkä voit ratkaista kaikki palvelimen ongelmat?
Yleensä nämä ideat ovat katsomisen arvoisia, riippumatta siitä, mitä olet valinnut etupään kehittämiseen. Mutta ne ovat erityisen tärkeitä, kun työskentelet projektin parissa, josta puuttuu suorituskyky alusta alkaen.
Hyvä lukijat! Millaisena näet ihanteellisen JavaScript-kehyksen?
Lähde: will.com