Ajouter de l’interactivité sans tout réécrire
Vue s’adopte par morceaux. On peut l’ajouter à une seule page d’un site qui existe, sans toucher au reste — c’est ce qui le distingue le plus nettement des autres bibliothèques d’interface.
- Ajouté page par page, sans réécriture préalable
- Un seul composant peut suffire, chargé quand il devient visible
- Adossé à vos API existantes, en REST ou GraphQL
- Développé et hébergé en France, sur notre infrastructure
Le principe
L’adoption progressive, concrètement
Le pari inverse des autres
La plupart des bibliothèques d’interface demandent que l’application entière leur appartienne : on décide au départ, et on réécrit. Vue accepte de n’occuper qu’un coin de page. Le reste du site continue d’être servi comme avant, en HTML, par WordPress, Symfony ou ce que vous employez déjà.
Ce n’est pas un détail de confort : c’est ce qui rend la décision réversible et le budget fractionnable. On commence par l’écran qui pose problème, on mesure, et on continue — ou pas.
Une démonstration, plutôt qu’une affirmation
Le site que vous lisez fonctionne exactement ainsi. Il n’envoie aucun JavaScript d’interface, sauf à un endroit : le formulaire de rappel, qui est un composant Vue chargé seulement quand il devient visible. Le reste des pages est du HTML.
C’est l’argument de l’adoption progressive, appliqué à nous-mêmes. Vous pouvez le vérifier : ouvrez les outils de développement de votre navigateur sur n’importe quelle page de ce site, et regardez ce qui se charge.
Ce qu’il faut savoir avant de choisir
Comme toute interface construite dans le navigateur, un écran Vue n’est pas indexable simplement — c’est très complexe, souvent impossible. Tant qu’il s’agit d’un composant posé dans une page servie normalement, la question ne se pose pas : c’est la page qui est indexée, pas le composant. Elle revient dès que l’interface devient le site, et la réponse s’appelle alors Nuxt.
Reste la question humaine. Vue est répandu, sa documentation est réputée abordable, et le passer à une équipe qui n’en fait pas encore demande moins d’effort que ses concurrents. Mais si vos développeurs pratiquent déjà autre chose, c’est cet autre chose qu’il faut choisir.
Les usages
Ce que nous construisons avec
-
Un composant dans une page existante
Un formulaire qui réagit, un filtre, une carte interactive. Le reste de la page ne change pas et reste servi en HTML.
-
Recherche et filtres à facettes
Un catalogue qui se filtre sans recharger, tout en gardant des URL propres et indexables pour les pages de résultats.
-
Back-offices et tableaux de bord
Des écrans denses, avec beaucoup d’états à tenir. Pas d’enjeu de référencement, donc pas de contrainte de rendu.
-
Adossé à vos API
REST ou GraphQL, sur vos systèmes existants — que nous pouvons aussi construire, en Symfony, Python, Java, Go ou Node.js.
-
Migration par étapes
Un écran après l’autre, avec un existant qui continue de tourner entre-temps. Le contraire d’un projet à tout ou rien.
-
Développé et hébergé ici
Sur notre infrastructure nantaise, sans dépendre d’une plateforme dont la facture suit le trafic.
Questions fréquentes
Vue.js : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Vue ou Nuxt ?
Vue seul quand l’interface s’ajoute à des pages qui existent et qui gardent leurs URL. Nuxt quand le projet EST le site : il apporte le routage et le rendu côté serveur, donc l’indexation. La question à trancher d’abord est celle-là — ajoutez-vous un composant, ou construisez-vous un site ?
Vue ou React ?
Techniquement, les deux font le même travail. React a le vivier de développeurs le plus large ; Vue s’ajoute plus facilement à un existant, sans réécriture préalable. Si vos équipes en pratiquent une, prenez celle-là — c’est le critère qui compte le plus au moment de reprendre le code.
Faut-il refaire le site pour ajouter du Vue ?
Non, c’est précisément son intérêt. Un composant s’installe dans une page servie par votre outil actuel, et rien d’autre ne bouge. Ce site en est l’exemple : un seul îlot Vue, chargé quand il devient visible, sur des pages autrement dépourvues de JavaScript.
Est-ce que cela alourdit les pages ?
Seulement celles qui en contiennent, et seulement quand le composant devient visible si on le configure ainsi. Une page sans composant n’envoie rien de plus qu’avant. C’est l’inverse d’une application front, qui charge son moteur sur toutes les pages.
Qui pourra reprendre le code ensuite ?
La documentation de Vue est réputée abordable, et le passer à une équipe qui n’en fait pas encore demande moins d’effort que ses concurrents. Cela dit, le meilleur outil reste celui que ceux qui reprendront le projet savent déjà lire.
Un composant, ou toute l’application ?
La réponse décide de l’outil et du budget. Elle est souvent plus modeste qu’on ne le croit — et c’est une bonne nouvelle.