Dan is het geen Javascript meer. Ik snap je punt wel, als je naar (bijvoorbeeld) prototype.js kijk die je ook dat ze hun classes op een eenduidige en standaard manier opbouwen. Waarom? Waarschijnlijk omdat die syntax zich voor hun bewezen heeft en het meest lijkt op wat ze gewend zijn.
Maar wat ik bedoel is dat schrijvers van libraries hun eigen voorkeur qua syntax gebruiken waarbij javascript zelf ook alternatieven biedt. Dat geeft een eenzijdig beeld.
Ook qua oplossingen zijn libraries natuurlijk een eenzijdige benadering die niet noodzakelijk de beste hoeft te zijn.
Echter als je technische analyse goed uitgevoerd is, heb je een library die het dichtst aan sluit bij wat jij (of jou team) wenst te hebben. Zie het als een kostten/baten analyse. De ene keer kun je een framework prima gebruiken, de andere keer niet. En daarbij: jij hebt waarschijnlijk ook een voorkeur om bepaalde dingen te doen. Sluit die aan bij andere mensen? Waarschijnlijk niet.
Dat is een voorbeeld van een eenvoudige abstractie die in ieder geval lekt qua performance (extra functiecalls) en de global namespace extra vervuilt
Dan kijk je niet verder als je neus lang is. (Hoewel het een theoretisch voorbeeld is omdat Javascript bij mijn weten geen ondersteuning heeft voor Threading). Is het idee achter MapReduce dat de initiële start-up cost zich heel makkelijk terug betaalt zodra je je applicatie omhoog gaat schalen (meer cores/servers) met zo min mogelijk moeite. (Je hoeft maar één of twee functies aan te passen).
Over de globale namespace kan ik kort zijn: nou en. Wil je dan maar geen functies meer gebruiken omdat die allemaal je globale namespace vervuilen? Of wou je het in een object steken? Waarom? Dit zijn twee functies die haast in je globale scope thuis horen, wat mij betreft.
Nogmaals, ik weet dat MapReduce amper van toepassing is op de standaard toepassingen van Javascript.
Een beter voorbeeld is misschien wel prototype's $() (tsja, naamgeving schijnt bij sommigen ook niet belangrijk te zijn
) - overmatig gebruik van deze abstractie kan behoorlijk negatieve gevolgen hebben voor de performance van je applicatie terwijl het op het eerste gezicht niet duidelijk is waarom dat zo is...
Overmatig gebruik van alles kan een negatief gevolg hebben voor de performance van je applicatie. Moet je het daarom maar helemaal niet meer gebruiken? Je dient zelf inschattingen te kunnen maken over het nut van die functie, hersenloze zijn nu eenmaal geen goede developers.
De naamgeving, ben het deels met je eens. De $ is erg nietszeggend maar het alternatief als je de functie getElementFor(...) gaat noemen is het punt van de korte naam een beetje weg en kun je haast net zo goed ElementX.getElementById(...) gebruiken. (En de andere varianten die $() ondersteund).
Verder kan je pas bepalen of restricties acceptabel zijn als je ook precies weet wat de restricties zijn van een bepaalde library. Documentatie (als die er al is) is daar meestal niet specifiek in dus heb je toch al een zeker mate van javascript kennis nodig om dat uit de code te kunnen halen.
Volgens mij is voor ieder van de libraries die in dit topic genoemd is gewoon documentatie aanwezig, al weet ik niet of ook voor iedere library gespecificeerd is wat de restricties zijn. Ik weet dat ik me op glad ijs begeef maar meestal is er om heen te werken (de frameworks zijn over het algemeen opensource, en je hoeft natuurlijk delen niet te gebruiken). Daarbij kies je een framework omdat je verwacht dat 't je meer op zal leveren als zal kostten.
Een 'hele community' is in de praktijk vaak maar een handjevol mensen (sommige libraries zijn zelfs one-men shows) en de prioriteiten van zo'n community zijn niet noodzakelijk de jouwe.
Mijn punt blijft, een community is over het algemeen veelzijdiger als jij. Ik kan in m'n eentje gewoon niet rekening houden met obscure browser X, wellicht omdat ik er niet van gehoord heb of omdat ik er geen tijd voor heb. Daarbij, kies je een framework om z'n bewezen technieken niet omdat je verwacht dat feature Y nog komen gaat. Als de prioriteiten niet aansluiten, tsja, een framework is nog steeds een
basis waar je zelf naar gelieve aan toe kunt voegen wat je wilt.
Overigens ben je dom bezig als je de community (en grootte daarvan) niet mee neemt in je analyse.
Overigens vind ik de kwaliteit van de meeste libraries maar middelmatig.
Voor je argumenten is wel wat te zeggen hoor maar het klinkt nogal Me vs. The World en Reinventing The Wheel achtig. Not Invented Here, misschien.
/u/24332/garfield-icon-by-negotiator.png?f=community){kind=icon}
/u/44276/got_icon5.png?f=community)
:strip_exif()/u/3333/pumpkin_avatar.gif?f=community){kind=avatar}
)/u/43729/gor.JPG?f=community)
:strip_icc():strip_exif()/u/5964/crop56503163e97a5.jpeg?f=community)
:strip_icc():strip_exif()/u/77332/crop5e54ec42433bc_cropped.jpeg?f=community)