Ne ekzistas pli rapida maniero malrapidigi retejon (vortludo) ol uzi amason da JavaScript-kodo sur ĝi. Kiam vi uzas JavaScript, vi devas pagi por ĝi per la agado de projektoj ne malpli ol kvar fojojn. Jen kiel la JavaScript-kodo de la retejo ŝarĝas la sistemojn de uzantoj:
- Elŝutante dosieron tra la reto.
- Analizo kaj kompili malpakitan fontkodon post elŝuto.
- Ekzekuto de JavaScript-kodo.
- Memorkonsumo.
Ĉi tiu kombinaĵo rezultas .
Kaj ni inkluzivas pli kaj pli da JS-kodo en niaj projektoj. Dum organizoj moviĝas al retejoj funkciigitaj de kadroj kaj bibliotekoj kiel React, Vue kaj aliaj, ni tre dependas de la kernfunkcio de retejoj de JavaScript.
Mi vidis multajn tre pezajn retejojn uzante JavaScript-kadrojn. Sed mia vizio de la afero estas tre partia. La fakto estas, ke la kompanioj kun kiuj mi laboras turnas sin al mi ĝuste ĉar ili alfrontas kompleksajn problemojn en la kampo de la agado de la retejo. Kiel rezulto, mi scivolis pri kiom ofta ĉi tiu problemo estas, kaj pri kiaj "punoj" ni pagas kiam ni elektas unu aŭ alian kadron kiel bazon por certa retejo.
La projekto helpis min eltrovi ĉi tion. .
datumoj
La projekto HTTP Archive spuras entute 4308655 ligilojn al regulaj labortablaj retejoj kaj 5484239 ligiloj al moveblaj retejoj. Inter la multaj metrikoj asociitaj kun ĉi tiuj ligiloj estas listo de teknologioj trovitaj en la respektivaj retejoj. Ĉi tio signifas, ke ni povas provi milojn da retejoj, kiuj uzas diversajn kadrojn kaj bibliotekojn kaj lerni pri kiom da kodo ili sendas al klientoj kaj kiom da ŝarĝo ĉi tiu kodo kreas sur la sistemoj de uzantoj.
Mi kolektis datumojn de marto 2020, kiuj estis la plej lastatempaj datumoj, al kiuj mi havis aliron.
Mi decidis kompari agregitajn HTTP-Arkivdatumojn tra ĉiuj retejoj kun datumoj de retejoj trovitaj uzante React, Vue kaj Angular, kvankam mi pripensis uzi ankaŭ alian fontomaterialon.
Por fari ĝin pli interesa, mi ankaŭ aldonis retejojn kiuj uzas jQuery al la fonta datumaro. Ĉi tiu biblioteko ankoraŭ estas tre populara. Ĝi ankaŭ enkondukas malsaman aliron al TTT-evoluo ol la modelo de Single Page Application (SPA) ofertita de React, Vue kaj Angular.
Ligiloj en la HTTP-Arkivo reprezentante retejojn, kiuj estas trovitaj uzi teknologiojn de intereso
Kadro aŭ biblioteko
Ligiloj al moveblaj retejoj
Ligiloj al regulaj retejoj
jQuery
4615474
3714643
Reagi
489827
241023
Vue
85649
43691
angula
19423
18088
Esperoj kaj revoj
Antaŭ ol ni transiru al datuma analizo, mi volas paroli pri tio, kion mi ŝatus esperi.
Mi kredas, ke en ideala mondo, kadroj devus iri preter renkonti la bezonojn de programistoj kaj provizi iun specifan avantaĝon al la averaĝa uzanto, kiu laboras kun niaj retejoj. Efikeco estas nur unu el tiuj avantaĝoj. Ĉi tie eniras alirebleco kaj sekureco. Sed ĉi tio estas nur la plej grava.
Do, en ideala mondo, ia kadro devus faciligi krei alt-efikan retejon. Ĉi tio devus esti farita aŭ pro la fakto, ke la kadro donas al la programisto decan bazon sur kiu konstrui projekton, aŭ pro la fakto, ke ĝi trudas limigojn al evoluo, prezentas postulojn por ĝi, kiuj malfaciligas la disvolviĝon de io, kio turniĝas. ekstere esti malrapida.
La plej bonaj kadroj devas fari ambaŭ: doni bonan bazon, kaj trudi limigojn al la laboro, permesante al vi atingi decan rezulton.
Analizi la mezajn valorojn de la datumoj ne donos al ni la informojn, kiujn ni bezonas. Kaj, fakte, ĉi tiu aliro forlasas de nia atento . Anstataŭe, mi derivis procentojn de la datumoj kiujn mi havis. Ĉi tiuj estas 10, 25, 50 (mediano), 75, 90 procentoj.
Mi interesiĝas precipe pri la 10-a kaj 90-a procentoj. La 10-a percentilo reprezentas la plej bonan agadon (aŭ almenaŭ pli-malpli proksiman al la plej bona) por aparta kadro. Alivorte, ĉi tio signifas, ke nur 10% de retejoj uzantaj apartan kadron atingas ĉi tiun nivelon aŭ pli altan. La 90-a procento, aliflanke, estas la alia flanko de la monero - ĝi montras al ni kiom malbonaj aferoj povas fariĝi. La 90-a procento estas la retejoj malantaŭaj - tiuj malsupraj 10% de retejoj, kiuj havas la plej JS-kodon aŭ la plej longan tempon por prilabori sian kodon sur la ĉefa fadeno.
Volumoj de JavaScript-kodo
Komence, estas senco analizi la grandecon de la JavaScript-kodo transdonita de malsamaj retejoj tra la reto.
La kvanto de JavaScript-kodo (Kb) transdonita al porteblaj aparatoj
Procentoj
10
25
50
75
90
Ĉiuj retejoj
93.4
196.6
413.5
746.8
1201.6
jQuery-ejoj
110.3
219.8
430.4
748.6
1162.3
Vue retejoj
244.7
409.3
692.1
1065.5
1570.7
Angulejoj
445.1
675.6
1066.4
1761.5
2893.2
Reagi Ejojn
345.8
441.6
690.3
1238.5
1893.6
Kvanto de JavaScript-kodo sendita al porteblaj aparatoj
Kvanto de JavaScript-kodo (Kb) transdonita al labortablaj aparatoj
Procentoj
10
25
50
75
90
Ĉiuj retejoj
105.5
226.6
450.4
808.8
1267.3
jQuery-ejoj
121.7
242.2
458.3
803.4
1235.3
Vue retejoj
248.0
420.1
718.0
1122.5
1643.1
Angulejoj
468.8
716.9
1144.2
1930.0
3283.1
Reagi Ejojn
308.6
469.0
841.9
1472.2
2197.8
Kvanto de JavaScript-kodo sendita al labortablaj aparatoj
Se ni parolas nur pri la grandeco de la JS-kodo, kiun retejoj sendas al aparatoj, tiam ĉio aspektas kiel vi povus atendi. Nome, se unu el la kadroj estas uzataj, tio signifas, ke eĉ en ideala situacio pliiĝos la volumo de la JavaScript-kodo de la retejo. Ĉi tio ne estas surpriza - vi ne povas fari JavaScript-kadron la bazo de retejo kaj atendi ke la volumeno de la JS-kodo de la projekto estos tre malalta.
Kio estas rimarkinda pri ĉi tiuj datumoj estas, ke iuj kadroj kaj bibliotekoj povas esti konsiderataj pli bona deirpunkto por projekto ol aliaj. Retejoj kun jQuery aspektas plej bone. Sur labortablaj versioj de retejoj, ili enhavas 15% pli da JavaScript ol ĉiuj retejoj, kaj ĉe poŝtelefono ili enhavas 18% pli. (Konsentite, estas iom da datuma korupto ĉi tie. Fakto estas, ke jQuery ĉeestas en multaj retejoj, do estas nature, ke tiaj retejoj estas pli proksime rilataj ol aliaj kun la totala nombro da retejoj. Tamen, tio ne influas kiom kruda). datumoj estas eligitaj por ĉiu kadro.)
Dum la 15-18% pliiĝo en kodvolumo estas rimarkinda figuro, komparante tion kun aliaj kadroj kaj bibliotekoj, oni povas konkludi ke la "imposto" pagigita de jQuery estas tre malalta. Angulaj retejoj en la 10-a percentilo sendas 344% pli da datumoj al labortablo ol ĉiuj retejoj, kaj 377% pli al poŝtelefono. React-ejoj estas la sekvaj plej pezaj, sendante 193% pli da kodo al labortablo ol ĉiuj retejoj, kaj 270% pli al poŝtelefono.
Antaŭe mi menciis, ke kvankam uzado de kadro signifas, ke certa kvanto da kodo estos inkluzivita en la projekto, je la komenco mem de laboro pri ĝi, mi esperas, ke la kadro kapablas iel limigi la programiston. Precipe, ni parolas pri limigo de la maksimuma kvanto de kodo.
Interese, jQuery-ejoj sekvas ĉi tiun ideon. Kvankam ili estas iomete pli pezaj ol ĉiuj retejoj ĉe la 10-a procento (je 15-18%), ili estas iomete pli malpezaj ĉe la 90-a procento je ĉirkaŭ 3% sur kaj labortablo kaj poŝtelefono. Ĉi tio ne volas diri, ke ĉi tio estas tre grava avantaĝo, sed oni povas diri, ke jQuery-ejoj, almenaŭ, ne havas grandegajn JavaScript-kodgrandojn, eĉ en siaj plej grandaj versioj.
Sed pri aliaj kadroj oni ne povas diri la samon.
Same kiel en la kazo de la 10-a percentilo, ĉe la 90-a percentilo lokoj sur Angular kaj React diferencas de aliaj retejoj, sed ili diferencas, bedaŭrinde, por la pli malbona.
Ĉe la 90-a procento, Angulaj retejoj sendas 141% pli da datumoj al poŝtelefono ol ĉiuj retejoj, kaj 159% pli al labortablo. React-ejoj sendas 73% pli al labortablo ol ĉiuj retejoj, kaj 58% pli al poŝtelefono. La kodgrandeco de React-ejoj ĉe la 90-a percentilo estas 2197.8 KB. Ĉi tio signifas, ke tiaj retejoj sendas 322.9 KB pli da datumoj al porteblaj aparatoj ol iliaj plej proksimaj konkurantoj bazitaj sur Vue. La interspaco inter labortablaj retejoj bazitaj sur Angular kaj React kaj aliaj retejoj estas eĉ pli granda. Ekzemple, labortablaj React-ejoj sendas 554.7 KB pli da JS-kodo al aparatoj ol ekvivalentaj Vue-ejoj.
Tempo necesa por prilabori JavaScript-kodon en la ĉefa fadeno
La supraj datumoj klare indikas, ke retejoj uzantaj la kadrojn kaj bibliotekojn studatajn enhavas grandajn kvantojn da JavaScript-kodo. Sed kompreneble tio estas nur unu parto de nia ekvacio.
Post kiam la JavaScript-kodo alvenis en la retumilon, ĝi devas esti alportita en funkcian staton. Precipe multaj problemoj estas kaŭzitaj de tiuj agoj, kiuj devas esti faritaj per la kodo en la ĉefa retumila fadeno. La ĉefa fadeno respondecas pri prilaborado de uzantaj agoj, por kalkulado de stiloj, por konstrui kaj montri la paĝan aranĝon. Se vi superŝutas la ĉefan fadenon per JavaScript-taskoj, ĝi ne havos la ŝancon plenumi la ceterajn taskojn ĝustatempe. Tio kondukas al prokrastoj kaj "bremsoj" en la laboro de la paĝoj.
La datumbazo de HTTP Archive havas informojn pri kiom da tempo necesas por prilabori JavaScript-kodon en la ĉefa fadeno de la V8-motoro. Ĉi tio signifas, ke ni povas kolekti ĉi tiujn datumojn kaj ekscii kiom da tempo bezonas la ĉefa fadeno por prilabori la JavaScript de diversaj retejoj.
Procesortempo (en milisekundoj) rilata al skriptprilaborado sur porteblaj aparatoj
Procentoj
10
25
50
75
90
Ĉiuj retejoj
356.4
959.7
2372.1
5367.3
10485.8
jQuery-ejoj
575.3
1147.4
2555.9
5511.0
10349.4
Vue retejoj
1130.0
2087.9
4100.4
7676.1
12849.4
Angulejoj
1471.3
2380.1
4118.6
7450.8
13296.4
Reagi Ejojn
2700.1
5090.3
9287.6
14509.6
20813.3
Procesoro tempo rilata al skripto prilaborado sur porteblaj aparatoj
Procesortempo (en milisekundoj) rilata al skriptprilaborado sur labortablaj aparatoj
Procentoj
10
25
50
75
90
Ĉiuj retejoj
146.0
351.8
831.0
1739.8
3236.8
jQuery-ejoj
199.6
399.2
877.5
1779.9
3215.5
Vue retejoj
350.4
650.8
1280.7
2388.5
4010.8
Angulejoj
482.2
777.9
1365.5
2400.6
4171.8
Reagi Ejojn
508.0
1045.6
2121.1
4235.1
7444.3
Procesoro tempo rilata al skripto prilaborado sur labortablaj aparatoj
Ĉi tie vi povas vidi ion tre konatan.
Por komenci, retejoj kun jQuery elspezas signife malpli por JavaScript-prilaborado en la ĉefa fadeno ol aliaj retejoj. Ĉe la 10-a percentilo, kompare kun ĉiuj retejoj, jQuery-ejoj en poŝtelefono pasigas 61% pli da tempo prilaborante JS-kodon sur la ĉefa fadeno. En la kazo de labortablaj jQuery-ejoj, pretiga tempo pliiĝas je 37%. Ĉe la 90-a procento, jQuery-ejoj poentas tre proksime al la entuta poentoj. Specife, jQuery-ejoj sur porteblaj aparatoj pasigas 1.3% malpli da tempo en la ĉefa fadeno ol ĉiuj retejoj, kaj 0.7% malpli da tempo sur labortablaj aparatoj.
Aliflanke de nia taksado estas la kadroj, kiuj estas karakterizitaj de la plej alta ŝarĝo sur la ĉefa fadeno. Ĉi tio estas, denove, Angula kaj Reagi. La nura diferenco inter la du estas, ke dum Angular-ejoj sendas pli da kodo al retumiloj ol React-ejoj, Angular-ejoj bezonas malpli da CPU-tempo por prilabori kodon. Multe malpli.
Ĉe la 10-a procento, labortablaj Angulaj retejoj pasigas 230% pli da tempo pri la ĉefa fadeno prilaboranta JS-kodon ol ĉiuj retejoj. Por moveblaj retejoj, ĉi tiu cifero estas 313%. React-ejoj estas la plej malbonaj agantoj. Sur labortablo, ili pasigas 248% pli da tempo pri prilaborado de kodo ol ĉiuj retejoj, kaj 658% pli ĉe poŝtelefono. 658% ne estas tajperaro. Ĉe la 10-a procento, React-ejoj pasigas 2.7 sekundojn da ĉefa fadena tempo prilaborante sian kodon.
La 90-a procento, kompare kun ĉi tiuj grandegaj nombroj, aspektas almenaŭ iomete pli bone. Kompare kun ĉiuj retejoj, Angulaj projektoj pasigas 29% pli da tempo sur labortablaj aparatoj en la ĉefa fadeno, kaj 27% pli da tempo sur porteblaj aparatoj. En la kazo de React-ejoj, la samaj ciferoj aspektas kiel 130% kaj 98%, respektive.
Procentaj devioj por la 90-a percentilo aspektas pli bone ol similaj valoroj por la 10-a percentilo. Sed ĉi tie indas memori, ke la nombroj indikante la tempon ŝajnas sufiĉe timigaj. Ni diru 20.8 sekundoj sur la ĉefa movebla fadeno por retejo konstruita kun React. (Mi opinias, ke la rakonto pri tio, kio efektive okazas dum ĉi tiu tempo, indas je aparta artikolo).
Estas unu ebla komplikaĵo ĉi tie (dankon pro atentigi min pri tiu ĉi trajto, kaj por zorge pripensi la datumojn el tiu ĉi vidpunkto). La fakto estas, ke multaj retejoj uzas plurajn antaŭajn ilojn. Aparte, mi vidis multajn retejojn uzante jQuery kune kun React aŭ Vue, ĉar tiuj retejoj migras de jQuery al aliaj kadroj aŭ bibliotekoj. Kiel rezulto, mi denove trafis la datumbazon, ĉi-foje elektante nur tiujn ligilojn, kiuj respondas al retejoj, kiuj uzas nur React, jQuery, Angular aŭ Vue, sed ne ajnan kombinaĵon de ili. Jen kion mi ricevis.
Procesortempo (en milisekundoj) rilata al prilaborado de skriptoj sur porteblaj aparatoj en situacio kie retejoj uzas nur unu kadron aŭ nur unu bibliotekon
Procentoj
10
25
50
75
90
Retoj kiuj nur uzas jQuery
542.9
1062.2
2297.4
4769.7
8718.2
Retoj kiuj nur uzas Vue
944.0
1716.3
3194.7
5959.6
9843.8
Retejoj kiuj nur uzas Angular
1328.9
2151.9
3695.3
6629.3
11607.7
Retejoj kiuj nur uzas React
2443.2
4620.5
10061.4
17074.3
24956.3
Procesora tempo rilata al prilaborado de skriptoj sur porteblaj aparatoj en situacio kie retejoj uzas nur unu kadron, aŭ nur unu bibliotekon
Unue, io, kio ne estas surpriza: kiam retejo uzas nur unu kadron aŭ unu bibliotekon, la agado de tia retejo pliboniĝas pli ofte ol ne. Ĉiu instrumento rezultas pli bone ĉe la 10-a kaj 25-a procentoj. Ĝi havas sencon. Retejo kiu estas farita per unu kadro devus funkcii pli bone ol retejo kiu estas farita per du aŭ pli da kadroj aŭ bibliotekoj.
Fakte, la agado de ĉiu antaŭfina ilo studita aspektas pli bona en ĉiuj kazoj, krom unu kurioza escepto. Kio surprizis min estis, ke ĉe la 50-a procento kaj pli, retejoj uzantaj React funkcias pli malbone kiam React estas la sola biblioteko, kiun ili uzas. Ĉi tio, cetere, estis la kialo, ke mi prezentas ĉi tiujn datumojn ĉi tie.
Ĉi tio estas iom stranga, sed mi ankoraŭ provos serĉi klarigon por ĉi tiu strangaĵo.
Se projekto uzas kaj React kaj jQuery, tiam tiu projekto verŝajne estas ie duonvoje tra la transiro de jQuery al React. Eble ĝi havas kodbazon kie ĉi tiuj bibliotekoj estas miksitaj. Ĉar ni jam vidis, ke jQuery-ejoj pasigas malpli da tempo en la ĉefa fadeno ol React-ejoj, ĉi tio povus diri al ni, ke efektivigo de iuj funkcioj en jQuery helpas la retejon funkcii iom pli bone.
Sed ĉar la projekto transiras de jQuery al React kaj pli dependas de React, aferoj ŝanĝiĝas. Se la retejo estas vere altkvalita, kaj la retejo-programistoj uzas React zorge, tiam ĉio estos bone kun tia retejo. Sed por la meza React-ejo, ampleksa uzo de React signifas, ke la ĉefa fadeno estas sub peza ŝarĝo.
La interspaco inter porteblaj kaj labortablaj aparatoj
Alia vidpunkto de kiu mi rigardis la esploritajn datumojn estis studi kiom granda estas la interspaco inter laborado kun retejoj sur poŝtelefonaj kaj labortablaj aparatoj. Se ni parolas pri komparo de la volumoj de JavaScript-kodo, tiam tia komparo ne malkaŝas ion teruran. Kompreneble, estus bone vidi pli malgrandajn kvantojn da elŝutebla kodo, sed ne estas multe da diferenco en la kvanto de poŝtelefona kaj labortabla kodo.
Sed se ni analizas la tempon necesan por prilabori la kodon, tre granda interspaco inter porteblaj kaj labortablaj aparatoj fariĝas rimarkebla.
Pliiĝo en tempo (procento) rilata al prilaborado de skriptoj sur porteblaj aparatoj kompare kun labortablo
Procentoj
10
25
50
75
90
Ĉiuj retejoj
144.1
172.8
185.5
208.5
224.0
jQuery-ejoj
188.2
187.4
191.3
209.6
221.9
Vue retejoj
222.5
220.8
220.2
221.4
220.4
Angulejoj
205.1
206.0
201.6
210.4
218.7
Reagi Ejojn
431.5
386.8
337.9
242.6
179.6
Dum ia diferenco en koda pretiga rapideco inter telefono kaj tekkomputilo estas atendata, tiaj grandaj nombroj diras al mi, ke modernaj kadroj ne estas sufiĉe celitaj al malfortaj aparatoj, kaj ke ili strebas por fermi la breĉon, kiun ili malkovris. Eĉ ĉe la 10-a procento, React-ejoj pasigas 431.5% pli da tempo sur la movebla ĉefa fadeno ol sur la labortabla ĉefa fadeno. jQuery havas la plej malgrandan interspacon, sed eĉ ĉi tie la responda cifero estas 188.2%. Kiam retejprogramistoj faras siajn projektojn tiel, ke ilia prilaborado postulas pli da procesoro-tempo (kaj tio okazas, kaj ĝi nur plimalboniĝas kun la tempo), la posedantoj de malaltaj aparatoj devas pagi por ĝi.
Rezultoj
Bonaj kadroj devus doni al programistoj bonan bazon por konstrui retprojektojn (laŭ sekureco, alirebleco, rendimento), aŭ ili devus havi enkonstruitajn limigojn kiuj malfaciligas konstrui ion kiu malobservas tiujn limigojn.
Ĉi tio ŝajnas ne aplikiĝi al la agado de interretaj projektoj (kaj supozeble ne al ilia ).
Indas noti, ke nur ĉar React aŭ Angular-ejoj pasigas pli da CPU-tempo por prepari kodon ol aliaj, tio ne nepre signifas, ke React-ejoj estas pli CPU-intensaj ol Vue-ejoj dum funkciado. Fakte, la datumoj, kiujn ni reviziis, diras tre malmulte pri la funkcia agado de kadroj kaj bibliotekoj. Ili parolas pli pri la evoluaj aliroj, kiujn, konscie aŭ ne, ĉi tiuj kadroj povas peli programistojn. Ni parolas pri dokumentado por kadroj, pri ilia ekosistemo, pri komunaj evoluteknikoj.
Ankaŭ indas mencii ion, kion ni ne analizis ĉi tie, nome, kiom da tempo la aparato pasigas por ekzekuti JavaScript-kodon dum navigado inter paĝoj de la retejo. La argumento favore al SPA estas, ke post kiam la unupaĝa aplikaĵo estas ŝarĝita en la retumilon, la uzanto teorie povos malfermi la paĝojn de la retejo pli rapide. Mia propra sperto diras al mi, ke tio estas malproksime de fakto. Sed ni ne havas datumojn por klarigi ĉi tiun aferon.
Kio estas klara estas, ke se vi uzas kadron aŭ bibliotekon por krei retejon, vi faras kompromison pri komence ŝargi la projekton kaj pretigi ĝin por komenci. Ĉi tio validas eĉ por la plej pozitivaj scenaroj.
Estas perfekte eble fari iujn kompromisojn en taŭgaj situacioj, sed gravas, ke programistoj faras tiajn kompromisojn konscie.
Sed ni ankaŭ havas kialon por optimismo. Mi ĝojas vidi kiom proksime la programistoj de Chrome laboras kun la programistoj de kelkaj el la antaŭfinaj iloj, kiujn ni reviziis por helpi plibonigi la agadon de tiuj iloj.
Tamen mi estas pragmata homo. Novaj arkitekturoj kreas rendimentajn problemojn tiom ofte kiom ili solvas ilin. Kaj necesas tempo por ripari erarojn. Same kiel ni ne devus atendi solvos ĉiujn rendimentajn problemojn, vi ne atendu tion de novaj versioj de niaj plej ŝatataj kadroj.
Se vi volas uzi unu el la antaŭfinaj iloj diskutitaj en ĉi tiu artikolo, tio signifas, ke vi devos fari kroman penon por ne damaĝi la agadon de via projekto intertempe. Jen kelkaj konsideroj por konsideri antaŭ ol komenci novan kadron:
- Provu vin kun komuna saĝo. Ĉu vi vere bezonas uzi la elektitan kadron? Pura JavaScript hodiaŭ kapablas multon.
- Ĉu ekzistas pli malpeza alternativo al la elektita kadro (kiel Preact, Svelte aŭ io alia), kiu povas doni al vi 90% de la kapabloj de ĉi tiu kadro?
- Se vi jam uzas kadron, konsideru ĉu ekzistas io, kiu ofertas pli bonajn, pli konservativan, normajn elektojn (ekz. Nuxt.js anstataŭ Vue, Next.js anstataŭ React, ktp).
- Kio estos via JavaScript-agado?
- Kiel vi povas ĉu disvolva procezo por malfaciligi pli da JavaScript-kodo en projekton ol estas nepre necesa?
- Se vi uzas kadron por facile disvolviĝi, konsideru sendi kadrokodon al klientoj. Eble vi povas solvi ĉiujn problemojn sur la servilo?
Kutime ĉi tiuj ideoj estas rigardindaj, sendepende de tio, kion vi elektis ĝuste por antaŭa evoluado. Sed ili estas precipe gravaj kiam vi laboras pri projekto al kiu mankas agado ekde la komenco.
Karaj legantoj! Kiel vi vidas la idealan JavaScript-kadron?
fonto: www.habr.com