Software-update: jQuery 2.0

Voor het vereenvoudigen van client-side-scripting in html kun je gebruikmaken van jQuery. Dit is een opensource-JavaScript-library, waarvan de syntax het makkelijker maakt om door documenten te navigeren, DOM-elementen te selecteren, animaties in elkaar te zetten, events af te handelen en natuurlijk Ajax-applicaties te ontwikkelen. Daarnaast kan de functionaliteit worden uitgebreid door plug-ins te gebruiken. Voor meer informatie verwijzen we naar deze pagina. De ontwikkelaars hebben versie 2.0 de deur uitgedaan, voorzien van de volgende aankondiging:

jQuery 2.0 Released

You asked for it, you got it: jQuery 2.0 has arrived!

As promised, this version leaves behind the older Internet Explorer 6, 7, and 8 browsers. In return it is smaller, faster, and can be used in JavaScript environments where the code needed for old-IE compatibility often causes problems of its own. But don’t worry, the jQuery team still supports the 1.x branch which does run on IE 6/7/8. You can (and should) continue to use jQuery 1.9 (and the upcoming 1.10) on web sites that need to accommodate older browsers.

How to Use It

jQuery 2.0 is intended for the modern web; we’ve got jQuery 1.x to handle older browsers and fully expect to support it for several more years. If you want, you can serve 2.0 to newer browsers and 1.9 to older ones using our conditional comment trick, but that is not required. The simplest way to support older browsers is to use jQuery 1.x on your site, since it works for all browsers.

With the release of jQuery 2.0, there are a few environments where the jQuery team will no longer support use of the 1.x line because 2.x is a far better choice. These are typically non-web-site scenarios where support for older IE isn’t relevant. They include:

• Google Chrome add-ons
• Mozilla XUL apps and Firefox extensions
• Firefox OS apps
• Chrome OS apps
• Windows 8 Store (“Modern/Metro UI”) apps
• BlackBerry 10 WebWorks apps
• PhoneGap/Cordova apps
• Apple UIWebView class
• Microsoft WebBrowser control
• node.js (combined with jsdom or similar)

Many of these environments are themselves a work in progress, and have unique sets of rules or restrictions that are different from the ones typically found when jQuery is used for browsers on Internet web sites. Although we aren’t able to test regularly in all of these non-browser scenarios, we’d like to hear about your experiences in using jQuery with them. Even better, we’d love for the communities supporting these environments to pool and share their knowledge about how to use jQuery 2.0 there.

How 2.0 Changed

Here are some highlights of the changes that jQuery 2.0 brings:

No more support for IE 6/7/8: Remember that this can also affect IE9 and even IE10 if they are used in their “Compatibility View” modes that emulate older versions. To prevent these newer IE versions from slipping back into prehistoric modes, we suggest you always use an X-UA-Compatible tag or HTTP header. If you can use the HTTP header it is slightly better for performance because it avoids a potential browser parser restart.

Reduced size: The final 2.0.0 file is 12 percent smaller than the 1.9.1 file, thanks to the elimination of patches that were only needed for IE 6, 7, and 8. We had hoped to remove even more code and increase performance, but older Android/WebKit 2.x browsers are now the weakest link. We’re carefully watching Android 2.x market share to determine when we can cross it off the support list, and don’t expect it to take very long.

Custom builds for even smaller files: This feature has been greatly refined and extended since its debut in jQuery 1.8. You can now exclude combinations of 12 different modules to create a custom version that is even smaller. A new minimal selector engine, basically a thin wrapper around the browser’s querySelectorAll API, lets you shrink the build to less than 10KB when minified and gzipped. See the README for instructions on how to create a custom build, and remember that any plugins you use will also need to stick to the subset you select.

jQuery 1.9 API equivalence: jQuery 2.0 is API-compatible with 1.9, which means that all of the changes documented in the jQuery 1.9 Upgrade Guide have been applied to jQuery 2.0 as well. If you haven’t yet upgraded to jQuery 1.9, you may want to try that first. Be sure to use the jQuery Migrate plugin.

The full record of changes can be found in the changelog below, and in the list of commits on GitHub.

What’s Next

