[HTML, CSS, JS] Frontend #40: De Node is hoog

quote:

Op woensdag 21 mei 2014 09:16 schreef Tijn het volgende:

[..]

Ik vind het slim om eerst Javascript zelf te leren voordat je met frameworks en libraries aan de gang gaat, maar wat je hier zegt over jQuery is echt niet waar. De syntax is gewoon standaard Javascript, jQuery dwingt verder geen structuur af, dus je kunt je programma's schrijven zoals je wil. Verder is jQuery helemaal niet traag, waarom denk je dat? De manier waarop het soms gebruikt wordt in de praktijk is misschien traag, maar jQuery zelf zit hartstikke goed in elkaar.

Het is gewoon >90kb aan script die op elke pagina geparst moet worden, voor elke call die je maakt wordt een gigantische functie aangeroepen.

quote:

Op woensdag 21 mei 2014 09:19 schreef Catch22- het volgende:
Dat heb je zelf in de hand. En een DOM-selector zoals jij die schrijft kan je nooit sneller & completer maken dan jQuery (Sizzle, eigenlijk).

Ik zal waarschijnlijk ook nooit zo goed worden als de developers van libraries, vaak is de compleetheid van een library alleen veel meer dan ik ooit nodig zal hebben. Waarom zou het niet sneller zijn dan?

* Zal deze post later nog een keer terug lezen en mezelf voor m'n kop slaan omdat ik zo eigenwijs was tegen JS-veteranen

[ Bericht 16% gewijzigd door n8n op 21-05-2014 09:29:12 ]

quote:

Op woensdag 21 mei 2014 09:22 schreef n8n het volgende:

[..]

Het is gewoon >90kb aan script die op elke pagina geparst moet worden, voor elke call die je maakt wordt een gigantische functie aangeroepen.

jQuery is echt hartstikke efficiënt geschreven. Je doet net alsof het allemaal retezwaar is, maar in de praktijk merk je de overhead van jQuery niet eens bij het laden van een pagina.

jQuery wordt ook gecached dus vrijwel geen laadtijd.
Voor mobiele websites gebruikt ik meestal een kleinere library zoals Intel AppFramework dat voor een groot deel compatible is met jQuery (minder selectors) en wat sneller is.

jQuery is juist een perfecte tool als je weet wat je aan het doen bent.

Nu ik m'n code aan het abstraheren ben zie ik alweer het nut van jQuery omdat ik uiteindelijk gewoon een framework aan het maken ben. Ga dan toch kijken naar de Closure library omdat deze een compiler heeft.

quote:

Op woensdag 21 mei 2014 09:22 schreef n8n het volgende:
* Zal deze post later nog een keer terug lezen en mezelf voor m'n kop slaan omdat ik zo eigenwijs was tegen JS-veteranen

Google today released Chrome version 35 for Windows, Mac, and Linux

[...]

Next, Chrome 35 adds new JavaScript functionality defined in the ECMAScript 6 standard. There are three of them:

• Promise, a value that may not be available yet but will be known at some point in future, and is meant to help writing cleaner asynchronous code.

• WeakMaps and WeakSets allow developers to create efficient, garbage-collected data structures. In both, references to objects are held weakly: if there is no other reference to an object stored in the WeakSet, it can be garbage collected. This helps avoid memory leaks.

• Object.observe lets developers observe changes to JavaScript objects. Callbacks can observe multiple objects and will receive all changes to any objects in a single asynchronous call.

• Google has also added support for unprefixed Shadow DOM; the prefixed implementation of Shadow DOM was made available with the release of Chrome 25. The addition brings reliable composition of user interface elements by allowing developers to scope their HTML markup, CSS, and hide the implementation details of complex components, as well as build their own first-class elements and APIs with Custom Elements.

• CSS Font Loading has been added for dynamically loading font resources.

• The SVG ‘paint-order’ property lets developers control the order in which fill, stroke, and markers are painted.

Shadow DOM

Netflix: Improving the performance of our JavaScript inheritance model


As can be seen from the graph above, after running our application for one minute the memory savings is close to about 12.2MB. We could pull the line back to the beginning and the memory savings would be even more because after one minute the application code has long been interpreted, and the classes have been created.

quote:

