Fronteers — vakvereniging voor front-end developers

Hoe manage jij je front-end code?

  • Robert Gaal
  • 17 mei 2008
  • (Niet gecategoriseerd)

De meeste front-enders kennen dit probleem vast wel: je CSS of Javascript code raakt onoverzichtelijk. Je hebt teveel aparte bestanden of te lange bestanden en het wordt moeilijk om dingen terug te vinden, zelfs met een goeie zoekfunctie. Classes worden overbodig en niet verwijderd, stukken markup hebben niet de ID die je verwacht, functies zijn onderverdeeld in verkeerde bestanden, etc. Het is allemaal niet onmogelijk om bij te houden natuurlijk, iedereen heeft zo z'n routine. En daar gaat deze post over!

Hoe manage jij je front-end code? Gebruik je bijvoorbeeld SASS of Blueprint? Is er de perfecte IDE die het meer managable maakt? Specificeer je voor alles Classes in Javascript? Heb je een naam-structuur uitgedacht voor je bestanden en mappen? Kortom: wat doe jij om rotzooi te voorkomen? Laat het ons weten.

Kleine kanttekening: ik ben zelf ook vaak bezig met Ruby On Rails en de DRY en MVC methodes daarvan spreken me erg aan. Misschien is een open-source front-end framework met die principes een idee?

Reacties

1 Henri op 17-05-2008 om 20:15 uur:
Ik verdeel alles in bestanden:

PHP, TPL, JS en CSS in een voor mij logische mappenstructuur.

Enig nadeel is dat de CSS soms nogal lang wordt. Op zich is het redelijk te beheren. Ik zie er op zich wel naar uit om een bepaalde logica erin aan te brengen (zoals je noemt).
2 Stephan op 19-05-2008 om 09:53 uur:
Ik maak meestal gebruik van een master.css waar alleen @import dingen instaan. Onderverdeling bijv. in layout.css, forms.css, tables.css, content.css

Id's laat ik beginnen met een hoofdletter, voor herkenbaarheid en ook gevoel t.o.v. classes. Een id is ook krachtiger in meerdere opzichten (uniek, sterkere selector). Classes doe ik alleen met kleine letters.

Een static map vind ik vaak lekker, met daarin de mappen images/css/js. De images map hierin verdeeld in backgrounds/icons/arrows. De background images zelf beginnen dan met bg_, de icons met icon_ etc.

Binnen de css zet ik vaak vlaggetjes d.m.v. een '=' teken (/* =Main */), zeker met grote stylesheets komt dat vaak van pas bij het zoeken.

Ik ben wel benieuwd hoe jullie omgaan met inspringen bij geneste selectors in stylesheets. Zelf vind ik inspringen zeker overzichtelijk, maar wel tot op zekere hoogte.
Bij complexere sites is het soms misschien juist prettiger alle css zonder inspringing neer te zetten.
3 Marcel op 19-05-2008 om 09:57 uur:
Binnen het bedrijf waar ik voor werk hebben we een frontender project gestart waarmee we dit soort problemen voorkomen. Onze gecombineerde CSS is dan wel lang, maar het is onderverdeeld in o.a.:

forms.css, tables.css, units.css, body.css, type.css, etc.

We includen maar 1 top-level CSS file welke zelf de rest include. Een "custom.css" staat toe om custom CSS definities te plaatsen waar de standaard stijlen niet voldoen.

Zonder al teveel informatie te geven (het is immers bedrijfs-software!) moet ik zeggen dat het erg makkelijk werkt zo.

Verder wil ik er naartoe om, als frontender die vooral prototypes maakt, alles in XSL/XML te gaan opzetten. Hierin past het DRY (Don't Repeat Yourself) concept weer goed: stukken code die je in HTML templates zou herhalen (prototypes oid.) kan je in een XSL-template stoppen, hier parameters aan meesturen en je bent er.

Daarnaast is XSL enorm foutgevoelig, met andere woorden: verplicht nette HTML schrijven. 1 Fout wordt direct bestraft met een error in de browser.

Dus een nette structuur van standaard classes, custom classes om jezelf als ontwerper niet te beperken (voor zover de ontwerper/frontender dezelfde persoon zijn) en een slimme manier van werken maken het leven een stuk simpeler.
4 Egor Kloos op 20-05-2008 om 12:29 uur:
Ik heb nog geen eenvoudig methode gevonden die voor verschillende werkwijze goed toepasbaar is.
Ik werk vaak met bestaande sites en hierdoor kom ik het onderhoud probleem vaak tegen.

Hierdoor is mijn werkwijze de laatste zeven jaar niet veel veranderd. Schrijf zo min mogelijk code met duidelijke comments.
Voor het CSS deel lijkt veel op die van Douglas Bowman: http://www.stopdesign.com/log/2005/05/03/css-tip-flags.html
Deze techniek is ook goed toepasbaar met HTML en JavaScript.

Het blijft moeilijk om oude code te verwijderen. Omdat het veel test tijd in beslag kan nemen. Hiertoe probeer ik tegenwoordig mijn comments zo te schrijven zodat dependancy duidelijker is. Onderhoud kost de klant nog steeds teveel geld.
5 Henri op 26-05-2008 om 22:40 uur:
Mooie reacties, alhoewel het ook sterk afhangt van de grootte van de projecten en het team. Teveel bestanden lijkt me ook lastig, maar goed, in teamverband is dat ideaal. Een centrale projectlocatie is van cruciaal belang en uiteraard goede documentatie.
6 Vincent de Lau op 09-06-2008 om 16:35 uur:
De laatste tijd probeer ik meerdere klassen in mijn (X)HTML. (Voor IE6- vereist dat Dean Edwards IE7).

Op die manier voorkom ik dat ik hele stukken CSS moet kopiëren en is het vrij duidelijk welke HTML ik moet genereren vanuit PHP. Een blokje met headlines krijgt dan bijvoorbeeld de klassen "news headlines gadget corners" mee.

Voor de rest probeer ik ook CSS bestanden in stukken te verdelen, naar functie (layout, typografie) of paginasoort (homepage, artikel).
7 Jeroen Oliemans op 13-06-2008 om 14:14 uur:
Op Kings of Code werd duidelijk dat het gebruik van veel CSS files ( inclusief het gebruik van @import ), de snelheid van je site niet ten goede komt vanwege de HTTP-requests.
Als je styled voor site die zwaar belast wordt kan je beter op het laatst toch weer alles in één CSS file stoppen.

Maar het blijft wel snelheid vs. gemak
8 Mathias Bynens op 11-07-2008 om 17:03 uur:
@Jeroen, dat zou je dan kunnen oplossen door een PHP-scriptje te schrijven dat alle CSS-bestanden in de desbetreffende map includet. Op die manier werk je als fronteer nog steeds in verschillende bestandjes, maar wordt alle CSS voor bezoekers mooi samengeperst tot één bestandje, met een minimum aan HTTP-requests tot gevolg.

Persoonlijk werk ik graag met afzonderlijke statische mappen voor CSS, JavaScript, templates, en afbeeldingen. Deze laatste bevat dan enkel afbeeldingen die deel uitmaken van de eigenlijke inhoud, en aldus via IMG-elementen in de HTML worden geplaatst. Voor design-gerelateerde afbeeldingen gebruik ik een submapje binnen de CSS-map.

Voor JavaScript werk ik in een uitgebreid becommentarieerd bestand, meestal scripts.js. De uiteindelijke versie wordt steevast ge-minified en bewaard onder een naam als scripts.min.js. Afhankelijk van de grootte van het oorspronkelijke bestand kan dit algauw enkele KiB schelen.
Plaats een reactie