In keeping with our pledge to minimize API divergence between the 1.x and 2.x branches, we’ll be releasing a jQuery 1.10 within a couple of months that incorporates the bug fixes and differences reported from both the 1.9 and 2.0 beta cycles. In the future, we will be maintaining feature parity between 1.10 and 2.0, 1.11 and 2.1, etc. Patch releases will happen in each branch on their own schedule, based on team resources and severity of any reported bugs.

Please do try this new release with all your web sites and HTML apps. If you find problems, create a minimal test case (preferably using a site like jsFiddle or jsbin) and submit it to our bug tracker. We’re particularly interested in situations where jQuery 1.9.1 behaves differently than jQuery 2.0.0, since that’s something we’ve tried to avoid.

jQuery 2.0.0 Changelog

Ajax

• #12838: domManip script evaluation implementations with alternate signatures
• #13276: In IE 9/10 $.parseXML() returning document object instead of XMLDOMDocument
• #13292: $.ajax with 1.9.0 doesn’t call anymore success function in case of 204
• #13306: File input added to serialized forms caused a change in behavior and only halfway follows spec
• #13388: Ajax request not returning responseXML

Attributes

• #12072: Remove Firefox deprecated nodeValue, getAttributeNode, specified

Build

• #12656: Make event shorthands an excludable module
• #13316: Check against jquery.min.js with TestSwarm
• #13335: “use strict”; break asp.net ajax postacks in FF
• #13741: Make wrap*/unwrap methods an optional module
• #13744: Move jQuery.fn.size() to deprecated
• #13755: Update .jshintrc to match style guide
• #13759: Better undefined gzip compression
• #13760: getComputedStyle no longer works in node with jsdom
• #13776: License comment is breaking the SourceMap

Core

• #13356: Consistently clean up after .ready() handler

Css

• #13310: hide() and fadein() corrupt the css display value

Deferred

• #13150: Be able to determine if $.Callback() has functions

Effects

• #12846: overflow:hidden is not removed when .stop() is called
• #13183: Wrong animation initial value calculation (1.9.0rc1)
• #13483: Issue with stop(true).slideDown() during slideUp()

Event

• #13360: Creating String.prototype.namespace can cause an exception in jQuery.Event
• #11570: Move element cache to the element[expando] to avoid cleanup and reduce code.
• #13143: e.target can be a text node on mousewheel
• #13554: Move [un]bind & [un]delegate to event-alias

Manipulation

• #13232: In 2.0beta1, using html() function on a tbody selector yields insertion of new tbody
• #13233: Unexpected behavior when iterating over and manipulating detached nodes in jquery 1.9
• #13282: QtWebKit — TypeError: ‘[object Object]‘ is not a valid argument for ‘Function.prototype.apply’ (evaluating ‘elem.nodeType’)
• #13596: .replaceWith should always remove the context set
• #13721: remove(“:nth-child(1)”) works differently than filter(“:nth-child(1)”).remove()
• #13722: .replaceWith argument handling is inconsistent with other manipulation methods
• #13779: .remove() changed in beta3 – now remove nodes in reverse doc order

Selector

• #13434: Create querySelectorAll/matchesSelector selector option
• #13331: jQuery.fn.add returns incorrect order in Chrome and Safari
• #13378: ie8 & ie9 iframe – .filter(“:focus”) – document.activeElement returns unspecified error.
• #13420: jQuery 1.9.1 fails to filter SVG parent nodes by class name when using .parent() and .closest()
• #13499: Descendant selector fails when searched ID doesn’t exists but NAME does (IE7 only)
• #13505: jquery#add: seems to get items in collection out of order on larger lists

Support

• #10814: make support as lazy as possible with closure in mind
• #12040: Test against Content Security Policy (CSP)
• #13089: support adds zoom style to body in Chrome/Safari
• #13743: Remove jQuery.support.boxModel

Traversing

• #13265: parent method fails with text nodes in IE10
• #13332: .closest(“*”) yields input even for non-element nodes
• #13349: find function slower since 1.9.0, especially in chrome

Versienummer	2.0
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	jQuery
Download	http://docs.jquery.com/Downloading_jQuery
Licentietype	GPL

