jQuery eller JavaScript
 

Du har verkligen en aversion mot jQuery? :) Eftersom du sagt detta ungefär 100 gånger nu så är det kanske läge att någon svarar. Visst är det onödigt att använda jQuery om man bara är ute efter en enda js-funktionalitet men det är lite märkligt att utgå från att varje fråga i forumet gäller det enda js man har på sin sajt. På de flesta lite större sajter blir det ofta många rader js och då tjänar man en hel del på att använda sig av exempelvis jQuery eller prototype. Det underlättar dessutom för dom som inte har lust eller tid att sätta sig in i vanligt js och vill ha en massa färdiga plugins.

Det beror nog på att jag genomgående bara fick svaret att använda jQuery till allt mellan himmel och jord så fort jag ställde en fråga om javascript. Och nej, jag tycker inte jQuery är någon vidare lösning utan mest används där kunde ha varit en enkel js-lösning.
Där slår du nog huvudet på spiken. jQuery är säkert jättebra om man inte fattar något men ändå vill åstadkomma något. Jag har en stark känsla av att det är därför det är så omtyckt i dagens klipp-och-klistra-webdesign.

Jag kanske ska tillägga att jag jobbar en hel del med både jQuery och JavaScript i övrigt och för det mesta, även i större applikationer, är det enklare och bättre att skriva om taffliga jQuery-alster till vanlig JavaScript. Det ger både bättre prestanda och översiktiligare kod.

Verkar som du är lite sur på att vem som helst kan göra samma saker som du och jag genom att klippa och klistra :) Tvärtom tycker jag att det har utvecklat internet i en positiv riktning.

Jag tycker man för det mesta bör skilja js, css och html åt och använda inline-varianterna så lite som möjligt. Dessutom innebär 50-80 kb js ingenting med dagens internetuppkopplingar + att man på mer populära webbplatser (en rad av Sveriges största webbplatser använder sig utav jQuery eller prototype) normalt sett har en stor andel återkommande besökare = mycket cachat innehåll. Mängden script som inte cachas blir således också för det mesta mindre allteftersom man utvecklar. Sedan vad gäller händelser i klienten så är de i princip momentana oavsett för det mesta så en eventuell skillnad där är irrelevant. Utöver detta så sparar man en hel del tid och pengar på att skriva $('#blabla') istället för document.getElementById('blabla') osv. och skriver man tusentals rader js varje månad så gör det en hel del i längden vilket man snabbt inser. Ingen lösning är givetvis optimal i alla lägen men för de allra flesta är jQuery ett snabbare och smidigare alternativ, särskilt om de inte är vana kodare och dina motiveringar utgår ofta från antaganden som du inte har en aning ifall de stämmer eller inte då du i princip aldrig vet hur frågeställarnas webbplatser är uppbyggda.

Visst, använder man bara js på några få ställen så finns det ingen poäng med att köra jQuery men så är sällan fallet på användarvänliga större webbplatser idag som flera oss arbetar med. Normalt sett drar andra delar av webbplatserna betydligt mer resurser och det är utan tvekan bättre att lägga denna tid och energi där istället samt på vidareutveckling av tjänsterna. Det gäller att prioritera rätt helt enkelt.

Edit: Flyttade ut inläggen till en ny tråd då det blev aningen OT.

Ursprungstråd: http://www.wn.se/t1045185-15-2.html


Ok, kanske läste jag för mycket mellan raderna då. Ibland är det svårt att tolka "..."

Bra att du lade upp ett exempel. Det blir dock ganska bökigt att behöva tänka på whitespace i markuppen, elementens ordning osv. Sånt där slipper man tänka på om man kör med ramverk. Även om det är en väldigt liten och simpel grej kan man spara tid. Använder man dessutom CDN behöver många besökare eventuellt inte ladda ner jQuery eftersom chansen finns att det redan ligger i cachen.

Vilken sjyst attityd du verkar ha. :D

Kan du ge något exempel på det du skriver om i sista meningen? Min åsikt är nämligen den att man kommer väldigt långt på att optimera sin jQuery men det vore intressant och kanske även lärorikt att se exempel på när det inte räcker till.

Låter man google ta hand om serverandet av Jquery dessutom (och andra sajter gör det också) så är det stor chans att det inte behöver laddas hem i överhuvudtaget ;-)

Håller inte med om att det är mest "noobs" som använder JQuery - Om du inte kan JS Syntax kan det vara svårt att förstå JQuery också.

Fördelar med o nyttja jQuery, det är testat mot flera browsers och plattformar i förväg, det är unittestat och prestanda kontrollerat.
Nackdelar, det är ett framework som e 20kb stort.

Fördelar Javascript rakt av, man kan fuska o knacka lite js direkt i onclick evnetet på en a-tag koden blir som regel inte mindre men enklare att hitta o felsöka om man spaghetti kodar.
Nackdelar: det krävs många ggr felhantering för o funka överallt och på mobila enheter.

20 Kb är inte något i dagens samhälle. 20 Kb för 10 år sen däremot....

Precis, det är snarare en fördel än en nackdel att det är så pass litet. Man kan dessutom lätt spara in ett antal kb på js om man använder jQuery beroende på hur mycket man använder på sin sajt.

Ni missade ironin alldeles när jag sa att det var 20kb stort.. Det e jue fan iiingenting.. och man får koncis konsekvent, cross-browser kapabel javascript kod, emot den där jevla spaghetti koden man drogs med för några år sen när de satt onclick, och nestade href taggar med javascript anrop i högt, lågt och tamefan överallt...

Så sant. Däremot om du, som ganska många har 311 olika Jquery plugins, och dessutom i separata filer så blir det rätt många requests som alla tar tid. Lägger man dom dessutom högt upp i html dokumentet så måste ju JS executeras först av browsern och det skapar ytterligare en liten delay :)

Det går ju naturligtvis att komma ifrån genom att kombinera dessa på samma sätt som man kan ha en enda JS fil.

Fast å andra sidan, koda ngt dylikt : http://sandbox.supercharge.se/ (funkar nog bara i chrome) utan att dra nytta av ett ramverk, blir cepe jobbigt.

Då i detta fallet hanterar den resize events på div'ar genom custom triggers, en hög med animationstyper som tar hänsyn till varandra.. minns när ja gjorde liknande saker utan ett design pattern för typ 5år sen, med gamla hederliga event triggers direkt på dom objekten, det vart snabbt oöverskådligt och helt jekla hopplöst att underhålla.

nu laddar jag jue dock, jquery, jquery-ui + generic.js filen som innehåller beteendena, så ja det e nog iaf.. 300kb som ska in i ett svep.

dAEk till martine: Hallå, någon där?

Två dagar innan julafton är kanske fel tillfälle att ropa? :)

Jo, inte är det rätt tajming iaf. :)

I min värld är det ganska vågat att säga att man kan skriva kod som presterar bättre än jQuery. Om det stämmer vore det säkert lärorikt att se lite detaljer och vad är då bättre en ett exempel?

Prestera bättre är säkert inga större problem om man duktig. Blir ju en hel del overhead när man laddar in ett helt ramverk fast man bara använder någon procent av alla funktioner som finns där.
Gör man ett bra script som bara löser exakt det man vill så kan man nog få bättre prestanda. Priset för det är ju dock att det tar väldigt mycket längre tid utveckla(och därmed dyrare, tid = pengar) och hur översiktlig kod det blir är ju upp till den som programmerar. jQuery är verkligen inte hinder för att göra översiktlig kod, utan i de allra flesta fall, ett hjälpmedel för det.

Eftersom scripten körs hos klienten hjälper det ju inte till att minska lasten på servern heller, förutom marginellt mindre bandbredd(motsvarar en normalstor bild)...

På det stora hela är det nog väldigt få fall där nackdelarna överväger fördelarna när det rör sig om att göra nya funktioner från scratch. Ska man bara använda använda en eller två jQuery funktioner kanske man kan göra det själv utan jQuery.

Ja, det går att skriva kod som presterar bättre. Vad är så bra att det inte går att förbättra ytterligare? Inte mycket. Men att säga att det är enklare att skriva egen kod och att den presterar bättre är något jag har svårt att ta på allvar. Det känns som att man antingen överskattar sin egen förmåga eller underskattar insatsen som krävs för att skriva högpresterande js som funkar i olika webbläsare.

Ska man bara dölja en div eller liknande är det såklart onödigt att läsa in ett ramverk men de flesta av oss skriver lite mer avancerade sidor än så. Ramverk medför viss overhead men hittills har jag inte varit med om att det skulle vara något som gör att det faller bort pga den skillnaden. Vad för typ av app skriver man i de fallen?


Overheaden ligger i att läsa filen från nätet och läsa in den från cache + minnesanvändningen. Funktioner som inte används orsakar inte mer overhead än så eftersom ramverket är modulärt. Det innebär förresten att man inte behöver läsa in hela jQuery om man inte vill. De moduler som man inte använder kan man stycka bort så att de inte behöver skickas till webbläsarna öht. Kolla i byggskriptet för mer info.

