Article didactique sur la meilleure manière de créer un package NPM.

Notamment la partie pour le double support CommonJS et Module est top!

Sinon comme toujours réfléchissez-y à deux fois avant d'ajouter de la complexité à l'écosystème Javascript qui est déjà affreusement complexe.

J'en ai eu besoin récemment, une astuce pour avoir un spread operator conditionnel en JS

const isActive = true;

const user = {
  name: "Amit",
  age: 30
};

const activeUsers = {
  ...isActive && user
};

Très bon article explicatif pas à pas pour tout comprendre de l'asynchronicité en Javascript !

Un nouveau (LOL encore) framework Javascript frontend.

Ils se focalisent sur la vitesse lors du premier affichage de l'application en supprimant la phase d'hydratation.

Lorsque l'on télécharge une page web en React par exemple, le navigateur doit interpréter le HTML et le JS, puis:

• re-créer tous les listeners sur les noeuds du DOM
• re-créer l'arbre de composant représentant l'application
• restorer l'état (state) de l'application

Qwik permet de sauter ces étapes avec plusieurs astuces, par exemple pour les listeners, ils sont directement dans le HTML:

<button on:click="./chunk.js#handler_symbol">click me</button>

Sinon la syntax est très similaire à celle de React avec du JSX.

L'article parle des inconvénients de React. (c'est l'auteur de React Admin)

Pour l'auteur, les formulaires sont compliqués à écrire correctement à cause d'un trop haut niveau d'abstraction.

De son point de vue, les hooks ont amené un niveau supplémentaire de complexité sur des parties métiers qui était déjà gérées correctement par Redux.

Il continue sur d'autres points en donnant toujours des exemples voir des comparaisons avec d'autres framework.

Pino est vraiment un super logger, en plus de ses excellentes performances, il permet de

• cacher automatiquement des valeurs dans les objets (comme les jeton d'authentification par exemple)
• créer des sous logger par module
• écrire les logs dans des destinations différentes en fonction des niveaux

Les log sont très souvent une partie critique de l'application car écrire des une sortie est assez consommateur (chez Kuzzle, on s'est rendu compte que nos access log ralentissaient le backend outre mesure.

Il faut aussi faire attention à ce que l'on veut loguer et trouver un équilibre sur la quantité car on peut facilement remplir des tera octets de logs.

Dans l'idéal, il faut construire un système permettant de changer dynamiquement le niveau de log pour activer le mode debug lorsqu'on en a besoin, et l'arrêter ensuite.

Je ne connaissais pas Radash mais ça tombe bien parce que je trouvais également que Lodash était vieillissant (et tellement lent..)

La librairie standard de Javascript est tellement inexistante que ce genre de lib est quasiment obligatoire malheureusement.

Mes fonctions préférées:

Remplacement de Bluebird.map:

import { parallel } from 'radash'

const userIds = [1, 2, 3, 4, 5, 6, 7, 8, 9]

// Will run the find user async function 3 at a time
// starting another request when one of the 3 is freed
const users = await parallel(3, userIds, async (userId) => {
  return await api.users.find(userId)
})

Terminé les for (let i = 0; i < 5; i++):

import { range } from 'radash'

for (const i of range(0, 5)) {
  console.log(i) // => 0, 1, 2, 3, 4, 5
}

Nombre aléatoire dans un interval:

import { random } from 'radash'

random(0, 100) // => a random number between 0 and 100

Et toutes les fonctions de manipulation de string comme en Ruby: capitalize, snake, camal, etc

Un REX du gouvernement Britannique qui a enlevé JQuery de ses pages (32Kb compressé).

Ils ont observé une amélioration de 17% des performances en moyenne!

Par contre, ils n'ont pas utilisé d'autre lib JS à la place non plus :-)

Deno annoncent quelques changements avec notamment le support des packages JS en provenance de NPM!

Ils annoncent aussi qu'ils souhaitent être le moteur JS le plus rapide.

Je ne serais pas surpris que cela soit poussé par la sortie de Bun.js qui a de très bonnes performances, supporte le typescript et les packages NPM

Bun, le runtime Javascript qui se présente comme une alternative à Node.js, a levé 7 millions de dollars.

Ils recrutent maintenant pour sortir une version stable de leur produit.

A suivre de très près !

C'est vrai que Redux n'est pas forcément nécessaire pour démarrer une app React, tout comme Vuex ne l'est pas pour une app Vue.

Comme pour chaque outil, il faut se demander si l'on en a vraiment besoin et surtout si ça répond à un problème.

