Hoe (her)begin ik aan frontend webdev?

[? ?]

Ik maakte de afgelopen 15+ jaar geregeld een website, web applicatie of andere dingen met aan serverside asp, php, asp.net, jsp en aan clientside javascript, html en css ( ).

Ik kan dat allemaal "redelijk goed" en geen probleem is te klein groot. Alleen zou ik mezelf geen css specialist noemen bv. Op javascript gebied kan ik van alles uit m'n hoed toveren en gebruik daarbij graag jquery.

Nu zou ik in de toekomst veel meer websites willen gaan maken en me vooral focussen op de frontend.
Daar loop ik toch een beetje "achter" als ik het zo mag noemen. Frameworks (behalve jquery) gebruik ik eigenlijk niet en nog niet zo lang geleden ben ik bootstrap.js beginnen gebruiken...

Hoe kan ik zo snel mogelijk weer up-to-date zijn om zo eenvoudig, snel, efficiënt mogelijk frontend wesites te maken. Welke frameworks gebruik jij, welke editors, andere tools?

[Spinal]

Editor: PhpStorm
Framework: Angular (1)
Andere tools: Sass, grunt/makefile

jQuery is bij mij over het algemeen overbodig geworden. Dingen waar jQuery 3 jaar geleden goed in was zitten nu in browsers ingebakken en het zorgt alleen maar voor overhead. Idem voor jQuery UI.