Reacties (44)

Je kan dus gewoon ook jQuery 1.9 én jQuery 2.0 gebruiken door dit te doen:

<!--[if lt IE 9]>
<script src="jquery-1.9.1.js"></script>
<![endif]-->
<!--[if gte IE 9]><!-->
<script src="jquery-2.0.0b2.js"></script>
<!--<![endif]-->

Hoeveel zin heeft het om deze constructie te gebruiken?
Dit zou dus betekenen dat je dit voor bijna iedere javascript file zou moeten doen ivm functies die wel in de ene en niet in de andere versie van jQuery zit..

Het is leuk dat het kan, maar het levert misschien wel wat problemen op.

Daarnaast is het alleen maar goed dat we de oude browsers niet langer meer gaan ondersteunen...

En straks krijg je nog een if blok voor android 2.x en later weer een andere. Het voelt alsof ik weer terug ben in 1997 toen ik zowel voor MSIE als Netscape aparte websites moest maken..

en uiteindelijk krijs je een SSI bestand om de if/else include boom te onderhouden. Want als Jquery twee versie heeft, dan krijg je ook een tweedeling in Jquery-UI en JQuery-Mobile.

Het was beter geweest als 2.0 modulair was gemaakt en dan op basis van de user agent besluit welke modules ingeladen moeten worden voor de juiste support.

Daarbij is alleen 2.0 API compatibel met 1.9, er is niets gezegd over de comptabiliteit van toekomstige versies. Met Windows 8 komt touchscreen ook naar de desktop. En als je veranderingen in zowel de 1.9 branch moet maken als de 2.x branch, dan had je net zo goed een enkele branch kunnen behouden..

Totdat de twee versies scheef gaan lopen. En dat gaan ze.

Op dat moment is het hebben van twee verschillende jQuery's niets beter dan het gezever dat je zonder dat met IE zou hebben.

Misschien handig om te vermelden is het toepassen van de jQuery Migrate plugin om te testen of je over kunt: https://github.com/jquery/jquery-migrate/#readme

En voor het blijven ondersteunen van IE6,7 en 8 kun je natuurlijk jQuery 1.9.1 gebruiken met een soortgelijke conditional statement zoals hier is beschreven: http://blog.jquery.com/20...uery-2-0-beta-2-released/

Ik vraag me zelf wel af of je die nog wilt blijven ondersteunen, maar voor sommige sites is het wel handig denk ik.

Verder vind ik de stap wel erg raar, maar juich het wel toe dat men steeds meer aanmoedigt om hun browser te updaten.

In ieder geval ben ik blij dat ze eindelijk weer een grote mijlpaal hebben bereikt. Hopelijk volgen de andere plugins ook snel. Wat ik me nog wel afvraag is of ze nog wat gedaan hebben aan het feit dat de community vaak pushed op het gebruiken van meerdere plugins. Iets wat ik zelf liever niet heb want het maakt je site trager met laden en uitvoeren van acties. Nog naast het feit dat sommigen niet lekker naast elkaar draaien.

Hebben ze niets van touch events ofzo erin gestoken? Bijvoorbeeld drag and drop op mobile devices was leuk geweest.

http://jquerymobile.com/ ?

Dat is precies wat ik zeg. Zoals op de site van jquery mobile staat:
jQuery Mobile 1.3.0 supports jQuery 1.7.0 to 1.9.1

Het is een aanvullende library voor jquery met allerlei elementen voor mobiele apparaten.

Ik vind het slim van ze dat ze dit niet allemaal proppen in jQuery.

Ik ben zelf sinds kort begonnen met PhoneGap om iets te ontwikkelen in IOS en Android en begon met de logische keuze van Jquery Mobile, maar dit geeft een enorme overhead aan design, css en beinvloeden van je HTML. Uiteindelijk heb ik besloten JQM achter me te laten en Jquery en wat andere libs te gebruiken met een veel lichtere HTML/CSS voor een vrijwel zelfder resultaat. JQM gaat nog veel dieper dan Jquery-UI die zich al erg diep wroet in je html .

