De Devschuur Coffee Corner - Iteratie ➑

[.oisyn]

.edit: of deze:

[ Voor 36% gewijzigd door .oisyn op 23-01-2015 23:34 ]

[F.West98]

Rannasha schreef op woensdag 21 januari 2015 @ 21:28:
[...]


Wel goedkoop tanken in Luxemburg En de route over het Jura gebergte is erg mooi (alleen niet in de winter en niet in een bus )

Maar veel plezier op CERN F.West98! Ik zal morgen even zwaaien als ik langs rij

Maar daar hebben we niet getankt
En de tunnels door het gebergte waren erg mooi zo in de nacht!

Maar het was erg leuk! CMS vanbinnen bekeken, en meerdere projecten bekeken. Bijvoorbeeld datacenter en de drie (!) serverkasten die het hele CERN Internet Exchange vornen, waar de hele omgeving gebruik van maakt. Ze genereren er dus 1TB data per minuut waarvan een klein deel behouden blijft, wat ze opslaan op tapes.

Verder viel het me op dat het terrein van buiten net een verlaten industrieterrein is, terwijl daar dan echt baanbrekend onderzoek wordt gedaan...

[Douweegbertje]

CIXP zit ook 'maar' op 1-2 Gbit/s

Mja en verder word heel het onderzoek natuurlijk gedaan in een dik datacentrum(s) en via het 'grid'. Dus het is dan niet nodig dat iedereen daar zit. Overigens wel enorm veel data wat daar gegenereerd wordt.. ik dacht laatst nog te lezen dat ze nu iets van 80petabyte nu fysiek hebben opgeslagen, terwijl ze ook veel nog 'negeren'...

Af en toe lees ik mij wel eens in, in dit soort projecten. Net als google waarbij men denkt dat ze al ver over de exabyte zitten qua opslag Google bezit iets van 2% van alle servers in de wereld... Het enige wat jammer is, is dat google nooit veel verteld over daadwerkelijke cijfers.

[F.West98]

CERN zit op 100PB inmiddels. Maar 1% van 1% van de data wordt opgeslagen. Het verkeer van het grid is ongeveer 1% van het internet.

En wauw, we rijden atm als één van de eersten door de vers vannacht gevallen sneeuw in de omgeving Nijmegen/Arnhem.

[Caelorum]

En ze zijn nu pas aan het strooien op de A12 ^^ Duidelijk dat ze niet naar de weermannen hebben geluisterd gisteren.

[F.West98]

Ze hebben hier (Zwolle) ook maar half gestrooid en een beetje geschoven..
Maar het was net wel even heel hard aan het sneeuwen.

[SPee]

Het is hier zonnig en geen schijntje sneeuw. (omgeving Rotterdam)

[afraca]

dev10 schreef op vrijdag 23 januari 2015 @ 11:23:
[...]


Dat Command + links of rechts is inderdaad ronduit ruk. Gelukkig worden in eigenlijk alle invoerveldem op een Mac de Emacs keybindings ondersteund. Daarmee kun je met Ctrl + a naar het begin van een regel en met Ctrl + e naar het einde van een regel. Met Ctrl + f ga je een karakter vooruit en met Ctrl + b ga je een karakter achteruit. Als je dan Ctrl mapt op de Caps Lock toets werkt het al een stuk beter en hoef je je handen niet van de home-row af te halen. (Voordeel is dat de Emacs keybindings ook werken in de terminal)

Wow, voor m'n werk dev ik sinds een tijdje ook op een Mac, maar qua keyboard commands wou dat nog niet helemaal ideaal werken. (Meerdere virtual desktops en de magic mouse werkt wel fijn overigens!) Deze emacs bindings zijn wel interessant, zal ze maandag eens testen

[Ealanrian]

Caelorum schreef op zaterdag 24 januari 2015 @ 08:24:
En ze zijn nu pas aan het strooien op de A12 ^^ Duidelijk dat ze niet naar de weermannen hebben geluisterd gisteren.

Waarschijnlijk zijn ze weer aan het strooien, zout is helaas niet het wondermiddel wat men er van verwacht. Het gaat pas werken als het ook word ingereden als dat niet gebeurd blijft de sneeuw er gewoon bovenop liggen

[Caelorum]

Er moet inderdaad eerst wat vloeistof bijkomen voordat het gaat werken, maar de A12 is toch best druk en als ze wel hadden gestrooid had het om 8 uur echt niet zo dik gelegen. Is overigens ook geen probleem. Kan gebeuren, maar wel grappig dat ze meestal om echt niets strooien en als het dan wel nodig is het heel laat doen. Normaal merk je dan ook niets van eventuele sneeuw of ijzel op de A12 (tussen Arnhem en Utrecht iig).

[Caelorum]

Zucht... Uiteraard moet net die ene 2TB HDD overlijden waarvan ik dacht dat die nog wel 3-5 jaar meeging en daarom een backup nog niet had geregeld...
Ach ja.. De data is niet van levensbelang, dus heb nog wel een jaar ofzo om te beslissen of ik de gok ga wagen en de platters ga overzetten in een vergelijkbare HDD. Alleen jammer van die ~120E. Online backup was goedkoper geweest ^^

[ Voor 5% gewijzigd door Caelorum op 24-01-2015 20:22 ]

[Gamebuster]

Ik maak de laatste tijd veel spaghetti omdat het spotgoedkoop is, makkelijk te maken is, alle ingrediënten lang houdbaar zijn en ik het lekker vind. Ik maak het zelf met gehakt, tomaatblokjes uit blik, ui, knoflook, kruiden en pasta (duh).

De ingredienten koop ik in bulk bij groothandel en dump ik in de vriezer/koelkast. Mijn vriendin kan geen spaghetti meer zien

Ik moet op zoek naar meerdere simpele maar lekkere recepten

[ Voor 13% gewijzigd door Gamebuster op 25-01-2015 11:24 ]

[Caelorum]

Lasagne is ook best makkelijk. Merendeel van de tijd zit in het wachten op de oven. Laat zich alleen niet zo goed invriezen, maar het gehakt/tomaat mengsel dat er in gaat uiteraard wel.
Verder alle wok gerechten uiteraard. Even alles in een pan met koken water gooien en dan in een wok. Saus er bij en is denk ik al met al nog sneller dan spaghetti. Meeste zooi die er in gaat kan je ook best lang bewaren in de vriezer.

Bovenstaande aangevuld met pizza is zo ongeveer wat ik normaal eet. Af en toe afgewisseld met een stoofpot of iets dergelijks als ik zin en tijd heb, maar dat duurt altijd zo ongelooflijk lang.

