Discussion :

[Lcf.vs]

@SylvainPV :

Passer par Date ou performance, comme pour l'incrémentation du compteur, cela me semble incontournable, quand tu fais du benchmark.

Ces opérations, sur une même machine sont, normalement, des constantes donc négligeables, puisque le but n'est pas de savoir combien de temps une fonction prend pour s'exécuter mais plutôt de pouvoir comparer le coût de différentes fonctions.

Pour ce qui est des décimales de ms, une précision de 18 est certainement exagéré mais bon nombre d'opérations prennent moins d'1 ms et, avec le temps, on finira pas se rendre compte que le µs ne suffira plus non-plus...

D'ailleurs, je fais partie de ceux qui pensent qu'il serait temps que l'on revoie les limites du JS, en termes de récursion, de calculs, de nombres d'arguments de fonctions et de longueurs d'arrays... les besoins identifiés à la création du JS ne sont plus les mêmes qu'aujourd'hui.

[SylvainPV]

D'accord si on joue la carte de la comparaison, encore que l'on ne puisse plus raisonner par proportionnalité. Au sujet de la précision, e ne trouve pas qu'aller au-dessous de la milliseconde soit utile. Si on cherche à optimiser une opération élémentaire, multiplier les itérations suffit à compenser le manque de précision de la mesure. Il faut voir la performance comme une contrainte et non comme un objectif en soi.

[Lcf.vs]

Il faut voir la performance comme une contrainte et non comme un objectif en soi.

Je ne partage pas cet avis... mais c'est, entre-autres, pour cela que certains me disent intégriste...

[SylvainPV]

En tout cas mes clients ne m'ont jamais félicité lorsque je passais le délai d'une page de 100ms à 10ms

[Kaamo]

Souvent les (enfin ceux de ma boite) clients demandent au plus un temps de réponse d'une seconde ... ce qui est selon moi énorme !

Du coup, oui, j'aurai plus tendance à qualifier ça de contrainte que d'objectif. Enfin, ça peut devenir un objectif si le client veut un temps de, disons, 500ms et que tu sais que ton système ne peux pas fournir cela quand tu lui vends

[Lcf.vs]

Ben, disons que n'ayant pas de job, ni de clients, je ne fais que développer mes outils et conseiller du monde sur le chat, donc j'ai du temps à consacrer à ce genre de détails et c'est toujours sympa de proposer des solutions plus légères à ceux qui ont moins de temps devant eux.

[fredoche]

D'ailleurs, je fais parti de ceux qui pensent qu'il serait temps que l'on revoie les limites du JS, en termes de récursion, de calculs, de nombres d'arguments de fonctions et de longueurs d'arrays... les besoins identifiés à la création du JS ne sont plus les mêmes qu'aujourd'hui.

C'est au programme semble t'il, tout au moins pour l'aspect récursion, qui devrait devenir sans limite, peut être dans ES6

Quels sont ces limites s'il te plait, pour les autres éléments que tu évoques ?

je vois par exemple 2^32 pour la longueur des arrays en ES5. C'est pas assez ?

[Kaamo]

La limite la plus "handicapante" c'est le localStorage à 5 Mo! (Bientôt 10 Mo ...) Mais ça ne reste pas suffisant pour des app offlines qui ont besoin de gros volumes.

[fredoche]

C'est hors-sujet, mais ma longue pérégrination bien loin d'être aboutie pour apprendre/comprendre le javascript m'amène à penser aujourd'hui que le local storage peut être un faux bon ami à plusieurs titres pour ce qui concerne la sécurité.

Après faut voir comment on s'en sert et ce qu'on y stocke, mais il n'est pas sur pour ma part que j'investisse du temps sur cette facilité, et je vais surement être plus regardant quand le stockage local m'est proposé par certaines applis.

La réponse négative sera probablement ma réponse par défaut quand on me le proposera.

[Watilin]

il serait temps que l'on revoie les limites du JS, en termes de […] nombres d'arguments de fonctions

T'ES FOU TOI nanméoh tu veux revenir aux vilaines interfaces C d'Unix avec 40 arguments à passer dans le bon ordre ? Une bonne fonction ça a 4 arguments maximum, et encore. Si t'as besoin de plus tu t'arranges pour qu'il y ait un hash ou un tableau dans le tas.

Grrmblmbl.

[Kaamo]

Pour ceux qui seraient passés à côté : Le Hello World (un quine, affichez la source) version Martin Kleppe. Explications durant la dernière JSConf.

Pour ceux qui n'auraient pas compris ce que je viens de dire, je les renvoie ici (j'en avais parlé dans ce sujet il y a quelques semaines.)

[Kaamo]

Détecter les variables globales. En dehors des natives, bien sûr, qui sont livrées de base avec window(147 char). Des meilleures idées dans l'assemblée ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
(function(d,c,i,r,o){
c=(d=document).body.appendChild(i=d.createElement('iframe')).contentWindow,r={};d.body.removeChild(i);for(o in this)o in c||(r[o]=this[o]);return r
})()

[SylvainPV]

Au premier abord j'aurais pensé à ça

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

return Object.keys(window)

[Kaamo]

Cette méthode retourne en plus des objets créés par le navigateur (Par exemple, dans Chrome : "chrome, document, external, location, top, window")

[SylvainPV]

Il faut voir ce que tu appelles globales "natives", je pensais que tu faisais référence à celles héritées du prototype Les navigateurs mettent pas mal de bazar dans le scope global, dur de faire le tri. Il me semble que ces propriétés sont ajoutées seulement quand un document existe au sein de l'objet Window, donc impossible de passer outre la modification du DOM.

[Kaamo]

Il me semble que ces propriétés sont ajoutées seulement quand un document existe au sein de l'objet Window, donc impossible de passer outre la modification du DOM.

t'as mis le doigt dessus, d'où ma fonction ci-dessus
Elle permet justement de filtrer en ajoutant une iframe, pour récupérer tout ce qui est embarqué dans window et exclure de notre document.
Ainsi, il reste de cette différence que les variables globales créées par notre code.

Ainsi, en exécutant ce code sur cette page du forum, on peut voir que DVP a allègrement distillé pas moins de 160 variables globales dans window

[Watilin]

Au passage, les scripts de TinyMCE qui touchent à l'objet console je trouve ça vraiment moyen.
… Mais c'est peut-être parce que la version utilisée ici a quinze ans de retard

[Kaamo]

Si vous êtes passés à côté, il est temps de corriger le tir !

Encore un coup du fameux Martin Kleppe (JSFuck, 140bytes, le Quine World, etc) :

Sheet, un excel-like basique en 318 caractères à cette heure (qui n'en finit pas d'être regolfé ! voir le commit history)

[Kaamo]

Encore un coup des gars du dessus (d'ailleurs l'excel-like est passé à 295 caractères !)

Cette fois c'est un JSFiddle-like (en 176 caractères) qui est proposé par Martin Kleppe et deux autres noms du Golfing à retenir : Mathieu 'p01' Henri et Maxime Euzière

[SylvainPV]

Ca c'est chouette ! Et le rafraîchissement est instantané par rapport à JSFiddle. Pratique pour des tests rapides