News

Soundbyte 53: One More Cup of Coffee

22 juli 2012

Sorry, this entry is only available in Nederlands.

Binnenkort gaat er bij de klant waar ik momenteel zit een project van start, waarbij onder andere een nieuwe webapplicatie ontwikkeld moet worden. Ik zit er hard over te denken of we hier wellicht een JavaScript applicatie van moeten maken…

In de Soundbyte van vorige week had Dick het even over discussies over client-side vs. server-side MVC-frameworks. Derk heeft het een paar maanden terug al eens over een aantal JavaScript frameworks gehad, waarmee meer structuur en architectuur in een JavaScript frontend aan te brengen is. Het leeft dus binnen Luminis.
Veel mensen vinden het een verschrikkelijke taal, en ik ken programmeurs die maar blijven roepen dat ze er zo ver mogelijk uit de buurt willen blijven. Maar als je het mij vraagt: JavaScript is HOT!

Er zijn tal van voorbeelden waarom JavaScript een lastige taal is. Neem nou dit voorbeeld. Ook het volgende zegt een hoop:

Op Twitter las ik het volgende:

Ik ken de context niet, maar ik ken wel het gevoel 😉

JavaScript was altijd iets wat je er als Java, C#, Ruby ontwikkelaar bijdoet. Even een beetje JavaScript toevoegen. Een kloddertje roze hier…
Dit is hoe het sinds eind jaren negentig veelvuldig toegepast is. Het lijkt wel alsof alles wat we doen om goede code te schrijven, overboord gegooid wordt wanneer we “even een beetje JavaScript toevoegen”.

Maar dit is aan het veranderen. Door de opmars van tablets en smartphones worden we steeds vaker geacht frontend applicaties te ontwikkelen voor meerdere platformen. In het begin werd vaak voor ieder platform een aparte applicatie ontwikkeld. Nu zie je steeds vaker dat gekozen wordt voor een HTML/CSS/JavaScript oplossing. Helemaal nu het bijvoorbeeld met Phonegap (Apache Cordova) mogelijk wordt de native API’s aan te spreken.

Inmiddels zijn de VM’s in browsers ook snel genoeg om client-side applicaties te renderen en de user interaction af te handelen. Hierdoor lijkt er ook qua algehele applicatie-architectuur een verschuiving plaats te vinden.
De afgelopen jaren zijn we druk in de weer geweest met bijvoorbeeld (G)Rails of ASP.NET MVC server-side HTML-output te genereren. De client doet een request, de server stuurt een HTML pagina terug. Dit herhaalt zich steeds. Toen gingen we binnen de context van een pagina met behulp van AJAX content (XML/JSON) ophalen en bijwerken.
Maar nu gaat het volgens mij echt de kant op dat we applicaties volledig in JavaScript gaan schrijven. Alle user interaction wordt client-side afgehandeld en views worden client-side gegenereerd. Er wordt met HTTP-services gecommuniceerd voor de data.
Deze verschuiving heeft de nodige voordelen. Zo verplaatsen we een hoop rekenkracht naar de client. Ook is de frontend nu echt gescheiden van applicatie services. Vaak zie je in een (G)Rails of ASP.NET MVC oplossing dat dit toch vermengd raakt.

Bij een hoop ontwikkelaars zal hier vast grote weerstand tegen ontstaan. Het is ook nogal een flinke verandering. Een C# webontwikkelaar die nu met behulp ASP.NET MVC zijn HTML pagina’s genereert, netjes zijn unit tests schrijft, en zijn buildprocess onder controle heeft moet nogal wat nieuwe dingen leren. ‘JavaScript is een slechte taal’ zal vaak als excuus gebruikt gaan worden om dit niet te hoeven doen.
Maar er zijn inmiddels al vele frameworks waarmee we fatsoenlijk JavaScript applicaties kunnen ontwikkelen. Deze frameworks nemen vaak 1 van de volgende zaken voor hun rekening: DOM-manipulatie, Architectuur of User Interface. Er zijn echter ook frameworks waarin alles ondersteund wordt, bijvoorbeeld JQuery Mobile of de Dojo Toolkit.

Mijn ervaringen

Ik ken natuurlijk niet alle frameworks goed, maar ik ben erg enthousiast over Backbone, en dan vooral icm RequireJS. Als UI toolkit vind ik Twitter Bootstrap erg prettig werken. Voor unit tests gebruik ik momenteel QUnit naar volle tevredenheid.
Een goede IDE heb ik nog niet echt gevonden. Cloud9 werkt op zich goed, maar om dat nu bij klanten te gaan gebruiken is voor mij nog een stap te ver. In Visual Studio 2012 schijnt de ondersteuning voor JavaScript sterk verbeterd te zijn; ik ben benieuwd.

Mijn advies voor alle applicatie-ontwikkelaars is in ieder geval: zorg dat je een meester in JavaScript wordt. Ik denk dat er veel vraag naar zal zijn in de toekomst.
Wellicht dat er een gangbare abstractie bovenop komt (iets als Coffeescript bijvoorbeeld), maar het is nooit slecht om te weten hoe het onder de motorkap werkt.

One More Cup of Coffee

Helaas kon ik de Bob Dylan versie niet vinden op YouTube, maar gelukkig laten The White Stripes het niet afweten.