Jquery leent zich enorm voor multiplatform (de voornaamste reden natuurlijk om het te gebruiken) en dan zouden touch events logischerwijs zijn weg hierin moeten kunnen hebben vinden. Als je oude browser support eruit haalt omdat het achterhaald is zou je zelf moeten inoveren richting nieuwere steeds populairdere platformen/devices zou je zeggen.

[Reactie gewijzigd door ultimasnake op 22 april 2013 12:32]

Ben erg beniewd welke "andere libs" je hebt gebruikt.
Het idee achter JQM is erg mooi, maar de performance is inderdaad nog een beetje treurig af en toe.

Zolang je niet teveel in de dom gaat inladen en met animaties gaat werken, gaat het prima. Animaties worden nog niet echt lekker berekend (mede ook door de verplichte support voor oude devices) en als je veel pagina's inlaad heb je daar ook wel wat snelheidsverlies.

Dat is weer afhankelijk per platform per versie. Ik vind het beter dat dit er niet in zit.

Ik ontwikkel veel voor mobiele websites en daarvoor is jQuery 2.0 natuurlijk ideaal: IE8 en minder zal je op een mobiel device niet tegen komen en de 12% kleinere download is op een mobiele website erg welkom

De jquery files hoeven zelden gedownload te worden omdat deze normaal gezien niet van de website maar vanaf een standaard content delivery network (CDN) komen komen en daarom dan al lang gecached zijn. De downloadsize is dus nauwelijk van belang voor internetters omdat ze slechts zelden een jquery file hoeven te downloaden.

Hier bijvoorbeeld de jquery files op de Microsofts CDN
http://www.asp.net/ajaxli...Party_Files_on_the_CDN_20

Verder heeft jquery ook een mobile version die nog kleiner is.

[Reactie gewijzigd door 80466 op 22 april 2013 11:59]

Een CDN is absoluut nuttig maar mobiele browsers hebben niet zo'n grote cache. De kans op mobiel is daardoor vrij groot dat het alsnog gedownload moet worden, zeker omdat mensen naar verschillende CDN's refereren (code.jQuery.com, Google, Microsoft) en vaak naar een specifieke versie.
http://www.guypo.com/unca...wser-cache-sizes-round-2/

Ik zie dat Firefox 3.6 nog evenveel marktaandeel heeft als IE7, is die ook niet meer supported?

Firefox 3.6 lijkt nog gewoon supported te zijn. Op zich niet zo vreemd, het gaat niet om leeftijd of marktaandeel maar om hoe compatible en feature compliant een browser is. Firefox 3.6 mag dan wel ruim drie jaar oud zijn, hij is wel een stuk moderner dan Internet Explorer 8.

Ik snap heel de discussie niet zo goed. Ik gebruik erg veel jQuery maar je hebt overduidelijk 2 versies nu. De 1.9x-reeks die iedereen gebruikt en zal blijven gebruiken, logisch.

Maar ik snap ook heel goed dat je vooruit wil, en je voorbereid op de toekomst zonder legacy-code; dat is 2.0. Als je een nieuwe jQuery gaat ontwikkelen ga je toch ontwikkelen naar nieuwe browsers en javascript-engines toe, niet om alles compatible te houden; daar is 1.9 voor.

Een beetje zoals OS9 / OSX en classic dus. Een bepaalde overgangs-fase; dan afschrijven.

Laten we hopen dat je in de kern gelijk hebt!
Echter dan vooral op browser front...

Het probleem is, dat veel klanten momenteel hippe dingen willen, waarbij zij helaas al te vaak gebruik maken van oude browsers..
Dit gaat een keer fout, nieuwe hippe dingen laten draaien op oude troep gaat niet lang goed, daarnaast is het vreemd dat de webindustrie een van de weinige industrieen is waar dat verwacht wordt... Gezien bij games/software/huizen etc. het vrij duidelijk is dat er bepaalde eisen zijn voordat iets kan werken.

