[MooTools] Wie gebruikt het?

[posttoast]

Aangezien MooTools 1.2 zojuist is uitgekomen en er op GoT nog vrij weinig te vinden is over dit Javascript framework leek het mij interessant dit draadje te starten.

Gebruiken jullie MooTools? Zo ja: waarom de keuze voor dit framework en niet voor bijvoorbeeld JQuery of Prototype?

Ik gebruik het zelf al een tijdje. In de eerste instantie omdat ik wat sneller basic dingen als Ajax-requests ermee op kon zetten, maar nu ga ik juist meer in mijn sites stoppen (drag&drop en style-transitions bijvoorbeeld) omdat het allemaal erg eenvoudig is.

Ik heb ooit even gebruik gemaakt van Prototype (door Lightbox ben ik daarop gekomen), maar MooTools vond ik door z'n modulaire opzet al snel een stuk interessanter. Het enige grote nadeel van MooTools vind ik de (naar mijn mening) nogal magere documentatie. Dat is bij JQuery en Prototype een stuk beter.

[storeman]

Ik ben ook geswitched van Prototype naar Mootools, mede omdat ik prototype vrij lomp vond in gebruik.

In het geval van een AJAX request is prototype soms wat fijner (meer states), maar over het algemeen is deze bij mootools ook goed.

Daarnaast vond ik wat leuke plugins voor Mootools (autocomplete, smoothbox), waardoor ik overgegaan ben van Prototype naar mootools. JQuery ken ik persoonlijk niet.

Het nieuws dat Zend Framework kiest voor Dojo heeft mij nog wel even aan het twijfelen gebracht, Dojo ziet er ook interessant uit, echter vervuilt deze je HTML met allerlei code (alleen als je de vieze maar makkelijke manier gebruikt).

Net even naar Google WebKit zitten kijken, ook daar maar weinig over op GOT, maar wat ik ervan gezien heb, niets dan lof, de hele filosofie erachter staat me wel aan (slimme client domme server in plaats van domme client, drukke server). Echter zonder JS is er weinig mee te beginnen, verwacht ik.

[ Voor 43% gewijzigd door storeman op 10-06-2008 10:35 ]

[posttoast]

En heb je al ervaring met 1.2? Ik nog niet, heb even op de final gewacht.

Ah, de documentatie van 1.2 staat ook online. Ziet er als ik zo snel even kijk al beter uit dan die van 1.1x.

[ Voor 51% gewijzigd door posttoast op 10-06-2008 10:35 ]

[BtM909]

De documentatie van 1.2 stond al een tijdje online hoor als beta @ http://docs12b.mootools.net/

Een aantal dingen zijn raar geimplementeerd in mootools, maar het framework is behoorlijk slim en compact opgezet (in vergelijking met andere frameworks)

[posttoast]

Ja, ik wist dat die documentatie er al was, maar ik had me er nog niet in verdiept.

Wat vind jij raar geimplementeerd?

[storeman]

Ik heb al wel even met 1.2 gespeeld, mede vanwege een plugin, maar andere plugins blijken dan weer niet te werken.

Over het algemeen zal je je scripts toch iets aan moeten passen om het overweg te kunnen laten gaan met mootools 1.2.

Overigens is de nieuwe versie flink kleiner dan 1.11 (30%), maar de compressie kan er dan weer minder mee:

Mootools 1.11: 180KB / 70KB
Mootools 1.20: 134KB / 101KB

Beide compressed met Dojo Shrinksafe

[ Voor 30% gewijzigd door storeman op 10-06-2008 13:06 . Reden: Iets met bestandsgroottes ]

[BtM909]

MooTools 1.2 YUI Compressor 60 kb

[H004]

Maar das alleen "core". More (alle plugins) is nog een kleine 30kb extra (YUI compressed). Bij elkaar dus 90kb.