[ Voor 18% gewijzigd door Caelorum op 25-01-2015 11:38 ]

[Gamebuster]

Suggestie voor lekker wokgerecht met houdbare en/of goedkope ingrediënten?

Ik heb wel zo'n "wokbrander" op mijn gasplaat, gebruik ik die ook eens een keer

Douweegbertje schreef op zondag 25 januari 2015 @ 02:38:
[...]


Gewoon de floors itereren en daar de specifieke on button click events aan hangen.

Hoewel ik dit wel een leuk spel vind, is het gewoon een beetje ruk dat je elke keer maar een beetje data extra krijgt. Ik heb geen zin om pas later rekening te gaan moeten houden met opeens 4 extra variabelen.

Er is toch gewoon een API documentatie?

[ Voor 95% gewijzigd door Gamebuster op 25-01-2015 11:45 ]

[Gamebuster]

*oeps

[ Voor 98% gewijzigd door Gamebuster op 25-01-2015 11:44 ]

[Caelorum]

Gamebuster schreef op zondag 25 januari 2015 @ 11:42:
Suggestie voor lekker wokgerecht met houdbare en/of goedkope ingrediënten?[...]

Lekker? Ik vind alles lekker, dus meestal pleur ik gewoon wat bij elkaar. Persoonlijk vind ik het belangrijkste dat er veel goed vlees in gaat. Dus goed kip of rundvlees. Mijn wokgerechten bestaan dan meestal ook uit zo'n 40% vlees, 20% groenten en 40% noodles ^^.
De saus moet je gewoon een beetje proberen. Je hebt kant en klare sausen van Amoy die best ok zijn, maar als je tijd hebt kan je natuurlijk ook je eigen woksaus maken. Het zal dan alleen wel experimenteren worden De basis is meestal toch wel olie, rijstazijn en sojasaus en dan daar naar smaak kruiden en andere zooi toevoegen.
Zelf heb ik hier een hele fijne olie staan. Is een fles olie waar ik een paar super hete pepers aan heb toegevoegd. Het is er niet heet van smaak van geworden, maar gegarandeerd dat je lippen achteraf aan het branden zijn

Gamebuster schreef op zondag 25 januari 2015 @ 11:42:
[...]Er is toch gewoon een API documentatie?

Jup, en die API is nog best wel karig, maar dat maakt het alleen maar leuker natuurlijk

[ Voor 11% gewijzigd door Caelorum op 25-01-2015 12:02 ]

[Struikrover]

Caelorum schreef op zondag 25 januari 2015 @ 12:01:
[...]

Lekker? Ik vind alles lekker, dus meestal pleur ik gewoon wat bij elkaar. Persoonlijk vind ik het belangrijkste dat er veel goed vlees in gaat. Dus goed kip of rundvlees. Mijn wokgerechten bestaan dan meestal ook uit zo'n 40% vlees, 20% groenten en 40% noodles ^^.
De saus moet je gewoon een beetje proberen. Je hebt kant en klare sausen van Amoy die best ok zijn, maar als je tijd hebt kan je natuurlijk ook je eigen woksaus maken. Het zal dan alleen wel experimenteren worden De basis is meestal toch wel olie, rijstazijn en sojasaus en dan daar naar smaak kruiden en andere zooi toevoegen.
Zelf heb ik hier een hele fijne olie staan. Is een fles olie waar ik een paar super hete pepers aan heb toegevoegd. Het is er niet heet van smaak van geworden, maar gegarandeerd dat je lippen achteraf aan het branden zijn

Grappig, bij mij is de verhouding altijd andersom. Minstens de helft groente en de rest vlees/mihoen

[Firesphere]

Mijn huisgenoot is jarig naar het schijnt.
Moet ik nu iets doen?

[WernerL]

Hem feliciteren?
[/captain obvious mode]

[ Voor 40% gewijzigd door WernerL op 25-01-2015 14:50 ]

[Gamebuster]

Geef hem 3 kussen op z'n wang en feliciteer hem

[Firesphere]

Teveel moeite.

[GateKeaper]

Firesphere schreef op zondag 25 januari 2015 @ 14:47:
Mijn huisgenoot is jarig naar het schijnt.
Moet ik nu iets doen?

Jezelf opsluiten in je kamer, en morgen zeggen dat je je verslapen hebt?

[Ealanrian]

GateKeaper schreef op zondag 25 januari 2015 @ 15:04:
[...]


Jezelf opsluiten in je kamer, en morgen zeggen dat je je verslapen hebt?

Dat word heel lastig voor hem nu

[azerty]

Ealanrian schreef op zondag 25 januari 2015 @ 15:17:
[...]

Dat word heel lastig voor hem nu

[Firesphere]

GateKeaper schreef op zondag 25 januari 2015 @ 15:04:
[...]


Jezelf opsluiten in je kamer, en morgen zeggen dat je je verslapen hebt?

Ealanrian schreef op zondag 25 januari 2015 @ 15:17:
[...]

Dat word heel lastig voor hem nu

Ik ontken het bestaan van WhatsApp. I reject your reality and substitute my own.

[Douweegbertje]

Als ik 'wok', want echt wokken kan ik simpelweg niet (moeilijk hoor ) dan is mijn verhouding meestal 100 kip, 200 groenten, 100 rijst. Meestal wordt het dan 400gram kipblokjes van de slager, dit is 5 cent duurder dan de kipfilets. Iets van 1,46 per 100g. Wellicht duurder dan de supermarkt maar de kwaliteit is veel beter en er zit geen ingespoten water in zoals de troep van de meeste supermarkten!. Vervolgens gewoon 4 zakken van de kant en klare wokgroente (of spaghetti/soep groente). Uiteindelijk dan basmati of zilvervliesrijst.
Verder gebruik ik ook een goede olie en redelijk wat knoflook, om het af te werken een sausje zonder te veel suikers.

Dit is wel meer een gerecht voor een goede lijn en tijdens het sporten, maar je kan het lekker goed opslaan in de diepvries!

[Ealanrian]

Firesphere schreef op zondag 25 januari 2015 @ 15:34:
[...]


[...]


Ik ontken het bestaan van WhatsApp. I reject your reality and substitute my own.

En zojuist heb je het weer onmogelijk gemaakt om te beweren dat je je hebt verslaapt

[Firesphere]

Ealanrian schreef op zondag 25 januari 2015 @ 15:44:
[...]

En zojuist heb je het weer onmogelijk gemaakt om te beweren dat je je hebt verslaapt

Dat was Tesla.

[Mercatres]

Wat heeft Elon Musk hier nu weer mee te maken?

Happy b'day Ealanrian

[Ealanrian]

Verdeel maar