Persoonlijk denk ik dat de discussie er vooral over gaat dat er dus leuke nieuwe dingen in jQuery 2.0 zitten, echter heeft het de support voor oude browsers laten vallen, terwijl dit in eerste instantie juist de kracht van jQuery was om dat verschil af te vangen (anders had je net zo goed vanilla javascript kunnen gebruiken).
In het meest hippe geval zou het zo zijn, dat je jQuery 2.0 + nieuwe functionaliteiten kunt gebruiken en dan het verschil met oude browser kan afvangen met bovenstaande conditional javascript load, echter is het de vraag of jQuery 1.9 de afvang kan maken zodat 2.0 zijn eigen ding nog kan blijven doen?
Zonder dat de functionaliteiten van 2.0 breken in oude browsers that is.

[Reactie gewijzigd door bloeper op 22 april 2013 18:21]

Je hebt in de basis wel gelijk, maar het is niet de plaats van een framework om te bepalen wat wanneer uitgefaseerd wordt. Dat moet uit de marktcijfers blijken.

Als een nieuwe ontwikkelaar een weloverwogen keuze gaat maken in een framework en ziet dat de nieuwste versie van jQuery niet ééns IE8 ondersteunt, is die persoon heel snel bij een ander framework dat ook prima werkt en wél IE8 ondersteunt.

Op deze manier lijkt jQuery de minder ontwikkelde landen compleet te negeren, waar oude browsers de normaalste zaak van de wereld zijn. Ze hebben daar geen moderne shit. En kom dan niet aan met "Jamaar, 1.9!", want dat is op dit moment alleen maar een slap geintje om ons niet helemaal weg te jagen van het framework. Pappen en nathouden, kietelen tot we eraan "vast" zitten en dan IE8 support helemaal droppen. mark my words, jQuery 1.9 verdwijnt op een gegeven moment, terwijl IE8 dan nog gebruikt wordt.

Ja, dat heeft OSX ook gedaan (en omgekeerd, de applicaties ervoor), maar op zo'n laat moment dat het gewoon okay is. Niemand heeft nog een Mac met een IBM-processor (was het toch?) maar miljoenen gebruiken nog IE8 en zelfs IE7.

[Reactie gewijzigd door _Thanatos_ op 23 april 2013 12:53]

Spanned. Ik ben benieuwd hoe dit gaat uitpakken. Hopelijk een sneller geladen framework en minder complexe code omdat de oude browsers worden genegeerd.

12% kleiner is nog niet echt een grote stap, maar het zal het aantal bugs wel wat verminderen. Nu hopen dat de oude android er ook snel uitgegooid wordt. Denk dat die ook nog wel wat quirks opleveren.

Ik heb pas een nieuwe telefoon, daarvoor draaide ik nog echter 2.3.x van android. Mijn vader en zusje gebruiken dit ook nog. Er is voor deze mensen echter geen mogelijkheid om te upgraden naar 4 ivm de hardware (singlecore 1ghz met 512mb ram, succes).

Je zou dan support droppen voor mensen die niet kunnen upgraden tenzij ze een nieuwe telefoon kopen.

Ik heb pas een nieuwe telefoon, daarvoor draaide ik nog echter 2.3.x van android. Mijn vader en zusje gebruiken dit ook nog. Er is voor deze mensen echter geen mogelijkheid om te upgraden naar 4 ivm de hardware (singlecore 1ghz met 512mb ram, succes).

Ik draai 4.2.2 op een single core van 800 Mhz met 512 MB (waarvan ~384 MB beschikbaar voor het OS) aan geheugen. De officiele updates gingen nooit verder dan 2.3.x. Toegegeven, een normale eindgebruiker zie ik niet zo snel een aparte firmware installeren, maar een tweaker (in de familie) moet dit zeker lukken. Alles draait snel en soepel. Het toestel kan zonder problemen tegelijk navigeren, muziek afspelen over Bluetooth en tetheren.

Je zou dan support droppen voor mensen die niet kunnen upgraden tenzij ze een nieuwe telefoon kopen.

Hoe lullig het ook is: smartphones en tablets hebben een verwachte levensduur vanaf het moment dat modellen uitkomen (niet vanaf het moment van aanschaf van een exemplaar). Na ongeveer twee jaar loop je helaas achter qua software (en beveiligingsupdates!) omdat de fabrikant geen nieuwe software meer wilt uitbrengen. Er wordt verwacht dat je een nieuw apparaat koopt, of dat je een tweaker bent die zichzelf kan redden.

