Vanilla JS: Javascript framework

Door Gamebuster op vrijdag 19 oktober 2012 11:00 - Reacties (7)
Categorie: if(post.relatedTo("programming")), Views: 2.528

Ik heb een klein project waarbij ik een contact formulier moet maken voor een website. Omdat ik in vorige websites vaak frameworks gebruik, maar nooit tevreden ben met de werking ervan, heb ik besloten het toch maar eens zelf te gaan proberen, als hobby.

Een CSS framework voor prive-gebruik hoeft niet heel groot te zijn. Met SCSS en Ruby on Rails is het prima mogelijk mijn (S)CSS in soort-van modules in te delen om zo relevante delen makkelijk te kunnen uitwisselen tussen projecten. Ik begon met het schrijven van de SCSS voor formulieren.

Uiteindelijk kwam ik op een punt aan dat ik iets wilde doen, maar dat dit niet mogelijk is met CSS: Het moment dat de gebruiker een veld foutief invult en het formulier verstuurt, komen er extra classnames op een DIV-element om het invoerveld. M.b.v. deze classnames geef ik een rood kleurtje aan het veld en wordt er een zinnetje met een foutmelding achter het invoerveld gezet.

Nou wil ik dat de foutmelding en rode kleur weggehaald wordt op het moment dat de gebruiker de ingevulde waarde aanpast: De velden hoeven niet opnieuw gevalideerd te worden: dit gebeurt serverside.

Ik besloot daarom maar wat javascriptjes aan te maken. Omdat ik toch al een "ik gebruik geen CSS frameworks, ik maak het zelf wel" houding had, nam ik een hele spannende keuze; iets dat ik na een paar jaar aan jQuery, Mootools en Prototype niet meer gedaan heb: Het Vanilla JS framework gebruiken.

Vanilla JS
Vanilla JS is het kleinste en snelste javascript framework dat er bestaat. Het complete framework dat de gebruiker hoeft te downloaden bestaat uit 0 bytes en sommige functionaliteit werkt 100x sneller dan de jQuery varianten.

Het nadeel van Vanilla JS is dat de API zeer beperkt is en de functienamen groot zijn. Ik pakte de Vanilla JS documentatie erbij en begon met mijn code.

Mijn gewenste functionaliteit met jQuery
Ik wil dat als een gebruiker een invoerveld wijzigt in een DIV met de class "field_with_errors", dat de class "field_with_errors" weggehaald, zodat de rode kleur verdwijnt en de foutmelding verborgen wordt.

In jQuery is dit makkelijk te doen; Uit de losse hand (zonder te testen) krijg je iets als:

JavaScript:
1
2
3
$(document).on("change", "div.field_with_errors :input", function() {
  $(this).closest("div.field_with_errors").removeClass("field_with_errors");
});



En dan zonder jQuery
Nu moet ik hetzelfde maken in Vanilla JS. Eerst uitzoeken hoe events uberhaupt werken. Na wat googlen kwam ik op element.addEventListener.

Al gauw komt weer bovenwater waarom ik ooit gestopt ben met VanillaJS: Al die frameworks dekken compatibiliteitsproblemen tussen browsers... met name Internet Explorer 6, 7 en 8. Tegenwoordig is de situatie iets veranderd. Browser-updates gaan sneller en nieuwere versies voldoen veel beter aan de steeds verbeterende standaarden. Zelfs Internet Explorer doet zijn inhaalronde om te voldoen aan de simpelste standaarden.


JavaScript:
1
2
3
document.addEventListener("change", function(event) {
  // event.target is het element dat de change-event trigger'de
});



Vanilla JS heeft niet de mogelijkheid om zoals in jQuery de callback alleen uit te voeren als de element die de event trigger'de voldoet aan een bepaalde CSS selector, dus daar mag ik zelf op gaan controleren.

Zover ik weet zijn er geen functies om te controleren of een element voldoet aan een bepaalde css selector, dus ik moet handmatig gedaan worden. Dit doe ik door een loop te starten over alle parent-elementen en hiervan de nodeName en className te controleren. Omdat de className meerdere css classes kan bevatten, gebruik ik hier een regular expression voor.

Tot slot moet de css class uit de lijst verwijderd worden. Dit doe ik met een simple String-replace.

JavaScript:
1
2
3
4
5
6
document.addEventListener("change", function(event) {
  var node = event.target;
  while((node = node.parentNode).nodeName != "DIV" || !node.className.match(/\bfield_with_errors\b/))
    if(!node.parentNode) return;
  node.className = node.className.replace(/\bfield_with_errors\b/g, "");
});



