[HTML, CSS, JS] Frontend #44: 0 === -0

quote:

Op maandag 23 november 2015 21:49 schreef Skunk-m het volgende:

[..]

Ja dat zeg ik..

Bijna iedereen gebruikt jquery. Je hebt namelijk makkelijker leesbare code met betere crossplatform ondersteuning. Kost je iets performance als je zelf onwijs gaat optimaliseren, maar dat is allemaal marginaal.

quote:

Op maandag 23 november 2015 20:45 schreef Catch22- het volgende:

[..]

Jquery is ook JavaScript.

jQuery is een framework/library geschreven in de taal Javascript. Dat maakt het twee verschillende dingen.

quote:

Op maandag 23 november 2015 22:05 schreef Catch22- het volgende:

[..]

Bijna iedereen gebruikt jquery. Je hebt namelijk makkelijker leesbare code met betere crossplatform ondersteuning. Kost je iets performance als je zelf onwijs gaat optimaliseren, maar dat is allemaal marginaal.

JS is prima leesbaar. jQuery is merkbaar vertragend en gebruikt settimeout voor scroll events ipv RAF. 1kb kost ruwweg 1ms om te parsen en jQuery is 87kb ofzo. Dat vind ik behoorlijk wat na alle andere zaken die vertragen.

quote:

Op maandag 23 november 2015 22:05 schreef Catch22- het volgende:

[..]

Bijna iedereen gebruikt jquery. Je hebt namelijk makkelijker leesbare code met betere crossplatform ondersteuning. Kost je iets performance als je zelf onwijs gaat optimaliseren, maar dat is allemaal marginaal.

Een snelheidsvergelijking tussen document.getElementById('foo') en $('#foo'):
http://jsperf.com/getelementbyid-vs-jquery-id/180

Tip: probeer die test ook eens andere browsers.

quote:

Op dinsdag 24 november 2015 08:14 schreef Light het volgende:

[..]

Een snelheidsvergelijking tussen document.getElementById('foo') en $('#foo'):
http://jsperf.com/getelementbyid-vs-jquery-id/180

Tip: probeer die test ook eens andere browsers.

Ja, met zoveel iteraties ofzo merk je het wel.

quote:

Op maandag 23 november 2015 23:55 schreef n8n het volgende:

[..]

JS is prima leesbaar. jQuery is merkbaar vertragend en gebruikt settimeout voor scroll events ipv RAF. 1kb kost ruwweg 1ms om te parsen en jQuery is 87kb ofzo. Dat vind ik behoorlijk wat na alle andere zaken die vertragen.

Dat klopt.

Mijn invalshoek is iets anders denk ik. Ik werk voor klanten die graag enige vorm van efficientie in bouw willen. Ik weet zeker dat als je goed en gestructureerd werkt met jQuery dat je echt niet merkbaar vertraging gaat krijgen in webapps. Het gaat wel uitmaken als je animatie-dependend websites maakt.

Ik werk nu veel met AngularJS en dat is ook niet super-performant, maar ik kan er wel erg snel mee developen en de vertraging in de UI is voor de gebruiker niet merkbaar.

Alles draait om een efficiente dom en efficiente code.
Het is altijd een afweging tussen developmenttijd en performance. Als je zelf een Proof of Concept doet en infinite tijd hebt is het heel leuk als je uren bezig kan zijn om ms van je render af te snoepen. En reallife situaties kan dat simpelweg niet uit.

Met een webapp laadt en parse je al je assets als het goed is maar eenmalig, op dom updates en events na. Dan is wat laadtijd wel te doen.

Een website is niks meer dan een simpel documentje dus dan vind ik zware libraries onzin. Al die react/angular/ajax driven webpagina-navigatie vind ik ook altijd kut omdat de state niet lekker in de historie staat waardoor tussen pagina's navigeren (terug/vooruit) altijd butje is. Het kan wel, maar de praktijk wijst meestal anders uit.

Bij mijn projecten past vrijwel altijd de html, css en JS in 16kb gzipped, de css en JS zet ik dan ook mooi embedded. Afbeeldingen hebben een placeholder (kleur) dus meestal staat de volledige layout binnen 250ms voor je neus.

[ Bericht 0% gewijzigd door n8n op 25-11-2015 13:55:23 ]

Het is natuurlijk gewoon makkelijker en efficiënter om een framework in je project te knallen dat al het 'zware werk' voor je doet. Natuurlijk kan ik zelf een functie gaan schrijven om AJAX-requests af te handelen, maar waarom zou ik dat doen als de goede mensen van jQuery - en dat zijn echt betere programmeurs dan ik ben - al een implementatie hebben gemaakt die door miljoenen mensen wordt gebruikt? Zelfde met data binding. Zou ik vast zelf kunnen maken, maar kost me uren/dagen. KnockoutJS en AngularJS doen dat gewoon veel beter dan ik.

