Javascript, welk framework?

[kevinkrs]

Beste tweakers,

Ik heb me eens zitten te oriënteren op het internet, en nu vraag ik jullie mening.

Ik wil mijn website wat meer uitrusten met ajax, dat heeft natuurlijk voordelen dat er bijvoorbeeld pas een request wordt gedaan wanneer een gebruiker ergens op klikt of wilt. Dus dit kan aardig wat onnodige dataverkeer en processorkracht besparen.

Het liefst had ik zelf helemaal geen platform maargoed aangezien ik niet de ajax request in een function kan zetten (dus oproepen met: ajax_GET(url, blaat, normeer) is het denk ik maar niet anders.

Ik weet dus zelf niet wat beter zou zijn, op een of andere manier ajax request methods in een function zetten of een framework gebruiken.

Ik heb gekeken welke frameworken er zijn, jQuery, Prototype.
Waarvan Prototype me wat beter lijkt dan jQuery.

Dat denken jullie wat ik zou moeten doen?

Gewoon zelf ajax zonder framework gebruiken.

Of met framework?

Met vriendelijke groet, Kevin.

[b2vjfvj75gjx7]

ajax_GET(url, blaat, normeer) kan best- als je alles zelf programmeert

Ik werk regelmatig met Ajax en schrijf alle scripts zelf; daar komt geen framework aan te pas, behalve de mijne dan...

Het kost wat meer tijd om uit te zoeken, maar je dringt dan wel door tot de essentie van Ajax, scripting en bv. een PHP-parser die een Javascript aanstuurt welke vervolgens via Ajax de content van je site weer update...

Voordeel is ook dat je veel minder bloated-scripts krijgt, waarin 100 functies zitten, terwijl je er maar 1 gebruikt. Als ik naar mijn eigen Ajax-parsers kijk, zijn ze vaak maar 5 regels groot... en daarmee heb ik de vollédige Ajax-functionalteit van een website gevangen...

[ Voor 25% gewijzigd door b2vjfvj75gjx7 op 27-07-2010 22:58 ]

[kevinkrs]

b2vjfvj75gjx7 schreef op dinsdag 27 juli 2010 @ 22:56:
ajax_GET(url, blaat, normeer) kan best- als je alles zelf programmeert

Ik werk regelmatig met Ajax en schrijf alle scripts zelf; daar komt geen framework aan te pas, behalve de mijne dan...

Het kost wat meer tijd om uit te zoeken, maar je dringt dan wel door tot de essentie van Ajax, scripting en bv. een PHP-parser die een Javascript aanstuurt welke vervolgens via Ajax de content van je site weer update...

Voordeel is ook dat je veel minder bloated-scripts krijgt, waarin 100 functies zitten, terwijl je er maar 1 gebruikt. Als ik naar mijn eigen Ajax-parsers kijk, zijn ze vaak maar 5 regels groot... en daarmee heb ik de vollédige Ajax-functionalteit van een website gevangen...

Ja hier ben ik het wel met je eens ik had namelijk het zelfde gedachte.
Maar hoe kan je dan zo'n ajax function maken?

Ik heb wel met z'n heeeel lap tekst voor elkaar gekregen maar ik wil gewoon een request kunnen doen in 1 regel ipv eerst de request aanvragen dan controleren of de http status op 200 staat enzovoorts.

In een function is mij dus nog niet gelukt..

[CH4OS]

Ik weet niet wat je zoal middels AJAX wil doen en waarom, maar jQuery UI is ook een mooi framework...

[kevinkrs]

CptChaos schreef op dinsdag 27 juli 2010 @ 23:09:
Ik weet niet wat je zoal middels AJAX wil doen en waarom, maar jQuery UI is ook een mooi framework...

Eigenlijk grootdeels pages request, bijna niks meer. De rest doe ik eigenlijk met normaal javascript.

[NMe]

kevinkrs schreef op dinsdag 27 juli 2010 @ 23:08:
[...]

Ja hier ben ik het wel met je eens ik had namelijk het zelfde gedachte.
Maar hoe kan je dan zo'n ajax function maken?

Ik heb wel met z'n heeeel lap tekst voor elkaar gekregen maar ik wil gewoon een request kunnen doen in 1 regel ipv eerst de request aanvragen dan controleren of de http status op 200 staat enzovoorts.

In een function is mij dus nog niet gelukt..

Tuurlijk niet. Want je zal sowieso altijd een eigen onSuccess-functie moeten schrijven en die kan alleen asynchroon aangeroepen worden. Je zit dus minimaal naar 2 functies te kijken waarbij je mogelijk de event-handlerfunctie doorgeeft aan de andere generieke functie, zodat je per AJAX request een eigen onSuccess kan hebben.

Maar goed, als je dit soort dingen niet voor jezelf kan verzinnen dan doe je er goed aan je eerst eens wat beter in te lezen. Als je het dan begrijpt kun je het mogelijk zelf implementeren, maar zo niet, dan kun je veel beter naar een Mootools of jQuery kijken, zodat je in elk geval alvast de cross-browserproblemen uit de weg gaat.

En I hate to break it to you, maar die "check voor status 200" zal je altijd in enige mate nodig hebben. In plaats van het te mijden zou je er veel beter aan doen om te begrijpen hoe het werkt en waarom het nodig is.

kevinkrs schreef op dinsdag 27 juli 2010 @ 23:12:
[...]

Eigenlijk grootdeels pages request, bijna niks meer. De rest doe ik eigenlijk met normaal javascript.

Grapjas. AJAX gaat per definitie om requests. Probeer eens uit te leggen wat je precies met je AJAX-code wil bereiken.

[ Voor 11% gewijzigd door NMe op 27-07-2010 23:18 ]

[Copyman]

Als het je puur om AJAX-functionaliteit gaat, zou ik zelf gewoon wat schrijven. Mocht je toch voor een simpele oplossing willen gaan, kijk dan eens naar microAjax (src).

[kevinkrs]

Tuurlijk zou je die check voor status 200 nodig hebben.
Maar dat is volgens mij gewoon mogelijk om in een function te zetten.
Zodat je niet als je 2x een ajax event gebruikt dat je 2x die checker bijvoorbeeld hebt.

Ja dat kan je ook omzijlen dat weet ik maar liever in een function(makkelijk aanpasbaar is een voordeel namelijk) of anders een framework.

Hoewel het beter zou zijn om een function te gebruiken aangezien ik geen 500 functies uit een framework gebruik

[NMe]

kevinkrs schreef op dinsdag 27 juli 2010 @ 23:22:
Tuurlijk zou je die check voor status 200 nodig hebben.
Maar dat is volgens mij gewoon mogelijk om in een function te zetten.
Zodat je niet als je 2x een ajax event gebruikt dat je 2x die checker bijvoorbeeld hebt.

Ja dat kan je ook omzijlen dat weet ik maar liever in een function(makkelijk aanpasbaar is een voordeel namelijk) of anders een framework.

Hoewel het beter zou zijn om een function te gebruiken aangezien ik geen 500 functies uit een framework gebruik

Nogmaals, je zal minimaal een specifieke handlerfunctie moeten maken voor elk specifiek AJAX-request. En dat mag best een anonieme inline functie zijn die je in je functiecall gebruikt maar je hebt hem sowieso nodig.

[kevinkrs]

NMe schreef op dinsdag 27 juli 2010 @ 23:26:
[...]

Nogmaals, je zal minimaal een specifieke handlerfunctie moeten maken voor elk specifiek AJAX-request. En dat mag best een anonieme inline functie zijn die je in je functiecall gebruikt maar je hebt hem sowieso nodig.

Klopt helemaal, maar het staat beetje lelijk als je dat (bijvoorbeeld) 10 keer in je code/script hebt staan.
En daar vind ik een script ook onoverzichtelijk van worden

[Bosmonster]

Als je toch met ajax(-achtige) dingen bezig bent is het wel prettig een framework tot je beschikking te hebben. Uiteindelijk wil je namelijk ook je resultaat in de pagina verwerken via het DOM, misschien wel met een effect. Je wilt events koppelen, misschien wel via event delegation.

Uiteindelijk heb je natuurlijk veel meer nodig dan alleen die ene call die wat data ophaalt. Een framework zorgt ervoor dat je de volledige interactie en manipulatie op een eenduidige, eenvoudige en xbrowser manier kunt implementeren.

[ Voor 15% gewijzigd door Bosmonster op 28-07-2010 00:53 ]

[NMe]

kevinkrs schreef op dinsdag 27 juli 2010 @ 23:29:
[...]

Klopt helemaal, maar het staat beetje lelijk als je dat (bijvoorbeeld) 10 keer in je code/script hebt staan.
En daar vind ik een script ook onoverzichtelijk van worden

Als je vindt dat je code van losse functies en/of anonieme functies onoverzichtelijk wordt kun je maar beter wegblijven bij Javascript. En je kan het lelijk vinden zoveel als je wil, je gaat 't toch nodig hebben.

[wackmaniac]

b2vjfvj75gjx7 schreef op dinsdag 27 juli 2010 @ 22:56:

...

Voordeel is ook dat je veel minder bloated-scripts krijgt, waarin 100 functies zitten, terwijl je er maar 1 gebruikt. Als ik naar mijn eigen Ajax-parsers kijk, zijn ze vaak maar 5 regels groot... en daarmee heb ik de vollédige Ajax-functionalteit van een website gevangen...

Maar als je dan een framework als jQuery of Prototype gebruikt zijn de scripts zelf doorgaans ook een stuk minder bloated, omdat je geen rekening hoeft te houden met cross-browser incompatibilities. En dat bloated valt reze mee; zowel jQuery als Prototype (als MooTools etc) zijn via de Google-API geminified op te halen en zijn dan minder dan 100k. Dat is al minder dan een gemiddelde afbeelding, dus ik vind het een beetje een non-argument. Ik bouw zelf nooit meer iets zonder Prototype, maar jQuery of MooTools is net zo goed. Ik zou zeggen; kies er een en knallen!

[Anoniem: 111703]

Ik gebruik nu Dojo Toolkit en ik ben er zeer over te spreken. Een XHR is bijvoorbeeld met een heel klein stukje code te schrijven:

JavaScript:

dojo.xhrPost({url:'/mijn/server/', postData:'var1=bla&var2=bla2', load:mycallback});

function mycallback(transport)
{
  //Doe iets met de transport
}

Dojo Toolkit is widget-based, waarbij er alleen code wordt gedownload en uitgevoerd die je nodig hebt. Je hoeft enkel de base code (dojo.js) te includen in je header om ervoor te zorgen dat je Dojo Toolkit in gebruik kunt nemen.
Een zeer groot voordeel van Dojo Toolkit, is dat er ook heel veel handige utility methods (zoals die ook in Prototype te vinden zijn) in verwerkt zijn, bijvoorbeeld dojo.foreach(). Een voorbeeld:

JavaScript:

var array = [5, 6, 1, 9, 10]; //Een array met random integers

for (var i = 0; i < array.length; i++)
{
  myfunction(array[i]);
}

//Bovenstaande regels doen hetzelfde als:

dojo.foreach(array, myfunction);

function myfunction(val)
{
  //Doe iets
}

Ook bevat Dojo Toolkit bibliotheken voor animaties, charts en is 100% gratis en vrij te gebruiken in commerciële projecten.

[Cartman!]

Ik werk al jaren met MooTools, nooit meer gekeken naar iets anders ter vergelijking ook als ik eerlijk ben. Het doet goed wat het moet doen en ook crossbrowser. Het handige is dat je met de builder een custom MooTools kunt maken die alleen de functionaliteit bevat die je nodig hebt. YUI-compressed neemt het dan dusdanig weinig in dat ik al die moeite die anderen al voor me gedaan hebben niet opnieuw ga doen. Ik hou me liever bezig met het maken van het product zelf ipv. het achterliggende framework, 9/10 keer is dat zonde van je tijd omdat zij er meer tijd/resources voor hebben om het beter te doen dan jijzelf.

En ook even dezelfde functionaliteit als m'n bovenbuurman in dojo heeft vermeld:

JavaScript:

var myRequest = new Request({url: 'getData.php', method: 'get', onSuccess: function(responseText, responseXML) {
    alert(responseText);
}});


var myArray = [5, 6, 1, 9, 10];
myArray.each(test);

function test(val)
{
    //Doe iets
}

Kwestie van smaak vooral denk ik...

[ Voor 24% gewijzigd door Cartman! op 28-07-2010 14:48 ]

[Bosmonster]

Ooit begonnen met Mootools, maar dat beviel met niet zo goed. Teveel namespace/prototype vervuiling en te complexe en vaak onlogische api. Verder gekeken naar Prototype en jQuery. Prototype was nog erger dan Mootools in dit opzicht. Uiteindelijk was jQuery voor mij een schot in de roos. Minste code benodigd (snelste in te ontwikkelen dus), minste vervuiling (geen feitelijk) en verreweg de eenvoudigste api. jQuery heeft ook de meest actieve ontwikkelcyclus.

Uiteindelijk doen ze allemaal hetzelfde, het is maar net wat je zelf het prettigste vindt werken dus.

[ Voor 18% gewijzigd door Bosmonster op 28-07-2010 14:50 ]

[Wolfboy]

Bosmonster schreef op woensdag 28 juli 2010 @ 14:48:
Ooit begonnen met Mootools, maar dat beviel met niet zo goed. Teveel namespace/prototype vervuiling en te complexe en vaak onlogische api. Verder gekeken naar Prototype en jQuery. Prototype was nog erger dan Mootools in dit opzicht. Uiteindelijk was jQuery voor mij een schot in de roos. Minste code benodigd (snelste in te ontwikkelen dus), minste vervuiling (geen feitelijk) en verreweg de eenvoudigste api. jQuery heeft ook de meest actieve ontwikkelcyclus.

Uiteindelijk doen ze allemaal hetzelfde, het is maar net wat je zelf het prettigste vindt werken dus.

Mee eens. Voor mij ongeveer hetzelfde eigenlijk.

Bij jQuery gaat het updaten van een bepaald element met de content van een url zo simpel als dit:

JavaScript:

$('#jouw_html_element').load('/url/met/content/');

[R4gnax]

Wolfboy schreef op woensdag 28 juli 2010 @ 18:52:
[...]
Mee eens. Voor mij ongeveer hetzelfde eigenlijk.

Bij jQuery gaat het updaten van een bepaald element met de content van een url zo simpel als dit:

JavaScript:

$('#jouw_html_element').load('/url/met/content/');

Met een paar kleine kant tekeningen waar je je wel van bewust van moet zijn, dat wel.

[Cartman!]

Zoals wat voor kanttekeningen (zonder spatie) dan ? Je maakt me nieuwsgierig

[R4gnax]

Cartman! schreef op woensdag 28 juli 2010 @ 19:46:
Zoals wat voor kanttekeningen (zonder spatie) dan ? Je maakt me nieuwsgierig

Script tags worden onherroepelijk gestripped met behulp van een veel te simpele regex. Dat kan knap lastig zijn als je van script islands gebruik maakt om configuratie voor bijv. jQuery UI widgets inline mee te serveren.

Verder mag je niet klakkeloos een volledige normale html pagina inladen. Je moet ervoor zorgen dat ongeldige elementen als html, head en body gestript worden.

Er is een mechanisme om een jQuery selector direct op te nemen in de URL die je aan 'load' meegeeft als parameter, maar dat is niet in alle gevallen zaligmakend. Een voor de hand liggende selector zoals "body > *" werkt bijvoorbeeld niet altijd goed. Vermoedelijk is dit omdat body elementen door sommige browsers al automatisch gestript worden: de toe te voegen html wordt via een omweg tijdelijk aan de body v/h hoofd document ge-append, nog voor de selector gedraaid wordt, waarna een browser 'intelligent' kan gaan proberen een valide HTML document te behouden (en dus automatisch de geneste body node weg gooien).

[ Voor 7% gewijzigd door R4gnax op 28-07-2010 20:54 ]

[Wolfboy]

Uiteraard R4gnax, ik ga er alleen vanuit dat als je dat soort dingen aan het doen bent dat je dan ook vrij eenvoudig om de problemen heen kunt werken

Voor simpel gebruik is het afdoende iig.

[Bosmonster]

Uiteindelijk is load ook maar een wrappertje om de originele ajax-functionaliteit. Leuk als je eenvoudig een tellertje of stukje tekst wilt updaten, maar over het algemeen wil je geen stukken html ophalen.

[Wolfboy]

Wat is een framework anders dan een wrapper? Uiteindelijk zijn het allemaal wrappers om een lagere API

Maargoed, zoals met elk framework, je zal altijd wat werk zelf moeten doen.

[Rekcor]

b2vjfvj75gjx7 schreef op dinsdag 27 juli 2010 @ 22:56:
Ik werk regelmatig met Ajax en schrijf alle scripts zelf; daar komt geen framework aan te pas, behalve de mijne dan...

Het kost wat meer tijd om uit te zoeken, maar je dringt dan wel door tot de essentie

Dit argument contra frameworks heb ik nooit zo begrepen. Waarom zou ik door moeten dringen tot de essentie? Als ik in mijn auto rij, hoef ik ook niet precies te weten wat er allemaal gebeurt. Maakt dat mij tot een slechtere automobilist?

Een vriend van mij wilde wel de essentie van zijn auto kennen. Maar die reed dan ook in een 2CV .

[Sebazzz]

Wolfboy schreef op woensdag 28 juli 2010 @ 23:05:
Wat is een framework anders dan een wrapper? Uiteindelijk zijn het allemaal wrappers om een lagere API

Het doel van een framework is niet om een wrapper te zijn, het doel van een framework is o.a om vaakgebruikte functionaliteit of taken makkelijker mogelijk te maken.

[Wolfboy]

Sebazzz schreef op donderdag 29 juli 2010 @ 08:56:
[...]

Het doel van een framework is niet om een wrapper te zijn, het doel van een framework is o.a om vaakgebruikte functionaliteit of taken makkelijker mogelijk te maken.

Kijk je definitie van wrapper eens na. Dat is namelijk 1 van de redenen om een wrapper te maken.

[quote]Wikipedia: Wrapper library

Wrapper libraries (or library wrappers) consist of a thin layer of code which translates a library's existing interface into a compatible interface. This is done for several reasons:

• To refine a poorly designed or complicated interface.
• Allow code to work together which otherwise cannot (e.g. Incompatible data formats).
• Enable cross language and/or runtime interoperability.

[Anoniem: 111703]

De vraag is alleen, wil je een wrapper library (dat is een library op een library) gebruiken voor een taal als javascript.

[Wolfboy]

Vooral voor het "Enable cross language and/or runtime interoperability." gedeelte is een framework imho al onmisbaar. Het verschil in event afhandeling tussen de browsers bijvoorbeeld is iets wat je niet opnieuw wil uitvinden.

Dingen als ajax kan je nog wel fixen met een simpel wrapper functietje in plaats van een hele wrapper library. Maar je komt al snel op het punt dat het niet gebruiken van een wrapper library meer werk is dan dat het moeite waard is alles zelf te schrijven.

[kevinkrs]

Ik heb al eens met jQuery gewerkt, ik heb ook het gevoel dat jQuery de makkelijkste te begrijpen is vergeleken met de rest of ik kan het fout hebben

[Bosmonster]

Verschil is dat de frameworks gedeeltelijk wrapper-werk verrichten, maar ook heel veel functionaliteit toevoegen.

Een JS-framework een wrapper noemen is dus erg kort door de bocht.

[kwaakvaak_v2]

zoals met elk framework is iets deels wrapper en deels extra functionaliteit. Die wrappers zijn gewoon nodig om simpele dingen als parameter en method naming consistentie af te dwingen. Daar is geen ontkomen aan, of je krijgt van die houtje-touwtje oplossingen dat het bijvoorbeeld soms method(needle,haystack), dan weer othermethod(haystack,needle) is.

Elk framework kent daardoor dus overhead, de vraag is alleen kun je leven met die overhead als het er voor kan zorgen dat je gewoon sneller en consistenter kunt ontwikkelen, en mijn antwoord daarop is volmondig JA..

Welk framework, dat mag iemand zelf beslissen, zelf vind ik jQuery erg prettig werken. Maar ik heb laatst ook met een scheef oog gekeken naar sencha touch wat weer gebaseerd is op extJS. Omdat dit door dezelfde maker als jQtouch gemaakt wordt die sinds hij in dienst is getreden bij sencha logisch gewijs meer tijd daar aan kan besteden.

[StephanVierkant]

kevinkrs schreef op donderdag 29 juli 2010 @ 13:25:
Ik heb al eens met jQuery gewerkt, ik heb ook het gevoel dat jQuery de makkelijkste te begrijpen is vergeleken met de rest of ik kan het fout hebben

Ik werk er al een tijdje mee en met veel plezier (zie voor de gein eens DataTables). Het is erg gemakkelijk in gebruik en er zijn erg veel plugins. Haal je zoekterm + jQuery door Google en je verbaast je elke keer weer hoeveel leuke plugins er zijn.

Overigens kan ik je jQuery UI afraden voor gebruik op websites: die is over het algemeen net even te zwaar. Elke demo die op hun site staat, kent een lichter (en vaak beter) alternatief. Ik heb het wel gebruikt voor een intranetje (10 gebruikers), maar ik zou het afraden voor het groter publiek.

Mocht je echt alleen die ajax-requests doen, moet je je afvragen of er geen lichter alternatief is (MicroAjax werd al even genoemd). Zelf schrijven raad ik je af vanwege de ruime keuzemogelijkheden die er al zijn (tenzij je natuurlijk wilt hobby'en in een niet-productie-omgeving, daar is niets mis mee ;-))

En ten aanzien van het argument over de 'overhead': het zou best kunnen dat de overhead van een framework minder erg is dan de inefficiënte code die de individuele programmeur zelf bouwt.

[ Voor 7% gewijzigd door StephanVierkant op 29-07-2010 14:21 . Reden: toevoeging overhead ]

[Bosmonster]

jQuery UI zou ik ook afraden. Niet zozeer doordat het te zwaar is, want dat valt wel mee, maar de controls zijn vaak buggy, niet accessible en niet geoptimaliseerd voor touch (op iPhone/iPad kun je er vaak niks mee).

De enige die ik bruikbaar vind is de datepicker ongeveer.

Het is jammer dat dit vaak gezien wordt als "officiele jQuery-controls", want dat zijn ze dus eigenlijk niet waardig. Hoop dat er ooit een betere developer mee aan de slag gaat.

[ Voor 31% gewijzigd door Bosmonster op 29-07-2010 15:30 ]

[Wolfboy]

Bosmonster schreef op donderdag 29 juli 2010 @ 13:46:
Verschil is dat de frameworks gedeeltelijk wrapper-werk verrichten, maar ook heel veel functionaliteit toevoegen.

Een JS-framework een wrapper noemen is dus erg kort door de bocht.

Dat is simpelweg semantiek. Maar als je een andere naam prefereert, ook prima

kwaakvaak_v2 schreef op donderdag 29 juli 2010 @ 14:03:
Welk framework, dat mag iemand zelf beslissen, zelf vind ik jQuery erg prettig werken. Maar ik heb laatst ook met een scheef oog gekeken naar sencha touch wat weer gebaseerd is op extJS. Omdat dit door dezelfde maker als jQtouch gemaakt wordt die sinds hij in dienst is getreden bij sencha logisch gewijs meer tijd daar aan kan besteden.

ExtJS is prachtig kwa widgets en dergelijke. Maar gelijk ook wel heel erg bloated, leuk voor een admin scherm maar voor de frontend van een site veel te heavy naar mijn mening

[pieturp]

Wolfboy schreef op donderdag 29 juli 2010 @ 18:20:
[...]
ExtJS is prachtig kwa widgets en dergelijke. Maar gelijk ook wel heel erg bloated, leuk voor een admin scherm maar voor de frontend van een site veel te heavy naar mijn mening

Zeker waar als je alle widgets 'nodig' hebt. Je kunt gelukkig ook een build maken met alleen de widgets die je wilt. Maar kijk ook eens naar Ext Core; een stuk eenvoudiger en simplistischer

[Wolfboy]

Dat klopt, maar zelfs de basis widgets zijn al zeer zwaar. De opbouw van ExtJS widgets in de DOM is gewoon heel erg zwaar en geeft een merkbare performance drain op je systeem.

De pagina reageert gewoon direct trager als je een trage browser/computer hebt. Dat hoeft natuurlijk geen probleem voor je te zijn, maar het hangt wel van je doel af. Ik zou het in ieder geval nooit voor een frontend inzetten.

[kwaakvaak_v2]

ik heb met sencha touch lopen spelen op mijn iPhone 3G met ios4 en iPad en ik kan nu niet echt zeggen dat ik het idee had dat het zwaar was. Maar misschien liggen onze definities van zwaar op een andere schaa
verdeling

[Bosmonster]

Wolfboy schreef op donderdag 29 juli 2010 @ 18:20:
[...]
Dat is simpelweg semantiek. Maar als je een andere naam prefereert, ook prima

Dat heeft niks met semantiek te maken, maar met functionaliteit. Maar als jij een framework of library graag een wrapper wil noemen, ook prima

Wat betreft ExtJS, dat is ook geen library zoals jQuery, Mootools, etc. ExtJS is een compleet framework (of wrapper voor Wolfboy..) voor het ontwikkelen van webapplicaties. Niet bedoeld voor losse site-onderdeeltjes. Sproutcore is ook zoiets, al wel iets eenvoudiger.

@kwaakvaak: Sencha Touch gaan vergelijken met ExtJS is ook krom. Misschien is het een developer van ExtJS, misschien is de core er op gebaseerd, het is een compleet ander framework, geoptimaliseerd voor mobile (en touch dus, zoals de naam al doet vermoeden )

[ Voor 23% gewijzigd door Bosmonster op 29-07-2010 23:56 ]

[pieturp]

ExtJS is redelijk zwaar, maar draait op zich wel soepel. Zelfs in IE6. Dat laatste vind ik IMNSHO wel een prestatie.

Ext Core draait overigens overal wel snel en heeft (logischerwijs) dezelfde syntax. Waar ik af en toe met jQuery een beetje het PHP gevoel heb (Wat is ook weer de argument-volgorde van deze functie?), heb ik bij Ext eigenlijk altijd een helder idee. (Dat is gewoon bijna altijd een object met +/- dezelfde config opties.)

Daarentegen "voelt" jQuery vaak wel weer minder bloated door de 'slimme' $-notatie...

[kwaakvaak_v2]

Bosmonster schreef op donderdag 29 juli 2010 @ 23:52:
[...]


@kwaakvaak: Sencha Touch gaan vergelijken met ExtJS is ook krom. Misschien is het een developer van ExtJS, misschien is de core er op gebaseerd, het is een compleet ander framework, geoptimaliseerd voor mobile (en touch dus, zoals de naam al doet vermoeden )

Niet helemaal goed

Ext JS + jQTouch + Raphaël = Sencha

Zoals ik het hier lees hebben ze al die frameworks, plugins etc op 1 hoop geveegd en daar sencha uit op getrokken en als onderliggend framework van hun producten gebruiken ze extJS. Uiteraard is Touch geoptimiliseerd voor mobile gebruik, wat het lichter maakt omdat je met een aantal browser dinosauriers als IE6 geen rekening meer hoeft te houden. Maar als ik de Documentatie zo eens lees is het toch behoorlijk wat extJS wat de klok slaat

[R4gnax]

Stephan4kant schreef op donderdag 29 juli 2010 @ 14:19:
Overigens kan ik je jQuery UI afraden voor gebruik op websites: die is over het algemeen net even te zwaar. Elke demo die op hun site staat, kent een lichter (en vaak beter) alternatief. Ik heb het wel gebruikt voor een intranetje (10 gebruikers), maar ik zou het afraden voor het groter publiek.

Zoals eerder gezegd: het zware valt wel mee, zeker wanneer je een eigen bundle samenstelt met alleen die widgets die je nodig hebt. Alleen de bugs en lakende touch ondersteuning zijn minder fijn. Persoonlijk vind ik de $.widget() factory in jQuery UI dan wèl weer een grote voortuitgang op de gemiddelde jQuery plugin. En ook de wijze waarmee je met transitie effecten werkt is veel flexibeler.

[b2vjfvj75gjx7]

Rekcor schreef op donderdag 29 juli 2010 @ 08:52:

Waarom zou ik door moeten dringen tot de essentie? Als ik in mijn auto rij, hoef ik ook niet precies te weten wat er allemaal gebeurt. Maakt dat mij tot een slechtere automobilist?

Hangt er denk ik van af of je jezelf ziet als bestuurder van de auto [automobilist] of als onderhoudsmonteur [mecanicien] van de scripts waar je mee werkt.

En als er iets mis gaat, of als je net iets harder wilt rijden dan de fabrieksspecificaties, dan is het wel handig als je weet wat een bougie doet, bijvoorbeeld [als die al in een auto zitten, ik heb geen verstand van!].

[dominic]

Het nadeel van de meeste libraries is dat ze voor iedere ajax-request een concurrent connectie opzetten. Veelal wordt de filosofie van het queuen van requests over het hoofd gezien, waardoor requests door gebrek aan een beschikbare connectie wel eens verloren gaan.

Ik geef zelf de voorkeur aan het zelf schrijven van de ajax request handler om zo meer controle te hebben over het proces.

Een typische flow van een single-connection ajax handler bouw ik meestal zo;
1. Is connectie bezet of bezig? Zo ja, delay request (timeout) totdat connectie vrij gemarkeerd is.
2. Maak request en markeer connectie als bezig.
3. Wacht op response en markeer connectie als vrij.

Voorwaarde voor gebruik van deze methode is dat je wel alle parameters voor een request moet opslaan in de queue wil je een request kunnen delayen. In je generieke response handler zul je deze parameters weer uit moeten lezen om te weten wat de originele request was en wat je dus met de response moet doen.

Op deze wijze wordt er altijd maar één connectie gebruikt voor de complete ajax-afhandeling en komt iedere request gegarandeerd door.

[ Voor 14% gewijzigd door dominic op 31-07-2010 10:52 ]

[Juup]

@dominic:

Dat was vroeger in Firefox<3 enzo een probleem, nu al lang niet meer.

[dominic]

Juup schreef op zaterdag 31 juli 2010 @ 11:26:
@dominic:

Dat was vroeger in Firefox<3 enzo een probleem, nu al lang niet meer.

FireFox is niet de enige browser in de wereld en ik zou een dergelijke uitspraak niet zonder onderbouwing doen.

Het is nog steeds een probleem; aantal concurrent connecties dat beschikbaar is, is nog steeds gelimiteerd.

IE7: 4 connecties, 2 in worst-case
IE8: 6 connecties, 2 in worst-case
Safari: 4 connecties, 2 in worst-case
FireFox: ongelimiteerd maar instelbaar, max 6 per domein, dus 2 of 1 in worst-case
Opera: ongelimiteerd maar instelbaar, max 6 per domein, dus 2 of 1 in worst-case
Chrome: 6 connecties, 2 in worst-case

[ Voor 6% gewijzigd door dominic op 31-07-2010 11:39 ]

[Juup]

Ik bedoelde te zeggen dat het ALLEEN in firefox een problem was.

Dat er maar n concurrent connecties open kunnen zijn is geen probleem, je mag best 100 XMLHttpRequests openen, deze worden dan na elkaar afgehandeld.

Welke huidige browser dropt volgens jou connecties als er teveel worden open gezet?

[Bosmonster]

Daarnaast gaan de moderne libraries hier echt wel goed mee om en niet beter dan wat je zelf schrijft.

[R4gnax]

Bosmonster schreef op woensdag 04 augustus 2010 @ 11:01:
Daarnaast gaan de moderne libraries hier echt wel goed mee om en niet beter dan wat je zelf schrijft.

Wat dan weer wel een voordeel van een handgeschreven queue mechanisme is, is de mogelijkheid om prioritieitsniveau's te introduceren en de mogelijkheid het moment waarop en de volgorde waarin callbacks afgehandeld worden te beïnvloeden.

(Past trouwens netjes bovenop de reeds bestaande callback structuur in jQuery. Zelf ooit al eens geschreven.)

[ Voor 10% gewijzigd door R4gnax op 04-08-2010 20:43 ]