Fronteers — vakvereniging voor front-end developers

Front-end vraagstukken: Gebruik van javascript libraries

In het kader van front-end vragen uit de vereniging (vragen blijven welkom) stelt Jeroen Mulder een aantal gerelateerde vragen over het grootschalig gebruik van javascript libraries:

Unobtrusive Javascript is voor de meeste front-end ontwikkelaars een normale zaak geworden. Libraries als jQuery, Dojo en Prototype maken het met functionaliteiten als CSS selectors en event binding nog makkelijker om snel en unobtrusive functionaliteiten in een bestaand document te verwerken.

In een website waar op steeds meer plaatsen functionaliteiten in Javascript worden ontwikkeld, hoe zorg je er voor dat een middel tot groot developmentteam dit op een wijze doet die de onderhoudbaarheid en front-end performance niet verslechteren?

Specifiek voor degenen die uitgebreide ervaring hebben met het gebruik van een Javascript library: hoeveel werk doe je nog naast het gebruik van de library om de code herbruikbaar en onderhoudbaar te houden?

Ik denk dan met name aan de volgende drie vraagstukken:

1. Hoe weet een ontwikkelaar of bepaalde Javascript nog wel wordt gebruikt? En zo ja, op welke pagina's? Het gebruik van CSS selectors in Javascript maakt het net als in CSS zelf niet makkelijk om te zien hoe en waar welke code van toepassing is.

2. Hoe debugged een ontwikkelaar een document waarbij de Javascript functionaliteit op een unobtrusive manier wordt toegewezen? Als verschillende stukken code invloed hebben op de interactie van een element, hoe weet een ontwikkelaar waar hij of zij moet zoeken voor de verantwoordelijke code?

3. Hoe organiseer je het beste vele kleine Javascript functionaliteiten verspreid over een grote website? Kies je voor een aanpak waarbij je de functionaliteit als plugin inpakt welke volledig autonoom kan werken? Of kies je voor een aanpak waarbij de functionaliteit gevoed moet worden met een stel elementen en instellingen, welke vervolgens zichzelf registreert bij de onDOMReady handler?

Reacties

1 Tom op 27-03-2009 om 20:29 uur:
1. Dat is een goede! Wat zou ik dit graag als extra functionaliteit van Firebug zien! Tot het zover is: documenteer! Ik hanteer bijv. de syntax van JSDoc voor inline documentatie. Omvangrijkere projecten verdienen ook extra uitleg in tekst.

2. JS-code van een ander debuggen is geen sinecure. Ook in dit geval zal goede documentatie kunnen helpen.

3. Zelf maak ik gebruik van object literals (meestal naast jQuery). Klantspecifieke (sitebrede) functionaliteit wrap ik in een object literal die op onDOMReady wordt aangeroepen. Vaak heb je ook nog stukken code die zeer specifiek zijn: bijvoorbeeld een rekenmodule of formuliervalidatie. Deze kun je wrappen in hun eigen object literal die je bij de Main of Klant registreert. Deze laatste stukken code hoef je alleen aan de client te serveren als een specifiek gedeelte van een site opgevraagd wordt. Paginaspecifieke code in zijn eigen object literal wrappen maakt de code ook overdraagbaarder.
2 Sander v. L. op 27-03-2009 om 22:14 uur:
Wat betreft het (nog) in gebruik zijn van JavaScript code vraag ik me af of unit-test methodieken hierbij kunnen helpen, aangezien unit-testing tools eigenlijk altijd met code coverage rapportage uitkomen.

Ik heb helaas nog nooit unit-testing in de JavaScript wereld mogen doen, maar zag wel recent dat YUI een unit-testing component heeft, en hoewel deze op dit moment nog geen code coverage lijkt te hebben (controleer dit zelf: ik heb niet ver doorgekeken) heb ik het vermoeden dat dit nooit ver weg kan zijn.

Verder kom ik toevallig net ook (terwijl ik naar het bovenstaande kijk) de volgende Firefox extensie tegen: hrcov, welke een heel stuk in de buurt lijkt te komen. (Er is ook een firebug plugin die per functie een coverage rapport geeft, maar dat is een niet verder geupdate versie uit 2007, dus waarschijnlijk minder nuttig.)
3 Jeroen Mulder op 29-03-2009 om 22:44 uur:
Tom, documentatie zou inderdaad eigenlijk altijd een must zijn. Gegenereerde documentatie op basis van JSDoc zou helemaal geweldig zijn. Idem voor CSSDoc natuurlijk.

Op het moment maak ik persoonlijk geen gebruik van JSDoc of CSSDoc, dus kan ik niet inschatten in hoeverre het de 80% van de problemen op lost. Als ik kijk naar mijn ervaring met CSS en de problemen daarmee, dan verwacht ik niet echt dat documentatie het probleem volledig op lost.

Sander, ik ben niet heel bekend met dingen als code coverage, maar ik ga er zeker naar kijken.

Heeft iemand misschien Selenium (of iets dergelijks) gebruikt om dit probleem min of meer op te lossen?

In ieder geval, thanks voor de reacties. :-)
4 Martin Reurings op 14-04-2009 om 10:44 uur:
Ook ik probeer zoveel mogelijk mijn code in Object Literals te 'verzamelen' en die dan met JSDoc te documenteren. Ik heb, om ons ontwikkel team te ondersteunen in het lezen van de documentatie, zelfs een plugin geschreven voor maven 2 om 'JSDoc Toolkit' te gebruiken om documentatie te genereren.

Dit is een heel redelijke oplossing binnen een 'Java'-omgeving en zeker indien je een component-based framework gebruikt. In mijn geval zit ik de afgelopen 3 jaar veel met Tapestry 5 te werken en daarin kun je per 'component' CSS en/of JS-code includen. Dit kan dan ook meteen je coverage dekken, de html en js-code behoren tenslotte tot een geheel.

Selenium heb ik een jaar of 2 getracht te gebruiken bij een klus in Nieuw Zeeland. Echter daar hadden we het probleem dat (toen de tijd) Selenium op hele lelijke manieren handlers aan de pagina trachtte te koppelen en doordat we zelf pas na seleniums' routine sommige functionaliteit op links verrijkten liep of onze, of Seliniums' code in de soep, ik heb sindsdien geen nieuwe pogingen gedaan om het te gebruiken...

Nu dat ik binnen de Java-omgeving meer unit-testing in werk heb gezien hoop ik ook dat daar een mooie oplossing voor kan komen voor javascript, tegelijkertijd houd ik mijn hart vast wanneer ik terugdenk aan hoe mooi, strak en snel js-code kan zijn wanneer je terugstapt naar de basis, misschien willen we wel teveel?
5 Nick op 09-03-2010 om 18:48 uur:
Ik denk dat het meest belangrijkste is dat alles goed gedocumenteerd wordt tijdens een project. Ook interne coding standards zijn een must zeg ik altijd! Goeie afspraken onderling zorgt dat er veel koppijn bespaart wordt. :)

Gebruik van Object Literals, correcte benoemingen van variabelen (denk hierbij aan benaming van verschillende types bijv. oVariable, sVariable, nVariable voor object, string, numeric enz) en je code goed opsplitsen in beschrijfbare functies goes a long way!
6 Nick op 09-03-2010 om 18:52 uur:
Ik denk dat we de gedachte van "Semantiek" ook in zijn meest theoretische vorm kunnen doorvoeren in de scripting.

Denk hierbij aan goeie beschrijfbare functie namen enz....

goWhere: function() zegt minder als goThere: function()
Plaats een reactie