[Mercatres]

Moet dat?

[Firesphere]

Mercatres schreef op zondag 25 januari 2015 @ 15:56:
Wat heeft Elon Musk hier nu weer mee te maken?

Happy b'day Ealanrian

spoiler:

De katten heten Dodge en Tesla

[Mercatres]

Firesphere schreef op zondag 25 januari 2015 @ 15:59:
[...]

spoiler:

De katten heten Dodge en Tesla

Oooooh Pics?

[Firesphere]

Tesla:
https://onedrive.live.com...kE&v=3&ithint=photo%2cjpg

Dodge:
https://onedrive.live.com...tA&v=3&ithint=photo%2cjpg

[Mercatres]

Is dat de mooiste kant van Tesla

[Firesphere]

Mercatres schreef op zondag 25 januari 2015 @ 16:08:
Is dat de mooiste kant van Tesla

Aangezien dat de enige kant is die ik op de foto krijg.... Zodra ze de koelkast in springt...
Misschien is deze iets charmanter
https://onedrive.live.com...Fs&v=3&ithint=photo%2cJPG

[Ealanrian]

Mercatres schreef op zondag 25 januari 2015 @ 16:08:
Is dat de mooiste kant van Tesla

Dat is een goeie weergave van haar gedrag....

[Firesphere]

Ealanrian schreef op zondag 25 januari 2015 @ 16:12:
[...]

Dat is een goeie weergave van haar gedrag....

Nou, zo'n ramp is Tesla ook weer niet.
Als ze niet mauwt
Of niet vervelend overal bij moet zijn
Of niet overal in moet klimmen
Of slaapt
Of slaapt vooral.

Tesla is heel lief!
Als ze aandacht krijgt van ellendeling. Of slaapt.

[ Voor 10% gewijzigd door Firesphere op 25-01-2015 16:19 ]

[Mercatres]

Mooie beestjes

// Edit: een linux-distro installeren op een oude Dell Vostro, heuy. Al twee distro's die de wireless driver niet aan de praat krijgen (Debian en openSuse), nu dan maar Mint...

[ Voor 84% gewijzigd door Mercatres op 25-01-2015 16:44 ]

[Firesphere]

DELETE FROM table WHERE `Data` = X
Ow crap.... dat is de live-database.

BRB

[Mercatres]

Firesphere schreef op zondag 25 januari 2015 @ 17:27:
DELETE FROM table WHERE `Data` = X
Ow crap.... dat is de live-database.

BRB

But first, let me post it on GoT!

[Firesphere]

Mercatres schreef op zondag 25 januari 2015 @ 17:28:
[...]

But first, let me post it on GoT!

Ik heb't al (grotendeels) hersteld Eerst een backup terug gezet enzo Ik ben niet helemaal gek.

[Verwijderd]

Firesphere schreef op zondag 25 januari 2015 @ 17:27:
DELETE FROM table WHERE `Data` = X
Ow crap.... dat is de live-database.

BRB

Bwahahahaha. En dat op een zondagavond.

[TripleQ]

Tegenwoordig schrijf ik altijd eerst het Where gedeelte van een delete/update querie. Te vaak te enthousiast op f5 geramd op productie :-p

[ Voor 3% gewijzigd door TripleQ op 25-01-2015 19:55 ]

[Sebazzz]

Of eerst SELECT voordat ik er een delete of update van maak

[Douweegbertje]

TripleQ schreef op zondag 25 januari 2015 @ 19:54:
Tegenwoordig schrijf ik altijd eerst het Where gedeelte van een delete/update querie. Te vaak te enthousiast op f5 geramd op productie :-p

Nog steeds slecht. Je schrijft eerste een SELECT om te zien wat je überhaupt gaat verwijderen en hoeveel records dit zijn.

[RayNbow]

Bah... mutable stuff...

[Ryur]

TripleQ schreef op zondag 25 januari 2015 @ 19:54:
Tegenwoordig schrijf ik altijd eerst het Where gedeelte van een delete/update querie. Te vaak te enthousiast op f5 geramd op productie :-p

Ik HEB zelfs geen schrijfrechten op productie! (op mijn normale account dan, heb een tweede account waar ik wel schrijfrechten zou hebben).
Ook nooit nodig gehad dan.

Gebruik wel vaak om te kijken welke waarden er staan, maar hoef bijna nooit te schrijven.

[TripleQ]

Douweegbertje schreef op zondag 25 januari 2015 @ 21:12:
[...]


Nog steeds slecht. Je schrijft eerste een SELECT om te zien wat je überhaupt gaat verwijderen en hoeveel records dit zijn.

Ja ok.... Doe ik ook wel

[Firesphere]

F.West98 schreef op maandag 26 januari 2015 @ 00:10:
[...]

Dat is toch underscore.js?

Zo te zien wel. Nog een extra library bovenop een berg libraries om iets simpels te doen wat met vanilla echt niet ingewikkeld is

Beste mensen, leer het nu eens, gebruik libraries als je ze nodig hebt, niet omdat het kan?

[F.West98]

Is het erg dat ik underscore gebruik omdat die .filter wel een stuk makkelijker en korter en overzichtelijker is dan het alternatief?
Of dat ik (een gestripte) jquery gebruik omdat DOM manipulatie en AJAX requests een stuk makkelijker zijn?
Of dat ik Reactive Extensions gebruik om het geheel dynamisch te updaten met async dingen zonder allemaal gezeik te hebben met volgordes e.d.?

Zo ja dan moet ik eens mijn keuzes gaan heroverwegen.

[Rutix]

F.West98 schreef op maandag 26 januari 2015 @ 00:10:
[...]

Dat is toch underscore.js?

Lodash gebruikt ook _ en heeft ook _.each

https://lodash.com/docs#forEach

[F.West98]

Ah het is wel lodash, als ik het netwerkverkeer mag geloven.
- Font Awesome
- jQuery
- Lodash
- Riot
- Codemirror
- Analytics

[Megamind]

Firesphere schreef op maandag 26 januari 2015 @ 00:25:
[...]

Beste mensen, leer het nu eens, gebruik libraries als je ze nodig hebt, niet omdat het kan?

Laat jij ook Java of C# links liggen als iets in C of assembly kan?

[Firesphere]

Megamind schreef op maandag 26 januari 2015 @ 01:11:
[...]

Laat jij ook Java of C# links liggen als iets in C of assembly kan?

Dat is, wat mij betreft, in het geval van javascript, een heel andere discussie.

[Douweegbertje]

Megamind schreef op maandag 26 januari 2015 @ 01:11:
[...]

Laat jij ook Java of C# links liggen als iets in C of assembly kan?

