Bonjour à tous! Dans cet article, je voudrais vous expliquer comment réduire plusieurs fois la taille des fichiers javascript grâce à un langage de modèle tel que hmpl.

L'approche technologique qui apparaît dans l'article n'est pas nouvelle, mais elle est néanmoins suffisamment populaire aujourd'hui pour mériter d'être évoquée.

Réduire la taille du fichier javascript permettra aux pages de se charger plus rapidement sur le client. Si nous prenons le SPA moderne, il s'avère que la taille des fichiers, même en tenant compte de toutes les minifications, est encore assez importante. Bien sûr, une fois que vous chargez une page une fois, il est plus facile de s'y retrouver, mais le premier temps de chargement lui-même peut aller d'une seconde à, disons, plusieurs minutes avec une mauvaise connexion Internet. Peu de clients voudront attendre aussi longtemps.

Lorsque vous utilisez la plupart des frameworks et bibliothèques pour créer une interface utilisateur, vous devez écrire beaucoup de code passe-partout. Chaque symbole occupe de l'espace mémoire. Prenons un clicker Vue.js :

createApp({
  setup() {
    const count = ref(0);
    return {
      count,
    };
  },
  template: `

        Click!
        
Clicks: {{ count }}
    
`,
}).mount("#app");

Un clicker super simple, mais même s'il nécessite une bonne quantité de lignes de code en js, sans parler des cas où l'application est plus ou moins volumineuse.

Même sans deux virgules, il pourrait y avoir quelques octets de moins

Ce n'est pas seulement un problème avec Vue, mais aussi avec d'autres frameworks et bibliothèques qui fonctionnent de manière similaire. Mais ce n’est pas le seul point. Il y a un grand nombre de modules supplémentaires qui leur sont attribués, et ils reçoivent le même nombre de modules supplémentaires, et ainsi de suite jusqu'à « l'infini ».

En fait, l'une des solutions à ce problème a été proposée il y a longtemps et elle est très simple : elle consiste à préparer l'interface utilisateur sur le serveur et à la charger simplement sur le client. Grâce à cela, la taille des fichiers de candidature peut être considérablement réduite. C'est exactement l'idée utilisée dans HMPL.

Dans l'exemple, je vais aussi essayer de créer un clicker, mais en utilisant hmpl.js.

document.querySelector("#app").appendChild(
  hmpl.compile(
    `

        Click!
        
Clicks: {{ src: "/api/clicks", after: "click:button" }}
    
`
  )().response
);

Comme vous pouvez le voir, l'interface utilisateur sera la même, mais la taille du fichier sera un peu plus petite.

Même si vous réduisez les fichiers et supprimez tous les espaces inutiles des modèles, les fichiers seront peut-être à égalité ou quelque chose de plus gros, mais ce n'est qu'une hypothèse sur de petits exemples. Si nous prenons de grosses applications, alors il est évident qu'avec cette approche, il y aura beaucoup moins de js.

Comme le montre l'exemple, la fonctionnalité de calcul et de stockage de l'état de l'application peut, si vous le souhaitez, être déplacée vers le serveur.

Comme vous pouvez le voir sur l'exemple, la fonctionnalité de calcul et de stockage de l'état de l'application peut, si vous le souhaitez, être déplacée vers le serveur. Il est clair que s'il y a un grand nombre d'utilisateurs, cela fera simplement tomber le serveur, mais le fait que l'interface utilisateur soit la même est important.

Oui, bien sûr, cette méthode présente non seulement un tel inconvénient, mais aussi la réutilisabilité de l'interface utilisateur, comment mettre en cache l'interface utilisateur pour ne pas tout charger cent fois et bien plus encore. Il est important de trouver une alternative qui, si elle est correctement configurée, peut rivaliser avec la plupart des solutions modernes.

Merci à tous d'avoir lu cet article !

Liste des matériaux :

https://hmpl-lang.github.io/#/docs
https://vuejs.org/guide/quick-start.html