Pas op met Javascript

Ik loop inmiddels bijna 30 jaar mee in de IT wereld. Er is veel veranderd in die tijd, maar een hoop is uiterlijke schijn. Letterlijk. Software bouwen op goede fundamenten was en is nog steeds erg belangrijk.

De eerste computersystemen waarmee ik te maken kreeg, bestonden uit een centrale verwerkingseenheid ook wel Central Processing Unit of CPU genoemd. Daaraan gekoppeld waren een console en meerdere terminals bestaande uit een beeldscherm plus toetsenbord. Om die hardware te laten functioneren waren er diverse besturingssystemen waarvan mijn favoriet Unix was. De centrale kast met de CPU zelf diende bij voorkeur in een afgeschermde ruimte geplaatst te worden, maar kon ook in een veilige hoek van een kantoor worden opgesteld. Toen heel normaal.

Unix was een multi-user en multi-tasking operating system dat conceptueel en technisch zeer fraai in elkaar zat. Meerdere gebruikers konden meerdere applicaties tegelijk uitvoeren. Van Unix bestonden diverse varianten en het huidige Linux¹⁾ is hierop gebaseerd. En ook MacOS, iOS en Android trouwens.

De applicatiesoftware op die Unix systemen draaide op de CPU en kon worden bediend vanaf de console en de diverse “dumb” terminals. Het enige wat die laatste deden, was het tonen van de output op het scherm, en het verwerken en doorsturen van de toetsaanslagen naar de CPU. In de meest simpele variant was er 1 CPU met meerdere terminals en bevonden alle softwarecode en data zich op een schijf in de CPU-kast. De toenmalige computersystemen waren servers met meerdere via kabels aangesloten clients.

Flash forward to today. Tegenwoordig heeft vrijwel iedereen niet alleen een personal computer, vaak in de vorm van een laptop of notebook, maar tevens een tablet en zeker een smartphone. Windows, Linux, MacOS, iOS en Android zijn allemaal besturingssystemen die op één of meer van dit soort apparaten of devices draaien. Een flink aantal mensen bezit er zelfs zo veel dat de voorheen veel gebezigde coole term BYOD - Bring Your Own Device - uiteindelijk alleen maar leidde tot de vraag: Which one?.

De devices van tegenwoordig kunnen eigenlijk niet meer goed functioneren zonder een internetverbinding. Stand-alone applicaties zijn er steeds minder. Moderne applicaties bestaan uit een server component ergens in de cloud en een client component die op het device draait. De huidige client-server-applicaties zijn dus enorm veel complexer dan die van voor de eeuwwisseling.

De client kant van de software wordt getoond via een browser waarbij applicaties meestal goed werken onder zowel Chrome, Firefox, Safari als Edge. Allemaal moderne HTML5 browsers. Deze browsers kunnen met behulp van CSS opmaakbestanden en Javascript programmaatjes de geboden content op een toegankelijke en dynamische manier weergeven. Mits goed vormgegeven werken die vaak prettig en intuïtief. Het verschil tussen “gewone” informatieve websites en webapplicaties is goeddeels vervaagd. En ja, ook smartphone apps zijn vaak niets meer dan wrappers voor het weergeven en verwerken van webcontent die ook via een browser te benaderen is.

Zelfs louter informatieve websites zijn op zichzelf al mini-applicaties: content, layout en bepaalde functionaliteit bevinden zich na het volledig laden van de pagina in het geheugen van het device. De browser of de smartphone-app hoeft hierdoor niet voortdurend in contact te staan met de server. Handig in veel gevallen, want het netwerkverkeer en de serverbelasting nemen af ²⁾.

Bij het ontwerpen van moderne software is het essentieel om te bepalen welke functies op de server en welke functies op de client dienen te worden uitgevoerd. Ten tijde van de “dumb” terminals was dit eenvoudig; op de CPU natuurlijk. Tegenwoordig bestaat er de mogelijkheid om veel functies aan de client-kant te laten plaatsvinden.