Je gebruikt een DB wrapper om iets te versimpelen, maar ook gewoon om het feit dat je het meerdere malen gaat gebruiken. Je wilt dan domweg niet iets 1000x gaan doen. Nja IMO idem voor het geval met JS. Ik gebruik redelijk veel frontend dingen, maar ik ga pas jQuery gebruiken als ik er zeker van weet dat het inladen van een extra "lib" het waard is.
Het verschil, en het geen wat firesphere wilt aantonen is (denk ik dan ); je moet niet direct "*bam* include lib X, Y, en Z".. doen terwijl je niet eens weet wat je gaat doen. Voor iedereen ligt de waarde misschien anders, maar af en toe zit de waarde hem in de kennis van een persoon, in plaats van het nu van de code.
Zet mening PHP'er eens voor de vraag: maak een DB wrapper. Tja, kunnen ze niet
Idem met; gebruik eens wat anders dan $('element').show(); , waarom include je een gehele lib om één element in de gehele website te hide/show?

Nja, perse lodash gebruiken omdat je dan "makkelijker kan itereren" is voor mij geen reden.

[ Voor 4% gewijzigd door Douweegbertje op 26-01-2015 02:07 ]

[curvemod]

TripleQ schreef op zondag 25 januari 2015 @ 19:54:
Tegenwoordig schrijf ik altijd eerst het Where gedeelte van een delete/update querie. Te vaak te enthousiast op f5 geramd op productie :-p

Yup, doe ik ook dat scheelt een hoop 😃

[RayNbow]

Douweegbertje schreef op maandag 26 januari 2015 @ 02:06:
Zet mening PHP'er eens voor de vraag: maak een DB wrapper. Tja, kunnen ze niet

Er zit een verschil tussen een library ontwerpen en er een gebruiken.

(Ik zie trouwens liever dat DB vendors SQL laten vallen en in plaats daarvan een fatsoenlijke API gaan leveren.)

Idem met; gebruik eens wat anders dan $('element').show(); , waarom include je een gehele lib om één element in de gehele website te hide/show?

Omdat show()/hide() declaratiever zijn en daarnaast wat handmatig state management uit handen neemt?

Nja, perse lodash gebruiken omdat je dan "makkelijker kan itereren" is voor mij geen reden.

Een for each constructie is declaratiever en geeft goed de intentie weer wat de programmeur bedoelde. Net zoals dat for en while iets declaratiever zijn dan compares en gotos.

[Caelorum]

Douweegbertje schreef op maandag 26 januari 2015 @ 02:06:
[...]
Nja, perse lodash gebruiken omdat je dan "makkelijker kan itereren" is voor mij geen reden.

In dit geval is het al aanwezig of je het gebruikt of niet dus slaat de hele discussie en jouw startende opmerking nergens op.

RayNbow schreef op maandag 26 januari 2015 @ 06:22:
[...]Omdat show()/hide() declaratiever zijn en daarnaast wat handmatig state management uit handen neemt?
[...]

Mja, ik geef ze wel gelijk dat als dat het enige is dat je gaat gebruiken, het wel een beetje jammer is om zoveel data binnen te hengelen terwijl je het zelf ook vrij snel kan schrijven.

[HuHu]

Caelorum schreef op maandag 26 januari 2015 @ 08:12:

[...]

Mja, ik geef ze wel gelijk dat als dat het enige is dat je gaat gebruiken, het wel een beetje jammer is om zoveel data binnen te hengelen terwijl je het zelf ook vrij snel kan schrijven.

Als je libraries uit een openbare bron of CDN haalt (zoals https://developers.google.com/speed/libraries/ ), dan heb je grote kans dat 't toch al in de browser-cache zit.

edit: bijvoorbeeld zo:

HTML:

        <!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if offline -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.0/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="/js/vendor/jquery-1.11.0.min.js"><\/script>')</script>

[ Voor 25% gewijzigd door HuHu op 26-01-2015 08:45 ]

[RayNbow]

Caelorum schreef op maandag 26 januari 2015 @ 08:12:
[...]

Mja, ik geef ze wel gelijk dat als dat het enige is dat je gaat gebruiken, het wel een beetje jammer is om zoveel data binnen te hengelen terwijl je het zelf ook vrij snel kan schrijven.

De implementatie in jQuery voor showHide() is anders toch al snel een 40-tal regels code.

[Caelorum]

HuHu schreef op maandag 26 januari 2015 @ 08:42:
[...]

Als je libraries uit een openbare bron of CDN haalt (zoals https://developers.google.com/speed/libraries/ ), dan heb je grote kans dat 't toch al in de browser-cache zit.[...]

Maar zeker kan je er niet van zijn en de kans vermindert ook behoorlijk als je een specifieke library versie gaat lopen gebruiken die verder bijna niemand gebruikt (bijv. omdat het veroudert is of juist erg nieuw) of omdat je doelgroep gewoon niet wil meewerken. Er zijn nog wel andere voordelen uiteraard, maar het gebruik van een CDN is geen heilige graal ofzo.

RayNbow schreef op maandag 26 januari 2015 @ 09:01:
[...]
De implementatie in jQuery voor showHide() is anders toch al snel een 40-tal regels code.

code:

En dat is nogal 
{
     ruim

 uitgeschreven

}

^^
Daarnaast ging het in dit geval om een enkel element te hiden of showen en niet om sets van elementen.
Komt nog bij dat het nog steeds jammer is om 82KB (compressed!) als je maar een handvol functies gaat gebruiken. Nog afgezien van of je een CDN gebruikt of niet, want ook dat garandeert niet dat de gebruiker het niet alsnog moet downloaden.
Heb overigens geen idee wat verder de performance impact is van het moeten laden en parsen van 82KB tekst bestand door de browser. Het zal wel niet veel zijn, maar toch weer extra werk.

[Alex)]

Ryur schreef op zondag 25 januari 2015 @ 21:37:
[...]

Ik HEB zelfs geen schrijfrechten op productie! (op mijn normale account dan, heb een tweede account waar ik wel schrijfrechten zou hebben).
Ook nooit nodig gehad dan.

Gebruik wel vaak om te kijken welke waarden er staan, maar hoef bijna nooit te schrijven.

Ik heb onlangs helaas toegang gekregen tot de productie-omgeving.


De titel van dit topic ziet er een beetje funky uit i.v.m. andere pagina's:

[ Voor 12% gewijzigd door Alex) op 26-01-2015 09:33 ]

[Woy]

Modbreak:

Ik heb het verhaal over de Elevators game afgesplitst naar [JS]Elevator Saga The elevator programming game,

