#JaiDécouvert ici la fonctionnalité "Incremental Static Regeneration (ISR)" de NextJS.

L'Incremental Static Regeneration (ISR) est un mélange de génération static et de régénération dynamique.

Lors du build du site toutes les pages sont générées de manière statique. Cependant, certaines peuvent être "marquées" : ces pages clairement identifiées seront régénérées à intervalle régulier après le déploiement du site, faisant appel à des API ou une base de données pour garder la donnée à jour.

Lors de la visite d'une page à régénérer, une version "ancienne" de la page s'affiche, mais une demande de régénération est envoyée au serveur. La page est ainsi régénérée et renvoyée instantanément au visiteur, et prête à être affichée au visiteur suivant. Le cycle peut alors recommencer.

source

J'ai aussi lu cette page de documentation de Vercel :

Incremental Static Regeneration (ISR) allows you to create or update content on your site without redeploying. ISR's main benefits for developers include:

• Better Performance: Static pages can be consistently fast because ISR allows Vercel to cache generated pages in every region on our global Edge Network and persist files into durable storage
• Reduced Backend Load: ISR helps reduce backend load by using cached content to make fewer requests to your data sources
• Faster Builds: Pages can be generated when requested by a visitor or through an API instead of during the build, speeding up build times as your application grows

ISR is available to applications built with:

• Next.js
• SvelteKit
• Nuxt
• Astro
• Gatsby
• Or any custom framework solution that implements the Build Output API

source

J'ai étudié le support ISR de SvelteKit. Il semble que cette fonctionnalité soit supportée uniquement par l'adapter-vercel.
J'ai identifié l'issue suivante : Would revalidating a static page work when self-hosted?.

#JaimeraisUnJour prendre le temps de creuser plus en profondeur ce sujet.

En 2024, j'ai utilisé avec succès dans un projet client la librairie svelte-splitpanes.

A predictable responsive component to layout resizable view panels supporting an multitude of advanced features (min/max bounderies, snap, expand on double click, fixed size, rtl).

source

Le projet svelte-splitpanes a débuté en avril 2022.

Aujourd'hui, en étudiant les projets de Hunter Johnston, #JaiDécouvert une autre librairie de gestion de "pane", nommée PaneForge, qui a débuté en février 2024.
Cette librairie n'existait pas au moment où j'ai sélectionné svelte-splitpanes.

Pour le moment, je n'ai aucune idée de la motivation de Hunter Johnston d'avoir créé PaneForge plutôt qu'utiliser la librairie existante svelte-splitpanes.

Pour le moment, je n'ai pas compris pourquoi Hunter Johnston a décidé de créer PaneForge plutôt qu'utiliser la bibliothèque existante svelte-splitpanes 🤔.

Je viens de créer cette issue : "Suggestion: add an explanation of the differences between PaneForge and svelte-splitpane at the end of the README".

Un ami m'a partagé Zstandard (zstd), un algorithme de compression.

Il y a 2 ans, j'ai étudié et activé Brotli dans mes containers nginx, voir la note : Mise en œuvre du module Nginx Brotli.

Je viens de trouver un module zstd pour nginx : https://github.com/tokers/zstd-nginx-module

Mon ami m'a partagé cet excellent article : Choosing Between gzip, Brotli and zStandard Compression. Très complet, il explique tout, contient des benchmarks…

Voici ce que je retiens.

Brotli a été créé par Google, Zstandard par Facebook :

Zstandard is a newer compression method developed by Facebook.

source

Je lis sur canIuse, le support Zstandard a été ajouté à Chrome en mars 2024 et à Firefox en mai 2024, c'est donc une technologie très jeune coté browser.

Benchmark sur le dépôt officiel de Zstandard :

source

J'ai trouvé ces threads Hacker News :

• 2020-05-07 : Introduce ZSTD compression to ZFS
• 2022-08-20 : AWS switch from gzip to zstd – about 30% reduction in compressed S3 storage

Zstandard semble être fortement adopté au niveau de l'écosystème des OS Linux :

The Linux kernel has included Zstandard since November 2017 (version 4.14) as a compression method for the btrfs and squashfs filesystems.

source

Packages Ubuntu et Debian :

In March 2018, Canonical tested the use of zstd as a deb package compression method by default for the Ubuntu Linux distribution. Compared with xz compression of deb packages, zstd at level 19 decompresses significantly faster, but at the cost of 6% larger package files. Support was added to Debian in April 2018

source

