Ultra-light JS/CSS image slider

#17232

Hop, à nouveau tous les scripts / lib de sliders que je trouve sont trop lourds, trop complets, demandent jQuery…

… du coup j’ai pondu un slider très simple en quelques lignes de JS & CSS.

Rien de complexe, mais c’est ultra-léger, sans dépendances, et ça marche.
Et c’est assez simple à comprendre pour que vous puissiez ajouter ce que vous voulez vous-même :).

javascript - Can (a ==1 && a== 2 && a==3) ever evaluate to true? - Stack Overflow

#17169

:o

Effectivement, les espaces avant et après les variables sont étrangement posées. Si les espaces sont des espaces « exotiques » en unicode, ils font partie du nom de la variable et on a donc trois variables différentes :

a␣ = 1, ␣2 = 3, a = 3;
if (a␣ == 1 && a == 2 && a == 3) {
  console.log('Hello World!');
}

Mais même avec ça, il y a une solution relativement simpliste : suffit de redéclarer il suffit de savoir le fonctionnement même de JavaScript, qui essaye toujours de trouver l’égalité sur les types de variables, puis de redéfinir une méthode qui existe déjà :

const a = {
  i: 1,
  toString: function () {
    return a.i++;
  }
}

if (a == 1 && a == 2 && a == 3) {
  console.log('Hello World!');
}

https://stackoverflow.com/questions/48270127/can-a-1-a-2-a-3-ever-evaluate-to-true

Tous les parsers JSON sont mauvais - LinuxFr.org

#16944

Nan, c’est juste qu’ils ne permettent pas d’analyser des objets qui ont un trop grand nombre de niveaux d’imbrications. Le parseur en lui-même n’a aucun problème (je ne vois pas ça comme un soucis du parseur à proprement parler, c’est à dire le code qui va lire le JSON en entrée, bit par bit, et déclencher les fonctions qu’il faut au bon moment).

Selon l’article, Ruby plante à partir de 100 imbrications. C++ à 13 786.

C’est gênant, mais il faut bien une limite quelque part :/.

Il ne m’est jamais arrivé d’atteindre la limite sur le parsage du JSON. Par contre, j’ai déjà poussé à bout le moteur SQLite en PDO (qui a une limite de 1000 pour le nombre de variables que l’on peut mettre dans le prepare()).
Il me suffit alors de faire plusieurs requêtes plus petites au lieu d’un énorme.

AMP, and why I don't like it | nota-bene.org

#16935

Perso je vois pas tellement l’intérêt.

Il est assez simple de faire des pages web légères et rapides sans utiliser de framework / API / site externe.

Si tout le monde virait déjà tous les scripts qui apportent que-dalle à leur page, le web serait déjà beaucoup plus rapide !

Et je ne parle pas de la pub (pas forcément, en fait), mais juste des trucs comme les scripts de tracking, les scripts de popup, les scripts de rézosocio (alors qu’un lien HTML suffit pour partager un article)…
Tout ça ne n’apporte rien à l’utilisateur, c’est juste là pour l’égo du blogueur. Si vous voulez des stats, regardez les logs du serveur, tout simplement.

C’est pas comme si je demandais non plus de faire un site sans JS du tout, ni un site ultra-sofistiqué qui doit absolument fonctionner sur un 3310, mais simplement de revenir un peu aux bases.

Un seul exemple : https://lehollandaisvolant.net/tout/tools/graph/
j’avais pris cette idée d’une autre page. Cette page avait utilisé jQuery juste pour prendre le contenu placé dans le champ et la transmettre au code qui fait fonctionner le graphique. C’était d’une lenteur abominable.
Rien que virer jQuery donne le résultat visible ici. Et j’ai eu exactement le même problème avec une version de cet outil qui devra tracer des graphiques en 3D.

J’aime bien faire du vanilla-JS (javascript tout seul, sans framework superflu), tout simplement parce qu’on peut déjà tout faire et c’est guerre plus long à faire, et c’est carrément plus rapide.
Et franchement, à quoi bon inclure toute une lib externe de 100 ko si c’est juste pour traiter un event sur un seul bouton ? C’est ridicule.

C'est pourtant ce genre de choses qui ralentissent le web.