[Reactie gewijzigd door The Zep Man op 23 april 2013 09:22]

Als je 10 jaar bij dezelfde hardware blijft dan heb je die mogelijkheid inderdaad niet. Eenzelfde gebeurd bij Windows PCs. Daar zijn ook nog wel wat Windows 8 en Windows XP gebruikers die ook niet naar IE10 kunnen upgraden. Maar je moet je afvragen of dat geen krenterigheid is en of je daar nou rekening mee moet gaan houden. Als het aandeel minder dan 1% is, heb ik de neiging om ze over te slaan.

Maar daarvoor heb je je website statistieken. Heb je nog W2K/XP users met MSIE 8 of lager? Zo ja, dan moet je dus bij 1.9 blijven totdat het percentage dermate klein is dat jij (of werkgever/opdrachtgever) besluit dat deze groep niet langer ondersteund hoeft te worden.

En dan heb je nog de Android 2.x issue. Zij zeggen dat ze dat in de gaten houden totdat ze die code kunnen droppen. In dat geval moet je 1.9 gebruiken voor MSIE 6/7/8, 2.0 voor Android 2.x en voor de laatste generatie zit je dan mogelijk op de 2.1 branch.

Indien je website in elke javascript-enabled browser moet werken, ben je dus genoodzaakt om bij 1.9 te blijven. Dat is namelijk de enige methode om alle browsers sinds 2001 te ondersteunen..

De update moet worden uitgebracht door de fabrikant van het toestel. Niet iedere fabrikant update toestellen die op Android 2.3 draaien. Er zijn wel fabrikanten die met deze hardware toestellen produceren die op Android 4.0 draaien.

Het probleem is niet zozeer dat de foons het niet aankunnen, maar dat er gewoonweg geen updates (meer) voor uitgebracht worden. Op zich wel een logische keuze als fabrikant zijnde; op de updates wordt immers toch geen winst meer gemaakt. Voor de niet-tweaker is dit dan weer een nadeel.

Er zijn genoeg mensen die niet verder kijken naar hoe mooi de foon is en niets weten of niets willen weten van de gebruikte hardware en software. Daarnaast worden er nog steeds 'Android telefoons' die op een zwaar verouderd OS draaien.

En niet te vergeten de nieuwe features gaan zo veel sneller door naar de final.

Nu hopen dat de oude android er ook snel uitgegooid wordt

begrijp ik niet: android 2.x heeft nog een dikke 40% marktaandeel. Het lijkt me dat als iemand jquery gebruikt hij ook wil dat zijn site toch ook bij door die 40% van de android gebruikers kan gebruikt worden.
De nieuwe low-end android telefoons gebruiken nog altijd 2.3

[Reactie gewijzigd door vampke op 22 april 2013 14:32]

Is er voor die groep eigenlijk geen andere browser beschikbaar op android? Dat je ze daarop wijst bv?
Verder moet je je afvragen hoeveel mensen daarvan nog zware gebruikers zijn. Mijn moeder heeft ook een 2.x toestel gehad en deed eigenlijk niet meer dan whatsapp en facebook. Als ze verder weinig apps downloaden of browsen en het aandeel daar dus ook significant lager is, kun je ze al wel makkelijker laten liggen.

[Reactie gewijzigd door Martinspire op 23 april 2013 10:36]

As promised, this version leaves behind the older Internet Explorer 6, 7, and 8 browsers.

Jarenlang jQuery gebruikt, maar dit is toch wel een ULTRAFAIL.

Nu is niet het moment om IE8 te laten vallen. IE7 laten vallen valt nog enigzins mee te leven, maar IE8 wordt gewoon gebruikt. Als webdeveloper heb je daar zo goed als geen invloed op, dus als framework-bouwer al helemaal niet. jQuery gaat er echt niet voor zorgen dat oude browsers niet meer gebruikt worden - het zal de bezoeker echt jeuken welk framework je gebruikt.

[Reactie gewijzigd door _Thanatos_ op 22 april 2013 12:32]