Chaque outil rajoute une couche de complexité cognitive supplémentaire qui ralentit et complique le développement.

Une autre lib qui propose de faire du frontend avec un virtual DOM.

Ils annoncent des performances bien plus élevées que React tout en supportant une partie de l'API comme useState, useEffect etc

Je suis toujours sceptique lorsque je vois les couches d'abstractions s'empilées côté frontend.

Tous les patterns de destructuration d'objets en Javascript

Un de ceux que je trouve le plus utile c'est celui pour avoir une valeur par défaut si la propriété n'existe pas.
C'est très utile pour les options par défaut:

function checkout (name, { currency='€' } = {}) {
  console.log(currency);
}

checkout('aschen'); // print €
checkout('aschen', { currency: '$' }); // print $

On peut même mixer ça avec un type:

function checkout (name, { currency='€' }: { currency: string } = {}) {
  console.log(currency);
}

Sinon j'avais jamais utilisé celui pour conserver le reste:

const user = {
  name: 'Chris',
  age: 33,
  username: 'DailyDevTips',
};

const { name, ...rest } = user;

On commence à voir des tests des performances de Bun par rapport à Node.js.

Pour l'instant il manque encore trop de compatibilité à Bun avec les lib Node.js pour pouvoir aller très loin (pas de child_process) par exemple.

Dans cet article, l'auteur note un gain sensible de performances avec Bun.

Un autre article qui analyse les faiblesses des Hooks de React.

Une source de bug très courante est l'oubli d'une propriété dans le tableau de dépendances avec useEffect.

Le respect de la Règle des Hooks qui force le nombre de Hooks d'un composant à toujours être le même impose des architectures de composants contre nature.

L'auteur continue son raisonnement en avançant notamment que depuis les Hooks, React peut être utilisé comme un framework alors que ce n'était pas vraiment prévu, ce qui cause pleins de problèmes d'architectures.

Proposition d'un operateur pipe (|>) en Javascript.

Plutôt que d'encapsuler ou de chainer des appels à des fonctions, on pourrait utiliser l'opérateur pipe.

// Nesting
divide(half(convert('6')))

// Chaining
'6'.convert().half().divide(2)

// Pipe
6 |> convert(%) |> half(%) |> divide(%, 2)

Perso je suis pas vraiment pour rajouter des couches de complexité supplémentaire à un langage qui ressemble déjà au monstre de Frankenstein.

Ça va compliqué le boulot de tout ceux qui travaillent avec l'AST et rendre le langage plus difficile à aborder pour des nouveaux venu.

Un article sur l'architecture hexagonale qui explique notamment la distinction entre port et adapter.

L'auteur fait aussi un commentaire intéressant I’ve never applied these architectures to the letter, though.

Comme pour tout, il faut éviter de rentrer dans une application dogmatique de tel ou tel architecture, process, etc

L'architecture hexagonale offre un excellent moyen de structurer son code en modules indépendants mais elle doit être utilisée avec un regard critique et peut être contournée lorsque cela s'avère nécessaire.

Un article qui va dans le sens inverse de la tendance actuelle autour de l'utilisation des Hooks dans React.

L'auteur disserte sur le non respect des principes SOLID par les Hooks et sur les problèmes de dettes technique que cela créé.

Les Hooks sont vraiment quelque chose d'étrange, ils ne respectent pas la programmation fonctionnelle, ni la programmation objet.

Ce sont juste des helpers pour écrire et lire de la donnée dans une sorte de gros objet global, l'avantage avec le système de props étant qu'on n'a pas besoin de les passer entre chaque composant.

Un autre article sur la recherche de memory leak en Javascript.

L'auteur utilise une fonctionnalité non documenté de Chrome qui permet d'afficher toutes les instances d'une classe.

class User {
  //... 
} 

const user = new User();

// find all instances of User
queryObjects(User);

Ça ne marchera pas pour les POJO du coup mais c'est un bon outil supplémentaire pour aider dans la recherche des fuites mémoires.

Un autre runtime Javascript côté serveur concurrent à Node.js.

C'est assez intéressant car Bun est développé from scratch (en Zig), et il n'est pas basé sur le moteur Javascript v8 de Chrome mais sur JavascriptCore, celui de Safari.

Dans les promesses de Bun:

• Plus rapide et moins de mémoire consommé que Node.js
• Transpiler et bundler intégré
• Compatible avec l'écosystème (node_modules et NPM)

Le projet est encore en cours de développement (voir ce qu'il manque) et donc pas encore recommandé pour de la production.