C’est pas compliqué de faire des trucs simples en pure-JS :
détecter le sens du scroll ? 10 lignes de JS.
créer un sommaire pour une page web ? 40 lignes.
un lazyload ? 10 lignes de JS aussi

Ou même des trucs sans JS du tout :
un champ / formulaire flexible ? quelques lignes de CSS

Date.prototype.toLocaleDateString() - JavaScript | MDN

#16856

Ça en revanche c’est quelque chose de génial !

var d = new Date();
console.log(d);
// 2017-10-07T16:53:48.160Z
console.log(d.toLocaleDateString('fr-FR', {weekday: "long", year: "numeric", month: "long", day: "numeric"}))
// "samedi 7 octobre 2017"
console.log(d.toLocaleDateString('de-DE', {weekday: "long", year: "numeric", month: "long", day: "numeric"}))
// "Samstag, 7. Oktober 2017"
console.log(d.toLocaleDateString('ko-KR', {weekday: "long", year: "numeric", month: "long", day: "numeric"}))
// "2017년 10월 7일 토요일"

Les libs de localisation sont déjà incluses dans JS, pas besoin de refaire des trucs dans son propre code (chose que je faisais, en PHP, pour l’avoir en JS).

https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/Date/toLocaleDateString

Date.prototype.getTimezoneOffset() - JavaScript | MDN

#16855

gnîîîîî !

Encore ces incohérences entre JS et PHP.
Ici sur la sortie d’une date en une chaîne au format ISO 8601 : en PHP, la chaîne prend en compte le décalage par rapport à l’UTC. En JS, il n’y a pas de décalage : tout est en UTC.

Quant à calculer ce décalage : un UTC+2 (correspondant à Paris en été, par exemple), il est positif pour PHP (logique) mais négatif en JS (probablement car UTC est 120 minutes de moins que l’heure locale).

Javascript createElement and appendchild in one step - Stack Overflow

#16805

Ah bien !

Une méthode pour faire des .appendChild() embriqués, sans passer par des variables supplémentaires :

Au lieu de faire :

var ul = document.createElement('ul'); 
var li = document.createElement('li');
li.appendChild(document.createTextNode('du texte');
ul.appendChild(li);

Faire :

ul.appendChild(  (document.createElement('li')).appendChild(document.createTextNode('du texte')).parentNode  );

L’astuce ici est le .parentNode à la fin. Le .appendChild retourne l’élément ajouté. Donc sans l’astuce, il enverrait le texte directement au UL. Ici, on revient sur le parentNode du texte, donc le LI, que l’on envoie au UL. Brillant.

https://stackoverflow.com/a/11252478/5099624

Date.prototype.getMonth() - JavaScript | MDN

#16800

Donc…
En JS, les mois vont de 0 à 11.
En PHP, les mois vont de 1 à 12.

Et les jours ?
En JS, les jours vont de 1 à 31.
En PHP, les jours vont de 1 à 31.

Le JS c’est à se taper la tête contre les murs, vraiment. Et là c’est juste une broutille (suffit de faire un −1 entre les deux langages [oui car mon PHP écrit du JS]). Mais parfois c’est bien plus chiant à corriger…

Without JavaScript — David Larlet

#16609

:/

Perso je ne bloque pas le JS, je n’ai jamais bloqué le JS. Je bloque plutôt des ressources distantes.

Le JS fait partie du web. Bloquer ça revient au même que de bloquer le CSS ou les PNG.

Je pars du principe que si un site choisit d’utiliser JS pour voler vos informations personnelles, alors c’est à moi de me demander ce que je fous encore sur ce site.
Mais à part ça, bloquer le JS pour bloquer le JS, parce que c’est du JS, je trouve ça simplement bête.

https://larlet.fr/david/blog/2017/without-javascript/

gpu.js - GPU Accelerated JavaScript

#16600

Une lib qui donne votre JS au module WebGL afin de le faire traiter par le GPU plutôt que par le CPU.

C’est bourrin, mais avec leur test là, c’est beaucoup plus rapide !

Ça ne marche pas dans tous les cas, typiquement juste dans les cas où les calculs sont parallélisables (chose que le GPU font plus vite), mais why not.