Ik vind hier helemaal niets mis mee. Voor "normale" websites kun je gewoon 1.9 blijven gebruiken. Voor mobiele websites kun je nu bijvoorbeeld alvast 2.0 in gaan zetten, en over een jaartje (als IE11 uit is) is het wel zo'n beetje tijd om IE8 uit te faseren. Alles in overleg met je opdrachtgever natuurlijk

Het kost de grootste moeite om IE7 support te droppen, laat staan IE8.

Daarbij zijn er ook bestaande projecten die onderhouden moeten worden. Op een gegeven moment kun je jQuery dus niet meer updaten voor die sites omdat er ooit IE7-support beloofd is en we dat contractueel moeten waarborgen.

Je kunt wel vanalles willen en mooi vinden, maar wat niet gaat, zal niet gaan.

Je hoeft JQuery natuurlijk niet te updaten voor bestaande projecten he. Maar het is heel simpel: standaard support ik bij nieuwe projecten vanaf IE8. IE7 erbij? Prima, maar dan reken ik ook extra uren.

Daar los je jQuery 2.0 niet mee op, want die ondersteunt IE8 dus ook niet

Ehm... waar praat je over? Zoals aangegeven wordt de 1.x serie nog steeds ondersteund. Deze versie is o.a. uitgekomen om Windows apps e.d. minder bloated te maken, voor websites kan je prima een versie van jQuery gebruiken die dit wel ondersteund.

Bovendien is het erg mooi dat moderne browsers minder hoeven te lijden onder de verplichtte compatibiliteit met oude browsers. Nu kan je voor oude IE versies een 1.x versie van jQuery laten inladen, terwijl moderne browsers de 2.x versie kan krijgen, en dus minder data hoeft te gebruiken.

Maar hoe lang worden 1.9 en 2.0 nog doorontwikkeld? Het is een kwestie van tijd voordat ze zeggen "oh sorry, 1.9 doen we eigenlijk niets meer, gebruik 2.0 maar voor die nieuwe feature".

Het is niet voor niets dat ze er twee verschillende versies van maken. Als ze 2.0 als full en light versie (ofzo) hadden uitgebracht, had ik nergens over geklaagd, want dan zijn ze tenminste "hetzelfde".

We had hoped to remove even more code and increase performance, but older Android/WebKit 2.x browsers are now the weakest link.

Dit is grappig.

Iets wat al vaker gezegd is, Webkit is op veel fronten het nieuwe IE6. En als webdeveloper ben ik daar helemaal niet blij mee. Waar je eerder hacks voor IE nodig had, ben je nu meer en meer speciale functionaliteit aan het bouwen voor webkit.

http://www.google.nl/sear...ie6&aq=0&oq=webkit+new+ie

Ik vind de stap die jQuery nu zet erg opmerkelijk. De kracht van jQuery is juist dat je je niet bezig wilt houden met cross browsed ontwikkeling. En waarom zou je dan wel oudere webkitversies blijven ondersteunen? Het is alles of niets. Nu wordt het chaotisch en zal er eerst gekeken moeten worden welke versie er draait en welke gewenst is

Ik blijf het een tikje vreemd vinden. Een hoeksteen van een javascript framework is multi-browser transparantie. En nu wijken ze daar drastisch van af.

Ik snap dat ik ook 1.9.1 kan blijven gebruiken en dat de api interface hetzelfde is als 2.0 maar DE reden voor het bestaan van jquery (en anderen) is browser support. (dom traversing is as close second).

Ik had veel liever gehad dat ze jquery modules hadden gemaakt van oldIE.

Als je oldIE een uitstervend ras vind moedig ik je aan China als markt te moeten bedruipen.

Ik vind het zelf ook raar, maar support blijft multi-browser maar niet multi-version. IE6 hebben zelfs veel webontwikkelaars achter zich gelaten (of vragen een fixe meerprijs voor ondersteuning).

De kwaliteit van Jquery word op sommige vlakken waarschijnlijk geremd door oude browsers, al vind ik dat ze wel ver gaan met b.v. 8 al eruit schrappen.

Zelf had ik ook liever gezien dat ze voor 2.0 een extra laagje hadden ontwikkeld die je kon gebruiken voor oude browsers en wie weet doet iemand dit uit de community wel