Op woensdag 21 mei 2014 09:22 schreef n8n het volgende:

[..]

Het is gewoon >90kb aan script die op elke pagina geparst moet worden, voor elke call die je maakt wordt een gigantische functie aangeroepen.

[..]

Ik zal waarschijnlijk ook nooit zo goed worden als de developers van libraries, vaak is de compleetheid van een library alleen veel meer dan ik ooit nodig zal hebben. Waarom zou het niet sneller zijn dan?

* Zal deze post later nog een keer terug lezen en mezelf voor m'n kop slaan omdat ik zo eigenwijs was tegen JS-veteranen

Je kunt eventueel nog require JS gebruiken, die laadt alleen bijvoorbeeld jQuery en andere plugins in waar nodig.

quote:

Op woensdag 21 mei 2014 09:16 schreef Tijn het volgende:

[..]

Ik vind het slim om eerst Javascript zelf te leren voordat je met frameworks en libraries aan de gang gaat, maar wat je hier zegt over jQuery is echt niet waar. De syntax is gewoon standaard Javascript, jQuery dwingt verder geen structuur af, dus je kunt je programma's schrijven zoals je wil. Verder is jQuery helemaal niet traag, waarom denk je dat? De manier waarop het soms gebruikt wordt in de praktijk is misschien traag, maar jQuery zelf zit hartstikke goed in elkaar.

Klopt, sommige mensen hebben geen idee hoe het DOM eigenlijk werkt, overigens ben ik groot voorstander om overal JQuery te gebruiken al was het alleen maar als abstractie laag.

quote:

Op woensdag 21 mei 2014 22:04 schreef boem-dikkie het volgende:

[..]

Je kunt eventueel nog require JS gebruiken, die laadt alleen bijvoorbeeld jQuery en andere plugins in waar nodig.

thanks, zal het een keer bekijken.

Heeft iemand hier al iets voor in het wild gezien, CSS/JS scrollen met velocity physics zoals in iMessage en deze animatie?

quote:

Op maandag 26 mei 2014 17:14 schreef n8n het volgende:
[ afbeelding ]

Heeft iemand hier al iets voor in het wild gezien, CSS/JS scrollen met velocity physics zoals in iMessage en deze animatie?

Framerjs.com kan het wel, maar dat is een prototype tool.

Jammer wel proto/app tools, ff kijken of ik het kan ontleden (en dan of het performance-wise haalbaar is )

quote:

Op dinsdag 27 mei 2014 00:09 schreef Catch22- het volgende:
Dat laatste zal problematisch worden. Zulke dingen staan gebruiksgemak, snelheid en beleving vaak nogal in de weg

ja hoop dan op hardwareacceleratie. Leek me een leuk projectje.

Als je zelf iets gaat bouwen, zou ik iig http://julian.com/research/velocity/ gebruiken voor de animaties.

quote:

Op dinsdag 27 mei 2014 01:42 schreef Tijn het volgende:
Als je zelf iets gaat bouwen, zou ik iig http://julian.com/research/velocity/ gebruiken voor de animaties.

wat een geweldige website. Staat voor de verandering een keer duidelijk omschreven wat iets is, wat het doet en waarom. Dank.

quote:

Op dinsdag 27 mei 2014 00:09 schreef Catch22- het volgende:
Dat laatste zal problematisch worden. Zulke dingen staan gebruiksgemak, snelheid en beleving vaak nogal in de weg

Inderdaad. Superhip om in je portfolio te zetten dat je het kan, maar de eerste de beste serieuze gebruiker gaat gelijk over zijn nek. En anders zijn telefoon wel.

quote:

Op maandag 26 mei 2014 17:14 schreef n8n het volgende:
[ afbeelding ]

Heeft iemand hier al iets voor in het wild gezien, CSS/JS scrollen met velocity physics zoals in iMessage en deze animatie?

Famo.us

quote:

Op maandag 26 mei 2014 11:51 schreef Catch22- het volgende:
Ik ben nu serieus aan het bouwen met AngularJS (icm ionic framework). En ik moet zeggen dat het wel heel vet is. Je moet even wennen aan de structuur, maar als je het goed doet, dan is het echt heel tof.

Angular, das toch met die extra attributen op je DOM ?