joeni

Ingewijden zijn bekend met het feit dat JavaScript een Turing-complete

programmeertaal is; je kunt er dus daadwerkelijk programma's mee schrijven.

Een prominent voorbeeld hiervan is Google met haar Google Docs, Sheets,

Presentations, GMail, ...

Het valt dan natuurlijk op dat binnen Joeni *geen enkele lijn JavaScript

geschreven is*. En dat is ook expres gedaan.

Dat klinkt misschien nogal contra-intuïtief; een volledig programma, dat

hoofdzakelijk gebruikt zal worden via de browser, dat client-side scripting

expres aan zijn neus voorbij laat gaan.

Hier zijn meerdere redenen voor. Eén van de voornaamste redenen (en eentje die

Google, Facebook, ... allemaal klaarblijkelijk vergeten zijn) is dat een

grondregel van /web development/ is dat je er niet van mag uitgaan dat de

gebruiker JavaScript ondersteunt.

*Client-side scripting (Css* (niet te verwarren met Cascading Style Sheets, CSS))

*mag enkel een strikt cosmetisch effect hebben op

een website.* De functionaliteit gaat namelijk compleet verloren als de

gebruiker geen ondersteuning biedt.

Alhoewel het in de praktijk steeds neerkomt op "JavaScript (JS) dient vermeden te

worden op het web", ga ik enkel spreken over "Client side scripting" (Css),

omdat veel van de problemen die zich met JS zouden voordoen, zich eveneens

zouden voordoen bij eender welke andere taal (Python, Clojure, ...),