De discussie die aan de hand daarvan onstaan is over het gebruik van libraries heb ik hier laten staan om te zorgen dat dat topic niet meteen offtopic gaat

[ Voor 12% gewijzigd door Woy op 26-01-2015 09:38 ]

[Adion]

HuHu schreef op maandag 26 januari 2015 @ 08:42:
[...]
Als je libraries uit een openbare bron of CDN haalt (zoals https://developers.google.com/speed/libraries/ ), dan heb je grote kans dat 't toch al in de browser-cache zit.

Misschien maakt het voor velen niet echt uit, maar denk er ook aan dat Google vanuit China bijvoorbeeld zonder VPN niet te bereiken is, dus als je site verder wel bereikbaar is in China zal je alsnog problemen hebben als deze libraries niet geladen kunnen worden.

[Alex)]

Adion schreef op maandag 26 januari 2015 @ 09:37:
[...]

Misschien maakt het voor velen niet echt uit, maar denk er ook aan dat Google vanuit China bijvoorbeeld zonder VPN niet te bereiken is, dus als je site verder wel bereikbaar is in China zal je alsnog problemen hebben als deze libraries niet geladen kunnen worden.

En als Google over een paar jaar zegt "Die hosting van allerlei JS-libraries op ons CDN mag ook wel eens aan banden worden gelegd" zit je ook met een groot probleem.

Het zou niet voor het eerst zijn dat Google een wijdgebruikte functie de nek omdraait.

[Afvalzak]

Alex) schreef op maandag 26 januari 2015 @ 09:30:
[...]

Ik heb onlangs helaas toegang gekregen tot de productie-omgeving.


De titel van dit topic ziet er een beetje funky uit i.v.m. andere pagina's:
[afbeelding]

Dat komt door die dat "8-ball" teken aan het eind, dat snappen sommige Chrome versies niet helemaal volgens mij.

Hier geen last van overigens.

[Robbiedobbie]

Bahbah, Ik zit weer eens in mijn favoriete week: Tentamenweek

Daarom ga ik mezelf maar een beetje opvrolijken met een 28" 4k monitor (Die komt vanmiddag binnen)

[jbdeiman]

Douweegbertje schreef op maandag 26 januari 2015 @ 02:06:
[...]

Zet mening PHP'er eens voor de vraag: maak een DB wrapper. Tja, kunnen ze niet

Dit geldt voor heel veel ontwikkelaars in heel veel talen, die vooral gebruik maken van "bestaande libraries" en zich niet (meer) altijd afvragen waarom bepaalde keuzes daarin zijn gemaakt.

[RayNbow]

Caelorum schreef op maandag 26 januari 2015 @ 09:14:
[...]

code:

En dat is nogal 
{
     ruim

 uitgeschreven

}

35 regels als ik declaraties op 1 regel prop, alle functieaanroepen op 1 regel prop, de accolades van ifs weggooi als die niet nodig zijn en tenslotte alle lege witregels verwijder. Tel daarbij op dat ik niet de implementatie van hulpfuncties meereken.

Ergo, een 40-tal regels aan code.

Heb overigens geen idee wat verder de performance impact is van het moeten laden en parsen van 82KB tekst bestand door de browser. Het zal wel niet veel zijn, maar toch weer extra werk.

Dat kun je cachen en dat valt in het niets met de tijd die het kost om het over het internet te pompen.

[HuHu]

Adion schreef op maandag 26 januari 2015 @ 09:37:
[...]

Misschien maakt het voor velen niet echt uit, maar denk er ook aan dat Google vanuit China bijvoorbeeld zonder VPN niet te bereiken is, dus als je site verder wel bereikbaar is in China zal je alsnog problemen hebben als deze libraries niet geladen kunnen worden.

Alex) schreef op maandag 26 januari 2015 @ 09:38:
[...]

En als Google over een paar jaar zegt "Die hosting van allerlei JS-libraries op ons CDN mag ook wel eens aan banden worden gelegd" zit je ook met een groot probleem.

Het zou niet voor het eerst zijn dat Google een wijdgebruikte functie de nek omdraait.

In het stukje voorbeeldcode dat ik geef zit nota bene nog een fallback voor het geval dat de library niet (meer) bij Google verkrijgbaar is. Dat is dus geen enkel probleem.

[Rutix]

In het geval van lodash betwijfel ik of ik methods kan schrijven die net zo performen als in lodash. Lodash is geschreven om te performen en daar zijn ook goede tests enzo voor. Ik weet dat sommige libraries overused worden maar sommige zijn ook wel rete handig.

[Jegorex]

Afvalzak schreef op maandag 26 januari 2015 @ 09:38:
[...]

Dat komt door die dat "8-ball" teken aan het eind, dat snappen sommige Chrome versies niet helemaal volgens mij.

Hier geen last van overigens.

Thuis heb ik er met de nieuwste Chrome versie ook geen last van.
Op het werk heb ik er met dezelfde Chrome versie wel "last" van.

Kan het zijn dat het probleem wel bij Win7 voorkomt en niet bij Win8.1?

[Adion]

HuHu schreef op maandag 26 januari 2015 @ 09:48:
[...]


[...]

In het stukje voorbeeldcode dat ik geef zit nota bene nog een fallback voor het geval dat de library niet (meer) bij Google verkrijgbaar is. Dat is dus geen enkel probleem.

Ah ik zie het nu, jammer dat Google dat in hun eigen voorbeeldcode ook niet aangeeft.

[Afvalzak]

Jegorex schreef op maandag 26 januari 2015 @ 09:50:
[...]

Thuis heb ik er met de nieuwste Chrome versie ook geen last van.
Op het werk heb ik er met dezelfde Chrome versie wel "last" van.

Kan het zijn dat het probleem wel bij Win7 voorkomt en niet bij Win8.1?

Could be, ik heb de laatste Chrome en Win 8 hier.

[EddoH]

Het is maandag en ik heb geen zin.

[Mercatres]

Moggeh.

[Struikrover]

Ik snap op zich dat er op het gebruik van libraries geageerd wordt, maar het is de realiteit. Als je een devver voor de keuze stelt om zich op zijn project te focussen in plaats van de core functionaliteit nogmaals uitvinden terwijl dit allang door derde partijen mooi is opgeschreven en getest, lijkt het me een makkelijke keuze.

Functies geimplementeerd in libraries als Lodash, jQuery, Bluebird etc. zijn vaak erg snel, goed getest, en open source zodat je ze als je wilt gewoon kunt pakken en in je source steken (mits je die zelf ook open source uitbrengt). Zo heb je de keuze: als je veel lodash functies gaat gebruiken pak je de lib, als je er maar eentje nodig heb haal je die gewoon uit de lodash source.
Mijns inziens kan dit alleen maar voor minder bugs in JS apps zorgen. Zie ik dat fout?