(gewoon alles gzippen, dan is t bij mij minder dan 20kb (v1.11 met bijna alle plugins), geloof ik.

[Verwijderd]

Ik ben en blijf fan van Prototype, aangevuld met wat jQuery en script.aculo.us. Zou bij god niet weten welke uitbreidingen ik nog nodig zou moeten hebben, op "prototip" na, omdat dat werkelijk bestaat uit inconsequenties

[SchizoDuckie]

Mootools fan hier check

Mijn laatste meukseltje: http://www.schizofreend.nl/pigwindow/ [src]

Een simpel draggable en sluitbaar window classje die content in kan laden zonder alle IE support meuk (die bij de andere classes er wel in zit) Ik gebruik dit voornamelijk voor backends / CMSen dus ik vind het best als het alleen in A-Grade browsers werkt

Het leuke is aan mootools dat alle standaard meuk gewoon allemaal aanwezig is, drag/drop, je hoeft *eindelijk* niet meer het wiel uit te vinden wat dat betreft

Nu nog even snel uitvogelen hoe die google code hosting in elkaar steekt en dan host ik m'n lib voortaan gewoon vanaf google

Het enige nadeel aan de nieuwe Hash uit 1.2 las ik gister is dat ie je 'reserved' properties als each,splat, indexOf, etc niet mag gebruiken maar dat gaan ze vast nog wel fixen Verder vind ik het echt geniaal van opzet, goed te lezen en van veel functionaliteiten heb ik echt zoiets van *glug*

[ Voor 53% gewijzigd door SchizoDuckie op 10-06-2008 17:51 ]

[Makkelijk]

Ik hou ook van mootools, ik vind prototype wel leuk, maar het modulaire aspect van mootools maakt het gewoon een stuk sneller.

[Cartman!]

* Cartman! meld zich ook als MooTools fan

Gebruik nu nog versie 1.11 maar ga zeker 1.2 een der komende dagen eens checken.

Verder werk ik sindskort met Zend Framework die Dojo gaan meeleveren maar dat lijkt me niks vanwege de zooi die het maakt van je html. Voorlopig sowieso MooTools dus

[ Voor 40% gewijzigd door Cartman! op 10-06-2008 21:13 ]

[Verwijderd]

Ik gebruik ook mootools, het is echt verbazend hoe snel je je het onder die knie krijgt en hoe handig het is!

De documentatie is inderdaad redelijk basis maar de voorbeelden op de site helpen je goed vooruit om te verstaan hoe het systeem in z'n werk gaat.

[Amorphis]

Hier ook een mootools fan. Mootools heeft javascripten weer ontzettend leuk gemaakt.

[ruuds]

Ik gebruik het ook een paar maanden nu. Heb een paar maanden terug heel snel jquery, mootools en nog eentje naast elkaar gelegd, en daaruit vond ik mootools het meest laagdrempelig.

Werk al een tijdje met 1.2beta (wat overigens wel een wereld van verschil met 1.11 was), dus maar eens tijd om wat bestandjes bij te gaan werken

[Bosmonster]

Ben recent aan het kijken naar een interessante library en kwam door reviews al snel op Mootools en daar dus een aantal dingen mee gedaan. Mootools zit netjes in elkaar. Nadeel is dat het wat complex is, de documentatie aan de beperkte kant en de community niet zo sterk. Ook de updates laten vaak lang op zich wachten.

Recent wat meer naar JQuery gekeken en wat daar direct opvalt is dat de syntax veel simpeler is. Het is ook minder netjes (eigenlijk gewoon niet OO), maar ik kon er veel sneller mee uit de voeten. De updates zijn regelmatig (ook voor kleine bugfixes) en de community is zeer actief.

JQuery is misschien iets meer voor de 'gewone man' en Mootools voor de meer ervaren developer. Ik ben er nog niet helemaal over uit.

[BtM909]

Dojo vs JQuery vs MooTools vs Prototype Performance Comparison

En zou je het qua performance zelf willen testen:

SlickSpeed Selectors Test @ mootools

[ Voor 28% gewijzigd door BtM909 op 11-06-2008 09:53 ]

[Japius]

SchizoDuckie schreef op dinsdag 10 juni 2008 @ 17:45:
Mootools fan hier check

Mijn laatste meukseltje: http://www.schizofreend.nl/pigwindow/ [src]

Een simpel draggable en sluitbaar window classje die content in kan laden zonder alle IE support meuk (die bij de andere classes er wel in zit) Ik gebruik dit voornamelijk voor backends / CMSen dus ik vind het best als het alleen in A-Grade browsers werkt

Je haalt nog een script van GetFirebug, site is laatste tijd erg slecht bereikbaar.

Daarnaast: heb je de Mootools Mocha UI ook gezien? Moest er gelijk aan denken toen ik je pigwindow zag.

[SchizoDuckie]

Japius schreef op woensdag 11 juni 2008 @ 10:15:
[...]


Je haalt nog een script van GetFirebug, site is laatste tijd erg slecht bereikbaar.

Daarnaast: heb je de Mootools Mocha UI ook gezien? Moest er gelijk aan denken toen ik je pigwindow zag.

Ik zal die firebug link even aanpassen, thanks.

Mocha UI heb ik idd eerst gebruikt, die geeft alleen problemen met firefox op de mac met scrollbars en body overflow, plus de container schaalt niet automagisch als je bijv. via ajax nieuwe content inlaadt.Daarna ben ik in eerste instantie overgestapt ben op de lib van clientside voor de StickyWindow. Deze heeft ook nogal wat dependencies en IE bugfixes enzo wat ik helemaal niet nodig heb, vandaar mn eigen lightweight dingetje

Ik zit nog te twijfelen trouwens of ik die hele handel op zal bouwen met een tabel met 3 rijen /cellen zodat het ook in IE wat beter werkt. scheelt ook een hoop CSS nog.

[ Voor 13% gewijzigd door SchizoDuckie op 11-06-2008 10:30 ]

[Bozozo]

Ik vind het leuk om mijn eigen scripts te schrijven. Voor basic dingetjes als drag&drop, AJAX en JSON ga ik echt geen framework gebruiken. Morph effecten (volgens mij een van de meest populaire features van MooTools) zijn nou net zo leuk om zelf te coderen.

Ik heb het gevoel dat veel te veel mensen dit soort frameworks / libraries gebruiken waar het helemaal niet nodig is. Met een crossbrowser add / remove Event functie en een goed xmlhttprequest object (als je AJAX wilt gebruiken) kom je m.i. een heel eind.

Dit om maar eens tegengas te geven aan alle MooTools fans hier

[ZpAz]

@Hierboven

Zelf ben ik vervend gebruiker van jQuery, en hiermee kan je met een enkele regel iets drag and dropable maken, of de effectjes er op los laten.

Dus je laad dan wel een extra +- 70 kb mee (maar wat is dat voor een breedbandverbinding), maar aan de andere kant werkt alles crossbrowser, met een paar regels, ipv dat je zelf een uur coded.

Vooral is de chain mogelijkheid van jQuery erg cool

-----

Voordat ik jQuery gebruikte maakte ik ook alles zelf hoor, drag and drop enz. Maar met een framework werkt het toch een stuk fijner, makkelijker en sneller!

[ Voor 16% gewijzigd door ZpAz op 11-06-2008 10:51 ]

[crisp]

BtM909 schreef op woensdag 11 juni 2008 @ 09:52:
Dojo vs JQuery vs MooTools vs Prototype Performance Comparison

En zou je het qua performance zelf willen testen:

SlickSpeed Selectors Test @ mootools

Persoonlijk vind ik zo'n vergelijking nogal nietszeggend. Ten eerste test je maar een klein onderdeel van de hele library (de selector-engine) en ten tweede is het raar om de performance voor bijna nooit gebruikte selectors even zwaar te laten tellen als die van veel gebruikte simpele selectors.

Ik vraag me ook af in hoeverre mensen ueberhaupt gebruik maken van uitgebreide selectors. Ik heb persoonlijk nooit de behoefte gehad aan uitgebreide CSS-syntax selectors en kom met enkel ID, className en tagName (en de iteratieve DOM-methods) altijd prima (en waarschijnlijk ook veel sneller) uit de voeten.

Verder zou je je keuze voor een library ook niet moeten laten afhangen op een verschil van enkele milliseconden voor een bepaald soort selector. Dat soort dingen zijn micro-optimalisaties die volledig wegvallen in het grote geheel. Dit soort performance vergelijkingen zijn dan ook niets meer dan wedstrijdjes ver-pissen...

[ Voor 13% gewijzigd door crisp op 11-06-2008 12:25 ]

[Verwijderd]

Compressie toepassen op de JS lijkt me ook compleet zinloos.

Het gaat maar om een besparing van 50k, dus voor de bandbreedte hoef je het niet te doen (plus dat je die JS natuurlijk makkelijk clientside kan laten cachen).

Daarnaast zijn internet verbindingen zo snel dat het zo goed als niets scheelt, zeker niet als je de overhead van het opbouwen van het request meerekent.

Wat wel belangrijk is is dat ook op tragere JS engines de lib lekker snel ingeladen is. Het is natuurlijk compleet zinloos als je JS engine binnen 0.01 sec bij de gebruiker is, maar de PC van de gebruiker vervolgens 1 sec nodig heeft om het ding te parsen.

Dan kun je die compressie stap dus beter achterwege laten en gewoon de cleane JS (dus wel stripped van commentaar ed) naar de gebruiker sturen.

[Makkelijk]

crisp schreef op woensdag 11 juni 2008 @ 12:22:
[...]

Persoonlijk vind ik zo'n vergelijking nogal nietszeggend. Ten eerste test je maar een klein onderdeel van de hele library (de selector-engine) en ten tweede is het raar om de performance voor bijna nooit gebruikte selectors even zwaar te laten tellen als die van veel gebruikte simpele selectors.
[...]

Ik vind het vooral nogal nietszeggend dat ze op basis van deze test concluderen dat Safari op XP extreem snel is. Het feit dat selectors het snel doen op safari zegt natuurlijk niets.

[crisp]

Makkelijk schreef op woensdag 11 juni 2008 @ 12:31:
[...]


Ik vind het vooral nogal nietszeggend dat ze op basis van deze test concluderen dat Safari op XP extreem snel is. Het feit dat selectors het snel doen op safari zegt natuurlijk niets.

Core JS performance is ueberhaupt vaak onbetekenend in vergelijking met bijvoorbeeld dynamische renderperformance van de browsers. Dat laatste is vaak de grootste bottleneck.

Verder meen ik dat de daar geteste versie Safari al native getElementsByClassName ondersteuning had itt de andere geteste browsers. Libraries die daar gebruik van maken zullen dan inderdaad ook beter performen. Firefox 3 heeft nu ook native gEBCN ondersteuning, en IE8b1 heeft support voor querySelector.

Verwijderd schreef op woensdag 11 juni 2008 @ 12:30:
Compressie toepassen op de JS lijkt me ook compleet zinloos.

Het gaat maar om een besparing van 50k, dus voor de bandbreedte hoef je het niet te doen (plus dat je die JS natuurlijk makkelijk clientside kan laten cachen).

50k is toch vrij fors. Bedenk ook dat first-time bezoekers snel van oordeel zijn als een pagina traag inlaadt (en dus ook snel weg zijn). Daarbij is HTTP-compressie behoorlijk eenvoudig te implementeren

[ Voor 13% gewijzigd door crisp op 11-06-2008 12:42 ]

[Verwijderd]

Ja natuulijk, maar ik ga er vanuit dat HTTP level gzip compressie sowieso al door iedereen wordt toegepast.

Ik doelde meer op die JS compressie technieken als YUI Compressor

[crisp]

Verwijderd schreef op woensdag 11 juni 2008 @ 12:45:
Ja natuulijk, maar ik ga er vanuit dat HTTP level gzip compressie sowieso al door iedereen wordt toegepast.

Ik doelde meer op die JS compressie technieken als YUI Compressor

true, de winst die je dan nog extra haalt is dan nog maar minimaal en het levert je ook weer extra problemen op:
- een extra stap in je deployment procedure
- lastiger om accurate foutinformatie te krijgen
- lastiger te debuggen
- risico op problemen veroorzaakt door de compressie/minification (bijvoorbeeld conditional compilation statements die gezien worden als gewone comments)
- afhankelijk van de gebruikte tool moet je ook rekening houden met bepaalde syntax-requirements (altijd verplicht de semi-colon gebruiken of zelfs altijd verplicht braces, dingen als a = i++ + 5 vermijden e.d.)

sommige van deze dingen kan je natuurlijk wel automatiseren of extra debug-mogelijkheden inbouwen waarmee je makkelijk kan switchen naar non-minified sources, maar als je die moeite al neemt dan zou ik eerder kiezen voor een tool die automatisch bepaalde JS (en CSS) bestanden kan samenvoegen zodat je het aantal benodigde HTTP requests voor een pagina kan terugdringen

[SchizoDuckie]

Bozozo schreef op woensdag 11 juni 2008 @ 10:30:
Ik vind het leuk om mijn eigen scripts te schrijven. Voor basic dingetjes als drag&drop, AJAX en JSON ga ik echt geen framework gebruiken. Morph effecten (volgens mij een van de meest populaire features van MooTools) zijn nou net zo leuk om zelf te coderen.

Ik heb het gevoel dat veel te veel mensen dit soort frameworks / libraries gebruiken waar het helemaal niet nodig is. Met een crossbrowser add / remove Event functie en een goed xmlhttprequest object (als je AJAX wilt gebruiken) kom je m.i. een heel eind.

Dit om maar eens tegengas te geven aan alle MooTools fans hier

Mja, dat is het nou juist, ik vind het dus *niet* leuk om dat soort dingetjes als drag&drop en morph effecten zelf opnieuw uit te vinden, net als een goed request object, inclusief alle quirks en opruiming die daar bij hoort. leve de frameworks vind ik dus

[H004]

crisp schreef op woensdag 11 juni 2008 @ 13:01:
[...]

true, de winst die je dan nog extra haalt is dan nog maar minimaal en het levert je ook weer extra problemen op:
- een extra stap in je deployment procedure
- lastiger om accurate foutinformatie te krijgen
- lastiger te debuggen
- risico op problemen veroorzaakt door de compressie/minification (bijvoorbeeld conditional compilation statements die gezien worden als gewone comments)
- afhankelijk van de gebruikte tool moet je ook rekening houden met bepaalde syntax-requirements (altijd verplicht de semi-colon gebruiken of zelfs altijd verplicht braces, dingen als a = i++ + 5 vermijden e.d.)

sommige van deze dingen kan je natuurlijk wel automatiseren of extra debug-mogelijkheden inbouwen waarmee je makkelijk kan switchen naar non-minified sources, maar als je die moeite al neemt dan zou ik eerder kiezen voor een tool die automatisch bepaalde JS (en CSS) bestanden kan samenvoegen zodat je het aantal benodigde HTTP requests voor een pagina kan terugdringen

T ligt een beetje aan de situatie, vind ik. Als je website voornamelijk one-time visitors trekt, is het denk ik verstandiger om Javacript gecomprimeerd (dus ook YUI) te versturen. Heb je daarentegen vrijwel alleen maar terugkerende bezoekers, dan kun je denk ik beter uncompressed Javascript versturen, welke de volgende keren gewoon uit de cache gehaald kan worden.

[Verwijderd]

Wat maakt dat uit?

Het hele punt was dat met de hedendaagse snelheden je maar zo weinig wint door die kb's te besparen dat de overhead van de JS compressie dat weer om zeep helpt.

Daarnaast krijg je zoals crisp al zei andere problemen bij de JS compressie.

Al met al dus goede redenen om het nooit te gebruiken.

Enig moment dat ik kan verzinnen dat het nuttig is is als je het bijvoorbeeld hebt over extreem beperkte bandbreedte situaties, maar dan is de client vaak ook niet super advanced.

Ook kan ik me indenken dat de gzip HTTP level compressie minder efficient kan worden als de JS compressie gebruikt wordt. Dan vertrouw ik liever op de gzip compressie wat op een laag niveau super efficient wordt afgehandeld tegenwoordig.

[ Voor 18% gewijzigd door Verwijderd op 11-06-2008 14:45 ]

[BtM909]

crisp schreef op woensdag 11 juni 2008 @ 12:22:
[...]
Verder zou je je keuze voor een library ook niet moeten laten afhangen op een verschil van enkele milliseconden voor een bepaald soort selector. Dat soort dingen zijn micro-optimalisaties die volledig wegvallen in het grote geheel. Dit soort performance vergelijkingen zijn dan ook niets meer dan wedstrijdjes ver-pissen...

Dit was ook eigenlijk niet de test die ik wilde linken, maar kon de uitgebreide test niet meer vinden op Ajaxian.com.

[Bosmonster]

Bozozo schreef op woensdag 11 juni 2008 @ 10:30:
Ik vind het leuk om mijn eigen scripts te schrijven. Voor basic dingetjes als drag&drop, AJAX en JSON ga ik echt geen framework gebruiken. Morph effecten (volgens mij een van de meest populaire features van MooTools) zijn nou net zo leuk om zelf te coderen.

Ik heb het gevoel dat veel te veel mensen dit soort frameworks / libraries gebruiken waar het helemaal niet nodig is. Met een crossbrowser add / remove Event functie en een goed xmlhttprequest object (als je AJAX wilt gebruiken) kom je m.i. een heel eind.

Dit om maar eens tegengas te geven aan alle MooTools fans hier

Dat is inderdaad soms leuk. Tot dat je erachter komt dat je het wiel telkens opnieuw aan het uitvinden bent (en bugs aan het fixen bent die de frameworks al jaren geintegreerd hebben zitten).

En de baas heeft ook liever dat het af is in een paar uur dan in een paar dagen

[Bozozo]

In principe hoef je het wiel maar een keer opnieuw uit te vinden. Dan heb je een oplossing die waarschijnlijk minder goed is dan de library functie, maar die je volledig begrijpt en die geen framework nodig heeft. De volgende keer heb je die kennis paraat.

Daarnaast zou je, na de heruitvinding van het wiel, eenvoudig kunnen uitbreiden naar four-wheel drive met ABS

[H004]

Bozozo schreef op woensdag 11 juni 2008 @ 15:38:
Daarnaast zou je, na de heruitvinding van het wiel, eenvoudig kunnen uitbreiden naar four-wheel drive met ABS

Maar dan wordt je alsnog ingehaald door een JS-Library met een v12, intercooler, 4 turbo's en 12 inch LCDschermen in de hoofdsteunen, deurpanelen en één verborgen onder de moterkap, voor tijdens het tunen.

[Duroth]

H004 schreef op woensdag 11 juni 2008 @ 16:06:
[...]

Maar dan wordt je alsnog ingehaald door een JS-Library met een v12, intercooler, 4 turbo's en 12 inch LCDschermen in de hoofdsteunen, deurpanelen en één verborgen onder de moterkap, voor tijdens het tunen.

En hoe geweldig zo'n JS wagentje ook is, als je hem niet (of zeer beperkt) kunt besturen, heb je er niks aan

[H004]

Daarom krijg je er ook een slipcursus bij en kun je even naar de pro's kijken, al lijken die momenteel even uit de bocht gevlogen...

[BtM909]

En klaar met de analogieën

[Kiphaas7]

Hier ook een jquery gebruiker, maar daarbij dan ook de disclaimer dat ik jquery gebruik omdat het zo lekker werkt, en niet omdat ik hoogstaande javascripts klop.

[Blue-eagle]

Op mijn werk heb ik Mootools er juist uitgewerkt, en iedereen jQuery laten gebruiken De reden is simpelweg omdat ik de enige ben met veel javascript ervaring en dat jQuery precies doet wat ik verwacht van een library. Niet intrusive, maar wel cross browser compatible, blijvende ontwikkeling, makkelijk componenten voor te schrijven en het werkt lekker samen met onze ontwikkelomgeving (Java met Wicket).

[Quinie]

Nog een mootools fan hiero..
mede omdat het in Joomla gebakken zit

[ Voor 41% gewijzigd door Quinie op 12-06-2008 15:56 ]

[418O2]

Ik ben er sinds 2 dagen ook mee bezig... Vind het wel een tof framework.

Zit alleen al 2 dagen met een probleempje met drag n drop. Ik krijg het niet voorelkaar om een div na een drag bij de drop op de oude locatie te krijgen. Volgens mij ben ik niet de enige, want de Kevin Bacon demo heeft ook last van mijn probleem, de dragable schiet ergens terug, niet op zijn oude plek. Heb de position proberen de definieren in de OnStart, maar dan is die variabele in de andere functies niet beschikbaar, vrij vervelend vooralsnog. Maar dit is wel een toevoeging op weg naar RIA's

[HendrikN]

Kan iemand mij uitleggen wat nou precies de grote verschillen zijn tussen Scriptaculous + Prototype en MooTools?

[remmelt]

In principe kunnen ze allemaal wel hetzelfde. Ze hebben allemaal (YUI, Mootools, jQuery, Dojo, Scriptaculous/Prototype) een ajaxding, ze kunnen allemaal draggen en droppen, faden, each-en, getElementBy-en, etc.

De een kan soms iets wat de ander niet kan, maar dat wordt dan vaak weer rechtgetrokken door een voordeel wat de eerste weer niet heeft. Soms gaan dingen gemakkelijker bij de een dan bij de ander.

Uiteindelijk komt het neer op persoonlijke voorkeur. Voorzichtig kun je stellen dat jQuery meer naar de Ruby-syntax neigt, en de andere twee naar een andere taal, net hoe de bedenker het heeft bedacht. Het is heus niet zo dat de een nou echt met kop en schouders boven de ander uitsteekt. Het is meer dat als een bepaalde programmeertaal je ligt, je makkelijker uit de voeten kan met de syntax en denkwijze van de een, en minder makkelijk met de ander.

Waar je wel op moet letten is dat je mijns inziens de fout ingaat als je meerdere libraries tegelijk gebruikt. Dan kom je echt in een verliessituatie terecht omdat er dan dingen door elkaar gaan lopen en je geheugengebruik van de browser ook omhoog zal gaan. Meerdere objecten/engines instantieren is natuurlijk ook alleen maar tijdverlies. Ik zou dus zeggen, kies het framework waar je het snelst mee uit de voeten kan en blijf daarbij.

[HendrikN]

Na een beetje rondloeren vind ik de documentatie van scriptaculous (en ook prototype) wat uitgebreider dan van MooTools.

Al lijkt dat te komen doordaat MooTools gisteren 1.2 heeft vrijgegeven...

[ Voor 25% gewijzigd door HendrikN op 13-06-2008 14:31 ]

[frickY]

Ik heb nooit een dergelijk javascript framework gebruikt, en was eigenlijk ook neit van plan dat te gaan doen.

Naar mijn idee zit er altijd veel meer in dan je daadwerkelijk nodig hebt. Als je een nieuwe functionaliteit nodig hebt moet je dat er zelf in gaan hacken, en als dan achteraf blijkt dat je niet goed hebt gekeken en het er wal in inzat heb je die moeite helemaal voor niets gednaan.
Naar mijn idee bieden dergelijke frameworks vaak ook features die je helemaal niet moet willen op een website (zoals drag&drop). En mocht je tegen een probleem aanlopen ben je vaak veel langer bezig met debuggen omdat je geen idee hebt waar en hoe iets geimplementeerd is.

Daarnaast natuurlijk ook nog dat ik het als ontwikkelaar het leukst vind zelf te scripten, en niet alles voorgekauwd te krijgen.

Ik begin alleen steeds meer het gevoel te krijgen dat ik alleen sta in die stelling

[ Voor 8% gewijzigd door frickY op 13-06-2008 14:33 ]

[418O2]

Bedrijfsmatig gezien is het leuk om voor webapp's drag en drop te hebben (ben nu bijv. met een planning bezig waarin je activiteiten sleept). En als het tijd scheelt om een framework te gebruiken is een framework wel handig...

[HendrikN]

Voor een deel ben ik het met je eens, maar zodra je gaat beginnen met bv. AJAX-requests ga je al gauw tegen browser incompatibiliteitsprobleempjes aanlopen. Juist daarom vind ik die frameworks zo makkelijk.

Overigens kan drag&drop best terecht op een website, alleen niet te pas en te onpas

[MueR]

Je kan het inderdaad zelf maken omdat er te veel functionaliteit in een framework zit. De tijd die je daaraan kwijt bent is dan je verlies. Daarbij kan je mootools natuurlijk ook in afgeslankte versie krijgen waardoor je de drag&drop bijvoorbeeld niet meeneemt.

[remmelt]

frickY schreef op vrijdag 13 juni 2008 @ 14:32:
Ik heb nooit een dergelijk javascript framework gebruikt, en was eigenlijk ook neit van plan dat te gaan doen.

Ik snap zeker wat je bedoelt. Het is leuk om iets zelf te maken, je leert er van en bent minder afhankelijk van iets wat iemand anders heeft gemaakt. Bovendien is het precies wat je wilt en niets meer of minder. Dit zijn allemaal hele goede argumenten.

Maar goed, op een gegeven moment kwam ik er achter dat ik ontzettend het wiel opnieuw aan het uitvinden was. Na een poosje weet je hoe iets werkt en is de lol er wel af en het leren ook, en dan moet je nog alle kleine kutdingen doen, zoals browsercompatibiliteit en IE6 en kleine bugjes die alleen bij sommige mensen voorkomen en en en.... En toen dacht ik: "Laat ik maar lekker een framework gebruiken." Daarnaast komt nog tijdsdruk, onderhoudbaarheid van je code door andere ontwikkelaars, bizarre klantwensen, etc. En dan is het ineens heel anders en kan je eigenlijk niet om het gebruik van een goed framework heen.

Ik zou eens kijken naar YUI, dat is namelijk echt een framework in plaats van een library zoals de andere gegadigden. YUI is veel meer gemaakt op uitbreidbaarheid. Dat betekent natuurlijk wel dat je er minder snel in komt en sommige dingen moeilijk zijn of veel tijd kosten, maar als bijvoorbeeld scriptaculous iets moet doen wat het net niet kan, ben je veel verder van huis.

[Bosmonster]

frickY schreef op vrijdag 13 juni 2008 @ 14:32:
Ik heb nooit een dergelijk javascript framework gebruikt, en was eigenlijk ook neit van plan dat te gaan doen.

Naar mijn idee zit er altijd veel meer in dan je daadwerkelijk nodig hebt. Als je een nieuwe functionaliteit nodig hebt moet je dat er zelf in gaan hacken, en als dan achteraf blijkt dat je niet goed hebt gekeken en het er wal in inzat heb je die moeite helemaal voor niets gednaan.
Naar mijn idee bieden dergelijke frameworks vaak ook features die je helemaal niet moet willen op een website (zoals drag&drop). En mocht je tegen een probleem aanlopen ben je vaak veel langer bezig met debuggen omdat je geen idee hebt waar en hoe iets geimplementeerd is.

Daarnaast natuurlijk ook nog dat ik het als ontwikkelaar het leukst vind zelf te scripten, en niet alles voorgekauwd te krijgen.

Ik begin alleen steeds meer het gevoel te krijgen dat ik alleen sta in die stelling

Heb je nooit bijvoorbeeld de Google Calendar gebruikt? Drag/drop kan wel degelijk een interessante toevoeging zijn aan webapps. Maar ik ben met je eens dat het ook regelmatig alleen gebruikt wordt 'omdat het kan'.

Wat betreft de libraries. Die geven je juist alleen basisfunctionaliteit. Daar hoef je zelf niks in te hacken. Als je al iets wilt toevoegen, dan kun je natuurlijk, zoals bijvoorbeeld bij JQuery, gewoon je eigen plugin implementeren. Of bij Mootools je eigen class implementeren.

Als je tegen een bug aanloopt, zal het zeer waarschijnlijk liggen in de code geschreven door de developer. Aangezien het framework het meeste ingewikkelde/browsercompatibility werk uit handen neemt is de code vaak erg doorzichtig en makkelijk te begrijpen.

[frickY]

HendrikN schreef op vrijdag 13 juni 2008 @ 14:36:
Voor een deel ben ik het met je eens, maar zodra je gaat beginnen met bv. AJAX-requests ga je al gauw tegen browser incompatibiliteitsprobleempjes aanlopen. Juist daarom vind ik die frameworks zo makkelijk.

Ik heb onlangs op initiatief van een collega XAJAX-moetem gebruiken, maar irriteer me er verschrikkelijk aan. Heb zelf een aantal functies klaar staan welke ik veel sneller geimplementeer krijg.

Heb bij die frameworks, en zeker bij XAJAX, altijd het gevoel dat het getarget is op de mensen die de achterliggende techniek niet snappen, en dus niet in staat zijn zelf een goede oplossing neer te zetten. Vanuit dat gevoel beredeneer ik dan; als je het zelf kan moet je dat doen. Maar wellicht is dat gevoel wel misplaatst.

Drag&drop was wellicht niet het beste voorbeeld. Voor applicaties en intranet kan het een enorme meerwaarde hebben. Maar het was even een breed bekend punt welke de meeste frameworks wel ondersteunen.

Ik zal eens nalezen wat YUI inhoud, nooit eerder van gehoord.

[Bozozo]

SchizoDuckie schreef op dinsdag 10 juni 2008 @ 17:45:
Mootools fan hier check

Mijn laatste meukseltje: http://www.schizofreend.nl/pigwindow/ [src]

Een simpel draggable en sluitbaar window classje die content in kan laden zonder alle IE support meuk (die bij de andere classes er wel in zit) Ik gebruik dit voornamelijk voor backends / CMSen dus ik vind het best als het alleen in A-Grade browsers werkt

Het leuke is aan mootools dat alle standaard meuk gewoon allemaal aanwezig is, drag/drop, je hoeft *eindelijk* niet meer het wiel uit te vinden wat dat betreft

...

Geïnspireerd door jouw PigWindow: Red Hot Window v0.2 (updated)

Het was even klussen (er zit een uur of 6 in) maar dat was wel leuk werk, ik heb wat bijgeleerd (o.a. mouseMove registreren boven iframe, zie een ander topic) én er komt geen library aan te pas. Who needs MooTools

dat die vensters an sich niet zo nuttig zijn is dan weer een heel ander verhaal

[ Voor 0% gewijzigd door Bozozo op 15-06-2008 13:27 . Reden: Nieuwe versie online ]

[remmelt]

Bij beide window-in -browser dingen gebeurt dit:


OSX 10.4, FF 2.0.0.14.

Heb jij zin dat te debuggen? Beter te maken op een systeem wat je misschien niet hebt? Tijd te stoppen in leuke nieuwe features of foutvrij maken voor mensen met IE5?

En dat is waarom we frameworks gebruiken.

[Bozozo]

Goed punt. Ik heb inderdaad geen Mac, dus dat is lastig debuggen.

Aan de andere kant heb je dit probleem net zo goed met andere stukjes script. Je kunt nou eenmaal niet álles uit een framework halen, tenzij je niets bijzonders doet natuurlijk.

Je zou ook kunnen zeggen dat browserfabrikanten wat beter hun best moeten doen met debuggen. Frameworks die 7613 workarounds voor bugs implementeren vertragen dat proces weer.

[SchizoDuckie]

remmelt schreef op zondag 15 juni 2008 @ 13:09:
Bij beide window-in -browser dingen gebeurt dit:
[afbeelding]

OSX 10.4, FF 2.0.0.14.

Heb jij zin dat te debuggen? Beter te maken op een systeem wat je misschien niet hebt? Tijd te stoppen in leuke nieuwe features of foutvrij maken voor mensen met IE5?

En dat is waarom we frameworks gebruiken.

Probeer ff3 eens op de mac, ik heb 'm daarin getest (overigens zonder iframes) en daar werkt het wel. Maar, dan zeg ik er eerlijk bij, ik wil ook die irritante rukscrollbars voorkomen in die venstertjes, vandaar dat ikz e automagisch meesize en er voor kies om de complete document te laten scrollen