to jQuery or not to jQuery?

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Top Low-Code Developer Gezocht!

Bedrijfsomschrijving Unieke Kansen, Uitstekende Arbeidsvoorwaarden & Inspirerend Team Wij zijn een toonaangevende, internationale organisatie die de toekomst van technologie vormgeeft door het creëren van innovatieve en baanbrekende oplossingen. Ons succes is gebaseerd op een hecht en gepassioneerd team van professionals die altijd streven naar het overtreffen van verwachtingen. Als jij deel wilt uitmaken van een dynamische, vooruitstrevende en inspirerende werkomgeving, dan is dit de perfecte kans voor jou! Functieomschrijving Als Low-Code Developer ben je een cruciaal onderdeel van ons team. Je werkt samen met collega's uit verschillende disciplines om geavanceerde applicaties te ontwikkelen en te optimaliseren met behulp van Low-code

Bekijk vacature »

Pagina: 1 2 volgende »

Ozzie PHP

Ozzie PHP

23/09/2013 13:02:32
Quote Anchor link
Ola peepz,

Ik ben benieuwd. Gebruiken jullie voor al jullie Javascript dingen jQuery? Ik ben wat huiverig om jQuery te gebruiken, omdat het toch telkens moet worden ingeladen. Van de andere kant vraag ik me af of je tegenwoordig wel zonder jQuery kunt? En hoe handelen jullie Ajax calls af? Ook met jQuery? Of gewoon in plain Javascript? Ik ben benieuwd... Is jQuery het gouden ei, of moet je het slechts met mate toepassen? Brand los...!
 
PHP hulp

PHP hulp

23/11/2024 10:38:38
 
Erwin H

Erwin H

23/09/2013 13:08:02
Quote Anchor link
Ozzie PHP op 23/09/2013 13:02:32:
omdat het toch telkens moet worden ingeladen.

Overhyped argument als je het mij vraagt. Er is altijd nog zoiets als caching, zowel server side als client side. Zeker als je een hosted versie gebruikt merkt de gebruiker er geen bal van.
Ozzie PHP op 23/09/2013 13:02:32:
Van de andere kant vraag ik me af of je tegenwoordig wel zonder jQuery kunt?

Jquery is gewoon javascript, dus ja natuurlijk kan je zonder. Jquery kan niets dat je niet zelf ook in plain javascript kunt bouwen.
 
Moe BE

Moe BE

23/09/2013 13:11:46
Quote Anchor link
Ik maak vrijwel altijd gebruik van jQuery door middel van gebruik te maken van de CDN link, waardoor de file vrijwel altijd uit de browser cache zal komen en dus niet meer ingeladen hoeft te worden. Al gaat het maar over een paar luttele kb.
 
- SanThe -

- SanThe -

23/09/2013 13:15:16
Quote Anchor link
Ozzie PHP op 23/09/2013 13:02:32:
Gebruiken jullie voor al jullie Javascript dingen jQuery?

Zo min mogelijk.
Alleen bij scripts van derden die ik gebruik. (Editor, Fotoviewer, etc)

Ozzie PHP op 23/09/2013 13:02:32:
En hoe handelen jullie Ajax calls af?

Gewoon in Javascript.
Gewijzigd op 23/09/2013 13:17:30 door - SanThe -
 
Kris Peeters

Kris Peeters

23/09/2013 13:16:26
Quote Anchor link
Ozzie PHP op 23/09/2013 13:02:32:
En hoe handelen jullie Ajax calls af? Ook met jQuery? Of gewoon in plain Javascript? Ik ben benieuwd...


http://www.phphulp.nl/php/forum/topic/utilsjs/85665/
Wel, hier heb je twee dingen: 'Ajax' en 'Events binden'.

Naar mijn mening kan jQuery niet echt iets spectaculairs.
jQuery houdt gewoon met heel veel rekening.
(Je kan vaak veel tijd verliezen als je alles zelf schrijft; zeker qua cross-browser conflicten)

Een bijkomend voordeel van jQuery is de uniformiteit. Als ik $.ajax aanroep, begrijpt iedereen direct wat ik aan het doen ben.
Als ik eigen functies gebruik, geldt dat niet.

