Nincs gyorsabb módja egy webhely lelassításának (szójáték célja), mint egy csomó JavaScript kód használata rajta. JavaScript használata esetén nem kevesebb, mint négyszeres projektek teljesítésével kell fizetni érte. A webhely JavaScript kódja a következőképpen tölti be a felhasználók rendszereit:
- Fájl letöltése a hálózaton keresztül.
- A kicsomagolt forráskód elemzése és fordítása letöltés után.
- JavaScript kód végrehajtása.
- Memória fogyasztás.
Ez a kombináció kiderül .
És egyre több JS kódot építünk be projektjeinkbe. Ahogy a szervezetek a keretrendszerek és könyvtárak, például a React, a Vue és mások által működtetett webhelyek felé haladnak, a webhelyek alapvető funkcióit erősen a JavaScript-től tesszük függővé.
Sok nagyon nehéz webhelyet láttam JavaScript-keretrendszert használva. De az én elképzelésem a kérdésről nagyon elfogult. Az a helyzet, hogy azok a cégek, akikkel dolgozom, éppen azért fordulnak hozzám, mert összetett problémákkal szembesülnek az oldal teljesítménye terén. Ebből kifolyólag kíváncsi lettem, mennyire gyakori ez a probléma, és milyen "büntetéseket" fizetünk, ha egy adott oldal alapjául egyik vagy másik keretrendszert választjuk.
A projekt segített kitalálni ezt. .
Adat
A HTTP Archívum projekt összesen 4308655 5484239 XNUMX normál asztali webhelyekre mutató hivatkozást és XNUMX XNUMX XNUMX mobilwebhelyre mutató hivatkozást követ nyomon. Az ezekhez a hivatkozásokhoz kapcsolódó számos mérőszám között található a megfelelő webhelyeken található technológiák listája. Ez azt jelenti, hogy több ezer webhelyről mintát vehetünk, amelyek különféle keretrendszereket és könyvtárakat használnak, és megtudhatjuk, mennyi kódot küldenek az ügyfeleknek, és mekkora terhelést jelent ez a kód a felhasználók rendszerein.
2020 márciusi adatokat gyűjtöttem, ezek voltak a legfrissebb adatok, amelyekhez hozzáfértem.
Úgy döntöttem, hogy az összes webhely összesített HTTP-archívuma adatait összehasonlítom a React, Vue és Angular használatával talált webhelyek adataival, bár fontolóra vettem más forrásanyagok felhasználását is.
Az érdekesebbé tétel érdekében a jQuery-t használó webhelyeket is hozzáadtam a forrásadatkészlethez. Ez a könyvtár még mindig nagyon népszerű. Ezenkívül a React, a Vue és az Angular által kínált egyoldalas alkalmazás (SPA) modelltől eltérő megközelítést vezet be a webfejlesztéshez.
A HTTP-archívumban található hivatkozások, amelyek olyan webhelyeket képviselnek, amelyekről kiderült, hogy érdekes technológiákat használnak
Keretrendszer vagy könyvtár
Mobil webhelyekre mutató hivatkozások
Hivatkozások normál oldalakra
jQuery
4615474
3714643
Reagál
489827
241023
Vue
85649
43691
szögletes
19423
18088
Remények és álmok
Mielőtt rátérnénk az adatelemzésre, arról szeretnék beszélni, hogy mit szeretnék remélni.
Úgy gondolom, hogy egy ideális világban a keretrendszereknek túl kell lépniük a fejlesztők igényeinek kielégítésén, és bizonyos előnyöket kell biztosítaniuk az oldalainkkal dolgozó átlagos felhasználók számára. A teljesítmény csak egyike ezeknek az előnyöknek. Itt jön a képbe a hozzáférhetőség és a biztonság. De ez csak a legfontosabb.
Tehát egy ideális világban valamilyen keretrendszernek egyszerűvé kell tennie egy nagy teljesítményű webhely létrehozását. Ezt vagy azért kell megtenni, mert a keretrendszer megfelelő alapot ad a fejlesztőnek egy projekt felépítéséhez, vagy azért, mert korlátozásokat szab a fejlesztésre, olyan követelményeket támaszt vele szemben, amelyek megnehezítik valami megforduló fejlesztését. lassúnak lenni.
A legjobb kereteknek mindkettőt meg kell tenniük: jó alapot kell adniuk, és korlátozásokat kell szabniuk a munkának, lehetővé téve a megfelelő eredmény elérését.
Az adatok medián értékeinek elemzése nem fogja megadni a szükséges információkat. És valójában ez a megközelítés kimarad figyelmünkből . Ehelyett százalékokat származtattam a rendelkezésemre álló adatokból. Ezek a 10, 25, 50 (medián), 75, 90 percentilisek.
Különösen a 10. és 90. percentilis érdekel. A 10. percentilis egy adott keretrendszer legjobb teljesítményét jelenti (vagy legalábbis többé-kevésbé közel áll a legjobbhoz). Más szavakkal, ez azt jelenti, hogy az adott keretrendszert használó webhelyek mindössze 10%-a jut el erre a szintre vagy magasabbra. A 90. percentilis viszont az érem másik oldala – megmutatja, milyen rosszra fordulhatnak a dolgok. A 90. percentilis a mögötte lévő webhelyek – a webhelyek alsó 10%-a, amelyek a legtöbb JS-kóddal rendelkeznek, vagy a leghosszabb ideig dolgozzák fel kódjukat a főszálon.
JavaScript kód kötetei
Először is érdemes elemezni a hálózaton keresztül a különböző oldalak által továbbított JavaScript-kód méretét.
A mobileszközökre átvitt JavaScript-kód mennyisége (Kb).
Percentilisek
10
25
50
75
90
Minden webhely
93.4
196.6
413.5
746.8
1201.6
jQuery webhelyek
110.3
219.8
430.4
748.6
1162.3
Vue oldalak
244.7
409.3
692.1
1065.5
1570.7
Szögletes helyek
445.1
675.6
1066.4
1761.5
2893.2
React Sites
345.8
441.6
690.3
1238.5
1893.6
A mobileszközökre küldött JavaScript-kód mennyisége
Az asztali eszközökre átvitt JavaScript-kód mennyisége (Kb).
Percentilisek
10
25
50
75
90
Minden webhely
105.5
226.6
450.4
808.8
1267.3
jQuery webhelyek
121.7
242.2
458.3
803.4
1235.3
Vue oldalak
248.0
420.1
718.0
1122.5
1643.1
Szögletes helyek
468.8
716.9
1144.2
1930.0
3283.1
React Sites
308.6
469.0
841.9
1472.2
2197.8
Az asztali eszközökre küldött JavaScript-kód mennyisége
Ha csak a JS-kód méretéről beszélünk, amelyet a webhelyek küldenek az eszközöknek, akkor minden úgy néz ki, ahogyan azt várná. Ugyanis, ha valamelyik keretrendszert használjuk, az ideális esetben is azt jelenti, hogy az oldal JavaScript kódjának mennyisége megnő. Ez nem meglepő – nem tehet egy JavaScript keretrendszert egy webhely alapjává, és nem számíthat arra, hogy a projekt JS-kódjának mennyisége nagyon alacsony lesz.
Ami figyelemre méltó ezekben az adatokban, az az, hogy egyes keretrendszerek és könyvtárak jobb kiindulópontnak tekinthetők egy projekthez, mint mások. A jQuery-t tartalmazó webhelyek néznek ki a legjobban. A webhelyek asztali verzióin 15%-kal több JavaScriptet tartalmaznak, mint az összes webhelyen, mobilon pedig 18%-kal többet. (El kell ismerni, itt van némi adatsérülés. A tény az, hogy a jQuery sok oldalon jelen van, így teljesen természetes, hogy az ilyen oldalak a többinél szorosabban kapcsolódnak a webhelyek teljes számához. Ez azonban nem befolyásolja a nyers Az adatok az egyes keretrendszerekhez kerülnek kiadásra.)
Míg a kódmennyiség 15-18%-os növekedése figyelemre méltó adat, ezt más keretrendszerekkel és könyvtárakkal összehasonlítva megállapítható, hogy a jQuery által kivetett "adó" nagyon alacsony. A 10. százalékos szögletes webhelyek 344%-kal több adatot küldenek asztali számítógépre, mint az összes webhely, és 377%-kal többet mobilra. A React webhelyek a következő legsúlyosabbak, 193%-kal több kódot küldenek asztali számítógépre, mint az összes webhely, és 270%-kal több kódot mobilra.
Korábban már említettem, hogy bár egy keretrendszer használata azt jelenti, hogy bizonyos mennyiségű kód bekerül a projektbe, remélem, már a munka elején, a keretrendszer képes valamilyen módon korlátozni a fejlesztőt. Különösen a kód maximális mennyiségének korlátozásáról beszélünk.
Érdekes módon a jQuery webhelyek ezt az ötletet követik. Míg a 10. percentilisnél valamennyivel nehezebbek (15-18%-kal), a 90. percentilisnél valamivel könnyebbek, 3% körüliek asztali számítógépen és mobileszközön egyaránt. Ez nem azt jelenti, hogy ez nagyon jelentős előny, de elmondható, hogy a jQuery oldalak legalábbis nem rendelkeznek hatalmas JavaScript kódméretekkel, még a legnagyobb verzióikban sem.
De ugyanez nem mondható el más keretekről.
Csakúgy, mint a 10. percentilis esetében, a 90. percentilisnél az Angular és a React helyei eltérnek a többi oldaltól, de sajnos rosszabbul.
A 90. percentilisnél az Angular webhelyek 141%-kal több adatot küldenek mobilra, mint az összes webhely, és 159%-kal többet az asztali számítógépekre. A React webhelyek 73%-kal többet küldenek asztali számítógépre, mint az összes webhely, és 58%-kal többet mobilra. A React-helyek kódmérete a 90. percentilisnél 2197.8 KB. Ez azt jelenti, hogy az ilyen oldalak 322.9 KB-tal több adatot küldenek mobileszközökre, mint a legközelebbi, Vue-n alapuló versenytársaik. Még nagyobb a szakadék az Angular és React alapú asztali webhelyek és más webhelyek között. Például az asztali React webhelyek 554.7 KB-tal több JS-kódot küldenek az eszközöknek, mint a megfelelő Vue-helyek.
Időbe telik a JavaScript kód feldolgozása a fő szálban
A fenti adatok egyértelműen jelzik, hogy a vizsgált keretrendszereket és könyvtárakat használó webhelyek nagy mennyiségű JavaScript-kódot tartalmaznak. De természetesen ez csak egy része az egyenletünknek.
Miután a JavaScript kód megérkezett a böngészőbe, azt működőképes állapotba kell hozni. Különösen sok problémát okoznak azok a műveletek, amelyeket a fő böngészőszálban található kóddal kell végrehajtani. A fő szál felelős a felhasználói műveletek feldolgozásáért, a stílusok kiszámításáért, az oldalelrendezés felépítéséért és megjelenítéséért. Ha túlterheli a főszálat JavaScript-feladatokkal, annak nem lesz lehetősége időben elvégezni a többi feladatot. Ez késésekhez és "fékezésekhez" vezet az oldalak munkájában.
A HTTP Archívum adatbázis információkat tartalmaz arról, hogy mennyi ideig tart a JavaScript kód feldolgozása a V8 motor fő szálában. Ez azt jelenti, hogy összegyűjthetjük ezeket az adatokat, és megtudhatjuk, hogy a fő szál mennyi időt vesz igénybe a különböző webhelyek JavaScript-kódjának feldolgozásához.
Processzoridő (ezredmásodpercben), amely a mobileszközökön végzett szkriptfeldolgozáshoz kapcsolódik
Percentilisek
10
25
50
75
90
Minden webhely
356.4
959.7
2372.1
5367.3
10485.8
jQuery webhelyek
575.3
1147.4
2555.9
5511.0
10349.4
Vue oldalak
1130.0
2087.9
4100.4
7676.1
12849.4
Szögletes helyek
1471.3
2380.1
4118.6
7450.8
13296.4
React Sites
2700.1
5090.3
9287.6
14509.6
20813.3
A mobileszközökön történő szkriptfeldolgozáshoz kapcsolódó processzoridő
A processzor ideje (ezredmásodpercben), amely az asztali eszközökön végzett szkriptfeldolgozáshoz kapcsolódik
Percentilisek
10
25
50
75
90
Minden webhely
146.0
351.8
831.0
1739.8
3236.8
jQuery webhelyek
199.6
399.2
877.5
1779.9
3215.5
Vue oldalak
350.4
650.8
1280.7
2388.5
4010.8
Szögletes helyek
482.2
777.9
1365.5
2400.6
4171.8
React Sites
508.0
1045.6
2121.1
4235.1
7444.3
Az asztali eszközökön végzett szkriptfeldolgozáshoz kapcsolódó processzoridő
Itt valami nagyon ismerős dolog látható.
Először is, a jQuery-t használó webhelyek lényegesen kevesebbet költenek a fő szál JavaScript-feldolgozására, mint más webhelyek. A 10. percentilisnél az összes webhelyhez képest a jQuery-webhelyek mobileszközökön 61%-kal több időt töltenek a főszálon lévő JS-kód feldolgozásával. Az asztali jQuery webhelyek esetében a feldolgozási idő 37%-kal nő. A 90. percentilisnél a jQuery-webhelyek nagyon közel állnak az összesített pontszámokhoz. Pontosabban, a mobileszközökön lévő jQuery-webhelyek 1.3%-kal kevesebb időt töltenek a főszálon, mint az összes webhely, és 0.7%-kal kevesebb időt az asztali eszközökön.
Értékelésünk másik oldalán azok a keretek állnak, amelyeket a főszál legnagyobb terhelése jellemez. Ez ismét az Angular and React. Az egyetlen különbség a kettő között, hogy míg az Angular webhelyek több kódot küldenek a böngészőknek, mint a React webhelyek, az Angular webhelyek kevesebb CPU-időt vesznek igénybe a kód feldolgozásához. Sokkal kevésbé.
A 10. percentilisnél az asztali Angular webhelyek 230%-kal több időt töltenek a fő szálon a JS-kód feldolgozásával, mint az összes webhely. A mobilwebhelyek esetében ez a szám 313%. A React oldalak teljesítenek a legrosszabbul. Asztali számítógépeken 248%-kal több időt töltenek a kód feldolgozásával, mint az összes webhelyen, és 658%-kal többet mobilon. A 658% nem elírás. A 10. percentilisnél a React webhelyek 2.7 másodpercet töltenek a főszálból a kódjuk feldolgozásával.
A 90. percentilis ezekkel a hatalmas számokkal összehasonlítva legalább egy kicsit jobban néz ki. Az összes webhelyhez képest az Angular projektek 29%-kal több időt töltenek az asztali eszközökön a fő szálon, és 27%-kal több időt a mobileszközökön. A React oldalak esetében ugyanezek az adatok 130%-nak, illetve 98%-nak tűnnek.
A 90. percentilis százalékos eltérései jobban néznek ki, mint a 10. százalékos hasonló értékek. De itt érdemes megjegyezni, hogy az időt jelző számok meglehetősen ijesztőnek tűnnek. Tegyük fel, hogy 20.8 másodperc a fő mobilszálon egy Reacttel épített webhely esetében. (Azt hiszem, hogy ez alatt az idő alatt valójában mi is történik, megérdemel egy külön cikket).
Itt van egy lehetséges bonyodalom (köszönöm amiért felhívtam a figyelmemet erre a tulajdonságra, és alaposan átgondoltam az adatokat ebből a szempontból). Az a tény, hogy sok webhely több front-end eszközt használ. Különösen sok olyan webhelyet láttam, amely a jQuery-t használja a React vagy a Vue mellett, mivel ezek a webhelyek a jQuery-ről más keretrendszerekre vagy könyvtárakra költöznek. Ennek eredményeként ismét rátaláltam az adatbázisra, ezúttal csak azokat a hivatkozásokat választottam ki, amelyek csak a React, jQuery, Angular vagy Vue-t használó webhelyeknek felelnek meg, de ezek kombinációját nem. Íme, amit kaptam.
Processzoridő (ezredmásodpercben) a szkriptek mobileszközökön történő feldolgozásához kapcsolódóan olyan helyzetben, amikor a webhelyek csak egy keretrendszert vagy csak egy könyvtárat használnak
Percentilisek
10
25
50
75
90
Csak a jQuery-t használó webhelyek
542.9
1062.2
2297.4
4769.7
8718.2
Csak a Vue-t használó webhelyek
944.0
1716.3
3194.7
5959.6
9843.8
Csak az Angulart használó webhelyek
1328.9
2151.9
3695.3
6629.3
11607.7
Csak a Reactot használó webhelyek
2443.2
4620.5
10061.4
17074.3
24956.3
A mobileszközökön lévő szkriptek feldolgozásához kapcsolódó processzoridő olyan helyzetben, amikor a webhelyek csak egy keretrendszert vagy csak egy könyvtárat használnak
Először is valami, ami nem meglepő: ha egy webhely csak egy keretrendszert vagy egy könyvtárat használ, az ilyen webhely teljesítménye gyakrabban javul. Mindegyik műszer jobban teljesít a 10. és 25. percentilisnél. Van értelme. Az egyetlen keretrendszer használatával készült webhelynek jobban kell teljesítenie, mint a két vagy több keretrendszerrel vagy könyvtárral készült webhelynek.
Valójában az egyes vizsgált front-end eszközök teljesítménye minden esetben jobbnak tűnik, kivéve egy furcsa kivételt. Meglepett, hogy az 50. percentilisnél és a felett a Reactot használó webhelyek rosszabbul teljesítenek, ha a React az egyetlen könyvtár, amelyet használnak. Egyébként ez volt az oka annak, hogy itt bemutatom ezeket az adatokat.
Ez kicsit furcsa, de azért megpróbálok magyarázatot keresni erre a furcsaságra.
Ha egy projekt a React-ot és a jQuery-t is használja, akkor ez a projekt valószínűleg valahol a jQuery-ről a React-re való átmenet felénél tart. Talán van egy kódbázisa, ahol ezek a könyvtárak keverednek. Mivel már láttuk, hogy a jQuery-webhelyek kevesebb időt töltenek a főszálon, mint a React-webhelyek, ez azt jelezheti számunkra, hogy a jQuery bizonyos funkcióinak megvalósítása javítja a webhely teljesítményét.
De ahogy a projekt áttér a jQuery-ről a React-re, és egyre inkább a React-ra támaszkodik, a dolgok megváltoznak. Ha az oldal valóban jó minőségű, és az oldal fejlesztői körültekintően használják a Reactot, akkor minden rendben lesz egy ilyen oldallal. Az átlagos React webhelyen azonban a React széles körű használata azt jelenti, hogy a fő szál nagy terhelés alatt áll.
A mobil és az asztali eszközök közötti szakadék
Egy másik szempont, ahonnan a vizsgált adatokat vizsgáltam, az volt, hogy megvizsgáljam, mekkora a szakadék a mobil és asztali eszközökön végzett webhelyekkel való munka között. Ha a JavaScript-kód mennyiségének összehasonlításáról beszélünk, akkor egy ilyen összehasonlítás nem tár fel semmi szörnyűséget. Persze jó lenne látni kisebb mennyiségű letölthető kódot, de a mobil és az asztali kód mennyiségében nincs nagy különbség.
De ha elemezzük a kód feldolgozásához szükséges időt, akkor észrevehetővé válik a mobil és az asztali eszközök közötti nagyon nagy szakadék.
A szkriptek mobileszközökön történő feldolgozásához kapcsolódó időnövekedés (százalék) az asztali számítógépekhez képest
Percentilisek
10
25
50
75
90
Minden webhely
144.1
172.8
185.5
208.5
224.0
jQuery webhelyek
188.2
187.4
191.3
209.6
221.9
Vue oldalak
222.5
220.8
220.2
221.4
220.4
Szögletes helyek
205.1
206.0
201.6
210.4
218.7
React Sites
431.5
386.8
337.9
242.6
179.6
Bár a telefon és a laptop kódfeldolgozási sebességében némi eltérés várható, az ilyen nagy számok azt sugallják, hogy a modern keretrendszerek nem céloznak kellően az alacsony fogyasztású eszközöket, és igyekeznek bezárni a felfedezett rést. A React-webhelyek még a 10. percentilisnél is 431.5%-kal több időt töltenek a mobil főszálon, mint az asztali főszálon. A jQuerynél van a legkisebb eltérés, de még itt is 188.2%. Amikor a weboldal-fejlesztők úgy készítik el projekteiket, hogy a feldolgozásuk több processzoridőt igényel (és ez megtörténik, és ez idővel csak romlik), az alacsony fogyasztású eszközök tulajdonosainak fizetniük kell érte.
Eredményei
A jó keretrendszereknek megfelelő alapot kell adniuk a fejlesztőknek a webes projektek elkészítéséhez (biztonság, hozzáférhetőség, teljesítmény szempontjából), vagy beépített korlátozásokkal kell rendelkezniük, amelyek megnehezítik olyan dolgok létrehozását, amelyek megsértik ezeket a korlátozásokat.
Úgy tűnik, ez nem vonatkozik a webprojektek teljesítményére (és feltehetően nem is azokra ).
Érdemes megjegyezni, hogy csak azért, mert a React vagy az Angular webhelyek több CPU-időt töltenek a kód elkészítésével, mint mások, nem feltétlenül jelenti azt, hogy a React webhelyek futás közben CPU-igényesebbek, mint a Vue webhelyek. Valójában az általunk áttekintett adatok nagyon keveset mondanak el a keretrendszerek és a könyvtárak működési teljesítményéről. Inkább azokról a fejlesztési megközelítésekről beszélnek, amelyekre ezek a keretrendszerek – tudatosan vagy sem – nyomni tudják a programozókat. A keretrendszerek dokumentációjáról, azok ökoszisztémájáról, a közös fejlesztési technikákról beszélünk.
Érdemes még megemlíteni valamit, amit itt nem elemeztünk, mégpedig azt, hogy mennyi időt tölt a készülék JavaScript kód futtatásával, amikor az oldal oldalai között navigál. Az SPA mellett szól az az érv, hogy miután az egyoldalas alkalmazást betöltik a böngészőbe, a felhasználó elméletileg gyorsabban tudja majd megnyitni az oldal oldalait. Saját tapasztalataim azt mutatják, hogy ez távol áll a valóságtól. De nem rendelkezünk adatokkal ennek a kérdésnek a tisztázására.
Egyértelmű, hogy ha keretrendszert vagy könyvtárat használ egy webhely létrehozásához, akkor kompromisszumot köt a projekt kezdeti betöltése és az indulás előkészítése tekintetében. Ez még a legpozitívabb forgatókönyvekre is vonatkozik.
Tökéletesen meg lehet kötni bizonyos kompromisszumokat megfelelő helyzetekben, de fontos, hogy a fejlesztők tudatosan kössenek ilyen kompromisszumokat.
De van okunk az optimizmusra is. Izgatottan várom, hogy a Chrome fejlesztői milyen szorosan együttműködnek az általunk felülvizsgált kezelőfelületi eszközök fejlesztőivel annak érdekében, hogy javítsuk ezen eszközök teljesítményét.
Ennek ellenére pragmatikus ember vagyok. Az új architektúrák olyan gyakran okoznak teljesítményproblémákat, ahányszor megoldják azokat. A hibák kijavítása pedig időbe telik. Ahogy nem is várhatnánk megoldja az összes teljesítményproblémát, ezt nem szabad elvárni kedvenc keretrendszereink új verzióitól.
Ha az ebben a cikkben tárgyalt kezelőfelületek egyikét szeretné használni, ez azt jelenti, hogy további erőfeszítéseket kell tennie, hogy közben ne rontsa a projekt teljesítményét. Íme néhány szempont, amelyeket figyelembe kell venni egy új keretrendszer elindítása előtt:
- Teszteld magad józan ésszel. Valóban használnia kell a választott keretet? A tiszta JavaScript ma sok mindenre képes.
- Van valami könnyebb alternatíva a választott keretrendszerhez (mint például a Preact, Svelte vagy valami más), amely a keretrendszer képességeinek 90%-át biztosítja?
- Ha már keretrendszert használ, fontolja meg, hogy van-e valami, ami jobb, konzervatívabb, szabványos opciókat kínál (pl. Nuxt.js a Vue helyett, Next.js a React helyett, és így tovább).
- Mi lesz a tiéd JavaScript teljesítmény?
- Hogyan tudod egy fejlesztési folyamat, amely megnehezíti a feltétlenül szükségesnél több JavaScript kód beszúrását egy projektbe?
- Ha keretrendszert használ a fejlesztés megkönnyítése érdekében, fontolja meg keretkódot küldeni az ügyfeleknek. Esetleg meg tudod oldani az összes problémát a szerveren?
Általában ezeket az ötleteket érdemes megnézni, függetlenül attól, hogy pontosan mit választott a front-end fejlesztéshez. De különösen fontosak, ha olyan projekten dolgozik, amely a kezdetektől fogva nem teljesít.
Kedves olvasók! Hogyan látja az ideális JavaScript-keretrendszert?
Forrás: will.com