Local Premier HTMX pt1

Aperçu

Il y a un refrain courant sur Internet selon lequel les choses ont empiré et continuent d'empirer. Il y a une prolifération d'horribles publicités à chargement nerveux sur chaque site Web, chaque moteur de recherche affiche un résumé d'IA merdique devant votre résultat de recherche, chaque site/application Web semble être devenu de plus en plus lent. Je ne peux pas fournir de solution à tout cela, mais je peux indiquer un meilleur paradigme pour la conception de sites Web et d'applications Web. Ce paradigme est le local d’abord.

Local first est un principe de conception pour les applications Web dans lequel l'interface utilisateur et les données sont colocalisées et les modifications apportées aux données sont synchronisées avec le serveur distant. Les premières applications locales semblent rapides et très performantes car elles ne nécessitent pas de RTT réseau entre l'action d'un utilisateur et le rendu du résultat de l'action. Je recommande de jouer avec Linear.app pour découvrir à quoi ressemble une première application locale de première classe. Je ne passerai pas beaucoup de temps à essayer de convaincre des mauvaises applications Web - parce que si vous êtes ignorant et heureux, je ne veux pas gâcher ce bonheur.

Si vous êtes familier avec les problèmes de Jira ou de Github, vous devriez être en mesure de immédiatement comprendre à quel point une première application locale peut faire une grande différence. Jira est lent car pour autant que je sache, il est juste lent et il charge beaucoup de données lentement et si vous cliquez loin puis revenez en arrière, vous devez recharger tout cela à nouveau les mêmes données. Github est une webapp SSR ce qui signifie que le code HTML est généré sur le serveur puis vous est envoyé. Cela signifie que toute interaction nécessite généralement un aller-retour complet entre votre navigateur et le serveur, ce qui est généralement très visible. Ironiquement, le lent SSR de Github fonctionne bien mieux que Jira d'après mon expérience - ils font des choses différentes mais bon sang, je déteste utiliser Jira. Je ne peux qu'espérer qu'un jour je pourrai utiliser Linear au travail et que ce sera aussi rapide qu'aujourd'hui.

Je vais faire une pause ici et simplement préciser que presque toutes les architectures d'applications peuvent finir par être extrêmement lentes si elles sont mal mises en œuvre. Je dirais fortement que la plupart des sites Web, applications Web, etc. que nous visitons quotidiennement sont mal mis en œuvre. Il existe une variété de techniques qui peuvent être utilisées dans toutes ces différentes architectures (SPA traditionnelle, SSR, etc.), mais le local offre d'abord le plus d'avantages en tant qu'architecture en termes de performances.

Développement piloté par les mèmes

C'était plus sérieux que ce que je pensais, alors plongeons-nous dans le développement piloté par les mèmes (MDD). Passons au plat principal de cet article et parlons de Local First HTMX.

HTMX est... eh bien, un mème et peut-être aussi sérieux, je ne sais pas si quelqu'un le sait vraiment. HTMX est un framework/bibliothèque frontal javascript anti-javascript (les utilisateurs du frontend idk utilisent ces termes de manière très vague). Plus important encore, c'est un très bon mème et c'est la clé du MDD. J'ai donc pensé que je devrais d'abord combiner HTMX et local pour créer quelque chose de vraiment horrible et beau. Je ne recommande pas nécessairement cette approche, mais je suis ravi de partager ce que j'ai fait pour créer la première application Local First HTMX Todo.

HTMX n'est pas le bon framework mais c'est peut-être le cas

L'objectif de HTML est de simplifier le développement frontend tout en conservant un bon niveau d'interactivité. L'idée générale de HTMX est que votre HTML sera rendu par le backend — à la Server Side Rendering. Le terme technique est hypermédia comme moteur d'état de HATEOS. Si vous vous souvenez que SSR (nécessitant un RTT sur le serveur pour chaque interaction) présente des problèmes de performances et peut ralentir les sites Web (il est difficile de lutter contre la vitesse de la lumière). Si vous saupoudrez simplement d’interactivité, cela peut fonctionner. Mais et c'est l'idée clé de Local First HTMX : vous n'avez pas besoin de restituer le code HTML sur le backend. Vous pouvez créer un "serveur", le compiler dans WASM et l'exécuter dans le navigateur. Cela vous donnerait toute la vivacité d'un Javascript Local First SPA de première classe sans aucun du JS - et encore moins du JS. Le but n'est pas d'éviter JS mais d'avoir une application plus simple.

Présentation de l'architecture

Pour récapituler, nous construisons une application Local First HTMX en compilant notre code SSR dans WASM, puis en l'exécutant dans un service worker. Permettez-moi d'expliquer brièvement et peut-être de manière incorrecte quelques points sur les navigateurs. Il y a un fil principal, c'est là que se déroulent normalement vos tâches JS et HTML. Le fil principal est ce qui a accès au DOM et peut réellement restituer le contenu. Les navigateurs ont ajouté de nombreuses fonctionnalités, mais je souhaite en mentionner deux. Le premier concerne les Web Workers, qui vous permettent d'exécuter du code dans un thread différent doté d'autorisations limitées (pas d'accès au DOM). Le second est un service worker - qui ressemble à un web worker mais qui a une distinction importante. Un service worker peut être configuré pour intercepter toutes les requêtes fetch.

Le service Worker peut en faire ce qu'il veut en les proxy, en consultant le cache ou en traitant lui-même la demande. C'est ce dont je veux profiter : je souhaite proxy toutes les demandes de récupération et éventuellement choisir de restituer le HTML et de le renvoyer.

Une requête HTML de base ressemble à ceci

<button hx-post="/clicked"
    hx-trigger="click"
    hx-target="#parent-div"
    hx-swap="outerHTML"
>
    Click Me!
</button>

Normalement, cela enverrait une requête HTTP au serveur, mais nous voulons intercepter cette requête dans le service worker, gérer la requête et renvoyer du HTML. Ensuite, en arrière-plan, le service worker peut synchroniser les données avec le serveur tout en conservant son magasin de données local. Dans un article de suivi, je passerai en revue les détails de mise en œuvre de la façon dont j'ai procédé, certains problèmes que j'ai rencontrés, puis je parlerai d'autres idées.

Restez à l'écoute.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!