Als je zonder kan, doe het dan zonder.
 
Ozzie PHP

Ozzie PHP

23/09/2013 13:20:23
Quote Anchor link
@Erwin: dank voor je reactie. Een hosted versie zou ik niet gebruiken. Ik zou het wel op m'n server zetten dan. Maar als ie eenmaal is geladen dan staat ie toch in de browser cache?

Ja, jQuery is inderdaad gewoon Javascript dus je hebt gelijk dat je zonder kunt. Laat ik de vraag anders stellen. Is het efficiënt om met jQuery te werken? Levert het veel voordeel op? En dan gaat het met name om het gemak en de snelheid van programmeren versus het inladen van de library.

@San-The: ah oké, en waarom niet?

Kris Peeters op 23/09/2013 13:16:26:
Als je zonder kan, doe het dan zonder.

Maar dat betekent dus dat je (in het geval van Ajax) zelf je afhandeling moet bouwen. Brengt dat "risico's" met zich mee? Heeft jQuery bijvoorbeeld een betere cross-browser ondersteuning dan wanneer je het zelf zou maken?
 
Kris Peeters

Kris Peeters

23/09/2013 13:30:33
Quote Anchor link
Wel ja, zoals je ziet, kost het wat lijnen code om zonder jQuery een $.ajax na te maken.

Mag ik iets anders opwerpen ...
Jij zou er zelf veel aan hebben om zo'n functionaliteit te schrijven.

Begin met de xmlhttp=new XMLHttpRequest(); ... en giet alles in een functie/object
Het zou maken dat je zowel javascript als jQuery veel beter begrijpt en apprecieert.
Gewijzigd op 23/09/2013 13:51:32 door Kris Peeters
 
Frank Nietbelangrijk

Frank Nietbelangrijk

23/09/2013 13:46:24
Quote Anchor link
JQuery kan echt zonder probleem toegepast worden alleen in de nieuwste versies schijnen de oudere IE versies niet meer ondersteund te worden. Dit vormt nogal een discussie omdat er best nog heel wat van die oudere IE's gebruikt worden. Gelukkig bepaal je zelf welke versie je gebruikt.

Op de vraag of het efficiënt is om met JQuery te werken:
Dat hangt af van de situatie. Ik persoonlijk vind JQuery overkill als je het alleen gebruikt om bijv een paar click-events af te vangen. Wordt het script echter complexer of wil je bijvoorbeeld één van die prachtige JQueryUI onderdelen gebruiken dan is JQuery een uitkomst.
 
Ward van der Put
Moderator

Ward van der Put

23/09/2013 14:13:14
Quote Anchor link
De vraag of je een JavaScript-framework moet gebruiken, lijkt op de vraag of je een PHP-framework moet gebruiken. Soms wel, soms niet: het hangt er maar van af.

Als je naar jQuery lonkt voor Ajax, zou ik me inderdaad in Ajax verdiepen. Met één A4'tje JavaScript, netjes uitgeschreven ook nog, kom je al een heel eind.

Ik denk dat er te vaak voor "jQuery-gemak" wordt gekozen uit "JavaScript-onbegrip", als je begrijpt wat ik bedoel. Voor UI-componenten zie je daarnaast dat JavaScript (en jQuery) in toenemende mate worden vervangen door HTML5 en CSS3.
 
Ozzie PHP

Ozzie PHP

23/09/2013 14:18:47
Quote Anchor link
Thanks voor jullie zinvolle reacties!

Ward van der Put op 23/09/2013 14:13:14:
Ik denk dat er te vaak voor "jQuery-gemak" wordt gekozen uit "JavaScript-onbegrip", als je begrijpt wat ik bedoel. Voor UI-componenten zie je daarnaast dat JavaScript (en jQuery) in toenemende mate worden vervangen door HTML5 en CSS3.

Kan je met css3 dan ook van die mooie automatisch openklappende (sliding) menu's en dergelijke maken?
 
Ward van der Put
Moderator

Ward van der Put

23/09/2013 14:23:45
Quote Anchor link
Ozzie PHP op 23/09/2013 14:18:47:
Kan je met css3 dan ook van die mooie automatisch openklappende (sliding) menu's en dergelijke maken?


