Ik begin me de laatste tijd steeds meer af te vragen waar de scheiding tussen website en web-applicatie zit. Ook begin ik me af te vragen welke toekomst web-applicaties tegemoet gaan; er zijn enkele grote tekortkomingen aan de browsers van dit moment, als het om web-applicaties gaat.
Ik ben nu 23 en heb 'de opkomst' van het web meegemaakt in volle glorie. Van een 33k6 modempje en de eerste computerlessen op school (jaja, Microsoft Works op windows 3.11!) tot breedband en het web-applicatie bedrijf waar ik nu een bijbaan naast mijn studie Elektrotechniek heb. Voor zover ik gezien heb, heeft er een verschuiving plaatsgevonden in de manier waarop applicaties worden gevraagd en worden ontworpen. Waar dit pre-2000 vooral stand-alone applicaties waren, worden er op dit moment steeds meer projecten web-based uitgevoerd.
Uiteraard heeft dat z'n voordelen, zoals het flexibel kunnen updaten van de applicatie voor alle gebruikers of het beschikbaar zijn op een willekeurige, op internet aangesloten, computer. Ook is de ontwikkeltijd van een web-applicatie vaak korter dan van een stand-alone applicatie.
Het probleem waar ik nu mee in mijn hoofd zit is dat er bijvoorbeeld vaak slechte ontwerpkeuzes worden gemaakt, waardoor de performance van sommige websites/applicaties gewoon zeer triest te noemen is. Door de diversiteit aan browsers moet er in een (vaak niet aanwezige) testfase de volledige applicatie meerdere malen getest worden. Helemaal platform onafhankelijk zal het namelijk allemaal nooit (kunnen) worden. Wellicht komt er met javascript workers een oplossing voor websites die intensief (en dus meestal blokkerend) javascript gedrag uitvoeren. Dit is volgens mij hetzelfde probleem als waar Java applicaties last van hadden, toen de uitvoerende code nog vaak in dezelfde thread werd geplempt als waar de GUI in draaide.
Voor fora, bedrijfsprofielen, encyclopedieën, webshops, nieuwssites etc is het prima om een webbased-interface te hebben. Dit gaat dus voornamelijk om relatief statische informatie waarvan niet verwacht wordt om deze real-time bij te werken.
Wat ik steeds vaker zie, zijn echter steeds meer vragen over 'echte' applicaties in de webbrowser. Denk hierbij aan een e-mail applicatie of een chat-programma in de browser. Is allemaal hartstikke leuk om zonder het installeren van programma's in een chat terecht te kunnen komen, maar als je bedenkt hoe dit technisch opgebouwd is, dan breekt toch vaak mijn elektrotechnisch hartje.
Neem bijvoorbeeld Google Wave, mooi concept, het 'real-time' collaboreren in verschillende documenten/threads. Ik vind de technische uitwerking (aan de kant van de browser) verschrikkelijk. Wanneer je begint te typen haal je al 5 verbindingen per seconde. Nu zijn deze verbindingen niet erg intensief en is dat ook de enige reden dat het een beetje kan werken. Echter, stel dat je in een bedrijf met 10 man in google wave bezig bent, dan is het al snel 50 connecties per seconde. Een standaard-adsl verbinding heeft (volgens www.speedtest.nl) ongeveer een 800-1000 connecties per minuut als limiet. Dit is dus zo'n 14 connections per seconde en zou je dus met een standaard-adsl lijn al niet meer uit de voeten kunnen.
En hier komt nu het echte probleem waarmee ik in mijn hoofd zit: waarom wordt er zoveel in de webbrowser ontwikkeld, maar wordt er niet op grote schaal nagedacht waarom dit eigenlijk geen goed idee is. Als je een normale socket naar een server opent, dan kan dit prima in één verbinding, met weinig overhead. Google Wave gebruikt altijd de headers van de browser en headers van de server met een connectie, per request. Met een échte verbinding is dit vele malen kleiner, wordt de gebruikte bandbreedte kleiner en is het ook mogelijk om écht push-berichten vanaf de server te doen, terwijl dit (in een webbrowser) altijd gepolld is.
Onder andere dus een oproepje aan webbrowser-bouwers: maak het mogelijk om synchrone verbindingen open te zetten! Maar zorg er dan ook voor dat er een standaard komt, HTTP voldoet dan niet meer! Wat zijn jullie meningen over deze onderwerpen, namelijk de performance en het veinzen van functionaliteit die eigenlijk een work-around zijn op het web.
Ik ben nu 23 en heb 'de opkomst' van het web meegemaakt in volle glorie. Van een 33k6 modempje en de eerste computerlessen op school (jaja, Microsoft Works op windows 3.11!) tot breedband en het web-applicatie bedrijf waar ik nu een bijbaan naast mijn studie Elektrotechniek heb. Voor zover ik gezien heb, heeft er een verschuiving plaatsgevonden in de manier waarop applicaties worden gevraagd en worden ontworpen. Waar dit pre-2000 vooral stand-alone applicaties waren, worden er op dit moment steeds meer projecten web-based uitgevoerd.
Uiteraard heeft dat z'n voordelen, zoals het flexibel kunnen updaten van de applicatie voor alle gebruikers of het beschikbaar zijn op een willekeurige, op internet aangesloten, computer. Ook is de ontwikkeltijd van een web-applicatie vaak korter dan van een stand-alone applicatie.
Het probleem waar ik nu mee in mijn hoofd zit is dat er bijvoorbeeld vaak slechte ontwerpkeuzes worden gemaakt, waardoor de performance van sommige websites/applicaties gewoon zeer triest te noemen is. Door de diversiteit aan browsers moet er in een (vaak niet aanwezige) testfase de volledige applicatie meerdere malen getest worden. Helemaal platform onafhankelijk zal het namelijk allemaal nooit (kunnen) worden. Wellicht komt er met javascript workers een oplossing voor websites die intensief (en dus meestal blokkerend) javascript gedrag uitvoeren. Dit is volgens mij hetzelfde probleem als waar Java applicaties last van hadden, toen de uitvoerende code nog vaak in dezelfde thread werd geplempt als waar de GUI in draaide.
Voor fora, bedrijfsprofielen, encyclopedieën, webshops, nieuwssites etc is het prima om een webbased-interface te hebben. Dit gaat dus voornamelijk om relatief statische informatie waarvan niet verwacht wordt om deze real-time bij te werken.
Wat ik steeds vaker zie, zijn echter steeds meer vragen over 'echte' applicaties in de webbrowser. Denk hierbij aan een e-mail applicatie of een chat-programma in de browser. Is allemaal hartstikke leuk om zonder het installeren van programma's in een chat terecht te kunnen komen, maar als je bedenkt hoe dit technisch opgebouwd is, dan breekt toch vaak mijn elektrotechnisch hartje.
Neem bijvoorbeeld Google Wave, mooi concept, het 'real-time' collaboreren in verschillende documenten/threads. Ik vind de technische uitwerking (aan de kant van de browser) verschrikkelijk. Wanneer je begint te typen haal je al 5 verbindingen per seconde. Nu zijn deze verbindingen niet erg intensief en is dat ook de enige reden dat het een beetje kan werken. Echter, stel dat je in een bedrijf met 10 man in google wave bezig bent, dan is het al snel 50 connecties per seconde. Een standaard-adsl verbinding heeft (volgens www.speedtest.nl) ongeveer een 800-1000 connecties per minuut als limiet. Dit is dus zo'n 14 connections per seconde en zou je dus met een standaard-adsl lijn al niet meer uit de voeten kunnen.
En hier komt nu het echte probleem waarmee ik in mijn hoofd zit: waarom wordt er zoveel in de webbrowser ontwikkeld, maar wordt er niet op grote schaal nagedacht waarom dit eigenlijk geen goed idee is. Als je een normale socket naar een server opent, dan kan dit prima in één verbinding, met weinig overhead. Google Wave gebruikt altijd de headers van de browser en headers van de server met een connectie, per request. Met een échte verbinding is dit vele malen kleiner, wordt de gebruikte bandbreedte kleiner en is het ook mogelijk om écht push-berichten vanaf de server te doen, terwijl dit (in een webbrowser) altijd gepolld is.
Onder andere dus een oproepje aan webbrowser-bouwers: maak het mogelijk om synchrone verbindingen open te zetten! Maar zorg er dan ook voor dat er een standaard komt, HTTP voldoet dan niet meer! Wat zijn jullie meningen over deze onderwerpen, namelijk de performance en het veinzen van functionaliteit die eigenlijk een work-around zijn op het web.
:strip_icc():strip_exif()/u/49396/icoon.jpg?f=community)
:strip_icc():strip_exif()/u/116726/crop5e3ee297a8a03_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/133746/avatar.jpg?f=community){kind=avatar}