Beter Javascript schrijven vanuit PHP-referentiekader

vrijdag 16 februari 2018 18:06

Acties:

+1 Henk 'm!

Topicstarter

Als webdeveloper beheers ik PHP, HTML, JS, CSS en beheers ik nog wat andere tools/talen. Mijn focus ligt echter bij PHP, of specifieker: bij Symfony (full-stack, dus ook Doctrine ORM, Twig, etc.) en dat framework beheers ik dan ook goed. Mijn Javascript-skills zijn m.i. wat ondermaats en nu browsers steeds krachtiger worden voelt dat steeds meer als een gemis. Ik zoek dus al een tijdje naar een manier om de webapplicaties waarvoor ik verantwoordelijk ben naar een hoger plan te tillen als het gaat om JS.

Even wat achtergrond over mijn achtergrond en daarmee referentiekader. Als PHP'er ben ik begonnen met PHP 4 en via WordPress ben ik uiteindelijk bij Symfony uitgekomen. Volgens mij een route die veel mensen hebben afgelegd. Inmiddels is o.a. dankzij Composer (dat weer het daglicht zag dankzij namespaces) de PHP-wereld flink veranderd. Iedereen en z'n moeder (Laravel, phpBB, Joomla, Drupal, Magento, Prestashop, etc.) gebruikt op z'n minst één Symfony component. De PHP-FIG standards (en dan bedoel ik vooral de Interfaces, niet zozeer de Coding Standards) maken het bovendien mogelijk die nog uit te wisselen ook. Heerlijk.