[wouterwouter2]

Adion schreef op maandag 26 januari 2015 @ 09:37:
[...]

Misschien maakt het voor velen niet echt uit, maar denk er ook aan dat Google vanuit China bijvoorbeeld zonder VPN niet te bereiken is, dus als je site verder wel bereikbaar is in China zal je alsnog problemen hebben als deze libraries niet geladen kunnen worden.

Precies veel sites die maar half werken omdat jQuery vanaf de Google cdn wordt geladen, hetzelfde geldt voor sites die fonts van Google laden of sites die Facebook of Twitter buttons niet asynchroon laden...

[Ryur]

Struikrover schreef op maandag 26 januari 2015 @ 10:36:
Zo heb je de keuze: als je veel lodash functies gaat gebruiken pak je de lib, als je er maar eentje nodig heb haal je die gewoon uit de lodash source.

Ik snap je punt.
Krijg alleen zelf kriebels om een functie "gewoon" uit de source te halen.

Wat als daar net een bug inzit, en hij wordt met een hotfix later gefixt; dan zou je weer moeten kopieren?!

[EddoH]

Struikrover schreef op maandag 26 januari 2015 @ 10:36:
Ik snap op zich dat er op het gebruik van libraries geageerd wordt, maar het is de realiteit. Als je een devver voor de keuze stelt om zich op zijn project te focussen in plaats van de core functionaliteit nogmaals uitvinden terwijl dit allang door derde partijen mooi is opgeschreven en getest, lijkt het me een makkelijke keuze.

Functies geimplementeerd in libraries als Lodash, jQuery, Bluebird etc. zijn vaak erg snel, goed getest, en open source zodat je ze als je wilt gewoon kunt pakken en in je source steken (mits je die zelf ook open source uitbrengt). Zo heb je de keuze: als je veel lodash functies gaat gebruiken pak je de lib, als je er maar eentje nodig heb haal je die gewoon uit de lodash source.
Mijns inziens kan dit alleen maar voor minder bugs in JS apps zorgen. Zie ik dat fout?

Met het gebruik van libraries opzich is niets mis, maar het includen van een lib om er vervolgens maar 1 a 2 functies van te gebruiken wel. Een collega hier heeft er ook een handje van om jQuery te gebruiken op het moment dat hij 1 functionaliteit mist. Een functionaliteit die je bijvoorbeeld met 1 regeltje vanilla JS zo voor elkaar hebt. Dat is gewoon niet efficient, en komt de performance en leesbaarheid ook niet ten goede.

[incaz]

Neu, maar elke keer handmatig zo'n js-regeltje te schrijven om er vervolgens achter te komen dat je wellicht toch beter jquery gewoon had kunnen toevoegen aan je project... 't is altijd een beetje schipperen en hopen dat je de juiste keuze maakt.

Hmm. Ik haat git maar ik haat ook svn. Ongelofelijk hoe makkelijk ik het voor elkaar krijg om die dingen steeds in unresolvable states te krijgen.

[HuHu]

Alles begint met 1 of 2 functies. Die schrijf je dan zelf, in "vanilla js". En dan komt er een derde functie bij. En een vierde. En voor je het weet zit je hele project vol met halfbakken zelfgeschreven functies, die ook allemaal net anders werken dan het equivalent in jQuery dat iedereen kent.

Ik zou gewoon vanaf het begin direct een goede library pakken. Ook al is het maar voor 1 functie.

[Struikrover]

Ryur schreef op maandag 26 januari 2015 @ 10:56:
[...]

Ik snap je punt.
Krijg alleen zelf kriebels om een functie "gewoon" uit de source te halen.

Wat als daar net een bug inzit, en hij wordt met een hotfix later gefixt; dan zou je weer moeten kopieren?!

Klopt. Wat nu als je zelf de implementatie schrijft, en er zit een bug in? Dan moet je zelf ook een hotfix doen. Ik zie het verschil niet, behalve dat je de lib in de gaten moet houden. Daarom zou het mooi zijn als meer libs modulair worden. Geef aan welke functies je wilt, en je krijgt een kleinere versie die je zelf in je task runner kunt gebruiken om uiteindelijk 1 minified js file te behouden.

EddoH schreef op maandag 26 januari 2015 @ 10:57:
[...]


Met het gebruik van libraries opzich is niets mis, maar het includen van een lib om er vervolgens maar 1 a 2 functies van te gebruiken wel. Een collega hier heeft er ook een handje van om jQuery te gebruiken op het moment dat hij 1 functionaliteit mist. Een functionaliteit die je bijvoorbeeld met 1 regeltje vanilla JS zo voor elkaar hebt. Dat is gewoon niet efficient, en komt de performance en leesbaarheid ook niet ten goede.

Maar zoals ik al zei, vaak zijn die third party lib functies juist erg performant. Vaak kun je ze ook in hun geheel includen in je build, dan heb je (zoals hierboven beschreven) nog maar 1 minified JS file. Dan is het enige verschil nog, dat je bij page load iets meer kB binnenhaalt, maar dat daarna je app wel beter en meer bugvrij presteert. Is die eigen implementatie het verschil in page load waard? Dat moet je voor jezelf bepalen, maar ik doe de moeite al niet meer tegenwoordig.

[Douweegbertje]

Struikrover schreef op maandag 26 januari 2015 @ 10:36:
Ik snap op zich dat er op het gebruik van libraries geageerd wordt, maar het is de realiteit. Als je een devver voor de keuze stelt om zich op zijn project te focussen in plaats van de core functionaliteit nogmaals uitvinden terwijl dit allang door derde partijen mooi is opgeschreven en getest, lijkt het me een makkelijke keuze.

Functies geimplementeerd in libraries als Lodash, jQuery, Bluebird etc. zijn vaak erg snel, goed getest, en open source zodat je ze als je wilt gewoon kunt pakken en in je source steken (mits je die zelf ook open source uitbrengt). Zo heb je de keuze: als je veel lodash functies gaat gebruiken pak je de lib, als je er maar eentje nodig heb haal je die gewoon uit de lodash source.
Mijns inziens kan dit alleen maar voor minder bugs in JS apps zorgen. Zie ik dat fout?

Meer code is meer bugs, meer compatibliteitsissues, meer kennis nodig etc.. etc.
Soms is het juist simpel houden en iets native 'opschrijven' 'simpeler' dan een lib includen en zo'n functie gebruiken.
Nja, er zal vast wel een breakpoint zijn waarin het weer waard is om een lib te gebruiken oid, maar voor een single function? Meh.