Om dit te verduidelijken staat hieronder een voorbeeld van een tabel die interactief werkt door middel van Javascript. Alle programmacode hiervoor en de data die worden getoond, zijn tijdens het ophalen van deze pagina al ingeladen in het geheugen van het door jou gebruikte device. Contact met een server vindt niet plaats tijdens het interactieve gebruik van de tabel. Druk vooral eens op de knopjes en hersorteer bijvoorbeeld de tabel.

Javascript vormt met HTML en CSS tegenwoordig een drie-eenheid.

Javascript is one of the three quintessential development languages as defined by the World Wide Web Consortium (W3C). Along with HTML and CSS, JavaScript is used for manipulation of elements on a web application, and this has shaped the modern internet as it is known today. https://www.privacypolicies.com/blog/enable-disable-javascript/

Hoewel Javascript erg handig is voor bijvoorbeeld simpele functies en vloeiend bewegende componenten binnen een webpagina, zijn er applicatiefuncties waarvoor Javascript beter niet gebruikt kan worden. Die functies dienen plaats te vinden aan de serverkant.

Op een pagina van de World Wide Web Consortium (W3C) ³⁾ vond ik de volgende afwegingen voor een weloverwogen gebruik van Javascript.

Principles [for conscious use of Javascript]

1. Your site should work [good enough] without JavaScript.
2. [Since JavaScript is normally enabled by default], you can present your users with an extra layer of usability; a layer that allows them to perform their tasks more quickly, and that avoids jarring page reloads where possible.
3. JavaScript is unsafe. That is, you should never trust in JavaScript-only routines for crucial tasks such as checking user input in a form. After all, a [prudent] user can just turn JavaScript off and thus bypass your defenses.

https://www.w3.org/wiki/The_principles_of_unobtrusive_JavaScript#Principles

Ik zet de volgende kanttekeningen hierbij

• Aangezien de pagina waaruit dit citaat komt op 9 oktober 2014 voor het laatst is ge-update, heb ik de principes “hertaald” naar nu.
• Toen Javascript werd ontwikkeld, was het een programmeertaal voor de browser. Sinds enige jaren is het echter ook mogelijk om serverapplicaties te programmeren in Javascript. Dit soort applicaties wordt in deze quote en in mijn betoog nadrukkelijk niet bedoeld.
• Het laatste punt is wat mij betreft het belangrijkste: Javascript is onveilig. Je moet nooit vertrouwen op JavaScript-only routines voor cruciale taken.
• Met prudent users bedoel ik gebruikers die erg gesteld zijn op hun privacy en ervoor kiezen om Javascript uit te schakelen aangezien bepaalde routines ongemerkt gebruikersgegevens doorsturen.

De mogelijkheden bij het gebruik van Javascript zijn bijzonder groot. Er bestaan veel libraries, tools en frameworks die gebaseerd zijn op deze scripttaal. Maar er zijn ook applicatiefuncties waarvoor het gebruik van Javascript ongeschikt of zelfs ongewenst is.

Een drietal voorbeelden van situaties waarbij Javascript niet gebruikt dient te worden

• Websites die in een browser met Javascript uitgeschakeld deels werken maar hierdoor verkeerde informatie tonen.
• Invulformulieren met Javascript-only controle op verplichte of gelimiteerde inputvelden die zonder hercontrole aan de server-side linea-recta in de database worden geplaatst.
• Betaalmuur-popups voor niet abonnees die als blokkade worden getoond met daarachter een reeds volledig in het geheugen geladen premium artikel.

In een volgend artikel zal ik nader ingaan op het laatste voorbeeld, aangezien ik erachter ben gekomen dat veel sites gebruik maken van popup Javascript-only paywalls. Dit zijn fundamentele fouten die een mediabedrijf onbedoeld veel geld kunnen kosten.