Tim!Binnenkort gaat er bij de klant waar ik momenteel zit een project van start, waarbij onder andere een nieuwe webapplicatie ontwikkeld moet worden. Ik zit er hard over te denken of we hier wellicht een JavaScript applicatie van moeten maken…

In de Soundbyte van vorige week had Dick het  even over discussies over client-side vs. server-side MVC-frameworks. Derk heeft het een paar maanden terug al eens over een aantal JavaScript frameworks gehad, waarmee meer structuur en architectuur in een JavaScript frontend aan te brengen is. Het leeft dus binnen Luminis.
Veel mensen vinden het een verschrikkelijke taal, en ik ken programmeurs die maar blijven roepen dat ze er zo ver mogelijk uit de buurt willen blijven. Maar als je het mij vraagt: JavaScript is HOT!

Er zijn tal van voorbeelden waarom JavaScript een lastige taal is. Neem nou dit voorbeeld. Ook het volgende zegt een hoop:

Op Twitter las ik het volgende:

Ik ken de context niet, maar ik ken wel het gevoel 😉

JavaScript was altijd iets wat je er als Java, C#, Ruby ontwikkelaar bijdoet. Even een beetje JavaScript toevoegen. Een kloddertje roze hier…
Dit is hoe het sinds eind jaren negentig veelvuldig toegepast is. Het lijkt wel alsof alles wat we doen om goede code te schrijven, overboord gegooid wordt wanneer we “even een beetje JavaScript toevoegen”.

Maar dit is aan het veranderen. Door de opmars van tablets en smartphones worden we steeds vaker geacht frontend applicaties te ontwikkelen voor meerdere platformen.  In het begin werd vaak voor ieder platform een aparte applicatie ontwikkeld. Nu zie je steeds vaker dat gekozen wordt voor een HTML/CSS/JavaScript oplossing. Helemaal nu het bijvoorbeeld met Phonegap (Apache Cordova) mogelijk wordt de native API’s aan te spreken.

Inmiddels zijn de VM’s in browsers ook snel genoeg om client-side applicaties te renderen en de user interaction af te handelen. Hierdoor lijkt er ook qua algehele applicatie-architectuur een verschuiving plaats te vinden.
De afgelopen jaren zijn we druk in de weer geweest met bijvoorbeeld (G)Rails of ASP.NET MVC server-side HTML-output te genereren. De client doet een request, de server stuurt een HTML pagina terug. Dit herhaalt zich steeds. Toen gingen we binnen de context van een pagina met behulp van AJAX content (XML/JSON) ophalen en bijwerken.
Maar nu gaat het volgens mij echt de kant op dat we applicaties volledig in JavaScript gaan schrijven. Alle user interaction wordt client-side afgehandeld en views worden client-side gegenereerd. Er wordt met HTTP-services gecommuniceerd voor de data.
Deze verschuiving heeft de nodige voordelen. Zo verplaatsen we een hoop rekenkracht naar de client. Ook is de frontend nu echt gescheiden van applicatie services. Vaak zie je in een (G)Rails of ASP.NET MVC oplossing dat dit toch vermengd raakt.

Bij een hoop ontwikkelaars zal hier vast grote weerstand tegen ontstaan. Het is ook nogal een flinke verandering. Een C# webontwikkelaar die nu met behulp ASP.NET MVC zijn HTML pagina’s genereert, netjes zijn unit tests schrijft, en zijn buildprocess onder controle heeft moet nogal wat nieuwe dingen leren. ‘JavaScript is een slechte taal’ zal vaak als excuus gebruikt gaan worden om dit niet  te hoeven doen.
Maar er zijn inmiddels al vele frameworks waarmee we fatsoenlijk JavaScript applicaties kunnen ontwikkelen. Deze frameworks nemen vaak 1 van de volgende zaken voor hun rekening: DOM-manipulatie, Architectuur of User Interface. Er zijn echter ook frameworks waarin alles ondersteund wordt, bijvoorbeeld JQuery Mobile of de Dojo Toolkit.

Mijn ervaringen

Ik ken natuurlijk niet alle frameworks goed, maar ik ben erg enthousiast over Backbone, en dan vooral icm RequireJS. Als UI toolkit vind ik Twitter Bootstrap erg prettig werken. Voor unit tests gebruik ik momenteel QUnit naar volle tevredenheid.
Een goede IDE heb ik nog niet echt gevonden. Cloud9 werkt op zich goed, maar om dat nu bij klanten te gaan gebruiken is  voor mij nog een stap te ver. In Visual Studio 2012 schijnt de ondersteuning voor JavaScript sterk verbeterd te zijn; ik ben benieuwd.

Mijn advies voor alle applicatie-ontwikkelaars is in ieder geval: zorg dat je een meester in JavaScript wordt. Ik denk dat er veel vraag naar zal zijn in de toekomst.
Wellicht dat er een gangbare abstractie bovenop komt (iets als Coffeescript bijvoorbeeld), maar het is nooit slecht om te weten hoe het onder de motorkap werkt.

One More Cup of Coffee

Helaas kon ik de Bob Dylan versie niet vinden op YouTube, maar gelukkig laten The White Stripes het niet afweten.

Tim!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *