jQuery scripten - Hoe houdt je het overzicht?

[Gooly]

Ik ben eigenlijk op zoek naar tips, overwegingen en gedachten, want een concrete oplossing is er niet.

Als bijna volledig autodidact, en na enkele jaren PHP ben ik sinds kort ook in jQuery gedoken. En waar ik persoonlijk enorm tegen aan loop is dat ik met jQuery binnen no-time het overzicht volledig kwijt ben.
De reden; Enorme reeksen aan elkaar gekoppelde (als dan niet genestte) anonieme functies.

Het is puur persoonlijk, en zegt niks over jQuery. Maar wat ik fijn vind aan PHP is dat ik het functioneel en modulair kan gebruiken. Ik maak stukjes code, (procedureel of object georienteerd), en waar nodig roep ik ze er bij. Heerlijk overzichtelijk vind ik die structuur. Misschien ook omdat ik al een stuk meer ervaren ben met PHP en nog maar amper bij jQuery kom kijken, maar ik heb dus het gevoel alleen maar lange slierten abstracte code te produceren. Op het einde van een regel weet ik bij wijze van spreken amper nog hoe ik hem begonnen ben.

Voor een groot deel is dat ook wel noodzakelijk, omdat je in jQuery vaak functies als argumenten gebruikt. Dus ik zal me aan de jQuery way of working moeten aanpassen. Maar ik ben eigenlijk wel bijna wanhopig op zoek naar een manier waarop ik e.e.a. voor mezelf overzichtelijk kan houden.

Sinds kort gebruik ik PHP Storm, en ben ook al op zoek geweest naar daar eventuele ingebouwde tooltjes die daar bij zouden kunnen helpen, maar tot op heden niet echt iets gevonden. Dingen waar ik zelf aan denk die eventueel zouden kunnen helpen zijn: - Een goede (lees: nog betere) voorbereiding in de vorm van een goede architectuur van hetgeen ik bouw, zodat het scripten an sich alleen nog maar in code noteren van een intensief beschreven opzet is. En/of bepaalde code styling gebruiken die het overzichtelijker maakt.
Maar ook op die twee punten zou ik best wat tips kunnen gebruiken waar ik meer over zo'n architectuur en code styling kan vinden, of tools die ik daar bij kan gebruiken.
(Overigens mogen mij architectuur skill op PHP gebied ook wel een stuk beter )

Zijn er anderen die dit probleem al voor zichzelf hebben opgelost? Zijn er tips om ter harte te nemen? Zie ik (de autodidact) tools of ways of working over het hoofd die eigenlijk heel breed gebruikt worden?

[André]

Wat is de reden om jQuery te leren? Waarom niet eerst VanillaJS?

[CH4OS]

Je kan eventueel kijken naar bijvoorbeeld Laravel Mix icm Webpack, daarmee kun je diverse bestanden laten samenvoegen (en minifien) naar 1 bestand. Zo kun je dus voor jezelf gewoon structuur houden, terwijl uiteindelijk alle Javascript bij elkaar terecht komt en minified wordt.

Hiermee kun je dus ook het aantal requests verminderen op de pagina, wat natuurlijk ook een mooi voordeel is voor de clients.

Je bent ook bij jQuery niet verplicht om alles in anonieme functies te gooien. Je zal wel iets moeten hebben om het af te vuren, maar je kunt uiteindelijk ook vanuit jQuery (wat gewoon een subtaal is van Javascript) een functie aanroepen en daarna je ding doen.

[ Voor 42% gewijzigd door CH4OS op 22-01-2018 16:47 ]

[Kalentum]

Leesvoer: http://callbackhell.com

[Tsjilp]

Je bent ook bij jQuery niet verplicht om alles in anonieme functies te gooien. Je zal wel iets moeten hebben om het af te vuren, maar je kunt uiteindelijk ook vanuit jQuery (wat gewoon een subtaal is van Javascript) een functie aanroepen en daarna je ding doen.

jQuery is een library / framework, zeker geen subtaal

[Gooly]

Tnx so far. Vooral het artikel van rutgerw helpt. Dat is de informatie die ik zoek.
André, het is niet echt een heel bewuste keuze. jQuery kwam als eerste op mijn pad, wordt veel gebruikt en aangezien ik eigenlijk alleen maar voor WordPress script en jQuery in de praktijk altijd wel door de een of andere plugin of theme wordt geladen is het er in de meeste gevallen al. Maar ik moet eerlijk opbiechten dat er verder geen diepgaande motivering achter zit.

[Dark Blue]

Tsjilp schreef op dinsdag 23 januari 2018 @ 13:20:
[...]


jQuery is een library / framework, zeker geen subtaal

zo, om het even helemaal duidelijk te maken.

quote: http://jquery.com/

jQuery is a fast, small, and feature-rich JavaScript library.

Voor het organiseren van je code zou je naar een framework kunnen kijken als Angular. Dat stelt je in staat om je code op te splitsen en MVC aan te houden. Er zijn veel meer frameworks: https://javascriptreport....to-javascript-frameworks/

[Harrie_]

Ik denk dat het vooral ook een gevoelskwestie is. Ik (h)erken je probleem; ik heb daar zelf veel last van bij .NET-projecten. Mijn collega's die hun achtergrond hebben in .NET hebben daar kennelijk totaal geen last van.

V.w.b. jQuery probeer ik altijd de boel functioneel een beetje op te splitsen in verschillende .js files om het overzicht te houden (met comments!). Als we er een nieuwe versie uitgooien combine en minify ik de js files waar nodig

[Verwijderd]

Lijkt me handiger om eerst de geschiedenis van jQuery te leren. En begrijpen waarom het voorheen heel populair was (terecht!!) en het nu enorm aan het afnemen is.

jQuery is als een soort laagje over verschillende api's die hetzelfde doen. Je hebt dus een api in internet explorer, firefox en chrome of opera. Vroeger waren er grote verschillen in de api's en moest je dat voor elke browsers speciaal implementeren in javascript.

jQuery loste dit op door een abstractie laagje te maken met 1 uniform api welke onderliggend ging kijken welke browser er is en sprak daarmee dan weer de juiste api aan.

Tevens maakte jQuery de syntax gebruiksvriendelijker.
Eigenlijk kan je stellen dat jQuery echt broodnodig was destijds.

Nu zijn browsers veel meer gelijk aan elkaar getrokken en zijn de api's ook gebruiksvriendelijker geworden. Het gaat de goede kant op. jQuery was eigenlijk hoe de web al had moeten zijn.
Echter je moet wel vaak die hele bibliotheek mee laden dat kost resources.

Mijn advies: Leer eerst gewoon Javascript de taal aanzich en verdiep je in ES6 (ecmascript2015 standaard).
En dan tijdens het leren van Javascript ga je spelen met o.a. de DOM Api's en andere Api's die beschikbaar zijn in de browser.

jQuery, we mogen er blij mee zijn dat het er was.. maar het beste is wel voor de browsers dat ze zich goed aan de Api standaarden gaan houden zodat we het niet meer nodig hebben.

[McGuy81]

jQuery is erg handig als je veel met JavaScript code bezig bent.

Je hebt er de meeste profijt van door korte, simpele en meestal ook overzichtelijke code blocks te schrijven uit het jQuery framework, zodat je geen onnodige lappen code meer hoeft uit te typen.

Uiteraard heb je ook de nieuwste ecmascript in de meeste browsers, wat overigens veel mogelijkheden biedt, maar van de andere kant denk ik dat het jQuery framework met de tijd ook verder zal gaan uitbreiden.

[Ed Vertijsment]

McGuy81 schreef op zaterdag 27 januari 2018 @ 11:45:
jQuery is erg handig als je veel met JavaScript code bezig bent.

Je hebt er de meeste profijt van door korte, simpele en meestal ook overzichtelijke code blocks te schrijven uit het jQuery framework, zodat je geen onnodige lappen code meer hoeft uit te typen.

Uiteraard heb je ook de nieuwste ecmascript in de meeste browsers, wat overigens veel mogelijkheden biedt, maar van de andere kant denk ik dat het jQuery framework met de tijd ook verder zal gaan uitbreiden.

Zoals eerder aangegeven, jQuery is geen framework maar een library. En zoals eerder aangegeven focussen het zich op problemen die grotendeels in het verleden behoren. De populariteit loopt dan ook terug omdat er betere alternatieven zijn die:

1. Inhaken op standaarden.
2. minder zwaar zijn.
3. Betere syntax hebben (zonder christmas tree programming)

De alternatieven bestaan meestal uit een stack van een bundler, transpiler en optimaler.

bundler

Knoopt losse modules aan elkaar zodat je code kan opsplitsen in modules en third party packases kan gebruiken. Een voorbeeld van een bundler is webpack maar er zijn alternatieven.

transpiler

Vertaalt je code van taal 1 (voorbeeld: typoscript of es6) naar taal 2 (meestal es5). De meestgebruikte transpiler is babel (vaak i.c.m een bundler voor de import syntax).

optimizer

En optimizer minimaliseert en optimaliseert de gegenereerde code. Dit kan door bijvoorbeeld spaties weg te halen of ongebruikte code te lozen.

Er zijn verschillende snacks te verzinnen en ik zal degene kiezen die het gebruikelijker is voor de taal die je schrijft. Wil je langzaam van es5/jQuery naar es6/packages raad ik je aan om naar webpack en babbel te kijken. Wil je bijvoorbeeld naar typoscript kan ik me een andere stack voorstellen.

Lang verhaal kort:

Zoek geen oplossing voor het christmas tree probleem van jQuery maar besteed je tijd aan iets moderner. JQuery is dat gewoon niet. Een moderne stack stelt je in staat om gerichte (npm) packages te gebruiken die gespecialiseerd zijn en 1 ding goed doen in plaats van alles een beetje.

[Harrie_]

Mensen toch, ik vind dit allemaal wel erg gechargeerd. De poplulariteit van jQuery daalt ietwat de laatste tijd maar het is voorlopig nog niet zomaar weg.

Een kale minified jQuery.js is rond de 80kb en wordt door je browser gecached. Zo zwaar is het dus allemaal niet. Verder kun je ook gewoon 'normale' JS door je jQuery heenschrijven dus het is ook niet zo alsof je ineens van voor tot achter vastgebakken zit aan die rare syntax.

'Vroeger' hadden we er veel last van dat IE alles net even anders deed; met Edge gaat het de goede kant op. Nu zien we echter weer dat Safari steeds meer afwijkende fratsen aan het vertonen is. Als JS niet je 'main taal' is en je gebruikt het naast hetgeen je devt in PHP of aspx.NET dan zou ik jQuery niet zomaar linea recta overboord gooien.

[Ed Vertijsment]

Harrie_ schreef op maandag 29 januari 2018 @ 09:04:
Mensen toch, ik vind dit allemaal wel erg gechargeerd. De poplulariteit van jQuery daalt ietwat de laatste tijd maar het is voorlopig nog niet zomaar weg.

Niemand heeft gezegd dat jQuery morgen weg is. Alleen dat voor een beginner het weliswaar handiger is je tijd en energie te steken in de moderne tooling.

Harrie_ schreef op maandag 29 januari 2018 @ 09:04:
Een kale minified jQuery.js is rond de 80kb en wordt door je browser gecached. Zo zwaar is het dus allemaal niet. Verder kun je ook gewoon 'normale' JS door je jQuery heenschrijven dus het is ook niet zo alsof je ineens van voor tot achter vastgebakken zit aan die rare syntax.

2 syntaxen door elkaar gebruiken is een uitstekend recept voor spaghetti, laten we dat alsjeblieft niet doen. Het gewicht is inderdaad niet het issue hier, de architectuur van jQuery zelf, welke niet echt lekker botert in een moderne applicatie.

Harrie_ schreef op maandag 29 januari 2018 @ 09:04:
'Vroeger' hadden we er veel last van dat IE alles net even anders deed; met Edge gaat het de goede kant op. Nu zien we echter weer dat Safari steeds meer afwijkende fratsen aan het vertonen is.

Safar is inderdaad de nieuwe Internet Explorer, maar qua JavaScript achterstand is het gat echt niet zo groot dat we daar een library voor mee hoeven te sturen.

Harrie_ schreef op maandag 29 januari 2018 @ 09:04:
Als JS niet je 'main taal' is en je gebruikt het naast hetgeen je devt in PHP of aspx.NET dan zou ik jQuery niet zomaar linea recta overboord gooien.

Ik zou zeggen laat het dan over aan diegene die de taal wel begrijpt. Focus je vooral op wat je goed kan of waar je in wil investeren. Ga als backend dev niet je collega frontend devs opzadelen met code die hun in de weg kan zitten, net zoals een frontend dev geen rommel c#, php, python of iets anders moet gaan schrijven.

Als binnen een organisatie door het hele team jQuery gedragen wordt dan prima, dan zit je niemand in de weg. Maar als de frontend dev van je team probeert om een nette applicatie architectuur te bewaren dan wil je die niet dwarsbomen door code te schrijven die die structuur ondermijnt door een eigen eilandje te creëren met een afwijkende architectuur.

[Harrie_]

Ed Vertijsment schreef op maandag 29 januari 2018 @ 20:30:
Ik zou zeggen laat het dan over aan diegene die de taal wel begrijpt. Focus je vooral op wat je goed kan of waar je in wil investeren. Ga als backend dev niet je collega frontend devs opzadelen met code die hun in de weg kan zitten, net zoals een frontend dev geen rommel c#, php, python of iets anders moet gaan schrijven.

Als binnen een organisatie door het hele team jQuery gedragen wordt dan prima, dan zit je niemand in de weg. Maar als de frontend dev van je team probeert om een nette applicatie architectuur te bewaren dan wil je die niet dwarsbomen door code te schrijven die die structuur ondermijnt door een eigen eilandje te creëren met een afwijkende architectuur.

Puik plan als je ergens werkt waar frontend/backend sec gescheiden functies zijn. Als je ergens komt te werken waar je van alles wat doet (en die plekken zijn er zat) dan zul je daar toch een modus in moeten vinden...

[gitaarwerk]

jQuery heeft weinig toegevoegde waarde meer. Er zijn betere alternatieven. Maar, dat gezegd, heeft jQuery ook echt een hoop gebracht, namelijk de document.querySelector() / .querySelectorAll() functies. Samen met de laatste versies van EcmaScript is je code een heel stuk beter te strucureren in plaats van de callbackhell. Promises, Async&Await lossen een hoop op.

Met alles, het hangt er echt vanaf wat je wilt doen. De optie eerder gemeld over Webpack kun je, whatever library of vanilla je wilt gebruiken, het zal je enorm helpen in structureren. En dat is denk ik wat je wilt. Je zou je wel even moeten verdiepen in de tool. Als je carte blanche hebt, kun je vrij snel starten. Wanneer je een huidige code base moet omzetten met webpack, dan ga je even door de zure appel moeten heenbijten. Maar, uit ervaring, it's worth it!

Over lange slierten code. Ja, chaining... dat kan je ook in PHP toch? setter met daarin het 'this' object teruggeven, en chainen maar. Maar dat is misschien niet een pattern wat je zoekt, begrijp ik .
Juist met JavaScript ben ik bijvoorbeeld veel functioneler bezig dan voorheen. Het is heerlijk werken. jQuery chaining kan soms ook heel lastig zijn. Maar voor simpele dom modificaties is het soms wel fijn om lekker makkelijk iets te doen.


PHPStorm is prima voor front-end, VSCode is overigens ook een heel prettig alternatief. Iets minder krachtig. Als je een power-user bent, zul je PHPStorm wellicht aantrekkelijker vinden (short-keys, veel plugins, RESTApi tester, handigere deployment tools, hele uitgebreide edit functie).


Nogmaals, wat eerder is gezegd... kijk naar webpack en imports & exports. Het zal je leven verrijken :-) en wat je dan daarin gebruikt, zal een stuk makkelijker lijken.

Als je html en javascript/css aan elkaar moet koppelen, kun je ook nog kijken naar js-hooks te maken (classnames, of andere bindings aan je html om je code meer gescheiden te houden). Probleem is, er zijn een hoop mogelijkheden. En niet alle maniertjes zijn per se beter.