Ja, hallå... Jag bor inte på forumet om du nu trodde det. God jul på dig för övrigt.

I stort håller jag med ITisGood så du kan läsa hans inlägg. Jag skulle dessutom tillägga att det finns flera ramverk och det finns ingen anledning att stirra sig blind på just jQuery. Och gör man websidor lite oftare än bara ibland så lönar det sig snabbt att bygga upp egna bibliotek för just det man behöver i sammanhanget.

Om du inte kan göra bättre kod än jQuery så tillhör du nog de många som använder jQuery just för att de inte kan eller orkar göra det utan gratisskjutsen de får av jQuery. Djupstudera xml, dom, css, oop och js så upptäcker du nog ett och annat intressant (JavaScripts objectmodell är väldigt intressant):
http://www.w3.org/DOM/DOMTR
http://www.ecma-international.org/pu...s/Ecma-262.htm

Vad i jQuery är det som behöver göras bättre och snabbare? Kan du nämna något konkret istället för att länka till höger och vänster?

God jul!

Satt länge o utvecklade egna chainade js ramverk för specifika uppgifter, men o bygga ngt som e helt crossover och unit testat på alla vanliga plattformar tar en satans tid, och bara för man använder jQuery betyder det inte att man inte har ngn djupare koll på vad man gör utan bara ute efter och faktiskt hinna prestera komplexare lösningar på kortare tid, ergo tjäna mer pengar. ;)

Alla javascript-filer ska ju parsas och köras också. Det är ju klart att det tar längre tid parsa och köra funktioner i en stor fil än i en liten. Även om du skalar bort det som inte används är det mycket extra kod som inte används. Sedan är det ju som med alla andra ramverk att allt är anpassat efter att vara så flexibelt och mångsidigt som möjligt. Det gör ju tex att varje funktion kollar efter massa olika parametrar och tar hänsyn till de i koden även om de inte används någonstans i en viss applikation.
Men skillnaderna är nog i de allra flesta fall så små att de inte märks utan i vissa specialfall som tex mobiltelefoner.

Ja var själv ingen expert på JS innan jag fick upp ögonen för jQuery. Ja kunde göra grundläggande saker som AJAX, gömma delar av sidan och stoppa in innehåll där man vill och så vidare. Men när jag började med jQuery blev det väldigt roligt när man med bara några få rader kod kunde göra snygga animeringar och andra effekter.

Men den största vinsten med jQuery och ramverk generellt är ju att man blir mycket mer produktiv och därmed sänks utvecklingskostnaderna. När det gäller mikrooptimeringar som dessa är det nog i många fall utvecklingskostnaderna högre än kostnaden för de extra CPU-cyklerna som förbrukas.

Jo, jag glömde den faktorn. Men oavsett: jag vet egentligen inte vad vi argumenterar om längre. Premature optimization försöker jag undvika och hittills ser jag anledningarna till att inte använda ramverk som - just det - premature optimization. Jag har fortsatt svårt att se vilka särskilda förhållanden som motiverar ett sådant beslut och det verkar inte gå att få några exempel. Lika bra att avbryta här, antar jag.

Ta gärna upp några specifika exempel där det innebär några VÄSENTLIGA skillnader mellan js och jQuery (alltså inte där det bara är så att jQuery inte räcker till). Med ditt synsätt kan man lätt säga att PHP och .NET är onödigt i de flesta fall också :)

Det du också verkar glömma är att i princip alla som arbetar som utvecklare har en prioritering att rätta sig efter (antingen en egen eller uppifrån eller både och) då tiden ALDRIG räcker till. I 99,99% av fallen är det långt viktigare att optimera serversidan än att tjäna några tusendelar på klientsidan.

Det finns i bästa fall 2 andra ramverk som både har en hyffsad funktionalitet och en bra prestanda. Men för jquery har du mest litteratur, plugins och community aktivitet i övrigt. Det finns ingen anledning att stirra sig blind på jquery, men det är ingen slump att det under de senaste 5 åren utvecklats till det i särklass mest populära ramverket för allmänna applikationer.

På samma sätt som det inte är någon slump att PHP och ASP.NET tillsammans dominerar serverside-scripten. Det kan finnas anledning att rekommendera Ruby eller JSP, eller göra det i C för prestandans skull. Men då är det väldigt viktigt att veta vilka framtida problem man kan skapa för sig själv. Liksom om du skapar en stor webbapplikation med mycket JS utan att använda något populärt ramverk.