[Struikrover]

Douweegbertje schreef op maandag 26 januari 2015 @ 11:02:
[...]


Meer code is meer bugs, meer compatibliteitsissues, meer kennis nodig etc.. etc.
Soms is het juist simpel houden en iets native 'opschrijven' 'simpeler' dan een lib includen en zo'n functie gebruiken.
Nja, er zal vast wel een breakpoint zijn waarin het weer waard is om een lib te gebruiken oid, maar voor een single function? Meh.

Oke, je zegt "meer code is meer bugs". Stel, je schrijft zelf een random Lodash functie. Dan heb je ook meer code toegevoegd. Misschien wel meer dan de Lodash implementatie.

Als dat dan de enige functie is die je gebruikt, welke implementatie heeft dan meer kans om bugs te bevatten: jouw eigen snel in elkaar geschreven functie zonder unit tests, of die van lodash? En welke is denk je sneller? Eentje die je zelf hebt geschreven omdat je iets anders voor elkaar wilt krijgen, of eentje die is geschreven puur om die functie te bieden, met het oog op compatibility en andere quirks waar je niet snel aan zou denken (JS heeft er ten slotte genoeg).

[TheNephilim]

HuHu schreef op maandag 26 januari 2015 @ 11:00:
Alles begint met 1 of 2 functies. Die schrijf je dan zelf, in "vanilla js". En dan komt er een derde functie bij. En een vierde. En voor je het weet zit je hele project vol met halfbakken zelfgeschreven functies, die ook allemaal net anders werken dan het equivalent in jQuery dat iedereen kent.

Ik zou gewoon vanaf het begin direct een goede library pakken. Ook al is het maar voor 1 functie.

Wij hebben ook altijd jQuery standaard in onze eigen 'boiler template' voor WordPress thema's zitten. Als het thema klaar is kijken we gewoon even wat er niet gebruikt word en mikken we dergelijke libs etc. er uit.

[EddoH]

Struikrover schreef op maandag 26 januari 2015 @ 11:01:


Maar zoals ik al zei, vaak zijn die third party lib functies juist erg performant. Vaak kun je ze ook in hun geheel includen in je build, dan heb je (zoals hierboven beschreven) nog maar 1 minified JS file. Dan is het enige verschil nog, dat je bij page load iets meer kB binnenhaalt, maar dat daarna je app wel beter en meer bugvrij presteert. Is die eigen implementatie het verschil in page load waard? Dat moet je voor jezelf bepalen, maar ik doe de moeite al niet meer tegenwoordig.

Ik betwijfel of alle code parsen + binnenhalen + de aanroep zoveel sneller is dan een eigen brouwsel, maar dit is natuurlijk compleet afhankelijk van de context. Weinig over te zeggen dus.

Ik prefereer zo min mogelijk ballast, onderhoud en leesbaarheid(al die libs hebben weer hun eigen stijl) boven externe libs ja.
Daarnaast werk ik nog wel eens met platforms waar een HTTP GET 100x langzamer is dan op een gemiddelde pc, en dan ga je die extra lib echt wel merken.

[Struikrover]

Maar hoezo zou je iets extra's moeten binnenhalen? Je kunt libs als lodash, jquery, etc toch gewoon op een specifieke versie downloaden en streamlinen in je build proces? Dan houd je, voor de zoveelste keer, gewoon 1 minified JS file over met je eigen JS plus je dependencies.

[EddoH]

Struikrover schreef op maandag 26 januari 2015 @ 11:08:
Maar hoezo zou je iets extra's moeten binnenhalen? Je kunt libs als lodash, jquery, etc toch gewoon op een specifieke versie downloaden en streamlinen in je build proces? Dan houd je, voor de zoveelste keer, gewoon 1 minified JS file over met je eigen JS plus je dependencies.

Plus extra parse overhead + grotere files(sommige van onze webapps worden over 2G geladen) + andere syntax, voor 1 functie die je misschien in 1 native regeltje zelf had kunnen maken. Nah.
Maar wederom: ik heb het hier niet over krampachtig libs vermijden. Ik heb het over klakkeloos voor elk wissewasje een lib gebruiken.

[Struikrover]

De waarheid zal wel in het midden zitten. Ik moet zeggen dat ik nog nooit een kritische applicatie in JS heb gemaakt waarbij dataverbruik van het grootste belang was. Dit is natuurlijk het geval zodra je heel hard moet upscalen omdat je tienduizenden gebruikers hebt. Dan wordt iedere kB belangrijk, en speelt snelheid ook een grote rol. Maar dan mag je ook verwachten dat er een devver op het project zit die zoveel verstand van zaken heeft, dat hij/zij de keuze kan maken tussen third party lib of een goede eigen implementatie.
Het blijft een menselijke beslissing in een afweging natuurlijk. Zie het als een ROC curve tussen ontwikkelsnelheid en performance. Ergens ligt de optimale waarde voor het project

[Douweegbertje]

Struikrover schreef op maandag 26 januari 2015 @ 11:05:
[...]


Oke, je zegt "meer code is meer bugs". Stel, je schrijft zelf een random Lodash functie. Dan heb je ook meer code toegevoegd. Misschien wel meer dan de Lodash implementatie.

Als dat dan de enige functie is die je gebruikt, welke implementatie heeft dan meer kans om bugs te bevatten: jouw eigen snel in elkaar geschreven functie zonder unit tests, of die van lodash? En welke is denk je sneller? Eentje die je zelf hebt geschreven omdat je iets anders voor elkaar wilt krijgen, of eentje die is geschreven puur om die functie te bieden, met het oog op compatibility en andere quirks waar je niet snel aan zou denken (JS heeft er ten slotte genoeg).

Nja je noemt heel wat dingen op maar even bijv. jquery vs native js aangezien ik amper/niet lodash gebruik; vele functies zijn native sneller en simpeler
Ja, jquery is dan soms uitgebreider en makkelijker maar het biedt geen garantie dat je code "beter" is. Alleen met bepaalde variabelen kun je voordeel ervaren.

Overigens; http://jsperf.com/native-vs-array-js-vs-underscore/8

[Struikrover]

Een goede reden inderdaad om Lodash ipv underscore te gebruiken .

Tja, je moet inderdaad wel weten welke lib je gebruikt, anders ben je al gauw de l*l als je denkt dat je performance wint. Dat is ook het lastige van libs, er wordt lang niet altijd getest of ze beter zijn dan native.

[GateKeaper]

M.b.t. de library's.. Omdat ik deze discussie toch enigzins begonnen ben met de opmerking dat lodash beschikbaar is in de elevator game.