als die voor Css gebruikt zou worden. JS is sinds [[http://es6-features.org/][ES6]] een betere taal geworden,

maar de "kwaliteit" van een taal is volledig irrelevant in deze discussie. Het

bespreken van de faciliteiten die JS als programmeertaal biedt wordt in dit

hoofdstuk dus achterwege gelaten.

** Verschillende versies

Alles wat netwerkgerelateerd is, moet zich houden aan vooraf opgelegde

standaarden om correct te kunnen communiceren, en met het WWW is dat niet

anders.

Dit geeft opnieuw een reden om geen Css te gebruiken; op dit moment moet ik

- De standaard van HTML(5) en welke tags ondersteund worden

- De standaard van CSS(3) en de ondersteunde /properties/ binnen browsers

Dit op zich is al een hele klus, en vereist *continu onderhoud van de software*.

Stel dat men geen website ontwerpt, en /native software/ ontwikkelt, dan hoeft

men enkel rekening te houden met de syntax van de programmeertaal; als het

compileert kan het bij wijze van spreken gebruikt worden.

Met Css moet men rekening houden met welke onderdelen van de gebruikte

programmeertaal door de browsers wordt ondersteund, en dat is van vitaal belang,

want als het script niet ondersteund wordt, wordt het simpelweg niet uitgevoerd,

met als gevolg dat de website aan functionaliteit moet inboeten.

Als dit bij HTML of CSS gebeurt (bv. gebruik van [[https://developer.mozilla.org/en-US/docs/Web/HTML/Element/marquee][<marquee>]]), dan kan de browser

nog terugvallen op een standaardwaarde. Dit is ook mogelijk, omdat geen van

beide een programmeertaal is; men kán onderdelen vervangen zonder een al te

groot risico te lopen om de site kapot te maken.

** Turing-compleetheid

De kracht van Css schuilt in de [[https://nl.wikipedia.org/wiki/Turingvolledigheid][Turing-compleetheid]]. Dit maakt het tot een

De grote máár in deze kracht, is dat dat ook een hoop verantwoordelijkheid met

zich meebrengt. Er kunnen fouten in de code sluipen, die de hele website kunnen

doen vastlopen.

JavaScript heeft dan ook nog de ongelukkige eigenschap dat het een enorm

[[https://en.wikipedia.org/wiki/Strong_and_weak_typing][zwak getypeerde programmeertaal]] is; de taal doet in de achtergrond stille

conversies tussen verschillende types, en geeft liever foute resultaten terug

dan de programmeur te vertellen dat er een fout in de code zit.

Deze punten gelden natuurlijk ook voor de /server-side/, maar dit is (in

tegenstelling tot Css) absoluut onvermijdelijk om een dergelijke website te

creëren.

Daarnaast zijn er ook een hoop voordelen die men niet heeft bij Css:

- Vrije keuze van programmeertaal (en mogelijkheid om te linken met andere

  software)

- Zekerheid dat, als de software werkt op de ene /client/, die ook voor de

  andere /client/ werkt (zie [[Verschillende versies]])

HTML en CSS zijn geen "volwaardige programmeertalen". HTML is een opmaaktaal,

men beschrijft er dus mee hoe bepaalde onderdelen van de website moeten worden

voorgesteld; als een hyperlink, een paragraaf, ...

CSS laat toe om de stijl van deze opmaak te definiëren, hoe moet een hyperlink

uitzien, ...

Een fout hierin heeft hoogstens een estetisch vervelend effect tot gevolg; veel

mogelijk met een programmeertaal, een fout is een fout, en computers zijn niet

** Onbeschikbaarheid

Er zijn talloze manieren waarop de aangereikte code niet beschikbaar kan zijn

voor de gebruiker, waardoor een website die afhangt van Css plots zonder

waarschuwing niet meer werkzaam is. Een wilde greep uit de mogelijkheden:

- De gebruiker heeft een zwakke computer

- De computer heeft een slechte verbinding

- De gebruiker surft via de GSM (een zwakke computer met een slechte verbinding)

- De gebruiker heeft [[https://noscript.net][NoScript]], [[https://www.gnu.org/software/librejs/][GNU LibreJS]], of een andere extensie die Css blokkeert

- De verbinding wordt onderbroken tijdens het inladen, en de pagina blokkeert

  terwijl het tevergeefs wacht op de rest van het script

- De browser van de gebruiker ondersteunt simpelweg geen Css

- De browser van de gebruiker ondersteunt niet de Css-implementatie die op de

  website gebruikt wordt (zie [[Verschillende versies]])

- De website laadt Css in van een externe website, maar er is een fout in het

  certificaat, en de browser weigert om de verbinding op te zetten

Er hoeft maar één (en slechts één) van deze mogelijkheden op te treden, en *de

volledige website is onbruikbaar*.

Voor elk van deze mogelijkheden zou met Css een controle moeten worden

ingebouwd, en dan weer voor elke mogelijkheid een oplossing bedacht (want "Het

werkt niet en dat is de schuld van de gebruiker" is geen oplossing).

Daarentegen, wat als er server-side een fout optreedt? \\

Veel webframeworks hebben ingebouwde /debugging tools/ die bij fouten direct de

programmeur wijzen op de fout. Django is hier een goed voorbeeld van.

Daarnaast biedt de betere webserver ook ingebouwde oplossingen om vaak

voorkomende fouten af te handelen (zoals een HTTP 404). In dat geval kan er

gemakkelijk een e-mail naar de ontwikkelaar gestuurd worden, of kan een log

aangemaakt worden. En dit is vaak allemaal /ingebouwd/.

** Uitgesteld resultaat

Bestanden over het WWW worden quasi altijd verzonden via [[https://nl.wikipedia.org/wiki/Hypertext_Transfer_Protocol][HTTP]]([[https://nl.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure][S]]), en de browser

is daarna verantwoordelijk voor het in elkaar steken van alle ontvangen

onderdelen.

Het handige hieraan, is dat elke browser zelf kan bepalen hoe, en in welke volgorde dit

moet gebeuren, al dan niet in functie van bepaalde instellingen die de gebruiker

zelf kan aanpassen (bv. geen afbeeldingen laden via 4G).

Css interfereert op haast elk mogelijk niveau met deze werkwijze. Net omdat het

niet op voorhand geweten is wat er zal worden aangepast, of wanneer de code

ingeladen moet worden, is een browser verplicht om vanaf het eerste moment dat

een script gedetecteerd wordt (bv. via de ~<script></script>~-tags), direct de

code te evalueren en uit te voeren, ongeacht hoe lang het duurt of hoe zwaar het is.

Css breekt ook met het gebruikelijke mantra dat de browser/gebruiker bepaalt hoe

en wat wordt ingeladen.

Vaak betekent dit ook dat de code geëvalueerd moet worden, op dat exacte moment,

vooraleer de rest van de pagina getoond kan worden. \\

Dit is minder een probleem als Css gebruikt wordt voor het enige waarvoor het

zou gebruikt moeten worden (cosmetische elementen), omdat alle code dan expres

bruikbaar vooraleer de code ingeladen moet worden. \\

(Een groeiend aantal gebruikers blokkeert ook expres Css tijdens het surfen op

afweging is voor een ietwat minder cosmetisch aangeklede website. Met andere

woorden; zij stellen het resultaat uit voor onbepaalde duur.)

Dit geeft vanzelfsprekend ook problemen als de code niet geoptimaliseerd is, en

daar elke browser de aangereikte Css op een andere manier kan evalueren, is het

onbegonnen werk om voor alle mogelijke implementaties handige optimalisaties

door te voeren. Men beperkt zich natuurlijk meestal tot de populairste

implementaties ([[https://en.wikipedia.org/wiki/WebKit][WebKit]] en [[https://en.wikipedia.org/wiki/Gecko_(software)][Gecko]]).

_Maar je hoeft vanzelfsprekend niet te optimaliseren, als er geen code is om te optimaliseren._

Je zou kunnen zeggen dat deze redenering ook opgaat voor Joeni zelf, wat van

Python gebruik maakt. Maar het gebruikte framework ondersteunt het

[[https://docs.djangoproject.com/en/2.0/topics/cache/][cachen van pagina's]]. Dus eerder geëvalueerde code zal al op voorhand beschikbaar

zijn. Daarbij komt dat de snelheid van een server naar wens kan worden vergroot,

terwijl je bij de gebruiker er van moet uitgaan dat zijn/haar toestel traag is.

De code van de server hoeft ook slechts voor één platform geoptimaliseerd te

worden, dat van de server.

Uiteindelijk is het resultaat van (foutief) Css-gebruik 

sowieso: *Een traag werkende website.*

** Verlies van betekenis

Een bepaalde /tag/ in HTML draagt een bepaalde betekenis. ~<a />~ betekent dat dit

een hyperlink is, ~<body />~ betekent dat wat volgt getoond moet worden als de

'inhoud' van de pagina, ~<p />~ duidt op een paragraaf, ...

Deze betekenis wordt vaak door de browser ten volle benut; Alle links kunnen makkelijk

op voorhand verzameld worden (i.e. Alles wat tussen ~<a />~ staat), wat tussen

~<head />~ staat wordt niet getoond, ...

*Betekenis opent deuren voor het impliciet infereren van informatie.* Dit is de

reden waarom de tags in HTML (en vooral sinds HTML5) een aanduiding zijn voor

wat de ingesloten data /betekent/; ~<article />~ is een artikel en kan dus los

weergegeven worden van de rest van de pagina, ~<del />~ is data die niet

is een geordende lijst, dus de volgorde van de data is van belang, in

tegenstelling tot ~<ul />~. Er zijn ontelbare voorbeelden te vinden.

Deze betekenis gaat volledig verloren als onderdelen van de website met Css

worden "nagemaakt". ~<div onclick="hyperlink" />~ zal waarschijnlijk wel

doorlinken naar een website, maar waar dat je in bv. FireFox met een

middelmuisklik een ~<a />~ in een nieuw tabblad kunt openen, zal dit niet werken

met Css.

** Conclusie

Het moge duidelijk zijn dat het gebruik van Css om zogenaamde /web apps/ te

maken, fundamenteel een slecht idee is, dat meer problemen voortbrengt dan het

oplost. Alle problemen die sommige websites proberen op te lossen met Css, zijn

makkelijker op te lossen met slechts HTML en CSS (Cascading Style Sheets), en

Client side scripting maakt soms de problemen zelfs erger.

En zelfs al zouden alle bovenstaande punten onwaar zijn, dan nog is Joeni

het bewijs dat Css geen vereiste is om werkende software te schrijven, die

hoofdzakelijk via het WWW beschikbaar wordt gesteld.