En voila: Het werkt. Toegegeven: Mooi is anders. Even de voor- en nadelen op een rijtje:
+ Performance. Je hebt meer controle over wat je precies wilt. Dit zal de performance ten goede doen. Met een snippit als deze volledig onmerkbaar, maar als je een grote javascript applicatie hebt, zal het waarschijnlijk een merkbaar verschil kunnen opleveren, zeker vanaf mobieltjes.
+ Geen grote frameworks inladen. jQuery + allerlei plugins e.d. inladen kost veel bytes. Ook het verwerken van de jQuery code kost rekenwerk. Tegenwoordig peanuts: ~60kb downloaden en parsen kost "niets", maar opnieuw: Op mobieltjes met trager internet kan het verschil maken.
- Veel meer code per feature. Om iets te bereiken in Vanilla JS schrijf je zeker minstens 4 keer zoveel code, zowel in aantal tekens per regel als het aantal regels, tegenover jQuery of een ander framework. Dit kan je natuurlijk reduceren door zelf veelgebruikte patronen in functies te zetten. Dit is niet direct hetzelfde als jQuery gebruiken: Hoe mooi zo'n framework ook is, er zit altijd (veel) meer functionaliteit in dan die je ooit zelf zal gebruiken.
- Browsers blijven kut. Vele functies bevatten bugs, zijn niet of deels geÔmplementeerd. Dit is allemaal verschillend per browser en soms zelfs per browser versie.
- Vrijwel alles werkt met jQuery tegenwoordig. Als je 3rd-party code wil gebruiken, zal je weer terug moeten vallen op jQuery.
- De leerstof is beperkt; Er zijn meer tutorials te vinden voor jQuery dan voor Vanilla JS.

Word ik hier nu echt blij van? Tot nu toe niet echt. Ik ga nog even doorzetten om te kijken of ik er blij van kan worden. jQuery ken ik binnenste-buiten; Vanilla JS niet echt.

En ja, ik ben me ervan bewust dat Vanilla JS geen framework is en dat het een "spoof" van andere frameworks.

OMFG VERANDERINGEN

Door Gamebuster op donderdag 18 oktober 2012 16:25 - Reacties (7)
Categorie: quite useless, Views: 3.230

"WIJ KUNNEN NIET TEGEN VERANDERINGEN! TERUG NAAR 2000! VERANDER NIETS MEER!"
- Zo'n 60% van de actieve tweakers.net gebruikers.

Ik lees hele discussies over het forum over de nieuwe layout.

Persoonlijk vind ik v7 wel rustiger. De lagere CPI (Content Per Inch :+ ) vind ik wel fijn: Het geeft me wat meer rust. Toch kan ik me voorstellen dat sommigen de hoge CPI juist missen. Ik las dat sommigen T.net gebruiken i.c.m. auto-refresh om allerlei content in de gaten te houden. Misschien zou een soort overzicht-pagina een idee zijn; een pagina waarop alles wat er op dit moment op de site gebeurt gepropt wordt; zoveel mogelijk links die automatisch geŁpdatet worden, net als de vroegere tracker, maar dan over de hele pagina.

De hoeveelheid wit heeft een simpele oplossing: Mensen die een 30" scherm met 12.288.000 subpixels kopen en hun browser-venster in fullscreen modus hebben staan... Tja, dat moet je zelf weten. De ene website gebruikt volledige breedte van je venster, de andere niet. Persoonlijk vind ik dat het web gewoon in 980px horizontale pixels moet (kunnen) staan. Mijn browser-venster staat dan ook nooit groter dan zo'n 1000 pixels. Websites die breder zijn irriteren mij. Websites met dynamische breedte zijn prima, maar dat lijkt me op tweakers.net gewoon niet handig.

Tweakers.net's content is niet gemaakt voor content met dynamische breedte. Dynamische breedte op een forum geeft een rommeltje. Door de vele korte berichten (bij voorkeur na een one-liner quote) zal je veel lelijke ruimte hebben en weinig tekst. Een website met dynamische breedte moet deze breedte goed kunnen benutten. Tweakers.net's forum is een website die dat niet kan. Niet met dit design. Dan heb je net een breed venster gehad voor een website die de breedte wel goed benut, mag je daarna je venster weer smal maken omdat je anders allerlei forumposts over 1 regel krijgt, terwijl de avatars e.d. wel een vaste hoogte hebben.

Ook de nieuwsberichten e.d. op volledige breedte tonen ziet er niet uit. Daar zijn de nieuwsberichten te klein voor. Bij een krant staan de teksten in meerdere kolommen; dat leest prettiger. Bij t.net kan je dat niet: Eťn tekst over meerdere kolommen tonen zal er raar uitzien, of je moet meerdere nieuwsberichten naast elkaar tonen, of het is gewoon heel lastig te implementeren, zelfs als je CSS3's kolommen fatsoenlijk aan de praat krijgt.

Er zijn overigens wat vervelende bugjes bij het aanmaken van een nieuwe weblog: De categorie(Žn)-select is te laag en de tijd kan je niet invullen. Ook de streepjes tussen de datum-velden staan niet echt netjes uitgelijnd. Eigenlijk ziet het hele formulier er niet uit qua uitlijning; Het lijkt niet echt zorgvuldig getest te zijn.

http://i.imgur.com/MGwI2.png

Hoe dan ook; mijn mening is dat ik de nieuwe t.net een verbetering vind voor mezelf, maar ik kan me prima voorstellen dat anderen zich storen aan de lagere CPI. Van mij mag v7 blijven. Het is uiteindelijk ook gewoon erg wennen. Jammer dat tweakblogs.net nog wel de oude layout heeft.

Ik haat Matrixborden

Door Gamebuster op dinsdag 16 oktober 2012 13:01 - Reacties (60)
Categorie: quite useless, Views: 11.042

Ik heb een onbewuste haat richting matrixborden gekregen omdat zij de eersten zijn die mij confronteren met een nare realiteit. Het is niet de schuld van de matrixborden... maar toch mag ik ze niet.

Klootzakken.

http://static.autoblog.nl/images/wp2010/Matrixbord_70.jpg

grappig dat ik een plaatje op internet opzoek en dan precies de weg + richting vind waar ik veel op stil sta