Ja, onlangs nog gebruikt en aan te bevelen:

Ceaser - CSS easing animation tool
 
Kris Peeters

Kris Peeters

23/09/2013 14:24:18
Quote Anchor link
Je kan toch veel delegeren aan css3.
Zoek bv. eens naar "css3 transitions".
De meeste hover-effecten; divs groter/kleiner maken; ...
 
Ozzie PHP

Ozzie PHP

23/09/2013 14:29:00
Quote Anchor link
Ah ja, ik zie het inderdaad... geinig :)
Daar heb je dan inderdaad javascript niet meer voor nodig.
 
Wouter J

Wouter J

23/09/2013 14:44:13
Quote Anchor link
Nee, uit mij zelf gebruik ik geen jQuery. Als ik echter met FlightJS werkt gebruik ik het wel.
Anders gebruik ik MooTools, OO.js of de DoJo Toolkit.

Nuttige presentatie: http://vimeo.com/68009123 en bijbehorende blogpost: http://remysharp.com/2013/04/19/i-know-jquery-now-what/
 
Ozzie PHP

Ozzie PHP

23/09/2013 14:47:40
Quote Anchor link
Thanks Wouter, ik zal het binnenkort bekijken/doorlezen!
 
Eddy E

Eddy E

23/09/2013 17:00:06
Quote Anchor link
Ik gebruik, zodra ik ook maar 5 regels Javascript nodig heb (en dat is: als het dus met CSS echt niet meer gaat) al jQuery.

Uiteraard van een CDN (meestal die van Google) en dan korte codes.
Waarom? Makkelijker voor mij te schrijven (jquery is net wat 'simpeler' dan Javascript basic) en waarom niet?
In de praktijk komt er toch heel wat meer Javascript bij als je het eenmaal gebruikt.
 
Ozzie PHP

Ozzie PHP

23/09/2013 17:08:13
Quote Anchor link
En dat is inderdaad dus ook deels waar het om gaat. Is het slim om voor 5 regels javascript een library in te laden, of heb je dan teveel overhead?
 
Eddy E

Eddy E

23/09/2013 17:12:47
Quote Anchor link
Te veel overhead???
Die 24ms merk je echt niet....


Op mijn privé website ( www.eddyerkelens.nl ) worden er 16 HTTP-request gedaan. Die zijn allen binnen 200 ms klaar.
Browser wacht tussen inladen HTML (0 tm 40ms) gewoon 50ms seconden met iets doen voordat het volgende HTTP-request komt... (op 90 ms dus).
En dan komt jQuery tussen 90ms en 115ms....

Ja, 't is voor 5 regels wel veel.
maar ik heb er inmiddels meer Javascript in zitten dan 5 regels.
Eén plugin van 500 regels en nog wat kleine dingen.
't Is vooral handig voor uitbreiden. Gewoon 1 file extra inladen (een validator oid) en klaar.
Gewijzigd op 23/09/2013 17:17:51 door Eddy E
 
Ozzie PHP

Ozzie PHP

23/09/2013 17:14:55
Quote Anchor link
Nee, maar je snapt toch wat ik bedoel? Weegt het een op tegen het ander zeg maar...
 
Erwin H

Erwin H

23/09/2013 17:19:24
Quote Anchor link
Wat moet er niet tegen wat opwegen? Zoals Eddy zegt (en ik ook al zei), de gebruiker merkt er echt niets van, vooral niet als je het goed cached. Dus wat moet nu waar tegen opwegen?
 
Ozzie PHP

Ozzie PHP

23/09/2013 17:23:21
Quote Anchor link
Nou, je zou dus kunnen kiezen om alles met jQuery te doen (eigenlijk zoals Eddy zegt). Van de ene kant heel handig. Maar ik vraag me dan dus af of dat op een of andere manier nadelig is voor je performance. Ik snap dat het bij 10 bezoekers tegelijkertijd niks uitmaakt, maar wat als het er bijv. 1.000 tegelijk zijn? Gaat het dan wel wegen? En wat ik ook bedoel... is het middel niet te groot voor het doel in zo'n geval? Is het niet een hijskraan inzetten om een baksteen op te tillen?
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.