bext : un moteur web en Rust pour vos applications TypeScript

Un composant TypeScript, une page HTML, un visiteur qui obtient sa réponse. Entre ces trois étapes se cachent un compilateur, un moteur de rendu et un serveur web. bext réunit ces fonctions dans un moteur écrit en Rust. Avec PRISM, il permet de construire des sites et des applications à partir de composants TSX, puis de les rendre côté serveur.

Chez Webdesign29, nous développons ce moteur et l’utilisons pour notre propre site. Cet article ouvre le capot : vous allez suivre une page depuis son code, modifier un véritable composant dans une démo intégrée et comprendre où interviennent le rendu serveur et le cache.

Qu’est-ce que bext, le moteur d’applications web en Rust ?

bext est un moteur qui rapproche la préparation du code, son exécution et la diffusion des réponses HTTP. Son cœur est écrit en Rust ; les applications peuvent, elles, être développées en TypeScript. Le choix du langage du moteur et celui du langage de l’application sont donc indépendants.

Cette architecture part d’un problème concret. Sur un site sur mesure, il faut coordonner la compilation, le chargement des données, le rendu, le routage et la mise en cache. Une modification de contenu traverse plusieurs de ces étapes. Lorsque leurs règles sont dispersées, comprendre pourquoi une ancienne page reste visible ou pourquoi une réponse ralentit devient plus difficile.

bext place une partie de ces responsabilités dans un environnement commun. Sa présentation officielle décrit notamment la compilation TypeScript/JSX, l’exécution dans des isolats V8 et les fonctions de diffusion telles que le routage, la compression et le TLS. Les options exactes dépendent de l’application et de sa configuration.

PRISM : comment un composant TypeScript devient une page HTML

Avec PRISM, les pages sont décrites dans des fichiers TSX. Cette syntaxe associe la logique TypeScript à une représentation de l’interface proche du HTML. Un fichier de route peut aussi fournir un loader, une fonction qui prépare les données nécessaires à la page.

1. Écrire la routeLe développeur crée un composant et décrit les informations à afficher : le titre d’une prestation, un article ou des produits.
2. Préparer le codetsc-rs transforme le TypeScript et le JSX. Les annotations de types et les expressions d’interface sont traitées avant l’exécution.
3. Produire le renduDans l’application bext, PRISM intervient dans le rendu côté serveur. Les données du loader alimentent les composants pour produire la réponse HTML.
4. Servir la réponsebext envoie la page au navigateur. Selon la politique configurée, une réponse publique peut être conservée en cache et réutilisée.

Cette séparation aide à raisonner sur une panne. Un code impossible à transformer, une base de données lente et une page périmée en cache appellent trois diagnostics différents. Ils ne se résolvent pas tous en ajoutant de la puissance au serveur.

Démo interactive : du TSX à une page visible

Dans l’atelier ci-dessous, remplacez « Un site qui vous ressemble » par le nom de votre activité. Cliquez sur Compiler et afficher, puis ouvrez l’onglet JavaScript pour voir ce que le compilateur a produit. Vous pouvez aussi modifier la description ou ajouter un paragraphe dans le composant.

L’expérience montre deux choses : le TypeScript peut être compilé localement dans le navigateur, et le composant conserve sa fonction une fois transformé. La démonstration se limite à un fichier et à des composants sans dépendances externes. Le playground bext complet permet d’explorer davantage de modèles.

Rendu serveur, JavaScript et cache : ce qui change pour le visiteur

Le rendu côté serveur, ou SSR, consiste à produire le HTML avant de l’envoyer au navigateur. Un visiteur peut ainsi recevoir le texte d’un article ou la présentation d’un service dans la réponse initiale. Les interactions nécessaires peuvent ensuite compléter la page.

Le cache répond à une autre question : faut-il recalculer cette réponse à chaque visite ? Pour une page publique qui évolue peu, il peut être utile de conserver le résultat pendant une durée définie. La revalidation renouvelle ensuite ce contenu selon la politique retenue.

Ces exemples sont des décisions d’architecture, pas des réglages à appliquer indistinctement. La présence d’un compte, d’un cookie ou d’un prix personnalisé change la façon de traiter la réponse. La performance doit rester compatible avec l’exactitude des informations affichées.

Un exemple en production : le blog que vous lisez

Le site Webdesign29 fonctionne avec PRISM et bext. Ses articles restent dans une base de données : leur titre, leur texte, leur catégorie et leur état de publication sont gérés séparément du code qui dessine la page.

Lorsque vous ouvrez une actualité, la route retrouve l’article publié à partir de son adresse. Le composant construit ensuite le titre, le contenu, les liens vers les autres articles et les informations destinées aux moteurs de recherche. La même source éditoriale alimente la liste des actualités et le sitemap.

Cela illustre une propriété utile pour un projet client : le moteur de rendu ne doit pas dicter la façon de rédiger le contenu. Une interface d’administration peut continuer à gérer les textes tandis que l’équipe technique fait évoluer la présentation, les intégrations et les règles de diffusion.

Pour quels sites et applications choisir bext ?

bext mérite d’être étudié lorsqu’un projet demande une maîtrise du rendu et de l’hébergement : un site sur mesure, une application métier, une interface reliée à plusieurs services ou une plateforme qui produit des aperçus de code. Son intérêt se juge sur les contraintes du projet et sur la capacité de l’équipe à maintenir l’ensemble.

Avant une migration, nous examinons les fonctions existantes, les flux de données et les parcours à préserver. Une boutique doit continuer à calculer les bons montants. Un site éditorial doit conserver ses adresses utiles. Un espace professionnel doit respecter ses règles d’accès. Le choix d’un moteur vient après ces exigences.

Pour explorer l’architecture, commencez par la documentation bext. Pour comprendre la brique qui transforme le TypeScript, poursuivez avec notre article sur ts-rs, avec un compilateur à essayer en ligne.

Questions fréquentes sur bext et PRISM

Faut-il écrire du Rust pour développer avec bext ?

Le moteur est écrit en Rust, mais une application PRISM peut être écrite en TypeScript et TSX. Le développeur travaille sur les composants, les routes et les données de son application.

Quelle différence entre bext et PRISM ?

bext est le moteur qui exécute et diffuse l’application. PRISM est le système utilisé pour organiser et rendre les pages TSX. Le compilateur tsc-rs prépare le TypeScript et le JSX utilisés dans cette chaîne.

Le rendu serveur garantit-il un meilleur référencement ?

Il permet de livrer du HTML contenant les informations de la page. Le référencement dépend aussi de la qualité du contenu, des liens, de l’indexabilité, des URL et de nombreux autres éléments. Le SSR est un choix technique, pas une garantie de position.

Peut-on tester bext sans installer un serveur ?

Oui, l’atelier intégré permet de tester la compilation et un aperçu JSX. Le playground officiel propose une expérience plus complète dans le navigateur. L’exécution du moteur serveur demande ensuite un environnement adapté.