Webontwikkelaar bouwt compact jQuery-alternatief
Een webontwikkelaar heeft een sterk verkleinde versie van de jQuery-bibliotheek uitgebracht. De zogenaamde jquip-bibliotheek is aanzienlijk compacter maar bevat toch nog 90 procent van de belangrijkste jQuery-onderdelen.
De jquip-bibliotheek, jquip.js geheten, is na te zijn minified en gecomprimeerd met gzip slechts 4,28KB zwaar, slechts 13 procent van de grootte van het jQuery-framework. Volgens de ontwikkelaar Demis Bellot bevat jquip vrijwel alle belangrijke onderdelen van de populaire jQuery-bibliotheek en kan het gebruikt worden als een drop-in om zo een externe request naar de module over te slaan.
Webontwikkelaars die javascript toepassen en onderdelen van jQuery gebruiken, zouden door jquip toe te passen snelheidswinst kunnen behalen doordat de browser minder code hoeft in te laden. Mocht een ontwikkelaar toch een bepaald onderdeel missen, dan kan via een aantal plugins deze functionaliteit alsnog worden binnengehaald.
De maker claimt ook diverse optimalisaties in de broncode van jQuery te hebben doorgevoerd, maar het verzoekt gebruikers van jquip om mogelijk missende jQuery-onderdelen te melden zodat deze toegevoegd kunnen worden. Daarnaast verwijst hij voor verdere javascript-optimalisaties naar het Ender-project, een pakket dat het mogelijk maakt om eigen javascript-packages te bouwen.
Reacties (110)
Netjes. Ik vind toch dat JQuery iets te veel van het goede is af en toe, en juist omdat het zo makkelijk zie ik dat ik het gebruik voor dingen als $(".hide").hide(); ofzo. En om daar nou een hele library voor in te laden zie ik ook niet echt zitten. Dan komt dit toch heel goed van pas!
Jep, want zo'n 40KB inladen, nee dat trekt de gemiddelde internetverbinding hedendaags niet meer.
My thoughts exactly. Waarom een afgeslankte library maken als het verschil in absolute getallen minimaal is.
Één woord: mobiel
Wat is het probleem? als iedereen netjes naar een CDN versie van bijvoorbeeld google code verwijst gebruikt iedereen ook dezelfde library en kan het voortaan in de cache blijven waar het hoort. http://docs.jquery.com/Downloading_jQuery
CDN's zijn leuk, tot dat deze CDN het niet meer doet of een bepaalde versie het niet meer doet.
Stel dat google om wat voor reden dan ook de stekker er uit moet trekken. Hoeveel website zijn er dat stuk?
Stel dat google om wat voor reden dan ook de stekker er uit moet trekken. Hoeveel website zijn er dat stuk?
Veel, maar de vraag is dat het het heel goed mogelijk is dat de gemaakte snelheids winsts voor de website een groter voordeel heeft als de moeite die het later zou kosten om de code aan te passen. En als je het al helemaal netjes zou willen doen, dan maak je een automated job die het bestand in de CDN eens per x tijd (afhankelijk van de drukte van de site) checkt en ergens een config bestand aan past, maar denk dat dat toch echt overkill is.
Hoe dan ook, persoonlijk ben ik ook met een jquery lite project bezig die dezelfde basis functionaliteiten bevat als jquery, maar niet backward compatible is met oude browsers (voor een html5 app) en dus dingen als document.querySelectorAll() gebruikt enzo en het klinkt mij in de oren dat mogelijk jquip vergelijkbare 'tekortkomingen' heeft en mogelijk dus minder browser support zal hebben en minder uitgebreide selectors (querySelectorAll bijv. support alleen dezelfde css selectors als de browser support). Maja, ik zal er later eens naar kijken, maar ik vermoed dat er toch wel veel van dergelijke issues in zullen zitten die al dan niet problematische gevolgen kunnen hebben afhankelijk van het project, want 1 ding durf ik wel te zeggen, de jquery source code is absoluut niet super ineffecient ofzo dat je het zomaar zoveel korter kan maken.
Hoe dan ook, persoonlijk ben ik ook met een jquery lite project bezig die dezelfde basis functionaliteiten bevat als jquery, maar niet backward compatible is met oude browsers (voor een html5 app) en dus dingen als document.querySelectorAll() gebruikt enzo en het klinkt mij in de oren dat mogelijk jquip vergelijkbare 'tekortkomingen' heeft en mogelijk dus minder browser support zal hebben en minder uitgebreide selectors (querySelectorAll bijv. support alleen dezelfde css selectors als de browser support). Maja, ik zal er later eens naar kijken, maar ik vermoed dat er toch wel veel van dergelijke issues in zullen zitten die al dan niet problematische gevolgen kunnen hebben afhankelijk van het project, want 1 ding durf ik wel te zeggen, de jquery source code is absoluut niet super ineffecient ofzo dat je het zomaar zoveel korter kan maken.
De snelheid kan je ook bereiken door een andere subdomein te gebruiken. Daarmee omzeil je ook het aantal request dat je browser doet naar een domein. Daar heb je dus geen CDN voor nodig.
Daarnaast leuk, een jquery lite, maar krijg je daar door niet een wild groei aan verschillende jquery?
Daarnaast leuk, een jquery lite, maar krijg je daar door niet een wild groei aan verschillende jquery?
Het gebruik van een cdn zoals Google is niet zo zeer om aantal request naar een domein te verminderen. Het grote voordeel is dat een gebruiker waarschijnlijk dat bestand al had gecached omdat ie op een andere site was geweest.
ik gooi er ook iets bij. efficiëntie betekend niet kleinere code maar sneller uitvoerbaar.
redundant code werkt sneller als het achterelkaar staat dan wanneer het 10 keer een functie aanroept (wat wel kleiner is in code). zo zijn er nog een berg effecten die je niet meteen verwacht (zoals *0.5 sneller werkt dan /2)
for(int i=0; i<5; i+=2) {Console.WriteLine("bla"); Console.WriteLine("bla");} werkt sneller dan
for(int i=0; i<10; i++) {Console.WriteLine("bla");} (maar is korter). (efficiëntie zal ook wel per compiler verschillen maar het ging om de size tegen efficiëntie)
echter kom je zo waarschijnlijk niet aan code dat 8 keer in totaal kleiner is Oo. geen backward compatibility kan een mogelijkheid zijn om de size in te korten.
ik noem maar wat, weet er niet genoeg van
edit : dit was @GreatSlovakia
redundant code werkt sneller als het achterelkaar staat dan wanneer het 10 keer een functie aanroept (wat wel kleiner is in code). zo zijn er nog een berg effecten die je niet meteen verwacht (zoals *0.5 sneller werkt dan /2)
for(int i=0; i<5; i+=2) {Console.WriteLine("bla"); Console.WriteLine("bla");} werkt sneller dan
for(int i=0; i<10; i++) {Console.WriteLine("bla");} (maar is korter). (efficiëntie zal ook wel per compiler verschillen maar het ging om de size tegen efficiëntie)
echter kom je zo waarschijnlijk niet aan code dat 8 keer in totaal kleiner is Oo. geen backward compatibility kan een mogelijkheid zijn om de size in te korten.
ik noem maar wat, weet er niet genoeg van
edit : dit was @GreatSlovakia
[Reactie gewijzigd door Madnar op zondag 20 november 2011 23:52]
Maar is dat wel een realistisch idee? Er zijn maar weinig situaties te bedenken waarbij je eigen server stabieler/bereikbaarder is dan die van Google.Stel dat google om wat voor reden dan ook de stekker er uit moet trekken.
Daarnaast zie ik ook niet echt de toepassing van een afgeslankte versie van iets dat al superklein is. Zeker in vergelijking met alle andere assets die een gemiddelde website moet inladen.
Anderzijds klinken "diverse optimalisaties" wel aardig natuurlijk, maar het is wel triest dat je een merkbaar snelheidsverschil zou krijgen bij het inladen van een pagina, ook bij mobiele browsers.
Wat heb ik aan een Google server die online is als mijn eigen server offline( of labiel) is? Dan kan die namelijk ook niks laden van die Google server.Maar is dat wel een realistisch idee? Er zijn maar weinig situaties te bedenken waarbij je eigen server stabieler/bereikbaarder is dan die van Google.
Daarnaast zie ik ook niet echt de toepassing van een afgeslankte versie van iets dat al superklein is. Zeker in vergelijking met alle andere assets die een gemiddelde website moet inladen.
Anderzijds klinken "diverse optimalisaties" wel aardig natuurlijk, maar het is wel triest dat je een merkbaar snelheidsverschil zou krijgen bij het inladen van een pagina, ook bij mobiele browsers.
Uiteraard maakt het wel uit of de versie afgeslankt is, elk bestand dat geladen moet worden is er een teveel en als het dan toch moet wil je die bestanden zo klein mogelijk houden. Dat snelheidsverschil merk je met je mobiel misschien niet als je 3G gedekt zit, maar als je via een EDGE netwerk bestanden moet laden dan ga je dat wel degelijk merken.
De websites van slimme devvers zijn dan helemaal niet stuk. In de HTML5 Boilerplate van Paul Irish hebben ze hier ook al rekening mee gehouden. Als de CDN dan niet wordt gevonden, word automatisch een lokale versie ingeladen.
De snelheidswinst is dan wel weg, maar het is beter dan helemaal geen library.
De snelheidswinst is dan wel weg, maar het is beter dan helemaal geen library.
[Reactie gewijzigd door SpaceK33z op zondag 20 november 2011 17:33]
Snelheidswinst?De snelheidswinst is dan wel weg, maar het is beter dan helemaal geen library.
Wij hosten jquery gewoon zelf aangezien google de zooi juist vertraagde.
De mijne niet, alle externe scripts heb ik op mijn websites ook lokaal staan, zodra het mislukt om jQuery van de CDN te halen, dan haalt hij hetzelfde script van de eigen server af.
En wees nou eerlijk, een foto is gemiddeld al groter dan jquery.
Bovendien, jquip mist precies het punt waarom jQuery zo goed is, jquip mist namelijk elke vorm van xuac, ook mist het een goede documentatie.
En wees nou eerlijk, een foto is gemiddeld al groter dan jquery.
Bovendien, jquip mist precies het punt waarom jQuery zo goed is, jquip mist namelijk elke vorm van xuac, ook mist het een goede documentatie.
Het is een drop-in, dus je hebt geen nieuwe documentatie nodig; je kan die van jQuery gebruiken.
Goede webdevelopers bouwen natuurlijk een fallback naar een lokaal gehoste versie. Dat wordt onder andere gedaan in HTML5 Boilerplate.
http://carlos.bueno.org/2...cript-parse-and-load.html
En qua load performance: blijkbaar maakt het vooral veel uit welke browser je gebruikt:<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.5.1.min.js">\x3C/script>')</script>
http://carlos.bueno.org/2...cript-parse-and-load.html
[Reactie gewijzigd door AndrewF op maandag 21 november 2011 01:36]
Nadeel van deze methode is wel dat je daarmee de browser forceert om eerst jquery te laden en te compileren voordat de browser verder kan/mag met het renderen van de pagina en laden van andere resources. De snelheid van het laden van je site wordt daarmee voor 100% bepaald door de snelheid van Google's CDN. Zoals CyBeR ook al aangeeft is mijn ervaring dat die snelheid niet altijd optimaal is. Zonder deze fallback kun je jQuery gewoon deferred laten laden.
Bij diverse projecten combineer ik jQuery samen met andere script(s) die ik op alle pagina's nodig heb en minify deze tot één allpages.js die ik op alle pagina's inlaad. Met de juiste caching regels op de server laad de bezoeker dit script maar eenmalig in.
Bij diverse projecten combineer ik jQuery samen met andere script(s) die ik op alle pagina's nodig heb en minify deze tot één allpages.js die ik op alle pagina's inlaad. Met de juiste caching regels op de server laad de bezoeker dit script maar eenmalig in.
Welk gevaar denk je dat groter is, dat Google de sterkker eruit moet trekken of dat de developer in kwestie geen zin meer heeft z'n library te onderhouden en jij dat dus zelf mag gaan doen?
Omdat je veelal niet afhankelijk wil zijn van externe code? Ik heb sites best vaak op hun plaat zien gaan omdat de google analytics .js weer eens niet beschikbaar was. Dat is enerzijds slordigheid van de persoon die het bouwt, maar het illustreert wel goed dat je niet afhankelijk wilt zijn van een derde partij voor je eigen website.Wat is het probleem? als iedereen netjes naar een CDN versie van bijvoorbeeld google code verwijst
Daarnaast zit je nog aan wat andere beperkingen vast die je domweg niet wilt.
14,4mbps krijg je lang nooit van je leven.
Je mag al blij zijn als je met 150kbyte download, buiten dat heb je maar 1GB data per maand
Je mag al blij zijn als je met 150kbyte download, buiten dat heb je maar 1GB data per maand
ik haal vrijwel altijd (90% van de lokaties waar ik het meest tijd door breng) altijd 3.6 van de 3.6mbit die me beloofd is
erg frapant , weet uit persoonlijke ervaring van werken bij een grote mobiele partij dat er altijd wel een overhead van 10-15% zit waardoor je nooit de daadwerkelijke max haalt.
14.4 is toch nog flink wat sneller dan 3.6 hoor... Zeker voor cellulair
Ik haal toch regelmatig boven de 12Mbps, dus weet niet waar dit gezwets vandaan komt? Btw.. het gaat om een paar KB.. dus mijn 1.2GB is genoeg.
Waarom wordt ik omlaag gemod eigenlijk? Het is toch zo..
Waarom wordt ik omlaag gemod eigenlijk? Het is toch zo..
En dat heeft iedereen ter wereld ook heh 
Elf woorden: de cache van een mobiel is zo goed als non-existent.
Als jij 3 tabjes open hebt staan, is de cache van de eerste site al geleegd, iig op iphone en android. (bron: http://mobilism.nl/2011/speakers#steve-souders)
Als jij 3 tabjes open hebt staan, is de cache van de eerste site al geleegd, iig op iphone en android. (bron: http://mobilism.nl/2011/speakers#steve-souders)
Ik neem aan dat je op mijn "één woord" reageert? Ik doelde op het gebruik van een zo klein mogelijke library. Dat is goed voor mobiel.
Omdat je als ontwikkelaar dient te streven naar een betere oplossing voor een probleem. Hoe klein die verbetering dan ook mag zijn.
En zo klein is deze verbetering nou ook weer niet, ik zie niet elke dag een library ruim 80% dalen in grootte terwijl het veelal dezelfde functionaliteit biedt.
Goede zaak.
En zo klein is deze verbetering nou ook weer niet, ik zie niet elke dag een library ruim 80% dalen in grootte terwijl het veelal dezelfde functionaliteit biedt.
Goede zaak.
Ik stel me zo voor dat deze library alle bestaande plugins (of minstens veel) breekt. Hoeveel voortgang heb je dan nog. Verbetering, altijd goed. Maar in dit geval, zie ik weinig voordeel.
Op den duur ben je meer tijd kwijt aan het "beter maken" dan dat het daadwerkelijk oplevert, of wring je je in de code in zulke vreemde bochten dat het wel daadwerkelijk kleiner is maar niemand je code meer snapt. Een kleinere oplossing is niet per definitie de betere oplossing als het andere dingen met zich mee brengt als incompatibiliteit.
Op den duur ben je meer tijd kwijt aan het "beter maken" dan dat het daadwerkelijk oplevert, of wring je je in de code in zulke vreemde bochten dat het wel daadwerkelijk kleiner is maar niemand je code meer snapt. Een kleinere oplossing is niet per definitie de betere oplossing als het andere dingen met zich mee brengt als incompatibiliteit.
Voor vrijwel alle projecten waarbij slechts basisfunctionaliteit van JQuery gebruikt wordt die ook geboden wordt door deze gestripte library is deze kleinere oplossing toch wel de betere, dunkt me.
Voor wanneer je extensief gebruik maakt van plugins of andere geavanceerde functies die niet in deze library zitten, is JQuery uiteraard de betere keuze.
En dat is ook precies conform het credo waaronder de ontwikkelaar van deze afgeslankte library het heeft geschreven. Een streven naar een meer modulair gebruik van de functionaliteit die JQuery biedt.
Van de ontwikkelaar zelf:
"Smaller, Lighter, Faster, more modular jQuery - include only the parts you want! Don't use it, Don't include it."
Voor wanneer je extensief gebruik maakt van plugins of andere geavanceerde functies die niet in deze library zitten, is JQuery uiteraard de betere keuze.
En dat is ook precies conform het credo waaronder de ontwikkelaar van deze afgeslankte library het heeft geschreven. Een streven naar een meer modulair gebruik van de functionaliteit die JQuery biedt.
Van de ontwikkelaar zelf:
"Smaller, Lighter, Faster, more modular jQuery - include only the parts you want! Don't use it, Don't include it."
Iedere KB minder is een KB minder. Als je hier en daar de kaasschaaf gebruikt kun je de performance drastisch verbeteren.
40 kilobyte is inderdaad niks voor een client, maar als je server een paar miljoen keer 40 kilobyte moet uitdelen dan loopt het aardig hard op.
Als je miljoen requests krijgt voor jQuery, dan neem ik aan dat je ook wel weet hoe je de jQuery library kunt laten cachen door de client. En mocht je dat niet weten, dan kun je altijd nog het CDN gebruiken van o.a. Google.
Cachen verlicht de boel wel, maar het is niet één client die miljoenen keren opnieuw op site komt. Elke client komt er toch een eerste keer en moet zijn cache vullen. Daarnaast legen sommigen hun cache vaker, of het item verloopt gewoon uit de cache.
Natuurlijk kun je de CDN van Google pakken..... en laat het voor hen nu helemaal goed uitpakken als jQuery veel kleiner kan, zij krijgen immers nog veel meer request.
Natuurlijk kun je de CDN van Google pakken..... en laat het voor hen nu helemaal goed uitpakken als jQuery veel kleiner kan, zij krijgen immers nog veel meer request.
LOL. Dat dacht ik ook net. Natuurlijk, het is een mooie prestatie om ruim 80% verkleining te bewerkstelligen met behoud van 90% van de functies, maar is het nodig tegenwoordig? jQuery zelf is net over de 30 kB. Nou nou... veel sites bevatten al plaatjes van 100+ kB per stuk, om van fotosites nog maar niet te spreken.
Voor de snelheid hoef je het niet te doen. Mijn smartphone heeft tegenwoordig internet dat net zo snel is als hetgeen mijn desktop een jaar of 5 geleden had... en tóen was er al geen probleem met grotere sites.
Voor de snelheid hoef je het niet te doen. Mijn smartphone heeft tegenwoordig internet dat net zo snel is als hetgeen mijn desktop een jaar of 5 geleden had... en tóen was er al geen probleem met grotere sites.
Maar... heeft die ontwikkelaar nu een compleet alternatief geschreven voor jQuery, van de grond af aan, of heeft hij gewoon de grootste c.q. minder gebruikte onderdelen verwijderd en het overblijvende deel gehercomprimeerd?maar het verzoekt gebruikers van jquip om mogelijk missende jQuery-onderdelen te melden
[Reactie gewijzigd door Katsunami op zondag 20 november 2011 15:38]
Zeker weten dat dit een belangrijke verbetering is! Kijk niet naar jezelf als enkele gebruiker die maar 1 keer de library download, maar naar een website-eigenaar die deze library dagelijks misschien een keer of 10.000 laat downloaden.
Het is maar een deel, maar als op deze wijze met alle data omgesprongen wordt gaat dit toch een aanzienlijk stuk schelen in het data- en energieverbuik van dat deel van het internet
Het is maar een deel, maar als op deze wijze met alle data omgesprongen wordt gaat dit toch een aanzienlijk stuk schelen in het data- en energieverbuik van dat deel van het internet
Juist, waarom zouden we uberhaupt nog optimaliseren? Dit is het probleem van de hedendaagse developer IMHO, gebruik maken van logge trage frameworks, waardoor je steeds een snellere computer nodig hebt om hetzelfde te bereiken..
Denk groot.. denk eens aan websites met 1000'en concurrent users? Enig idee hoeveel bandbreedte dit kost die paar KB extra? En dan doel ik nog niet eens op de daadwerkelijke Internet connectie maar ook de hardware erachter die het allemaal aan moet kunnen.
Een stuk minder dan al die plaatjes van honderden kilobytes die op een beetje site staan. Komt nog eens bij dat de jQuery scripts gewoon een statische download zijn die prima te cachen valt.
40 KB is inderdaad niet zoveel. Echter het is niet alleen de code downloaden, deze voert ook weer initialisatiecode uit etc.Jep, want zo'n 40KB inladen, nee dat trekt de gemiddelde internetverbinding hedendaags niet meer.
Wat voor mij als developer echter veel belangrijker is aan een library dan de hoeveelheid code in bytes is de hoeveelheid code in 'surface area' of 'footprint'. Zeg maar de functies en variabelen die na het inladen van de library in het systeem aanwezig zijn. Alle code die zich in de pagina bevindt vormt een potentieel risico. Er kan een bug inzitten bijvoorbeeld. Of een veiligheidslek. Of de code kan een probleem gaan vormen in combinatie met een andere library die gebruikt wordt (compatibiliteitsprobleem).
Code die niet wordt ingeladen veroorzaakt ook gegarandeerd geen problemen. Als je maar 10 procent van een library gebruikt is het mooi als die andere 90 procent gewoon niet wordt geladen. Zeker als je grote applicaties bouwt en meer dan één library gebruikt wordt het belangrijk om hier op te letten.
Ik heb overigens toevallig zelf een project geschreven, Packages JS, dat eenzelfde doel dient. Je kunt packages definieren en daarbij aangeven dat je weer andere packages nodig hebt (dependency management). Ik bied jQuery daarbij in twee delen aan, de selector engine, Sizzle, en jQuery minus Sizzle. Dit was een makkie omdat jQuery en Sizzle al helemaal losstaand zijn in principe, alleen gooit jQuery standaard beide in een file.
Vanaf jQuery 1.7 registreert jQuery zichzelf als een CommonJS asynchronous module definition (AMD).Ik heb overigens toevallig zelf een project geschreven, Packages JS, dat eenzelfde doel dient. Je kunt packages definieren en daarbij aangeven dat je weer andere packages nodig hebt (dependency management).
Hiermee vervalt eigenlijk het nut voor jouw eigen smaak package management. Zoals je het zelf al zegt: het is extra code die een risico vormt ten opzichte van bewezen projecten zoals RequireJS, die zich al aan dit standaard patroon houden.
Het gaat niet alleen om het inladen van 40KB. Feit is dat een externe script-tag (in tegenstelling tot een plaatje) de page rendering compleet blokkeert, en dat de javascript niet alleen opgehaald moet worden, maar ook nog moet worden geparsed en uitgevoerd. Dat laatste kost doorgaans meer tijd dan het inladen zelf, en met een kleinere library haal je daar ook de meeste winst uit.Jep, want zo'n 40KB inladen, nee dat trekt de gemiddelde internetverbinding hedendaags niet meer.
Dat we tegenwoordig meer en meer memory, cpu en bandbreedte hebben, betekend niet dat we daar maar verkwistend mee om moeten gaan. Ik hekel programmeurs die 'dure' shortcuts nemen, omdat het 'toch weinig meer uitmaakt'. En dan later op de blaren zitten omdat die keuze achteraf structureel erg kostbaar bleek te zijn.Jep, want zo'n 40KB inladen, nee dat trekt de gemiddelde internetverbinding hedendaags niet meer.
Doe iets goed, of doe het niet. Maar niet half, en niet op manieren waarvan je kan weten dat ze je achteraf zullen bijten.
Door dat soort mentaliteit hebben we jarenlang opgescheept gezeten met memoryleakende bloatware als Windows en Flash player. Nee dank je feestelijk.
40kB is niet zoveel. Bovendien heb je ook nog je lokale cache. Als je bijvoorbeeld jquery.js van het domein google.com linkt, dan zal je browser deze niet zo heel vaak hoeven laden.
Aan de andere kant: jquery bevat een heleboel functies. Deze moeten niet alleen over de internetverbinding naar de browser toe; ze moeten ook door de JavaScript compiler heen. Dat kan best wat latency toevoegen in je webapplicatie, vooral op mobiele apparaten.
Aan de andere kant: jquery bevat een heleboel functies. Deze moeten niet alleen over de internetverbinding naar de browser toe; ze moeten ook door de JavaScript compiler heen. Dat kan best wat latency toevoegen in je webapplicatie, vooral op mobiele apparaten.
Als je het echt alleen voor zulke simpele dingen gebruikt; dan zou je natuurlijk ook gewoon geen enkele jQuery kunnen gebruiken en plain Javascript kunnen schrijven..
Is absoluut positief voor de performance van je site.
document.getElementById('hide').style.visibility = 'hidden';
(wel een id gebruiken dan en niet een class
)
Is absoluut positief voor de performance van je site.
document.getElementById('hide').style.visibility = 'hidden';
(wel een id gebruiken dan en niet een class
)[Reactie gewijzigd door HyperioN op zondag 20 november 2011 14:56]
Alleen doet visibility: hidden; heel wat anders dan de display: none; die jQuery zet... Nu is die ook vrij makkelijk te zetten in plain Javascript, maar jouw code doet toch echt wat anders dan die van PurpleMadness
Overigens is deze code toch ook al gelijk weer zo'n 40 bytes groter dan de jQuery variant, dus als je deze code zo'n 700 keer opneemt dan is jQuery zelfs kleiner. Voor heel simpele javascriptjes heb je dan wel weer gelijk.
Je kan trouwens ook gewoon jQuery van het CDN van Google oid laden, dan komt hij bij de meeste mensen gewoon uit de cache en maakt het verschil in performance nauwelijks meer wat uit.
Overigens is deze code toch ook al gelijk weer zo'n 40 bytes groter dan de jQuery variant, dus als je deze code zo'n 700 keer opneemt dan is jQuery zelfs kleiner. Voor heel simpele javascriptjes heb je dan wel weer gelijk.
Je kan trouwens ook gewoon jQuery van het CDN van Google oid laden, dan komt hij bij de meeste mensen gewoon uit de cache en maakt het verschil in performance nauwelijks meer wat uit.
Dan maak je er een functie van en roep je die aan. Dan is het weer kleiner.
En het voorbeeld is natuurlijk maar een voorbeeld display: none is natuurlijk ook gemakkelijk met Javascript te doen.
Het ging mij alleen maar om het punt dat, als je jQuery alleen voor heel simpele dingen gebruikt, je beter gewoon Javascript kunt gebruiken...
En het voorbeeld is natuurlijk maar een voorbeeld
display: none is natuurlijk ook gemakkelijk met Javascript te doen.Het ging mij alleen maar om het punt dat, als je jQuery alleen voor heel simpele dingen gebruikt, je beter gewoon Javascript kunt gebruiken...
Als je jQuery alleen voor dat soort basale functionaliteit gebruikt, kun je je natuurlijk afvragen waarom je überhaupt jQuery zou gebruiken. Met de komst van jQuery lijkt het erop dat developers nooitmeer gebruik maken van standaard javascript, waarmee dit soort dingen heel gemakkelijk kunnen. Dus je druk maken over een paar kb die de developer in dit nieuwsitem bespaart, maar wel standaard jQuery includen is een beetje tegenstrijdig..
Goed het was dan misschien niet zo'n goed voorbeeld, maar stel dat ik een animatie wilde gebruiken. Dan was het wel heel wat groter geweest!
Nee, dan zou je gewoon CSS3 hebben kunnen gebruiken :-)
jQuery is niet alleen omdat het makkelijk zelf een whatever.toggleClass() of zoiets uit te voeren maar ook om de crossbrowser compatibiliteit. Zelf even snel javascript schrijven heeft tot gevolg dat je fouten gaat maken.
Als je in jQuery $('#spannetje').text('hoi'); uitvoert weet je zeker dat in alle ondersteunde browser ook dat gebeurd. Als je zelf document.getElementById('spannetje').innerText = 'hoi'; schrijft dan werkt het enkel in Internet Explorer (en Opera). Als ik het me goed herinner spoken oude Safari versies er ook nog iets vreemds mee uit.
Afijn, als je gewoon je site wilt schrijven zonder het in elke browser uitvoerig te testen dan is het gebruik van deze mini-library natuurlijk verrekte handig.
Als je in jQuery $('#spannetje').text('hoi'); uitvoert weet je zeker dat in alle ondersteunde browser ook dat gebeurd. Als je zelf document.getElementById('spannetje').innerText = 'hoi'; schrijft dan werkt het enkel in Internet Explorer (en Opera). Als ik het me goed herinner spoken oude Safari versies er ook nog iets vreemds mee uit.
Afijn, als je gewoon je site wilt schrijven zonder het in elke browser uitvoerig te testen dan is het gebruik van deze mini-library natuurlijk verrekte handig.
jQuery wordt veel gebruikt, en ik denk ook dat de ontwikkeling van een nog kleiner pakket voordelen biedt. Maar google raadt aan om in je code te verwijzen naar de library die zij hosten (zie: http://code.google.com/apis/libraries/devguide.html#jquery) zodat je bij het bezoeken van een andere site niet opnieuw de jquery.js hoeft in te laden omdat deze uit het cache geheugen gehaald kan worden.
Hebben we gedaan, maar toch weer verwijderd. Eigenlijk voornamelijk omdat we Google niet perse de gegevens van onze klanten door willen geven (ook gedaan met Facebook). Dit voornamelijk omdat we zagen dat Google in tests in ene advertenties van concurrenten ging tonen aan potentiële klantendie zij hosten
[Reactie gewijzigd door HerrPino op zondag 20 november 2011 20:53]
Jij hebt een site met ads waarop je klanten werft? Ai...
Oke, en wat heeft hij dan veranderd? Minder workarounds voor bugs in browsers? Of is hij gewoon heeel erg slim en kan ie alles veel beter? Ik mis de inhoud een beetje van dit bericht.
Waarschijnlijk mist er gewoon veel.
10 procent ontbreekt er als ik het bericht mag geloven.De zogenaamde jquip-bibliotheek is aanzienlijk compacter maar bevat toch nog 90 procent van de belangrijkste jQuery-onderdelen.
Plus de compatibiliteit met alle bestaande jQuery plugins waarschijnlijk.
Als die JQuery plugins simpelweg gebruikmaken van die 90% van de bestaande JQuery onderdelen is er geen probleem. Dan zal die compatibiliteit perfect gehandhaafd blijven.
Misschien is er eerder gericht op legacy support, JQuery blijft een hoop deprecated functies ondersteunen in nieuwere versies (ook wel voor compatibiliteit met plugins ed) maar volgens een recente blogposting zijn ze van plan daar nu een paar onderdelen van te gaan strippen.
Wat ik me eerder afvraag is waarom deze developer niet gewoon bij de JQuery developers zelf aanklopt om bepaalde wijzigingen door te laten voeren. Het is een opensource project met ook een forum waar je dingen kan aanbrengen, als hij zoveel verbeteringen kan aanbrengen dan zou het toch ideaal zijn als dit in de JQuery library zelf geïmplementeerd kan worden.
Misschien is er eerder gericht op legacy support, JQuery blijft een hoop deprecated functies ondersteunen in nieuwere versies (ook wel voor compatibiliteit met plugins ed) maar volgens een recente blogposting zijn ze van plan daar nu een paar onderdelen van te gaan strippen.
Wat ik me eerder afvraag is waarom deze developer niet gewoon bij de JQuery developers zelf aanklopt om bepaalde wijzigingen door te laten voeren. Het is een opensource project met ook een forum waar je dingen kan aanbrengen, als hij zoveel verbeteringen kan aanbrengen dan zou het toch ideaal zijn als dit in de JQuery library zelf geïmplementeerd kan worden.
Concurrentie is altijd goed...
In plaats dat een select groepje mensen besluit wat wij allen nodig hebben en wat niet, kunnen mensen nu zelf beslissen. Als vervolgens blijkt dat er veel vraag is naar deze oplossing, dan zullen de makers van JQuery dat zeker ten harte nemen en soortgelijke beslissingen gaan nemen.
We weten allemaal dat het de komst van Google Chrome was, dat een race in gang zette naar snellere javascript verwerking in ALLE browsers. En dat heeft vervolgens weer de weg vrijgemaakt naar nieuwe technieken om webpagina's te bouwen.
Dit is mijn ook voornaamste redenen dat ik zeer sterk tegen patenten ben, het beperkt de mogelijkheid tot concurrentie via incrementele verbetering.
In plaats dat een select groepje mensen besluit wat wij allen nodig hebben en wat niet, kunnen mensen nu zelf beslissen. Als vervolgens blijkt dat er veel vraag is naar deze oplossing, dan zullen de makers van JQuery dat zeker ten harte nemen en soortgelijke beslissingen gaan nemen.
We weten allemaal dat het de komst van Google Chrome was, dat een race in gang zette naar snellere javascript verwerking in ALLE browsers. En dat heeft vervolgens weer de weg vrijgemaakt naar nieuwe technieken om webpagina's te bouwen.
Dit is mijn ook voornaamste redenen dat ik zeer sterk tegen patenten ben, het beperkt de mogelijkheid tot concurrentie via incrementele verbetering.
'bepaalde wijzigingen' is een behoorlijke understatement voor het comprimeren van 90% van de code...Wat ik me eerder afvraag is waarom deze developer niet gewoon bij de JQuery developers zelf aanklopt om bepaalde wijzigingen door te laten voeren.
Nu kan Jquery het toch ook overnemen?
Het is een enorm pluspunt als een browser minder code hoeft te laden om het doel te bereiken... Dat is wat er staat en wat de "minified" versie van jQuery doet. Voor webontwikkelaar is dit een leuke toevoeging, omdat je hiermee dus snellere applicaties kan bouwen voor zowel desktops als mobiele apparaten.
Niet webontwikkelaars zullen dit waarschijnlijk niet goed begrijpen.
Niet webontwikkelaars zullen dit waarschijnlijk niet goed begrijpen.
De vraag is ook: welke 10% ontbreekt? Is dat 10% van de hooks? hoe heeft hij dat gemeten? Want hoe kan hij over 10% spreken zonder zelf te weten wat er precies mis (hij vraagt om te melden wat er mist) en nog belangrijker: is dat niet toevallig net het deel dat het meest gebruikt wordt?
Ten eerste weet een jQuery ontwikkelaar wat het meest gebruikt wordt en ten tweede mist 10% van de functies die in de orginele library wel zitten.
Assumption is the mother of all f#...
Natuurlijk weet een jQuery ontwikkelaar dat niet. Sommige denken het kennelijk te weten. Meten is weten, aannames zijn de moeder van alle problemen. Kent "een jQuery ontwikkelaar" alle andere ontwikkelaars en wat zij met jQuery doen?
Natuurlijk weet een jQuery ontwikkelaar dat niet. Sommige denken het kennelijk te weten. Meten is weten, aannames zijn de moeder van alle problemen. Kent "een jQuery ontwikkelaar" alle andere ontwikkelaars en wat zij met jQuery doen?
Volgens de GitHub readme:
"Parts of jQuery that aren't ported over (because of code size) throw a "not implemented exception". At the moment this only gets thrown for complex filters that filter on more than a tagName."
Oftewel; de oude softwarematige Sizzle implementatie is er uit geschopt of in elk geval sterk versimpeld. Niet zo slim als je na gaat dat jQuery deze in toch nog een behoorlijk aantal gevallen aanspreekt. (Bijv. als je een XML of SVG DOM wilt manipuleren.)
Verder:
"Events passed to your event handers are the 'real' browser DOM events."
Oftewel; de complete event normalization van jQuery is er ook uitgesloopt. Dat verklaart dan ook gelijk waarom $.fn.delegate niet in de lijst ondersteunde features terug te vinden is. Je mag dus met de hand alle eigenaardigheden met je event objecten op gaan lossen. (Events die wel/niet bubblen per browser, browsers die event.currentTarget niet goed instellen, etc.)
En ook nog:
"val - does not do checkbox, select, etc."
Oftwel; je mag alle cross-browser issues met checkbox values en select values ook met de hand oplossen.
"Parts of jQuery that aren't ported over (because of code size) throw a "not implemented exception". At the moment this only gets thrown for complex filters that filter on more than a tagName."
Oftewel; de oude softwarematige Sizzle implementatie is er uit geschopt of in elk geval sterk versimpeld. Niet zo slim als je na gaat dat jQuery deze in toch nog een behoorlijk aantal gevallen aanspreekt. (Bijv. als je een XML of SVG DOM wilt manipuleren.)
Verder:
"Events passed to your event handers are the 'real' browser DOM events."
Oftewel; de complete event normalization van jQuery is er ook uitgesloopt. Dat verklaart dan ook gelijk waarom $.fn.delegate niet in de lijst ondersteunde features terug te vinden is. Je mag dus met de hand alle eigenaardigheden met je event objecten op gaan lossen. (Events die wel/niet bubblen per browser, browsers die event.currentTarget niet goed instellen, etc.)
En ook nog:
"val - does not do checkbox, select, etc."
Oftwel; je mag alle cross-browser issues met checkbox values en select values ook met de hand oplossen.
[Reactie gewijzigd door R4gnax op zondag 20 november 2011 22:04]
Bedankt; precies mijn punt: het weglaten van de ene functie heeft consequenties voor de functionaliteit van de andere; het feit dat 10% ontbreekt zegt dus duidelijk niet dat deze oplossing 90% bruikbaar is.
Netjes! Ga het snel uitproberen!
Tja, hoewel ik als webdevver er alles voor over heb om elke kb te besparen vind ik dit wel een beetje teveel van het goede. Allereerst heeft bijna iedereen jquery in zijn of haar cache staan. Via CDN (welke maakt niet veel uit) maak je handig gebruik van die cache en heeft iedereen en alles de volledige functionaliteit tot zijn beschikking. Neemt niet weg dat het initiatief leuk is
Als je 85% aan code kan reduceren, dan kan het niet anders dan dat de code ook sneller word uitgevoerd. Gezien z'n uitleg op github is dom traversal op IE <7, 7 tot 8x sneller, kan geen kwaad, want dat kan best een trage boel zijn.
Maar goed, aan de andere kant hij heeft een deel aan "core" elementen in die zipped 4KB gestopt en additionele zaken worden op hun beurt weer plugins. Echt heel veel winnen doen we hier niet en eigenlijk omslachtig als je een keer ajax nodig hebt (wat een aparte plugin is).
Maar goed, aan de andere kant hij heeft een deel aan "core" elementen in die zipped 4KB gestopt en additionele zaken worden op hun beurt weer plugins. Echt heel veel winnen doen we hier niet en eigenlijk omslachtig als je een keer ajax nodig hebt (wat een aparte plugin is).
Als er een dikke lap code zoals hieronder staat wordt het er natuurlijk niet sneller op.
if( IE )
{
//Use this logic because IE is rediciously slow doing the standard js code
}
else
{
//standard code.
}
Ken de jQuery code niet dus ik zeg niet dat het hier het geval is maar je
if( IE )
{
//Use this logic because IE is rediciously slow doing the standard js code
}
else
{
//standard code.
}
Ken de jQuery code niet dus ik zeg niet dat het hier het geval is maar je
is te makkelijk gesteld.Als je 85% aan code kan reduceren, dan kan het niet anders dan dat de code ook sneller word uitgevoerd
Dan nog moet de browser die cache interpreteren en door de code heen stampen die je met de functies aanroept. Met "eenvoudigere" code hoeft je browser minder te doen en dus sneller. Het is misschien geen denderende toevoeging maar toch leuk.
Prutser?
Heb je zijn blog wel eens gelezen? Er zijn heel wat Tweakers die de goede man zouden mogen benijden, zowel qua intellect als qua baan.
Ik denk dat iedere versnelling en verkleining op dit niveau welkom is, als je ziet hoe vaak zulke bibliotheken gedownload worden (zelfs al wordt er gecached). Aangezien je invloed kunt uitoefenen op de ontwikkeling, raad ik je aan hem te helpen in plaats van op hem af te geven. Dat maakt zijn project vast een stuk minder 'kansloos'.
Heb je zijn blog wel eens gelezen? Er zijn heel wat Tweakers die de goede man zouden mogen benijden, zowel qua intellect als qua baan.
Ik denk dat iedere versnelling en verkleining op dit niveau welkom is, als je ziet hoe vaak zulke bibliotheken gedownload worden (zelfs al wordt er gecached). Aangezien je invloed kunt uitoefenen op de ontwikkeling, raad ik je aan hem te helpen in plaats van op hem af te geven. Dat maakt zijn project vast een stuk minder 'kansloos'.
Er zijn tientallen klonen van jQuery die allemaal dit doel dragen, en na enkele weken zijn ze allemaal vergeten. Ook deze zal tot die groep gaan horen. Waarom? Omdat jQuery meer is dan enkel de code. jQuery heeft momentum: meer dan 50% van de top 10,000 websites gebruikt jQuery. Het grote aanbod aan plugins, ondersteuning bij problemen, een actieve communitie, innoverende concepten en natuurlijk de uitgebreide test-suites waarmee iedere release getest wordt onderscheidt het project, en anno 2011 zijn deze voor grotere websites belangrijker dan een paar kilobyte aan bestandsgrootte, helemaal als je een CDN gebruikt. Als jij, als bedrijf of particulier, veel geld en/of tijd investeerd in het maken van een website, dan wil je zeker weten dat de externe componenten die je gebruikt goed werken. jQuery kan dit garanderen, jquip niet.
Als de functies die aanwezig zijn in jQuip doen wat ze moeten doen dan is snelheid het tweede waar je naar kijkt.
Ben het hier met Fjerpje eens, ik weet niet precies wat jij als klonen ziet. Libraries die hetzelfde proberen te doen maar toch anders zijn? (Denk bijvoorbeeld aan mootools)
Ik zou dat geen klonen noemen, dit is de eerste waar ik van zie dat het een drop-in replacement zou kunnen zijn. In dat geval kan deze best momentum winnen, vooral als die 10% code is die niet veel (door plugins) wordt gebruikt.
Ik zou dat geen klonen noemen, dit is de eerste waar ik van zie dat het een drop-in replacement zou kunnen zijn. In dat geval kan deze best momentum winnen, vooral als die 10% code is die niet veel (door plugins) wordt gebruikt.
Ik laat dit ook even voorbij schieten. Zoals eerder aangegeven ben ik het er ook mee eens dat deze enkele kb's die bespaard worden bijna nihil zijn en dus verwaarloosd kunnen worden. Bovendien als er goed gebruik wordt gemaakt van een bekende CDN zoals die van Google of van andere cache mogelijkheden zullen de 40kb van jQuery je site echt niet merkbaar langzamer laten laden.
De enige mensen die dit zouden kunnen merken zijn oude mobieltjes die nog niet allemaal weten wat ze aan moeten met downloads en de cache. Maar vrijwel elk modern mobieltje maakt ook goed gebruik van alle beschikbare resources en zelfs meet een slechte 3g of wifi verbinding zou het downloaden dus eenmaal langer duren. Persoonlijk maak ik voor een moebieltje ook liever een aparte interface die gebruik maakt van een van de "mobiele" javascript libraries zoals jQuery Touch of jQuery Mobile (overigens ook nog 24kb).
Omdat de library op dit moment maar 90% van de library ondersteund wegen de voordelen dus totaal nog niet af tegen de nadelen, en daarmee bedoel ik natuurlijk het missen van alle bestaande plug-ins, wat voor veel mensen ook de voornamelijkste reden zijn voor het gebruik van jQuery.
Maar hoe dan ook wens ik de ontwikkelaar veel succes met de ontwikkeling.
De enige mensen die dit zouden kunnen merken zijn oude mobieltjes die nog niet allemaal weten wat ze aan moeten met downloads en de cache. Maar vrijwel elk modern mobieltje maakt ook goed gebruik van alle beschikbare resources en zelfs meet een slechte 3g of wifi verbinding zou het downloaden dus eenmaal langer duren. Persoonlijk maak ik voor een moebieltje ook liever een aparte interface die gebruik maakt van een van de "mobiele" javascript libraries zoals jQuery Touch of jQuery Mobile (overigens ook nog 24kb).
Omdat de library op dit moment maar 90% van de library ondersteund wegen de voordelen dus totaal nog niet af tegen de nadelen, en daarmee bedoel ik natuurlijk het missen van alle bestaande plug-ins, wat voor veel mensen ook de voornamelijkste reden zijn voor het gebruik van jQuery.
Maar hoe dan ook wens ik de ontwikkelaar veel succes met de ontwikkeling.
De core van dit nieuwe framework is inderdaad erg klein, maar veel functies die volgens mij nogal veel gebruikt worden (in ieder geval door mij) moeten met een plugin worden ingeladen. Dan heb ik het bijvoorbeeld over Ajax functionaliteit en de document.ready callback. Dat maakt de vergelijking voor mij wel iets anders.
Verder klopt het natuurlijk dat jQuery veel meer momentum heeft, maar interessant vind ik dat de maker ook zegt dat dit een impuls voor het jQuery ontwikkelteam moet zijn om de core kleiner te maken.
Iets waar ze bij jQuery zelf ook van overtuigt zijn aldus een recente blogpost van de ontwikkelaars van jQuery zelf. Hierin kondigen ze aan weinig gebruikte en verouderde functies uit te gaan faseren.
Verder klopt het natuurlijk dat jQuery veel meer momentum heeft, maar interessant vind ik dat de maker ook zegt dat dit een impuls voor het jQuery ontwikkelteam moet zijn om de core kleiner te maken.
Iets waar ze bij jQuery zelf ook van overtuigt zijn aldus een recente blogpost van de ontwikkelaars van jQuery zelf. Hierin kondigen ze aan weinig gebruikte en verouderde functies uit te gaan faseren.
[Reactie gewijzigd door Mac_Cain13 op zondag 20 november 2011 15:24]
Jammer dat de developer in kwestie niet gewoon is gaan samenwerken met het bestaande jQuery team om zijn optimalisaties via de originele core toe te voegen. Op die manier hoeft hij ook niet telkens als jQuery update zijn libs te updaten.
Als er echt zoveel te optimaliseren is aan de jQuery library dan had de beste man gewoon zijn bevindingen moeten delen met het team. Er zijn al zoveel jQuery clones, bovendien wordt jQuery via allerhande CDN's aangeboden.
Het is z'n goedrecht om de source te clonen, het is tenslotte Open Source. Ik had alleen in het geval van optimalisaties liever gezien dat zijn optimalisaties weer upstream terug te mergen waren naar het originele jQuery project.
Als er echt zoveel te optimaliseren is aan de jQuery library dan had de beste man gewoon zijn bevindingen moeten delen met het team. Er zijn al zoveel jQuery clones, bovendien wordt jQuery via allerhande CDN's aangeboden.
Het is z'n goedrecht om de source te clonen, het is tenslotte Open Source. Ik had alleen in het geval van optimalisaties liever gezien dat zijn optimalisaties weer upstream terug te mergen waren naar het originele jQuery project.
Ik kan me ook wel redenen bedenken om niet met het jQuery team samen te gaan werken.
Het is een beetje een kip-ei verhaal, maar als je (voor) ergens werkt, dien je natuurlijk wel te werken volgens het stramien dat daar geldt.
Zo zal het ook zijn bij het jQuery team. "We werken op deze manier en volgens deze structuur".
Er dan buitenom een minified versie van te maken omdat je het er niet helemaal mee eens bent, is ook een keuze. Een keuze voor in ieder geval ongedwongen te kunnen werken.
Aan de andere kant is het natuurlijk zo, dat met samenwerken, je een boel extra expertise van het team hebt waar je hulp bij kunt zoeken indien nodig. Of vragen waarom er bepaalde keuzes zijn gemaakt.
Het is een beetje een kip-ei verhaal, maar als je (voor) ergens werkt, dien je natuurlijk wel te werken volgens het stramien dat daar geldt.
Zo zal het ook zijn bij het jQuery team. "We werken op deze manier en volgens deze structuur".
Er dan buitenom een minified versie van te maken omdat je het er niet helemaal mee eens bent, is ook een keuze. Een keuze voor in ieder geval ongedwongen te kunnen werken.
Aan de andere kant is het natuurlijk zo, dat met samenwerken, je een boel extra expertise van het team hebt waar je hulp bij kunt zoeken indien nodig. Of vragen waarom er bepaalde keuzes zijn gemaakt.
Gaat waarschijnlijk ook gewoon gebeuren, je kan het ook als een proof of concept of een prototype zien. Wat echt efficiënter in elkaar zit zal zijn weg wel vinden naar jQuery.
gezien het zelf ook een een open source project is, staat niets de jQuery ontwikkelaars in de weg om de aangepaste code alsnog te integreren (als het de moeite waard zou blijken te zijn)
Heel leuk zo'n verkleinde versie van jQuery, maar ik krijg een beetje dit idee.
Op dit item kan niet meer gereageerd worden.
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
