Migrer WebDev sans réintroduire une dépendance éditeur

React, Angular, Vue : fuir PC SOFT pour tomber dans le cycle de versions d’un autre éditeur, ce n’est pas une migration — c’est un déménagement. Il existe une stack web moderne, stable et sans propriétaire : htmx + Web Components natifs + un backend Go ou C#. Voici pourquoi elle est la cible naturelle pour les applications issues de WebDev.

Première question : WebDev ou WinDev desktop ?

La réponse détermine toute la stratégie. Ce sont deux migrations différentes.

WebDev → migration directe. L’application vit déjà dans un navigateur. Le modèle page/traitement serveur, les champs dynamiques, les zones répétées — tout a un équivalent web direct. La cible htmx est très proche du modèle mental de WebDev : la logique reste sur le serveur, le navigateur affiche. C’est la migration la plus propre.

WinDev desktop → sujet à part. Transformer une app native en app web implique Electron (~150 Mo par app) ou Tauri. Ça marche, mais les clients avec lecteurs codes-barres, ports série ou impressions directes vont souffrir. Pour le desktop, C# WPF ou .NET MAUI reste souvent la meilleure cible.

La suite de ce guide concerne WebDev.

Pourquoi pas React, Angular ou Vue ?

La raison de quitter WinDev est précisément d’échapper à la dépendance envers un éditeur. Remplacer PC SOFT par Meta (React), Google (Angular) ou une fondation dont le financement est incertain (Vue) déplace le risque sans l’éliminer. Le cycle de versions des frameworks JavaScript est réel : une application Angular 12 non maintenue n’est plus supportée aujourd’hui. Le coût de ces migrations « de framework » est exactement le même type de rente que celle que vos clients fuient chez PC SOFT.

La promesse que vos clients veulent entendre : « On vous sort d’un éditeur propriétaire sans vous enfermer chez un autre. » C’est ce que garantit une stack sur standards W3C — une application htmx + Web Components construite aujourd’hui fonctionnera dans un navigateur dans quinze ans, sans aucune action de votre part.

La stack : htmx + Web Components + Go ou C#

htmx : le modèle serveur, pas le modèle client

htmx est une bibliothèque de 14 Ko — code source lisible, zéro dépendance, zéro build, zéro npm. Les requêtes partent du navigateur via des attributs HTML, le serveur renvoie directement du HTML, le fragment est injecté dans la page.

<input type="search" name="q"
       hx-get="/clients/liste"
       hx-trigger="input changed delay:300ms"
       hx-target="#resultats"
       placeholder="Rechercher un client…">

<div id="resultats"></div>

Pour un développeur WebDev, c’est le modèle mental le moins dépaysant : la logique métier vit côté serveur, exactement comme avant — sauf que le serveur est votre code, pas une boîte noire PC SOFT.

Web Components : les superchamps du web standard

Pour les quelques éléments qui exigent de l’interactivité locale — tables éditables complexes, plannings, sélecteurs enrichis — les Web Components natifs sont l’équivalent conceptuel des superchamps WinDev. Standard W3C, sans bibliothèque externe.

<table-gestion
  source="/api/commandes"
  colonnes="ref,client,montant,statut"
  editable="statut">
</table-gestion>

htmx couvre 90 % des écrans de gestion (listes, fiches, formulaires CRUD). Les Web Components prennent en charge les quelques composants riches. Les deux cohabitent sans conflit, sans npm, sans pipeline de build.

Le backend : Go ou C# selon votre contexte

htmx a besoin d’un serveur qui reçoit les requêtes et renvoie des fragments HTML — rôle conceptuellement identique à celui du serveur d’application WebDev, sauf que c’est votre code, sans licence par session.

Go produit un exécutable autonome de quelques mégaoctets, sans runtime externe, qui tient des milliers de connexions simultanées sur une petite VM. C# avec ASP.NET Core minimal API suit la même logique en mode self-contained — si vos clients sont dans une culture Microsoft, c’est la transition la plus naturelle. Le serveur d’application WebDev avec sa facturation par session disparaît, remplacé par un binaire que vous compilez et déployez où vous voulez.

Ce que cette architecture ne résout pas

• Les états denses côté client — planning drag & drop complexe, éditeur de documents riche, carte interactive temps réel : pas le domaine de htmx. Un composant React ou une bibliothèque dédiée peut coexister sans contaminer le reste.
• Les applications desktop pur — ports série, impression directe, périphériques USB : la cible web ne les couvre pas sans passer par les API Web (FileSystem Access, Web Serial…) ou une solution desktop distincte.
• Les équipes habituées aux SPAs — la transition vers « le serveur renvoie du HTML » demande un changement de paradigme réel. Facteur humain à intégrer dans le chiffrage.

Pourquoi cette stack est cohérente avec la promesse wxit

La raison pour laquelle vos clients fuient WinDev est une question de contrôle. Une stack htmx + Web Components + Go/C# repose entièrement sur des standards ouverts (W3C, HTTP, SQL) et sur des outils dont le code source vous appartient. Zéro dépendance à un éditeur de framework. Zéro cycle de montées de version imposées. Zéro licence par session.

La transpilation depuis WebDev est plus directe qu’on ne le croit. Le découpage page / traitement serveur qui existe déjà dans les sources WebDev se mappe naturellement vers le modèle htmx. Ce n’est pas une réécriture de zéro — c’est une translation d’architecture que le code source WebDev, une fois extrait en format texte, rend possible de façon assistée.

Votre application WebDev mérite mieux qu’un framework de remplacement. Audit gratuit — contact@wxit.fr.