Ærlig webudvikler: Vi bruger for meget Javascript, og det rammer brugerne

2. december 2021 kl. 03:4526
Ærlig webudvikler: Vi bruger for meget Javascript, og det rammer brugerne
Illustration: R_Tavani/Bigstock.
Masser af Javascript gør ikke meget for brugerne, mener tysk udvikler. Han opfordrer til at bruge mere HTML, som er færdiglavet på serversiden og kun bruge scripts, når det er strengt nødvendigt.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Dagens webteknologier benytter store mængder Javascript. Men er det gået for vidt? Det mener den tyske udvikler Stefan Judis, der gav et indlæg om emnet på den nyligt afholdte Gotocph-konference i København.

Pointen er, at tunge frameworks med masser af Javascript ikke giver en bedre brugeroplevelse – tværtimod. Det giver blot sider, som er længere om at loade i browseren, og det straffes af både brugerne og Googles søgemaskine-algoritme.

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
26 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
25
10. december 2021 kl. 18:17

At PHP, asp.net over har gjort det. Det var det som man ville væk fra da FE ikke sådan rigtig kunne udvide en side let uden også at rode med fx C#, da de kun kendte til JavaScript osv (hvilket er helt fair), da man lavede Ajax requested og gjorde det let at lave asynkrone kald afkoblede man FE og BE, men tiden har vist at det faktisk godt kan betale sig at rendere det serverside.

Cirklen er komplet :)

24
5. december 2021 kl. 12:43

@Malthe: Det tror jeg ikke er tilfældet. Jeg kender ikke systemet det er lavet i. Men når man ser i browser-konsollen under indlæsningen, så sendes over 600 forespørgsler til backenden hvor nogle data i et proprietært binært format hentes ned. Interessant nok ser det ud til de samme ting hentes flere gange, og ofte er svaret (selv detaljerede svar) det samme. Så det kunne nok optimeres lidt :-). Der ser ikke ud til at være tale om de helt rå smittedata men mere den information klienten skal tegne på dashboardet (en logisk repræsentation af graferne). Hvis man drejer bare det mindste på sin mus' scroll-hjul udløser det straks en ny avalanche af HTTP-forespørgsler hvor yderligere af disse resourcer hentes ned (dog ikke så mange som i første omgang). Det er måske for at håndtere at f.eks. zoom kunne have betydning for visning af detaljer i landkortet og lignende (lidt a la Google Earth). Med andre ord virker SSI's løsning faktisk ret orienteret mod server-side, på trods af den her kritiseres for at være JavaScript tung :-)

Næsten altid afhænger den optimale løsning af behovet for skalering. En løsning der skalerer til store datamængder kan være suboptimal (omend fungerende) for små. Lad os sige den samlede mængde information vedr. smitte er lav, f.eks. kan repræsenteres ved CVS-filer på f.eks. 200K, hvilket virker sandsynligt. I så fald kan SSI-løsningen virke mege tung og overkill agtigt. Det mest effektive vil være at hente hele dynen ned på klientsiden og håndtere alt her (på trods af den megen JavaScript-modstand!). Når data er hentet kan al visning herefter foretages offline.