Tuurlijk zijn er ook genoeg nadelen. Performance gaat erop achteruit (hoewel je je zeker niet blind moet staren op benchmarks, real world performance is het enige dat telt), en als je een of andere edge case tegenkomt en tegen bugs aan loopt ben je overgeleverd aan de grillen van de maker van het framework. Als je eigen code niet werkt heb je óók een probleem, maar dat is makkelijker te fixen

Het is, zoals Catch22 ook zegt, een afweging. Mijn baas wordt niet blij als ik anderhalf keer zo lang over een project doe omdat ik zo nodig alles zelf moet gaan zitten maken terwijl het er kwalitatief niet aantoonbaar beter van wordt Die heeft geen boodschap aan mijn mooie zelfgemaakte functies.

Er is niks mis met het gebruiken van een framework, als je er maar nette code mee schrijft. Te vaak zie ik nog (en echt niet alleen van beginners, ook van grote bureaus) gare jQuery-code met van alles keihard in de Javascript gezet (strings, id's van elementen, URL's etc), geen namespacing, meerdere document-ready's, anonieme functies die gebind worden etc etc. Javascript is al een taal waar je heel makkelijk 'slechte' code mee kunt schrijven en een framework als jQuery maakt dat nog 10x makkelijker.

Ajax was alleen ff kak omdat IE dwars lag. Je hebt ook micro.js of 140medly wat zeer kleine libraries zijn voor die basic dingen die je 20 keer nodig hebt.

Die laadtijd discussie is sowieso krom. De kans dat iemand op jouw website komt die nog nooit een website met jQuery of AngularJS gezien heeft, is nihil. Als je gewoon de bekende CDN's gebruikt staat dat framework dus al lang en breed in zijn cache, misschien zelfs wel precompiled? Dik kans dus dat een jQuery functie aanroepen in de praktijk nog sneller is dan je eigen functie aanroepen die eerst nog van jouw webserver gehaald moet worden.

quote:

Op woensdag 25 november 2015 15:46 schreef Iwanius het volgende:

[..]

Maar niemand dwingt je toch om IE in deze te gebruiken als je andere alternatieven voorhanden hebt?

Maar sommige van je users gebruiken wellicht wel (een verouderde versie van) IE.

Tja, zeg dat tegen de klanten Als je voor een bedrijf aan de slag gaat dan kom je niet weg met "dan moet je maar een fatsoenlijke browser gebruiken", het spul dat je maakt moet gewoon goed werken in de versie van IE die ze op dat moment draaien. Al moet ik zeggen dat zelfs de meest trage organisaties die ik ken allemaal wel minimaal IE9 hebben tegenwoordig, de meeste 10 of zelfs 11. En daar valt allemaal goed voor te ontwikkelen, alleen IE8 is echt een draak van een ding.

CDN's durf ik trouwens nooit echt op te vertrouwen. Ik zal wel lichtelijk paranoïde zijn, maar wie weet hoe lang je klant jouw product wil blijven gebruiken, en wie weet wat er met zo'n CDN gebeurt in de toekomst? Ik lever frameworks altijd gewoon mee, dan moeten ze maar eenmalig een paar honderd kB méér downloaden. Better to be safe than sorry. Ik heb ook al eens meegemaakt dat de klant de CDN van Google, nota bene, gewoon doodleuk blokkeerde Heel het product lag op zijn gat, want het prachtige Dojo framework waar het op gebaseerd is kon niet worden geladen. En dan kun je gaan lopen steggelen met de IT-afdeling en ben je weer dagen verder voordat ze hun firewall hebben aangepast, terwijl het humeur van de klant langzaam tot onder het vriespunt zakt

quote:

Op woensdag 25 november 2015 15:46 schreef Iwanius het volgende:

[..]

Maar niemand dwingt je toch om IE in deze te gebruiken als je andere alternatieven voorhanden hebt?

Gebruik ik ook niet, ondersteun sowieso niks <IE9, ga me niet door achterlijke bochten wringen.

quote:

Op woensdag 25 november 2015 17:01 schreef n8n het volgende:

[..]

Gebruik ik ook niet, ondersteun sowieso niks <IE9, ga me niet door achterlijke bochten wringen.

Zelfs Microsoft zelf ondersteunt IE8 in ieder geval niet meer op hun eigen website kwam ik gister achter.

quote:

Op woensdag 25 november 2015 17:01 schreef n8n het volgende:

[..]

Gebruik ik ook niet, ondersteun sowieso niks <IE9, ga me niet door achterlijke bochten wringen.