Tijdens het ontwikkelen van webapplicaties probeer ik zoveel mogelijk gebruik te maken van componenten om 'reinventing the wheel' te voorkomen. Maar dat niet alleen: ik wil niet afhankelijk zijn van Symfony. Het bevalt me nu prima, maar als er een beter framework opstaat, wil ik kunnen overstappen. Daarom schrijf ik zoveel mogelijk framework-agnostisch. Dat is (als je WordPress'ers even negeert) volgens mij nu de standaard: 'native' PHP met Dependency Injection. Ik zeg weliswaar dat ik Symfony-developer ben, maar in mijn ogen zou ik eenvoudig naar een ander framework (Laravel, Drupal) moeten kunnen overstappen, omdat je primair PHP'er bent.

Nu terug waar ik mee begon: Javascript. Ik wil graag beter worden in Javascript, maar niet direct afhankelijk zijn van één bepaald framework. De ontwikkelingen gaan immers erg snel en als ik twee willekeurige JS'ers (deze week op Tweakers Developers Summit, maar ook elders) vraag, ontstaat binnen enkele minuten een bitch-fight tussen React, Angular, Vue, etc. Een paar jaar geleden ging die bitch-fight naar mijn gevoel overigens tussen CommonJS, AMD en RequireJS, maar wellicht ten overvloede: op JS-terrein begeef ik me op enigszins glad ijs.

Twee vragen:

Wat moet ik leren anno 2018? Welke concepten moet ik begrijpen om écht Javascript te snappen? Veel sites duiken gelijk een framework in, en dat wil ik per se niet. Ter illustratie in welke richting ik zoek: als een JS'er of WordPress'er mij de omgekeerde vraag over PHP zou stellen zou ik dingen als Dependency Injection, Service container, Interfaces, auto-loading, SOLID, etc. noemen.
De PHP-wereld is flink veranderd sinds Composer (2011), dat op zijn beurt weer mogelijk werd door namespaces in PHP 5.3 (2009). Ook PHP-FIG ("a group of established PHP projects whose goal is to talk about commonalities between our projects and find ways we can work better together.") heeft in mijn ogen veel veranderd. JS heeft dan wel npm, maar echt interoperability zie ik nog niet. Of mis ik iets? Welke ontwikkelingen moet ik in de gaten houden?

vrijdag 16 februari 2018 18:27

Acties:

+1 Henk 'm!

Ed Vertijsment

StephanVierkant schreef op vrijdag 16 februari 2018 @ 18:06:
Wat moet ik leren anno 2018? Welke concepten moet ik begrijpen om écht Javascript te snappen? Veel sites duiken gelijk een framework in, en dat wil ik per se niet. Ter illustratie in welke richting ik zoek: als een JS'er of WordPress'er mij de omgekeerde vraag over PHP zou stellen zou ik dingen als Dependency Injection, Service container, Interfaces, auto-loading, SOLID, etc. noemen.

Ten eerste de basis, dat is ES5. Wat doen functies, wat is de scope van var, wat betekent this nou eigenlijk en hoe werkt dat rare prototype inheritance nou? Sommige van deze concepten zul je namelijk niet meer bewust mee (in ES6) werken maar zijn er nog wel degelijk (ES6 is grotendeels sugar over ES5).

Vervolgens raad ik je aan om in ieder geval te kijken naar:

Code schrijven voor nodejs.
XHR vs fetch API.
Het Array prototype en de parels die erin zitten.

En dan pas:

ES6 imports.
ES6 classes.
ES6 let/cons.
ES6 arrow functions.
Build tools (gulp, webpack babel etc.).

Als extra tip zou ik je aanraden om ver weg te blijven van jQuery, of je het in projecten moet gebruiken is een andere discussie maar het abstraheert bijna alles weg wat leren goed in de weg kan zitten.

StephanVierkant schreef op vrijdag 16 februari 2018 @ 18:06:
De PHP-wereld is flink veranderd sinds Composer (2011), dat op zijn beurt weer mogelijk werd door namespaces in PHP 5.3 (2009). Ook PHP-FIG ("a group of established PHP projects whose goal is to talk about commonalities between our projects and find ways we can work better together.") heeft in mijn ogen veel veranderd. JS heeft dan wel npm, maar echt interoperability zie ik nog niet. Of mis ik iets? Welke ontwikkelingen moet ik in de gaten houden?

Exact wat je zegt. NPM. Tools als webpack zorgen er namelijk voor je NPM modules in de browser kan gebruiken middels imports. Dit verandert een hele hoop, opeens hoef je een jQuery plugin meer van een CDN te trekken maar doe je npm install foobar.

Wat je verder wilt volgen is de ontwikkeling van ECMAScript (https://github.com/tc39/ecma262#ecmascript) er gebeurt zoveel dat ik daarmee deze post niet vol ga tikken.

De frontend als omgeving verandert elke dag weer en soms wil je juist even blijven met wat je hebt. Maar als jee goeie basiskennis hebt dan beweeg je wel mee. Wees overigens niet bang, modern JavsScript heeft ook best wat gemeen met PHP en is eigenlijk best wel een volwassen taal geworden.

vrijdag 16 februari 2018 18:32

Acties:

0 Henk 'm!

418O2

1 tip van een frontender, probeer niet alles tegelijk te leren. Begin vanuit een framework (ik zou vue aanraden omdat dat vrij dicht tegen web components aan ligt) met een starter template.

Webpack is een bitch en dat zelf opzetten loont de moeite niet. Een goede starter template behoeft enkel wat aanpassingen om goed te zijn vaak. En als beginner is het helemaal afdoende

vrijdag 16 februari 2018 18:36

Acties:

0 Henk 'm!

StephanVierkant

Topicstarter

Dank voor de suggesties! Ik kwam zelf al op http://jstherightway.org/#getting-started uit, dat ziet er ook interessant uit.

Als Symfony-developer ben ik natuurlijk gaan kijken naar Encore, dus het idee achter Webpack is bekend en zelfs al geïmplementeerd. Probleem blijft nog dat 80% van de scripts op basis van jQuery zijn. En waarom jQuery verschrikkelijk is, is ook bekend

.

vrijdag 16 februari 2018 18:37

Acties:

0 Henk 'm!

Ed Vertijsment

418O2 schreef op vrijdag 16 februari 2018 @ 18:32:
1 tip van een frontender, probeer niet alles tegelijk te leren. Begin vanuit een framework (ik zou vue aanraden omdat dat vrij dicht tegen web components aan ligt) met een starter template.

Webpack is een bitch en dat zelf opzetten loont de moeite niet. Een goede starter template behoeft enkel wat aanpassingen om goed te zijn vaak. En als beginner is het helemaal afdoende

Volgens mij was de vraag om juist niet met frameworks te beginnen maar om een betere begrip van de taal te krijgen. Ik kan inderdaad mensen aanraden een framework te proberen als "voet in het water" maar een ervaren programmeur die op zoek is om een taal beter te begrijpen wil je juist geen abstracties opleggen.

Wat wel interessant kan zijn is om de broncode van dergelijke frameworks te bekijken, wat doen zou eigenlijk? Verder is WebPack echt niet een gemene dame hoor, probeer even de achterliggende concepten/architectuur te snappen en het gaat een stuk gemakkelijker

.

vrijdag 16 februari 2018 18:57

Acties:

0 Henk 'm!

StephanVierkant

Topicstarter

Ed Vertijsment schreef op vrijdag 16 februari 2018 @ 18:37:
[...]

Volgens mij was de vraag om juist niet met frameworks te beginnen maar om een betere begrip van de taal te krijgen. Ik kan inderdaad mensen aanraden een framework te proberen als "voet in het water" maar een ervaren programmeur die op zoek is om een taal beter te begrijpen wil je juist geen abstracties opleggen.

Klopt, hoewel het één het andere niet hoeft uit te sluiten. Zonder Symfony (of een ander framework) is Dependency Injection een wat abstract begrip, je wilt het ook ergens gebruiken om te ervaren waarom dat concept überhaupt bestaat.

Wat wel interessant kan zijn is om de broncode van dergelijke frameworks te bekijken, wat doen zou eigenlijk? Verder is WebPack echt niet een gemene dame hoor, probeer even de achterliggende concepten/architectuur te snappen en het gaat een stuk gemakkelijker .

WebPack is inderdaad erg handig. Het dwingt uiteraard wel af dat je fatsoenlijk met ES6 omgaat, want jQuery door Webpack heengooien is vragen om problemen.

Kleine side note: Eén van de bijkomende voordelen van combinen en minify'en van js/css vond ik altijd al dat je met de neus op de feiten worden gedrukt: één foutje en geen enkel script/stylesheet werkt meer. Kortom: je leert een stuk nauwkeuriger programmeren.

vrijdag 16 februari 2018 21:28

Acties:

0 Henk 'm!

q-enf0rcer.1

[b]StephanVierkant schreef op vrijdag 16 februari 2018 @ 18:57:

Kleine side note: Eén van de bijkomende voordelen van combinen en minify'en van js/css vond ik altijd al dat je met de neus op de feiten worden gedrukt: één foutje en geen enkel script/stylesheet werkt meer. Kortom: je leert een stuk nauwkeuriger programmeren.

Hiervoor bestaat de linter, die doet precies wat jij hier zegt zonder dat je hoeft te builden

Sterker nog, veel build tools draaien ook een linter.

Ik kan me goed vinden in de gegeven tips, behalve het starten met een framework. Dat zou ik juist niet doen. Eerst ES5 leren vanuit vanilla JavaScript, om vervolgens aan de slag te gaan met ES6 via bijvoorbeeld het Angular framework zou wat mij betreft een hele goede route zijn om jezelf te ontwikkelen. Dan mis je uit eindelijk niets qua kennis. Je kunt dan code schrijven die direct in de browser / node.js is te gebruiken zonder scripts van derden, en bent tevens in staat modernere frameworks te gebruiken omdat je ook over de kennis van ES6 / TypeScript beschikt op die manier.

[ Voor 11% gewijzigd door q-enf0rcer.1 op 16-02-2018 21:31 ]

vrijdag 16 februari 2018 21:34

Acties:

0 Henk 'm!

StephanVierkant

Topicstarter

q-enf0rcer.1 schreef op vrijdag 16 februari 2018 @ 21:28:
[...]

(..)behalve het starten met een framework. Dat zou ik juist niet doen. Eerst ES5 leren vanuit vanilla JavaScript, om vervolgens aan de slag te gaan met ES6 via bijvoorbeeld het Angular framework zou wat mij betreft een hele goede route zijn om jezelf te ontwikkelen.

Well, that escalated quickly! Dit bedoelde ik dus met de bitch-fight. Ik heb nu vier reacties op mijn vraag en er zijn al twee frameworks aanbevolen.

vrijdag 16 februari 2018 21:35

Acties:

0 Henk 'm!

q-enf0rcer.1

StephanVierkant schreef op vrijdag 16 februari 2018 @ 21:34:
[...]

Well, that escalated quickly! Dit bedoelde ik dus met de bitch-fight. Ik heb nu vier reacties op mijn vraag en er zijn al twee frameworks aanbevolen.

Voor de duidelijkheid, dat bedoelde ik als een mooie vervolgstap in de toekomst

zeker niet om direct mee te beginnen.

vrijdag 16 februari 2018 21:38

Acties:

0 Henk 'm!

StephanVierkant

Topicstarter

q-enf0rcer.1 schreef op vrijdag 16 februari 2018 @ 21:35:
[...]

Voor de duidelijkheid, dat bedoelde ik als een mooie vervolgstap in de toekomst zeker niet om direct mee te beginnen.

Ja, dat begrijp ik. Maar m'n punt blijft hetzelfde. Zie ook m'n tweede vraag om de bredere context van m'n eerste vraag te begrijpen. Ik wil geen framework leren, maar Javascript. Ik heb nu het advies te krijgen om naar Vue.js en naar Angular te kijken, maar zonder enige context.

vrijdag 16 februari 2018 21:39

Acties:

0 Henk 'm!

q-enf0rcer.1

StephanVierkant schreef op vrijdag 16 februari 2018 @ 21:38:
[...]

Ja, dat begrijp ik. Maar m'n punt blijft hetzelfde. Zie ook m'n tweede vraag om de bredere context van m'n eerste vraag te begrijpen. Ik wil geen framework leren, maar Javascript. Ik heb nu het advies te krijgen om naar Vue.js en naar Angular te kijken, maar zonder enige context.

Dat is in verband met browser support. Veel ES6 functionaliteiten zijn niet out of the box te gebruiken met de browser. Het is gebruikelijk hiervoor een compiler/transpiler te gebruiken die in de meeste frameworks via een CLI zijn ingebakken. Of je moet zelf met bijvoorbeeld Babel aan de slag willen gaan om de code te compilen van ES6 naar ES5

Angular bevat daarna heel veel programmeer patronen die naar mijn mening echt een meerwaarde zijn om professionele applicaties te bouwen. Ik snap dat je JavaScript wilt leren, maar je moet ook begrijpen dat er veel dingen eigenlijk niet goed zijn in JavaScript. De zwakheden hiervan zijn aangepakt in TypeScript, een taal ontwikkeld door Microsoft waarin je ook ES6 patronen kunt gebruiken. Dat is nog een reden waarom ik dit aanraad, als volgende stap.

[ Voor 23% gewijzigd door q-enf0rcer.1 op 16-02-2018 21:41 ]

vrijdag 16 februari 2018 21:46

Acties:

0 Henk 'm!

StephanVierkant

Topicstarter

q-enf0rcer.1 schreef op vrijdag 16 februari 2018 @ 21:39:
[...]

Dat is in verband met browser support. Veel ES6 functionaliteiten zijn niet out of the box te gebruiken met de browser. Het is gebruikelijk hiervoor een compiler te gebruiken die in de meeste frameworks via een CLI zijn ingebakken. Of je moet zelf met bijvoorbeeld Babel aan de slag willen gaan om de code te compilen van ES6 naar ES5

Klopt, dat is bekend. Ik gebruik zelfs al (op kleine schaal) ES6 met Babel. Maar in de context van m'n vraag is browser support totaal irrelevant.

Ik vraag niet naar het beste framework, ik vraag hoe ik het beste Javascript kan leren. Als dat betekent dat ik een framework moet gebruiken dat mij veel leert, maar dat ik me in duizend bochten moet wringen om IE11 te ondersteunen; het zij dan maar zo. Compilers en polyfills FTW

(en ga dood, IE).

vrijdag 16 februari 2018 22:07

Acties:

0 Henk 'm!

q-enf0rcer.1

StephanVierkant schreef op vrijdag 16 februari 2018 @ 21:46:
[...]

Klopt, dat is bekend. Ik gebruik zelfs al (op kleine schaal) ES6 met Babel. Maar in de context van m'n vraag is browser support totaal irrelevant.

Ik vraag niet naar het beste framework, ik vraag hoe ik het beste Javascript kan leren. Als dat betekent dat ik een framework moet gebruiken dat mij veel leert, maar dat ik me in duizend bochten moet wringen om IE11 te ondersteunen; het zij dan maar zo. Compilers en polyfills FTW (en ga dood, IE).

Om in dat opzicht toch nog een goede toevoeging te geven; kijk vooral goed naar anderen. Of dat nou de makers zijn van een framework, of devs die een simpele gist hebben geplaatst op GitHub. Er zijn in JavaScript een heleboel patronen die wellicht nog onbekend voor je zijn. Als je code doorspit zul je die vaak zat tegenkomen. Mooie JavaScript pareltjes zijn bijvoorbeeld de Array Map en Array Reduce patronen. Toen ik van PHP overging op JavaScript, bleef ik heel lang plakken aan de ouderwetse for loop. Simpelweg omdat ik deze patronen niet begreep toen ik ze tegenkwam. Het had me veel tijd en onleesbare code kunnen besparen als ik deze patronen direct onder de knie had gekregen nadat ik ze was tegengekomen bij code van één van mijn leermeesters. Praten helpt hierbij uiteraard, want soms zijn er gewoon zaken die je niet meteen begrijpt zonder wat hulp van een ander.

Een goede referentie is https://developer.mozilla.org/nl/, heel handig voor als je code tegenkomt die je nog niet bekend is. Meeste patronen zijn hier te vinden met goede uitleg.

[ Voor 5% gewijzigd door q-enf0rcer.1 op 16-02-2018 22:09 ]

maandag 19 februari 2018 08:32

Acties:

0 Henk 'm!

Edwin88

Sowieso is het verstandig gewoon bij ES6 en wellicht TypeScript te beginnen, als je nu begint bij ES5 loop je al achter en leer je achterhaalde patterns. Juist ES6 maakt veel moderne technieken makkelijker en beter leesbaar (vooral => functies in functional style code).

Verder kan ik je aanraden Angular, Vue en React alledrie te gaan bekijken, zo krijg je vanzelf een idee van de verschillen. Tegenwoordig is ook een kijkje naar Redux of een van de vele varianten een must.

De meeste frameworks gebruiken dezelfde onderliggende JS structuren, waarbij het bijvoorbeeld in Angular het was vaster ligt dan React. In React heb je wat meer vrijheid andere externe packages te gebruiken.

Verder; wat is je doel? Wil je in front end aan de slag of is het puur hobby? Als je werk zoekt is een van de grote frameworks namelijk wel handig, als hobbyist is het leuker om alles uit te pluizen en beetje onder de knie te krijgen.

maandag 19 februari 2018 14:26

Acties:

0 Henk 'm!

wheels533

Ik kwam de volgende Git tegen: You Don't Know JS Ik heb het nog niet allemaal doorgenomen, maar er wordt goed uitgelegd hoe het werkt en je kan ook meteen mee typen in de console van je browser. Tot nu toe heb ik alleen de Up & Going bekeken.

maandag 19 februari 2018 14:51

Acties:

0 Henk 'm!

Verwijderd

ik ben 3 jaar geleden afgestapt van jquery of een ander framework (tot op heden) en ben zelf gaan schrijven, eerst in 1 bestand, daarna heb ik in js een require functie geschreven zodat ik het bestand kan opsplitsen en dynamisch met json kan inladen en heb nu een generator geschreven die van de core +/-80 files op het moment) weer 1 bestand maakt om te requiren. Heb nog geen tijd gehad voor de fancy effectjes die in sommige frameworks zit maar de basis is aanwezig. Het heeft in verhouding wel even geduurd maar hierdoor heb ik wel veel geleerd van functies zoals select, request, require, namespace (namespaces in js jaha...) als je interesse hebt in code lezen, kan ik je wel een linkje sturen...

dinsdag 20 februari 2018 14:59

Acties:

0 Henk 'm!

YopY

Ik heb een tijd terug een boek gelezen die JS vanuit de basisconcepten uitlegt; een goed boek IMO als je zowel de taal, hoe het met geheugen / scope omgaat, en functioneel programmeren wilt begrijpen: https://leanpub.com/javascriptallongesix/read

Ik bedoel het begint letterlijk met gewoon het nummer 42 en gaat al snel over naar identity en values vs references. enzo.

dinsdag 20 februari 2018 15:17

Acties:

0 Henk 'm!

418O2

Ed Vertijsment schreef op vrijdag 16 februari 2018 @ 18:37:
[...]

Volgens mij was de vraag om juist niet met frameworks te beginnen maar om een betere begrip van de taal te krijgen. Ik kan inderdaad mensen aanraden een framework te proberen als "voet in het water" maar een ervaren programmeur die op zoek is om een taal beter te begrijpen wil je juist geen abstracties opleggen.

Vue is niet zo erg opionated en gebruikt waar mogelijk gewoon javascript. De kennis van Vue is bijna 1:1 overdraagbaar naar webcomponents, wat op korte termijn toch wel de standaard zal worden (hoop ik)

Wat wel interessant kan zijn is om de broncode van dergelijke frameworks te bekijken, wat doen zou eigenlijk? Verder is WebPack echt niet een gemene dame hoor, probeer even de achterliggende concepten/architectuur te snappen en het gaat een stuk gemakkelijker .

Webpack is wel te doen, maar als je net begint zou ik het niet aanraden te willen begrijpen. Er zijn belangrijkere concepten om eerst op te focussen

Onderwerpen