Packages Fedora :

Fedora added ZStandard support to rpm in May 2018 (Fedora release 28) and used it for packaging the release in October 2019 (Fedora 31). In Fedora 33, the filesystem is compressed by default with zstd.

source

#JeMeDemande si dans mes projets de doit utiliser Zstandard plutôt que Brotli 🤔.

Je pense avoir trouver une réponse ici :

The research I’ve shared in this article also shows that for many sites Brotli will provide better compression for static content. Zstandard could potentially provide some benefits for dynamic content due to its faster compression speeds. Additionally:

• ...
• For dynamic content
  • Brotli level 5 usually result in smaller payloads, at similar or slightly slower compression times.
  • zStandard level 12 often produces similar payloads to Brotli level 5, with compression times faster than gzip and Brotli.
• For static content
  • Brotli level 11 produces the smallest payloads
  • zStandard is able to apply their highest compression levels much faster than Brotli, but the payloads are still smaller with Brotli.

source

#JaimeraisUnJour prendre le temps d'installer zstd-nginx-module à mon image Docker nginx-brotli-docker (ou alors d'en trouver une déjà existante).

Je viens de croiser pour la première fois la propriété windom.customElements (from). Elle fait partie de l'ensemble des technologies qui composent ce que l'on appelle les Web Components.

Je connais depuis longtemps les Web Components, mais je n'ai jamais essayé de mettre en œuvre cette technologie. Je me suis contenté de lire et d'écouter des retours d'expérience et de suivre l'évolution des spécifications.

#JaiDécouvert que je peux facilement créer des Web Components en Svelte : https://svelte.dev/docs/svelte/custom-elements.

Custom elements can be a useful way to package components for consumption in a non-Svelte app, as they will work with vanilla HTML and JavaScript as well as most frameworks.

source

#JaiDécouvert le site Custom Elements Everywhere (https://custom-elements-everywhere.com/). Je lis que les Web Components sont maintenant parfaitement supportés par les frameworks majeurs : ReactJS, VueJS, Angular, Svelte, Solid… Ce qui est une très bonne nouvelle 🙂.
Je vais essayer de garder cette information à l'esprit, les Web Components me seront sans doute utile à l'avenir.