Men jeg gætter på SSI anvender noget software der er lave til at kunne håndtere meget større og komplekse datamængder og skal kunne vise en fungerende dahboard uanset. Måske kan der være tale om en database på mange GB og som måske skal lægges udover landkortet på en kompleks måde, og hvor man først inddrager de mere detaljerede-data (kommuner etc.) når man zoomer ind. Det kan også være, at datamængderne der skal vises er små, men at det er en tung aggregeringsproces at danne dem. I denne situation er det nok smartere at gøre klienten tyndere og lade backenden være den der sorterer og aggregerer i data via effektive strukturer og caching, og finder det frem klienten ska tegne. Selv inden for sådan en løsning kan der jo være gradueringer. F.eks. kunne serveren sende en bitmap tilbage (det ville nok være mere effektivt i SSI's tilfælde) men så kræver hver eneste interaktion på klient-siden at man skal forbi serveren. Før JavaScript blev udbredt var der en del sider der fungerede sådan, og de kunne være ret tunge at arbejde med. En mellemting kan være at serveren sender de processerede data til klienten på et vist abstraksniveau, og at klienten gør den sidste del af arbejdet med at få tegnet primitiverne. Dermed kan der understøttes et vist omfang af zoom etc. før klienten skal bruge mere data. Især elegant hvis det sker på en cache-bar måde, så det hele ikke skal hentes igen når man går tilbage. Jeg synes det virker til det er den løsning SSI's software bruger. Selvom det måske ikke er helt optimalt for små datamængder, er der jo også en stor fordel i at kunne bruge noget standardsoftware man ved skalerer.

23
5. december 2021 kl. 01:37

Hvis alle prøversvar for en given dato bliver talt sammen for hver page load, holder jeg skråsikkert på at nogen har sovet gevaldigt i timen.

Ud fra SSIs beskrivelser, så mistænker jeg stærkt at dashboardet er en JS-klient som loader CSV-filer fra SSI. De CSV-filer fylder selvsagt mere og mere. Og min fornemmelse er også, at siden, over tid, tager længere tid at hente.

Når data så er loadet, kan man skifte mellem forskellige visninger, men data skal lige hentes frem og parses.

21
2. december 2021 kl. 21:40

Hvis vi taler om et forholdsvist statisk website, eksempelvis en blog eller Version2, så er det fint nok at lave HTML på serveren. Specielt hvis man kan cache den HTML så det ikke skal beregnes forfra ved hvert hit.

Men hvis vi derimod taler om noget mere dynamisk, så kan det være langt mere effektivt at lave noget af arbejdet på klienten. Mere effektivt både for server og klient. Jo mere komplekst systemet er, jo mere kan der være at spare.

Tag den klassiske indkøbskurv som eksempel. Det kan laves så at det hele sker på serveren. Det kræver tabeller i en database på serveren, en session identifikation mellem server og klient, genberegning af hele siden hver gang brugeren ændrer noget i kurven etc. Eller det kan gøres 100% i klienten, hvilket sparer database, session, genberegning af html gentagne gange på serveren OG samtidig sparer klienten for at starte forfra med at fortolke HTML for hver handling brugeren udfører. Det er nu engang langt mere effektivt at lave en hurtig opdatering af DOM end det er at submitte en form og vente på at serveren svarer.

En indkøbskurv er ikke særlig kompliceret og fungerer fint uanset om det er lavet på server eller klient. Se det som et eksempel og tænk på mere komplekse systemer, hvor det kan gøre en stor forskel.

Og så vil jeg også sige, at store tunge frameworks er langsomme uanset om de bruges på serveren eller i klienten. Man kan sagtens lave noget der er lean og hurtigt på klienten.

20
2. december 2021 kl. 20:41

.

18
2. december 2021 kl. 15:02

Fjern JavaScript fra browseren

Det er ikke realistisk at fjerne Javascript helt, da der nu engang er helt banal funktionalitet der afhænger af Javascript, eksempelvis håndtering af events.

Og uden Javascript, ingen Ajax.

Men når det så er sagt, så har Joachim helt ret, reducer brugen af Javascript til det absolut nødvendige, og sørg så for at håndtere logikken serverside i stedet - og jeg kan hilse og sige, at man kan opnå nogle meget hurtige sider på den måde.

17
2. december 2021 kl. 14:59

Enig i pendulbevægelsen, men Jeg læser at han er imod alle sider opbygges vha. javascript og DOM, frem for HTML og CSS. Det kan jeg kun være enig i. Dels fordi jeg er træt af at alle sites opfinder deres egne scrolbare ect, dels fordi HTML er meget hurtigere, og ofte tilstrækkelig.

15
2. december 2021 kl. 14:48

Jeg må indrømme jeg synes moderne websider er irriterende pga. den overdrevne brug af javascript. Og tit kører de sløvt på selv en kraftig maskine og gigabit internet.

Jeg savner faktisk rene html sider som opfører sig ens, fordi de alle følger samme begrænsede funktionalitet. Og forudsigelighed er god usability.

Og sidst men ikke mindst, kan jeg ikke lade være med at tænke på, hvilken impact det ville have for sikkerheden, hvis vi droppede tanken om at afvikle kode fra fremmede websider helt ukritisk. Jeg ved godt javascript er sandboxed, men det må immervæk være sværere at skabe kaos, hvis man kun havde html og css til rådighed.

Frameworks, abstraktionslag og objektorienteret programmering er fantastiske skridt fremad teknologisk, men jeg synes tiden er inde til en ny retning indenfor udvikling: Simplicitet & enkelhed.

Less is more.

13
2. december 2021 kl. 14:31

Siden jeg begyndte at interessere mig for IT, har der været pendullignende bevægelser mellem tynde klienter og "rich clients". Jeg ser denne diskussion som en fortsættelse af tendensen.

Javascript-tunge frameworks flytter normalt en del databehandling og forretningslogik ned i klienten (browseren). Det giver mulighed for at lave en backend, der består af fornuftige api'er, og lade det være op til klienten, hvordan de benyttes. Man fjerner kompleksitet fra serversiden, ved fx at lade state være håndteret af klienten.

Serverside frameworks, der leverer html, css og en minimal mængde javascript er glimrende til mange formål, ikke mindst til at lave sider, der er nemt tilgængelige for handikappede og søgemaskine-robotter. Det ville ikke overraske mig, hvis vi er på vej til at se pendulet svinge i den retning igen.

Som med al anden it, handler det primært om at vælge det rette værktøj til at løse opgaven. Det er naivt at tro, at en enkelt type frameworks kan løse alle opgaver optimalt.

12
2. december 2021 kl. 12:48

Når man tænker på mængden af informationer, som er tilgængelig på samme tid, så synes jeg ikke at 20 sekunder er alverden.

Der er en rodebunke af data tilgængelig, men så er det heller ikke mere imponerende.

Tværtom ville det være smartere at der kun blev vist de summerede data (som det nok er det hovedparten er interesseret i), og man så, hvis man havde interesse derfor, kunne dykke ned i detaljen.

Det er fuldstændigt forkert lavet at man skal hive hele datasættet ned, og efterfølgende behandle det totale datasæt, imo er der nogen løser den forkerte opgave med det forkerte værktøj:

https://xkcd.com/463/

10
2. december 2021 kl. 12:17

De frameworks, som er udviklet til at håndtere state og view af komplekse objekter og interaktion i en browser, er aldrig designet til at lave et simpelt website med iøvrigt statisk indhold.

Men man kan jo godt. Og for mange har det sikkert været mere spændende at øve sig med bleeding edge tech, selvom opgaven ikke kaldte på frameworket.

Det er først når sagen er i produktion og den daglige drift og udvikling melder sig, at man fornemmer om stakvalget er korrekt eller rock'n'roll.

8
2. december 2021 kl. 11:46

Når man tænker på mængden af informationer, som er tilgængelig på samme tid, så synes jeg ikke at 20 sekunder er alverden.

6
2. december 2021 kl. 10:54

Tunge sider spilder brugerens tid og strøm.

Jeg husker i 1994 gav følgende fly query på EaasySabre

CPH JFK 12dec SK

Svar på nogle få hundrede millisekunder via en 1200 baud modem.

I moderne tider er det sjovt at se verdens største sælger af krydstogter har en simpel ASCII grænseflade og giver lynhurtige svartider og rigtig gode søgningsværktøjer.

De fleste konkurrenter har flotte sider der loader langsomt og kræver “next page” i al uendelighed.

https://www.vacationstogo.com/

Der burde være en certificerings ordning på load tid og strømforbrug.

4
2. december 2021 kl. 09:50

Selvom jeg synes Blazor er fascinerende, så er jeg ikke så sikker på at den vil score højt på førnævnte ranking tjenester.

For mig at se er Blazor blot arvtageren til Java applets, som var notorisk langsomme at loade i browseren og som kunne kun interagere i begrænset omfang med resten af indholdet på siden.

Bevares: Microsoft har banket hastigheden op, fordi Blazor bruger webassambly, men er det ikke lidt katoffel-katoffel om en browser skal køre bytecode (java) vs webassembly?

3
2. december 2021 kl. 09:34

"Den benytter teknologi, såsom layout med HTML-tabeller, som professionelle udviklere ikke rigtigt bruger længere"

Øhh nej, for hvis man benytter tabeller til at lave layout, så får man noget af en opgave efterfølgende hvis siden bare skal være tilnærmelsesvis tilgængelig.

2
2. december 2021 kl. 08:25

Det er ikke så svært at få det lært! ;-)

1
2. december 2021 kl. 07:27

Hvor har men hørt om det før? Hmmm :)