Qua CSS zou ik me eens gaan inlezen in Flexbox en Grid layout. Flexbox is nu al goed bruikbaar en maakt bepaalde dingen oneindig veel makkelijker te implementeren. Grid werkt op dit moment alleen in IE/Edge, maar het duurt niet lang meer voordat het in alle (desktop) browsers werkt (http://caniuse.com/#feat=css-grid)

[DJMaze]

Editor: Geany
Framework: micro frameworks
Andere tools: Mercurial, Aqua Data Studio

jQuery sucks als je weet waarom
Angular is mij te SEO onvriendelijk en genereert te vaak te veel html fouten.

Heel veel websites zien er het zelfde uit in Bootstrap, maakt het niet "mooier" wel consistent.
One page design ziet er ook vaak het zelfde uit. Persoonlijk als ik zoiets zie op een website van een "designbureau" hebben ze het in mijn optiek niet begrepen.

CSS3 en HTML5 doe ik alles in.

[_Erikje_]

Editor: Atom
Framework: bootstrap, foundation
Andere tools: Git(github), gulp, npm, SASS

Er is een kleine beweging tegen jQuery, ik snap zelf het probleem niet zo echt. Veel plugins zijn echter wel enorm kut, maar dat weet je vast ook wel De tegenhanger van jQuery is plain VanillaJS. Het is en blijft een keuze...

In de afgelopen jaren is veel veranderd in de buildsystemen. Voorheen vond iedereen grunt geweldig, nu mag het niet meer. Ook bower is uit den gratie, je kunt hetzelfde met NPM.

Qua styling is flexbox nu de shit. Daar kan je echt leuke dingen mee doen. Professioneel gezien zou je kunnen kijken naar Atomic Design, waarbij je een library van frontend componenten opbouw om je website op te bouwen.

[Blauw]

Editor: Sublime 3
Framework: Bootstrap
Andere tools: Git, NPM

De grote truc is volgens mij om je niet al te veel laten afleiden wat er op dit moment 'hip' is, zoals React. De leercurve van die laatste is best hoog.

Bouw gewoon een aantal kleine interfaces, en focus je als frontender ook op de UI/UX kant. Dat is (imo) in toennemende mate ook heel belangrijk geworden. De frontender moet niet alleen kant- en klare designs omzetten maar ook nadenken over de beste interface op alle devices.

[Ed Vertijsment]

Editor: PyCharm
Framework: "Vanilla" voor simpele projecten, ReactJS voor dynamische componenten.
Andere tools:

- Git voor versiebeheer.
- Gulp voor het draaien van tasks.
- NPM voor het bouwen van herbruikbar libraries.
- NPM voor het binnenhalen van dependencies.
- WebPack voor linken/bundelen van NPM packages voor de browser.
- Babel voor het omzetten van ES6 JavaScript naar ES5.
- Karma voor het draaien van de testomgeving.
- Jasmine als testframework.
- SASS voor het makkelijker schrijven van CSS.
- PostCSS voor het automatisch prefixen (autoprefixer) van vendor properties.

Er is een tooltje voor alles, ik raad je echter aan het aantal dependencies to beperken in je project. Hoewel mijn typische setup (npm/webpack) heel makkelijk tientallen libraries kan inladen zijn dat ook tintallen dependencies die up to date moeten worden gehouden. Zoals eerder genoemd is het wellicht handig om afscheid te nemen van jQuery.

Wat ik je wel kan aanraden is om ES6 te gebruiken (nieuwe versie JavaScript) nog niet alle browsers ondersteunen alles dus zul je iets als Babel moeten gebruiken om dat te "transpilen" naar old school es5. Er zijn op internet goede tutorials te vinden voor het inrichten van webpack+babel om dit allemaal automatisch te doen.

Zeker voor de bouw van losse libraries (nuttige/herbruikbare code gaat als lib naar npm) wil je tests schrijven. Karma zorgt voor het draaien van het "platform" daarvan en Jasmine is het framework voor het draaien van tests, een alternatief hiervoor kan zijn chai/mocha.

Wat ik je wil *afraden* is om gebruik te maken van Bootstrap, de reden hiervoor is dat Bootsrap ontzettend veel global styling aanlevert waar je bij simpele dingen alleen maar mee zit te klooien (we gebruiken ook geen global in backend, dus waar om wel in frontend). Daarnaast breekt Bootstrap (oorspronkelijk een prototyping framework) zo'n beetje elke best practice op frontend gebied...

Als je, je meer op de vormgeving kant wil richten raad ik je aan om eens te kijken naar een methodologie als BEM (http://getbem.com).

[Guillome]

Ik zeg 1 ding, two-way databinding frameworks zoals angular 2, vue, knockoutjs of anderen.
1maal gebruikt = verslaafd De rest is hierboven al genoemd voor een groot deel.
Stop asap. met jquery is ook een tip die ik wil meegeven. Het is ouderwets en niet meer nodig. Zeker niet met 2-way databinding frameworks.

[ Voor 22% gewijzigd door Guillome op 28-09-2016 12:07 ]

[Verwijderd]

Ik ben nog student applicatie-ontwikkeling. Wat voor library van JavaScript gebruiken jullie dan als JQuery niet meer "up to date" "is"?

[Ramon]

Spinal schreef op vrijdag 16 september 2016 @ 11:17:
Editor: PhpStorm
Framework: Angular (1)
Andere tools: Sass, grunt/makefile

jQuery is bij mij over het algemeen overbodig geworden. Dingen waar jQuery 3 jaar geleden goed in was zitten nu in browsers ingebakken en het zorgt alleen maar voor overhead. Idem voor jQuery UI.

Laatst nog een site gemaakt in "vanilla js", maar echt gelukkig werd ik daar ook niet van hoor. Het is veel meer typen en er zijn een aantal eigenaardigheden die jQuery mooi heeft opgelost, zoals loopen door een NodeList.

Qua CSS zou ik me eens gaan inlezen in Flexbox en Grid layout. Flexbox is nu al goed bruikbaar en maakt bepaalde dingen oneindig veel makkelijker te implementeren. Grid werkt op dit moment alleen in IE/Edge, maar het duurt niet lang meer voordat het in alle (desktop) browsers werkt (http://caniuse.com/#feat=css-grid)

Flexbox is zeker handig, maar Grid layout zou ik voorlopig nog even overslaan, met de huidige browsersupport heb je er niets aan ...

DJMaze schreef op vrijdag 16 september 2016 @ 13:00:
Editor: Geany
Framework: micro frameworks
Andere tools: Mercurial, Aqua Data Studio

jQuery sucks als je weet waarom

Goed onderbouwd advies

CSS3 en HTML5 doe ik alles in.

Don't we all

Guillome schreef op woensdag 28 september 2016 @ 12:01:
Ik zeg 1 ding, two-way databinding frameworks zoals angular 2, vue, knockoutjs of anderen.
1maal gebruikt = verslaafd De rest is hierboven al genoemd voor een groot deel.
Stop asap. met jquery is ook een tip die ik wil meegeven. Het is ouderwets en niet meer nodig. Zeker niet met 2-way databinding frameworks.

Tja van een library naar een framework, van de regen in de drup wat mij betreft. Je kan niet zomaar zeggen je moet a, b, c, d doen dan ben je een goede front-end developer.

Een goede front-end developer kijkt naar de site die hij/zij gaat maken en past zijn tools daar op aan. Hij gaat geen react+webpack setup optuigen voor een simpele drie-pagina brochure site.

[DJMaze]

Ramon schreef op dinsdag 04 oktober 2016 @ 22:43:
Laatst nog een site gemaakt in "vanilla js", maar echt gelukkig werd ik daar ook niet van hoor. Het is veel meer typen en er zijn een aantal eigenaardigheden die jQuery mooi heeft opgelost, zoals loopen door een NodeList.

Een NodeList is een meestal live. Als je de DOM aanpast wordt die geupdatet.
Je kan er gewoon een statische Array van maken hoor (net als jQuery).

JavaScript:

var nodes = Array.prototype.slice.call(document.querySelectorAll('.myClassName'), 0);
nodes.forEach(function(node,index){
    // doe iets met node
});

of live mee werken:

JavaScript:

Array.prototype.forEach.call(document.querySelectorAll('.myClassName'), function(node,index){
    // doe iets met node
});

En als je dat te vaak moet typen doe je gewoon

JavaScript:

NodeList.prototype.forEach = Array.prototype.forEach;

document.querySelectorAll('.myClassName').forEach(function(node,index){
    // doe iets met node
});

Ramon schreef op dinsdag 04 oktober 2016 @ 22:43:
Goed onderbouwd advies

Ik zou het kunnen onderbouwen maar dan krijg je een welles/nietes discussie. Het is gewoon mijn mening en je bent vrij om het er niet mee eens te zijn.

[Cyphax]

DJMaze schreef op woensdag 05 oktober 2016 @ 10:55:

Ik zou het kunnen onderbouwen maar dan krijg je een welles/nietes discussie. Het is gewoon mijn mening en je bent vrij om het er niet mee eens te zijn.

Maar het is toch veel interessanter om te weten waarom je die mening hebt? Dan kan je nog beslissen of je het ermee eens bent of niet. Neem juist die uitdaging aan zou ik zeggen!

Zelf maak ik m'n hobbyprojecten met PHP icm zoveel mogelijk vanilla javascript, en zo weinig mogelijk jQuery.
M'n werk doe ik met ASP.net en dan moet ik zeggen dat ik best wel fan ben van MVC en dat is heel goed te combineren met frameworks als Angular. De hoofdzakelijke reden dat ik dat thuis niet doe is omdat MS nog niet helemaal klaar is met het platform-onafhankelijk en makkelijk installeerbaar te maken op mijn Linux-server.

[ Voor 32% gewijzigd door Cyphax op 05-10-2016 11:02 ]

[DJMaze]

Cyphax schreef op woensdag 05 oktober 2016 @ 10:58:
Maar het is toch veel interessanter om te weten waarom je die mening hebt? Dan kan je nog beslissen of je het ermee eens bent of niet. Neem juist die uitdaging aan zou ik zeggen!

querySelector
Ik heb de oude Slickspeed aangepast zodat hij berekend in μs omdat JavaScript engines native draaien en in combinatie met de nieuwe CPU's http://dragonflycms.org/slickspeed/
Snelheden bij mij:
Native: 8315μs
Array.slice: 11207μs
jQuery3: 14154μs

Dit is natuulijk voor alle heel rap op een PC en dan vind men dit nadeel van jQuery niet opwegen tegen de voordelen qua programmeertijd.

Doe ik de test op een Mobiel (Nexus 5) dan is het:
Native: 29002μs
Array.slice: 75132μs
jQuery3: 60068μs

jQuery-UI
Ik heb een hele lijst van "WTF?!?" waarom dit een slecht idee is. Met name voor WAI-AA en touch screens.
Dit is niet het juiste topic daarvoor. Googlen helpt een hoop (met name de Calendar is hopeloos).

JavaScript leren
Je leert geen JavaScript, je leert jQuery.

Geheugen gebruik
Alles is een jQuery object en alles hangt er onder, inclusief node events.
Wat gebeurt er als je de DOM4 ChildNode.remove() of ChildNode.replaceWith() aanroept.
Waar zijn de jQuery.on() events gebleven?
Hoe zit het met de NodeList?
Wat gebeurt er met de cached DOM structuur van jQuery? (dit zit niet in v3 volgens mij)

CMS
Met name in Joomla is het een hell. Joomla heeft standaard helemaal geen jQuery. Wat gebeurt er:
- elke template en module laden hun eigen jQuery
- je website laad nu 1 of meerdere versies van jQuery dwars door elkaar heen
- conflicten met $ en jQuery aanroepen
- etc. etc.

Dit laatste probleem is natuurlijk niet de schuld van jQuery zelf, maar van iedereen die programmeert

jQuery was vroeger top toen browsers nog veel dingen niet konden (IE vooral), tegenwoordig is het niet meer nodig.

P.S. I.p.v. jQuery kan je ook eens kijken naar Zepto http://zeptojs.com/

[ Voor 4% gewijzigd door DJMaze op 05-10-2016 12:51 ]

[moijamie]

Verwijderd schreef op dinsdag 04 oktober 2016 @ 21:13:
Ik ben nog student applicatie-ontwikkeling. Wat voor library van JavaScript gebruiken jullie dan als JQuery niet meer "up to date" "is"?

Vue en React zijn redelijk goed.

[Ramon]

DJMaze schreef op woensdag 05 oktober 2016 @ 10:55:
[...]

Een NodeList is een meestal live. Als je de DOM aanpast wordt die geupdatet.
Je kan er gewoon een statische Array van maken hoor (net als jQuery).

JavaScript:

var nodes = Array.prototype.slice.call(document.querySelectorAll('.myClassName'), 0);
nodes.forEach(function(node,index){
    // doe iets met node
});

of live mee werken:

JavaScript:

Array.prototype.forEach.call(document.querySelectorAll('.myClassName'), function(node,index){
    // doe iets met node
});

En als je dat te vaak moet typen doe je gewoon

JavaScript:

NodeList.prototype.forEach = Array.prototype.forEach;

document.querySelectorAll('.myClassName').forEach(function(node,index){
    // doe iets met node
});

Toch een stuk meer typewerk dan jQuery, precies wat ik zei.

[...]

Ik zou het kunnen onderbouwen maar dan krijg je een welles/nietes discussie. Het is gewoon mijn mening en je bent vrij om het er niet mee eens te zijn.

De TS vraagt hoe hij zo snel mogelijk weer up-to-date kan zijn mbt front-end development. Zeggen "jQuery is kut" helpt niemand daarbij.

DJMaze schreef op woensdag 05 oktober 2016 @ 11:47:
[...]

querySelector
Ik heb de oude Slickspeed aangepast zodat hij berekend in μs omdat JavaScript engines native draaien en in combinatie met de nieuwe CPU's http://dragonflycms.org/slickspeed/
Snelheden bij mij:
Native: 8315μs
Array.slice: 11207μs
jQuery3: 14154μs

Dit is natuulijk voor alle heel rap op een PC en dan vind men dit nadeel van jQuery niet opwegen tegen de voordelen qua programmeertijd.

Doe ik de test op een Mobiel (Nexus 5) dan is het:
Native: 29002μs
Array.slice: 75132μs
jQuery3: 60068μs

jQuery-UI
Ik heb een hele lijst van "WTF?!?" waarom dit een slecht idee is. Met name voor WAI-AA en touch screens.
Dit is niet het juiste topic daarvoor. Googlen helpt een hoop (met name de Calendar is hopeloos).

JavaScript leren
Je leert geen JavaScript, je leert jQuery.

Geheugen gebruik
Alles is een jQuery object en alles hangt er onder, inclusief node events.
Wat gebeurt er als je de DOM4 ChildNode.remove() of ChildNode.replaceWith() aanroept.
Waar zijn de jQuery.on() events gebleven?
Hoe zit het met de NodeList?
Wat gebeurt er met de cached DOM structuur van jQuery? (dit zit niet in v3 volgens mij)

CMS
Met name in Joomla is het een hell. Joomla heeft standaard helemaal geen jQuery. Wat gebeurt er:
- elke template en module laden hun eigen jQuery
- je website laad nu 1 of meerdere versies van jQuery dwars door elkaar heen
- conflicten met $ en jQuery aanroepen
- etc. etc.

Dit laatste probleem is natuurlijk niet de schuld van jQuery zelf, maar van iedereen die programmeert

jQuery was vroeger top toen browsers nog veel dingen niet konden (IE vooral), tegenwoordig is het niet meer nodig.

P.S. I.p.v. jQuery kan je ook eens kijken naar Zepto http://zeptojs.com/

Allemaal goede punten maar geen redenen om jQuery niet te gebruiken. Tenzij je de volgende facebook gaat maken merk je niets van de performanceverschillen. Developerproductiviteit is (vind ik) belangrijker dan hipheid van de tool, als je een simpele site maakt kost het setuppen van je webpack config meer tijd dan je javascript schrijven. Kies dus de tool die bij je project past in plaats van naar aanleiding van een theoretische benchmark te concluderen dat jQuery langzaam is en het daarom te skippen.

[Guillome]

Voor een kleine site is jquery niet een ramp, maar voor een webshop of ander groots project moet je echt verder kijken dan jquery. Dat is gewoon verouderd. En ik vind de werkwijze van de 2-way databinding frameworks echt een revolutionaire vooruitgang.

[Urk]

Spinal schreef op vrijdag 16 september 2016 @ 11:17:
Editor: PhpStorm
Framework: Angular (1)
Andere tools: Sass, grunt/makefile

jQuery is bij mij over het algemeen overbodig geworden. Dingen waar jQuery 3 jaar geleden goed in was zitten nu in browsers ingebakken en het zorgt alleen maar voor overhead. Idem voor jQuery UI.

Qua CSS zou ik me eens gaan inlezen in Flexbox en Grid layout. Flexbox is nu al goed bruikbaar en maakt bepaalde dingen oneindig veel makkelijker te implementeren. Grid werkt op dit moment alleen in IE/Edge, maar het duurt niet lang meer voordat het in alle (desktop) browsers werkt (http://caniuse.com/#feat=css-grid)

Ik ben recent begonnen met een nieuwe website voor een klant en kwam daarbij het CSS Flexbox model tegen, ik wilde er graag mee beginnen totdat ik de browser support zag. Die is over het algemeen redelijk echter geen support voor Internet Explorer < v11. En dat vond ik toch een beetje jammer. Als IE10 nou nog ondersteund zou worden had ik het aangedurfd.
Bron: https://scotch.io/tutoria...o-css3-flexbox-properties en http://caniuse.com/#feat=flexbox

[NNF]

Flexbox in IE10 gaat best redelijk, het is alleen iets anders geïmplementeerd (omdat de standaard toen gewoon nog niet definitief was en aan verandering onderhevig) waardoor je andere properties/prefixes moet toevoegen. Maar daar hebben we Autoprefixer voor

[Ramon]

Marktaandeel van IE10 is lager dan IE9 of IE8 dus zou me daar niet al teveel van aantrekken. Verder flexbox is fantastisch dus gewoon gebruiken.

[orf]

Haha, dit topic is een mooi voorbeeld van how it feels to learn JavaScript in 2016.

jQuery sucks als je weet waarom

In de afgelopen jaren is veel veranderd in de buildsystemen. Voorheen vond iedereen grunt geweldig, nu mag het niet meer. Ook bower is uit den gratie, je kunt hetzelfde met NPM

WebPack voor linken/bundelen van NPM packages voor de browser.
- Babel voor het omzetten van ES6 JavaScript naar ES5.

Ik zeg 1 ding, two-way databinding frameworks zoals angular 2, vue, knockoutjs of anderen.

Letterlijke quotes uit dit topic, letterlijke quotes uit how it feels to learn JavaScript in 2016

[R2D2]

Ed Vertijsment schreef op dinsdag 20 september 2016 @ 23:08:

Wat ik je wil *afraden* is om gebruik te maken van Bootstrap, de reden hiervoor is dat Bootsrap ontzettend veel global styling aanlevert waar je bij simpele dingen alleen maar mee zit te klooien (we gebruiken ook geen global in backend, dus waar om wel in frontend). Daarnaast breekt Bootstrap (oorspronkelijk een prototyping framework) zo'n beetje elke best practice op frontend gebied...

Je hoeft niet alles te gebruiken van een framework... je kunt ook alleen gebruiken wat je nodig denkt te hebben.

Nu zit ik zelf bij een grote uitgever en wat ik in de kleine 3 jaar dat ik hier zit veel heb zien gebeuren is dat iedere front-end developer denkt zelf het wiel opnieuw uit te moeten vinden. Ik heb al meerdere zelf in elkaar geknutselde of exotische frameworks voorbij zien komen en er mankeert altijd wel wat aan.

Ik ben nu zelf bezig met een rebuild van Schoolbank (ja het bestaat nog) en daar heb ik gewoon lekker Foundation for sites onder geschoven, niet alleen lekker makkelijk omdat het "vervelende werk" al gedaan is maar alle documentatie e.d. staat gewoon online wat betekent dat ik het niet hoef te schrijven.

Daarnaast is het voordeel van een framework wat al even bestaat dat de meeste cross browser issues e.d. er al uit gehaald zijn... scheelt mij weer tijd die ik aan een leuke feature kan besteden.

Denken dat je zelf nog een grid framework moet gaan zitten bouwen e.d. is allemaal leuk en aardig maar echt een "waste of time" in mijn ogen. Naar mijn mening pak je gewoon iets wat op de plank ligt en wat goed in elkaar zit. Zelf iets gaan proberen te bouwen loopt vaak op niets meer uit dan een beetje "gekloot in de marge" als je het mij vraagt.

En dat alle Bootstrap/Foundation/*insert framework* sites er hetzelfde uit zouden zien heeft vaak meer te maken met de capaciteiten van de developer dan van het framework an sich ;-)

[Ed Vertijsment]

R2D2 schreef op donderdag 13 oktober 2016 @ 14:32:
Je hoeft niet alles te gebruiken van een framework... je kunt ook alleen gebruiken wat je nodig denkt te hebben.

Dat is vaak lastiger dan dat jet het doe voorkomen. Het selectief (her) gebruiken van bepaalde code is natuurlijk prima, het is vaak echter lastig om een library op zo'n manier te gebruiken.

Bootstrap ondersteund dit (losse sass libs inladen/zelf bootstrap samenstellen) maar dat maakt de re-use documentatie van veel componenten weer lastige. Moet je eerst je Bootstrap install weer uitbouwen.

Verder weet bijna elke programmeur dat globals evil zijn. Tag selectors als "h1", "p" en "li" op root niveau zijn gewoon globals, je kan ze "bitters" of "atoms" noemen maar het zijn nog steeds globals met alle nadelen van dien. Ik snap niet zo goed waarom dat in frontend land voor lief genomen wordt.

Bootstrap stikt van de globals en het inladen van Bootstrap breekt vaak genoeg andere componenten doordat die de styling van bootstrap oppakt.

R2D2 schreef op donderdag 13 oktober 2016 @ 14:32:
Nu zit ik zelf bij een grote uitgever en wat ik in de kleine 3 jaar dat ik hier zit veel heb zien gebeuren is dat iedere front-end developer denkt zelf het wiel opnieuw uit te moeten vinden. Ik heb al meerdere zelf in elkaar geknutselde of exotische frameworks voorbij zien komen en er mankeert altijd wel wat aan.

Ik ben nu zelf bezig met een rebuild van Schoolbank (ja het bestaat nog) en daar heb ik gewoon lekker Foundation for sites onder geschoven, niet alleen lekker makkelijk omdat het "vervelende werk" al gedaan is maar alle documentatie e.d. staat gewoon online wat betekent dat ik het niet hoef te schrijven.

Eens, het heeft geen zin om alles opnieuw te schrijven, ik ben ok zeker niet tegen het gebruik van libraries, ik gebruiker er genoeg. Om wat te noemen:

- Aurelia/React voor dynamische frontends
- Webpack foor bundling
- Babel voor transpiling
- Aurelia HTTP client voor ajax (met een custom npm lib wrapper erover voor OOP)
- Jasmine voor tests
- ... whatever fits the purpose

Verder maken we veel gebruik van bestaande patterns/methodieken. In ons geval werken we met BEM met een custom npm lib voor selectie/manipulatie (van modifiers). De reden dat we niet een bestaande BEM library is dat we een functioneel geschreven (stateless) library willen die geen <insert class/function name here> object teruggeeft maar gewoon een HTMLElement. Forwards compatibility is wel een handige feature in het "low level" deel van de applicatie.

Hier zijn bestaande ideeen en eigen libraries dus samengegaan. Overigens ook gewoon netjes gepublished/gedocumenteerd (https://www.npmjs.com/package/bem.js)

R2D2 schreef op donderdag 13 oktober 2016 @ 14:32:
Daarnaast is het voordeel van een framework wat al even bestaat dat de meeste cross browser issues e.d. er al uit gehaald zijn... scheelt mij weer tijd die ik aan een leuke feature kan besteden.

Het ligt er aan welke browser je target, als je een beetje een moderne support set target is compatibility nauwelijks een issue meer. Kwestie van autoprefixer aan je sass straat hangen en optioneel babel polyfill als je moderne dingen in JS wil doen.

R2D2 schreef op donderdag 13 oktober 2016 @ 14:32:
Denken dat je zelf nog een grid framework moet gaan zitten bouwen e.d. is allemaal leuk en aardig maar echt een "waste of time" in mijn ogen. Naar mijn mening pak je gewoon iets wat op de plank ligt en wat goed in elkaar zit. Zelf iets gaan proberen te bouwen loopt vaak op niets meer uit dan een beetje "gekloot in de marge" als je het mij vraagt.

Niet perse, wij maken vaak gebruik van Bourbon Neat (zonder Bourbon zelf) maar dat werkt niet voor elk project. Ik werk in sass/css volgens een pattern dat zich misschien nog het beste laat vergelijken met lexical scoping (misschien in omgekeerde vorm). Lang verhaal kort: elk block kan alleen iets zeggen binnen zijn eigen box model, niet erbuiten, dus ook geen margins om een blok zelf, alleen op child blocks. Uiteindelijk laat ik een "view block" de verschillende componenten uitlijnen.

Deze methodiek werkt erg goed als je modulaire websites bouwt waarbij de componenten opnieuw gesorteerd moeten kunnen worden. Ook voorkomt het dat het aanpassen van A invloed heeft op B. Het is alleen niet echt compatible met neat omdat Neat omdat dit grid graag marges zet voor "gutters". Dit is soms nuttig maar niet in het bovenstaande geval.

R2D2 schreef op donderdag 13 oktober 2016 @ 14:32:
En dat alle Bootstrap/Foundation/*insert framework* sites er hetzelfde uit zouden zien heeft vaak meer te maken met de capaciteiten van de developer dan van het framework an sich ;-)

Als je de default styling van een framework teniet gaat doen met extra stijl regels ben je volgens mij niet echt efficient bezig. Dan ben je dus:

- Tijd kwijt met het installeren van een framework
- Tijd kwijt met het terugdraaien van de defaults
- Tijd kwijt met het bouwen wat je oorspronkelijk wou maken

Zonder framework ben je vaak met alleen de laatste klaar.

Ik wil niet zeggen dat er geen functie is voor frameworks als Bootstrap (of Foundation) maar voor 9/10 use cases ben (iig) sneller zonder en produceer ik efficiëntere/sneller/overzichtelijkere/meer herbruikbare code.

Het los downloaden van bestaande (web)components vind ik een veel beter idee. Iemand heeft bijvoorbeeld al een datepicker geïmplementeerd in React of iets anders. Dat is prima te downloaden zonder dat de rest van mn applicatie verandert.

[R2D2]

Ed Vertijsment schreef op donderdag 13 oktober 2016 @ 23:21:
[...]

Dat is vaak lastiger dan dat jet het doe voorkomen. Het selectief (her) gebruiken van bepaalde code is natuurlijk prima, het is vaak echter lastig om een library op zo'n manier te gebruiken.

In het geval van Foundation (iets wat tegenwoordig mijn voorkeur heeft) niet, daar heb ik in de app.css en in de config yaml op een vrij simpele manier de controle over wat ik wel en niet wil gebruiken aan standaard zaken. Heb ik het niet nodig dan comment ik de desbetreffende regel... mocht ik het later toch nodig hebben dan uncomment ik de desbetreffende regel weer en heb ik het voor handen.

Je kunt dus net zo ver gaan met downsizen van Foundation als je voorkeur heeft, zelfs de global styling kan zonder problemen uitgezet worden.

Bootstrap ondersteund dit (losse sass libs inladen/zelf bootstrap samenstellen) maar dat maakt de re-use documentatie van veel componenten weer lastige. Moet je eerst je Bootstrap install weer uitbouwen.

Aangezien Bootstrap al een eeuwigheid bezig is met versie 4 en dat nooit af lijkt te komen ben ik al een tijdje weg gebleven bij het framework, je zal dus ongetwijfeld gelijk hebben ;-)

Verder weet bijna elke programmeur dat globals evil zijn. Tag selectors als "h1", "p" en "li" op root niveau zijn gewoon globals, je kan ze "bitters" of "atoms" noemen maar het zijn nog steeds globals met alle nadelen van dien. Ik snap niet zo goed waarom dat in frontend land voor lief genomen wordt.

Ik snap eerlijk gezegd niet zo goed wat daar mis mee is als het in 90% van de gevallen de lading prima dekt. Het is altijd balanceren op het randje van zo min mogelijk regels vs leesbaarheid en herbruikbaarheid. Iedere regel css gaat over de lijn dus als ik iets in 1 keer af kan dekken dan doe ik dat, moet ik het in een zeldzaam geval ergens een keer overschrijven... helemaal prima.

Er zijn natuurlijk opties als placeholders e.d. binnen je Sass maar als het niet specifiek hoeft dan heeft het mijn persoonlijke voorkeur dat ook niet te zijn.

Niet perse, wij maken vaak gebruik van Bourbon Neat (zonder Bourbon zelf) maar dat werkt niet voor elk project.

Ik heb het in het verleden ook veel gebruikt, alleen ook daar lijkt de ontwikkeling een beetje stil te vallen, hoe lang is men inmiddels al niet bezig met versie 5? Nadeel van Bourbon / Neat vond ik overigens dat ze geen autoprefixer gebruikten maar zelf weer allerlei @includes hanteerden voor o.a. flexbox, in V5 is men gelukkig wel gebruik gaan maken van Autoprefixer.

Als je de default styling van een framework teniet gaat doen met extra stijl regels ben je volgens mij niet echt efficient bezig. Dan ben je dus:

- Tijd kwijt met het installeren van een framework
- Tijd kwijt met het terugdraaien van de defaults
- Tijd kwijt met het bouwen wat je oorspronkelijk wou maken

Zonder framework ben je vaak met alleen de laatste klaar.

Ik wil niet zeggen dat er geen functie is voor frameworks als Bootstrap (of Foundation) maar voor 9/10 use cases ben (iig) sneller zonder en produceer ik efficiëntere/sneller/overzichtelijkere/meer herbruikbare code.

Het los downloaden van bestaande (web)components vind ik een veel beter idee. Iemand heeft bijvoorbeeld al een datepicker geïmplementeerd in React of iets anders. Dat is prima te downloaden zonder dat de rest van mn applicatie verandert.

Een framework installeren hoeft nog geen uren te duren... een complete Foundation setup kost me nog geen 15 minuten inclusief het uitzetten van zaken waarvan ik op voorhand al weet dat ik ze niet ga gebruiken, het aanpassen van de nodige settings en ik ben klaar om te gaan.

Op sommige vlakken ben ik het dus helemaal met je eens, en op sommige wat minder. Enige wat ik wil zeggen is dat er meerdere wegen zijn die naar Rome leiden ;-)

Het enige waar ik een bloedhekel aan heb vandaag de dag zijn de 100.000.000 tooltjes die men vandaag de dag nodig denkt te hebben voor de meest simpele dingen maar ze vervolgens vergeet bij te houden met als gevolg projecten die voor het eind bereikt te hebben al aan elkaar hangen met duct-tape

[ Voor 0% gewijzigd door R2D2 op 14-10-2016 13:04 . Reden: typo ]