Voordeel van bedrijfsautomatisering : je kan klanten de optie geven.

Support voor oude meuk
Klaar voor de toekomst

Kiezen ze vaak het tweede.

quote:

Op woensdag 25 november 2015 20:10 schreef Catch22- het volgende:

[..]

Voordeel van bedrijfsautomatisering : je kan klanten de optie geven.

Support voor oude meuk
Klaar voor de toekomst

Kiezen ze vaak het tweede.

Zit hem vooral ook in de manier van uitleggen richting de klant/werkgever inderdaad.

Zit nogal een verschil tussen:

1. "We sluiten nu X% van onze klanten uit omdat we ze niet ondersteunen. Wil jij hier geld in steken?"
2. "X% van onze klanten loopt nog fors achter qua browserupdates, maar volgens de statistieken daalt dit aantal best snel. Wil jij hier geld in steken?"

quote:

Op woensdag 25 november 2015 20:15 schreef TwenteFC het volgende:

[..]

Zit hem vooral ook in de manier van uitleggen richting de klant/werkgever inderdaad.

Zit nogal een verschil tussen:

1. "We sluiten nu X% van onze klanten uit omdat we ze niet ondersteunen. Wil jij hier geld in steken?"
2. "X% van onze klanten loopt nog fors achter qua browserupdates, maar volgens de statistieken daalt dit aantal best snel. Wil jij hier geld in steken?"

ik werk met gecontroleerde omgevingen natuurlijk, dat scheelt. Als de klant overal chrome, Firefox, edge of andere nieuwe browsers kan installeren is dat dus geen issue.

quote:

Op woensdag 25 november 2015 20:23 schreef Catch22- het volgende:

[..]

ik werk met gecontroleerde omgevingen natuurlijk, dat scheelt. Als de klant overal chrome, Firefox, edge of andere nieuwe browsers kan installeren is dat dus geen issue.

Die luxe heb ik dan niet, maar uitzonderingen daargelaten en mits het geen specifieke vereiste is gaan wij sowieso niet meer optimaliseren voor verouderde browsers. Als blijkt dat het in IE8 een grote bende is dan laten wij het lekker zo. Het is de investering vaak toch niet meer waard.

Een grote melding in beeld met een link naar Chrome & Firefox en dat is dat.

quote:

Op woensdag 25 november 2015 15:17 schreef KomtTijd... het volgende:
Die laadtijd discussie is sowieso krom. De kans dat iemand op jouw website komt die nog nooit een website met jQuery of AngularJS gezien heeft, is nihil. Als je gewoon de bekende CDN's gebruikt staat dat framework dus al lang en breed in zijn cache, misschien zelfs wel precompiled? Dik kans dus dat een jQuery functie aanroepen in de praktijk nog sneller is dan je eigen functie aanroepen die eerst nog van jouw webserver gehaald moet worden.

die vergelijking klopt niet helemaal want in beide gevallen heb je applicatiecode, die van jQuery is potentieel korter, native waarschijnlijk sneller uitgevoerd. Daarnaast is er een wildgroei aan jq versies en cdn’s.

Onder de streep is het allemaal wel prima, afhankelijk van de ‘requirements’ en voorkeur.

[ Bericht 5% gewijzigd door n8n op 25-11-2015 22:43:15 ]

quote:

Op dinsdag 24 november 2015 09:17 schreef Catch22- het volgende:

[..]

Ja, met zoveel iteraties ofzo merk je het wel.

Het laat wel zien dat het maken van een jQuery object een 'dure' actie is, en dat het dus slim is om die objecten te hergebruiken. En je kunt die snelheden ook in verschillende browsers vergelijken (en zien dat Firefox veel sneller is, zeker als het aankomt op document.getElementById())

Sowieso al je variabele in de lokale scope cachen, ook -zeker- in libraries.

quote:

Op woensdag 25 november 2015 23:03 schreef Light het volgende:

[..]

Het laat wel zien dat het maken van een jQuery object een 'dure' actie is, en dat het dus slim is om die objecten te hergebruiken. En je kunt die snelheden ook in verschillende browsers vergelijken (en zien dat Firefox veel sneller is, zeker als het aankomt op document.getElementById())

Ja dat sowieso. Maar dat is gewoon common sense imo. Als je geen idee hebt wat je precies aan het doen bent, kan je vanilla js ook sloom maken

Kun je met een .innerHTML() of .html()-functie geen text in een <input type="text"> dingetje zetten? In een <textarea> werkt het wel.

quote:

Op donderdag 26 november 2015 16:31 schreef Ser_Ciappelletto het volgende:
Kun je met een .innerHTML() of .html()-functie geen text in een <input type="text"> dingetje zetten? In een <textarea> werkt het wel.

Die heeft een .value property.