Libraries standaard maar includen omdat ze één handige functie bevatten, lijkt me niet erg slim nee. Over iedere lib die je include moet gewoon goed worden nagedacht.

Lodash is er echter één, die wat mij betreft standaard geinclude mag worden. Hij is maar 11kb groot (gzipped), maar bevat echt veel handige utils.

[].forEach werkt niet in elke browser, _.each (of _.forEach) wel. [].map().reduce() werkt niet in elke browser, _.map() en _.reduce() wel.

Ook het filteren, met _.filter, _.where, en _.find werkt nogal verdomd handig. De hoogste floor vinden? Native js leest al een stuk lastiger dan _.max(floors, 'level').level; Alleen de levels in een array krijgen? _.pluck(floors, 'level') -> [1,2,3,4,5]. Floor 3 vinden? _.where(floors, { level: 3 }); Daar ga ik echt geen for of while lus meer voor gebruiken.

Mijn tip om op de lodash aanwezigheid te attenderen, was dus geen tip om makkelijker te ittereren, maar meer een tip voor het bredere denkwerk.

[EddoH]

Struikrover schreef op maandag 26 januari 2015 @ 11:25:
Tja, je moet inderdaad wel weten welke lib je gebruikt, anders ben je al gauw de l*l als je denkt dat je performance wint. Dat is ook het lastige van libs, er wordt lang niet altijd getest of ze beter zijn dan native.

Nou haal je wel een klein beetje je eigen argumenten van net onderuit he

[Alex)]

Om een hele library te includen voor een paar kleine functies vind ik een beetje onzin, het zelf schrijven van die functies (en het debuggen ervan) weegt in mijn ogen nog niet op tegen de meerkost die een library met zich meebrengt (bandbreedte, laadtijden, het bijwerken van die libraries wanneer nodig, enz.)

Een simpele functie als "pluk iets uit een lijst" kun je bijvoorbeeld ook zo schrijven:

JavaScript:

Array.prototype.Where = function (predicate) {
    var result = [];
    for (var i = 0; i < this.length; i++) {
        if (predicate(this[i])) {
            result.push(this[i]);
        }
    }

    return result;
};

Nou kan dit stukje code ongetwijfeld nog veel beter, maar voor enkel intern gebruik voldoet het in mijn ogen prima. Zo zou je moeten checken of predicate wel een function is en zou er nog iets van foutafhandeling in kunnen.

[Acid_Burn]

Aaarg... ik moet hier een verklaring geven waarom iets werkt zoals het werkt in een oud pakket (source is 14 jaar oud) welke ik zelf niet eens geschreven heb en er geen commentaar bij zit verwijzend naar de norm. Nu heb ik al zitten spitten in de norm, maar ik kan het nog steeds niet verklaren lekker dan.

[Struikrover]

EddoH schreef op maandag 26 januari 2015 @ 11:30:
[...]


Nou haal je wel een klein beetje je eigen argumenten van net onderuit he

Hahaha klopt . Ik zeg ook niet dat het een easy feat is. Maar sommige libs zijn wel echt handig t.o.v. native om te gebruiken. Ik noem maar Bluebird voor Promises, en Lodash voor handige array en object functies.

[GateKeaper]

Alex) schreef op maandag 26 januari 2015 @ 11:30:

Een simpele functie als "pluk iets uit een lijst" kun je bijvoorbeeld ook zo schrijven:

JavaScript:

Array.prototype.Where = function (predicate) {
    var result = [];
    for (var i = 0; i < this.length; i++) {
        if (predicate(this[i])) {
            result.push(this[i]);
        }
    }

    return result;
};

Nou kan dit stukje code ongetwijfeld nog veel beter, maar voor enkel intern gebruik voldoet het in mijn ogen prima. Zo zou je moeten checken of predicate wel een function is en zou er nog iets van foutafhandeling in kunnen.

Bestaande types prototypen is sowieso al een slecht idee. Aangezien jij geen controle hebt over het Array object, weet je niet wanneer jouw code ophoudt te werken.

En natuurlijk kan je alles ook zelf schrijven, maar jouw huidige versie (hierboven), is al niet gelijk aan de lodash _.where:

JavaScript:

//https://lodash.com/docs#where
var characters = [
  { 'name': 'barney', 'age': 36, 'pets': ['hoppy'] },
  { 'name': 'fred',   'age': 40, 'pets': ['baby puss', 'dino'] }
];

_.where(characters, { 'age': 36 });
// → [{ 'name': 'barney', 'age': 36, 'pets': ['hoppy'] }]

_.where(characters, { 'pets': ['dino'] });
// → [{ 'name': 'fred', 'age': 40, 'pets': ['baby puss', 'dino'] }]

Ook de aanroep _.where(characters, { 'age': 36 }); vs characters.Where(function(c) { return c.age === 36 });

Kwestie van persoonlijke voorkeur, maar die van lodash vind ik mooier. Daarnaast, waarom zou je voor dit soort basic dingen telkens het wiel opnieuw uitvinden? Het .net framework omarmen wanneer je in C# programmeert is bijna vanzelfsprekend, maar een paar standaard libs voor websites niet?

Met de huidige build tools, zal er geen extra request nodig zijn. Het gaat dus om het embedden van een paar kb, in het tijdperk van mb en bijna gb internetsnelheden. De telefoon als zwakke schakel kenmerken werkt ook niet meer. Mobiel internet is bijna sneller als de gemiddelde huisaansluiting.

Ik denk dat we degene moeten vervloeken die nog steeds niet minifyen en bundlen, maar kleine libs... ach. Kijk, mocht je nou zowel BaconJS als RxJS gaan includen omdat ze beide net die ene handige method hebben, dan wordt het een heel ander verhaal.

[Douweegbertje]

GateKeaper schreef op maandag 26 januari 2015 @ 11:40:
[...]


Ik denk dat we degene moeten vervloeken die nog steeds niet minifyen en bundlen, maar kleine libs... ach. Kijk, mocht je nou zowel BaconJS als RxJS gaan includen omdat ze beide net die ene handige method hebben, dan wordt het een heel ander verhaal.

Het is meer een gedachtegang. Prima die éne lib, maar meestal werkt het niet zo. Kijk naar Wordpress, bij menig WP website moet ik iets van 120 requests doen om een relatief simpele homepage te laden. Ja, het zijn niet allemaal libs maar er komt elke keer zoveel meuk bij dat het nergens meer over gaat.
Ik snap waarom mensen lodash gebruiken of jquery, maar soms slaan mensen door EN wordt er te simpel iets gebruikt terwijl het niet nodig is omdat men de pure basis kennis niet meer heeft en domweg afhankelijk is van een lib.