Avec Svelte, j'apprécie une sorte de "retour aux sources", c'est-à-dire, vers un web un peu plus "vannila", celui que j'ai connu au début des années 2000.
Je pense que Web Components vont encore renforcer cette sensation, comme par exemple le fait que si j'utilise la fonctionnalité développeur "inspection" du navigateur sur un Web Component, je vais voir, par exemple, la balise <button>....</button> du Web Component et non sa "soupe" HTML, comme c'est le cas avec un composant ReactJS ou Svelte (je sais qu'il existe des extensions navigateur pour éviter cela).

#JaimeraisUnJour prendre le temps d'étudier les performances des Web Components versus les composants de ReactJS, Svelte et Solid.

#JaiLu le thread du Subreddit ReactJS : Is it worth learning Web Components?. Voici quelques extraits :

Not worth it to be quite honest. I expect to get some hate for this.

I worked on a design system for three years that was written in Stencil (web component framework) that was used by multiple teams all using React, Angular, Vue. I regret everything, it should have all been react but the dumb decision to allow different teams to use different frameworks in order to do "micro frontend architecture" was the reason web components were picked shortly before I joined and took the lead.

Web components are also impossible to version and whichever one loads first is going to be the one that is globally used. This means production breaking changes without teams even knowing their breaking changes were going to fuck over another team.

source

Un peu plus loin du même auteur :

No, I view “micro frontend architecture” as a total disaster and it usually is implemented badly. When each application is a different framework too it’s quite honestly so difficult as to not even be worth entertaining.

source

Web components can be a great way to add functionality to legacy web apps. I don't know if I'd set out to use them in any other scenario though. I suppose you could, but I don't know many people writing vanilla HTML/JS apps these days.

source

J'ai effectué une recherche GitHub sur le topic "web-components" et j'ai trouvé des choses intéressantes :

• wired-elements - j'adore ! ( Voir note la 2024-12-11_1708)
• Open UI (https://open-ui.org) - cela semble être intéressant
• https://github.com/github/github-elements
• https://github.com/nolanlawson/emoji-picker-element
• https://atomicojs.dev

#JaiDécouvert Introducing the new Svelte CLI.

We’ve just released sv, a new Command Line Interface (CLI) for creating, enhancing, and upgrading Svelte projects.

...

This package merges the previous create-svelte and community-led svelte-add tools into a single package.

Dans le thread Hacker News "Rsbuild – A Better Vite?" #JaiDécouvert :

• Rsbuild : The Rspack-based build tool. It's fast, out-of-the-box and extensible.
• SWC : (stands for Speedy Web Compiler) is a super-fast TypeScript / JavaScript compiler written in Rust.
• VoidZero : a company dedicated to building an open-source, high-performance, and unified development toolchain for the JavaScript ecosystem.
• Oxc : is building a parser, Linter, formatter,, transformer, minifier, resolver ... all written in Rust.
• Rolldown : Rolldown is a JavaScript/TypeScript bundler written in Rust intended to serve as the future bundler used in Vite.

Voici ce que j'ai compris.

Tous ces outils sont écrits en Rust.

Rsbuild est une alternative à : Vite, Create React App et Vue CLI et qui offre d'excellente performance (les tâches de build… sont exécutées bien plus rapidement).

Jiahan Chen, développeur de chez ByteDance, a commencé le projet Rsbuild en octobre 2023.

Dans le thread HackerNews je lis ce commentaire :

The better, faster, Rust-powered Vite is… Vite.

https://voidzero.dev/posts/announcing-voidzero-inc

J'ai creusé le sujet et j'ai compris que le créateur de Vite, Evan You a fondé une société nommée VoidZero, composée de core développeurs des projets Oxc, Vite, Rolldown.

Accel a injecté 4,6 millions de dollars dans VoidZero avec comme objectif de financer le développement de Rolldown qui sera intégré dans une future version de Vite.
D'après ce que j'ai compris, Rolldown utilise Oxc.

Je me demande si Accel envisage de tirer des bénéfices directs de VoidZero ou si cette initiative relève davantage du mécénat. Du côté des intérêts indirects : plusieurs sociétés du portefeuille d'Accel utilisent la stack Javascript, ce qui permet de financer et de mutualiser le développement d'outils clés.

Voici les points principaux que je retiens. Rsbuild semble une alternative performante Vite qui est utilisable dès aujourd'hui.
Le projet Vite est bien structuré et financé, ce qui lui permettra de sortir une nouvelle version optimisée.
Pour ma part, j’espère voir le projet VoidZero réussir afin d’éviter une dilution des efforts au sein de la communauté Javascript dans une multitude de projets.

#JaiDécouvert le terme Cumulative Layout Shift (CLS) (from).

#JaiDécouvert https://github.com/sapics/ip-location-api (pour gibbon-replay).

#JaiDécouvert https://github.com/ghostdevv/svelte-hamburgers

Je l'ai utilisé dans https://sklein.xyz.

#JaiDécouvert better-sqlite3, je vais sans doute l'utiliser dans gibbon-replay à la place de Redis.

#JaiDécouvert cet article pnpm "Working with Docker".

J'y ai découvert corepack.

Pour le moment, je ne comprends pas l'avantage d'utiliser :

FROM node:20-slim AS base
ENV PNPM_HOME="/pnpm"
ENV PATH="$PNPM_HOME:$PATH"
RUN corepack enable

plutôt que :

FROM node:20-slim AS base
RUN npm install -g pnpm@9.10

🤔

Dans ce Dockerfile j'ai tout de même utilisé cette technique pour tester.

J'ai utilisé le système de cache store de pnpm :

RUN --mount=type=cache,id=pnpm,target=/pnpm/store pnpm install --prod --frozen-lockfile

Je me suis posé la question de partage le cache de ma workstation :

$ pnpm store path
/home/stephane/.local/share/pnpm/store/v3

Mais je ne pense pas que cela soit une bonne idée dans le cas où cette image est buildé par une CI.

#JaiDécouvert Mini Spreadsheet Component with Svelte 5 : sveltejs.

Très minimaliste et sympatique 🙂.

#JaiDécouvert isbot.

Detect bots/crawlers/spiders using the user agent string

#JaiDécouvert le package goatcounter-js pour directement charger le code JavaScript de Goatcounter. Ce qui, je pense, permet d'éviter le blocage de chargement de ce script par uBlock Origin.

#JaiDécouvert la fonctionnalité Skew Protection de Vercel : Introducing Skew Protection.

#JaiLu aussi Version Skew.

#JeMeDemande comment implémenter le même système que la fonctionnalité Skew Protection de Vercel en self hosted, par exemple, avec SvelteKit 🤔.