Toujours à la recherche de mon prochain framework Javascript préféré, voici le test de Svelte.dev

Introduction

Je cherche depuis quelques mois (pas pressé le garçon) un framework Javascript capable de remplacer jQuery (donc avec manipulation des éléments visuels et appels Ajax). J’ai trouvé le framework Svelte.dev, qui promet d’être meilleur que React.js, sans le plat de spaghettis (boiler-plate free). Doc go!

C’est quoi Svelte?

Il s’agit d’un nouveau framework Javascript destiné à écrire des interfaces utilisateur. Selon le site, alors que React et Vue.js font fonctionner leur bazar (modification du DOM) dans le navigateur, Svelte compile le code afin de réduire ce bazar. Et avec la promesse d’écrire moins de code que React (qui a dit “c’est pas difficile” ?)

Comment ça marche?

Comme la plupart des frameworks qui se veulent moderne, on passe par l’étape Node.js + npm. Il faut donc, comme pour une appli Java, compiler le code Javascript avant de l’exécuter.

En vrai, c’est bien?

C’est plutôt une bonne surprise, le code s’organise bien, c’est compatible avec scss, la syntaxe reste lisible (on a droit aux moustaches -simples- pour indiquer les bindings, comme ailleurs). La compilation n’est pas trop lente. Bref, après avoir digéré les exemples, on a envie de coder avec ce framework.

Du coup, premier projet

J’ai commencé à écrire une interface pour une nouvelle application (un truc financier). L’écran d’accueil n’a posé aucun souci (une image, un texte explicatif et deux boutons). Il faut bien sûr écrire des fonctions de routage pour diriger les urls vers les bons composants.

L’écran de login a commencé à donner du fil à retordre car il faut gérer les deux champs identifiant et mot de passe, faire un appel CRUD auprès d’un serveur Tomcat et, selon la réponse, soit afficher un message d’erreur soit changer de page (bref, un formulaire de login basique).

Bien sûr, comme je n’ai pas envie de copier / coller les mêmes fonctions dans tous les composants Svelte, je me suis lancé dans l’écriture de composants permettant de gérer certaines choses comme la notion de formulaire et d’appel CRUD.

Et c’est là que le bât blesse: on trouve de nombreux exemples de composants Svelte (comprendre composant d’interface) mais rien pour le reste. Une fois que j’ai trouvé la syntaxe adéquate pour faire cohabiter mon mini-framework avec Svelte, mon application a fait un bon en avant puisque j’ai pu constater que l’appel CRUD permettant de se connecter était bien fait (bonne url et données bien formées). Joie. Mais de courte durée la joie. En effet, l’url que j’ai utilisée est de la forme /crud/modlogin/login. Mais bien sûr je n’ai pas encore écrit ce service donc cette url devrait retourner une erreur 404. Et là surprise: le navigateur indique un code 200, sans données. Quelle est cette diablerie?! (bienvenue en 1200!).

J’ai commencé par mettre ce comportement sur le dos de Node.js donc j’ai préparé une WebApp Java pour accueil mon interface et commencer l’écriture du service CRUD de login.

Comment intégrer le code Svelte dans une WebApp?

D’après les informations que j’ai trouvé (et elles sont peu nombreuses), il suffirait de coller le dossier “public/build” dans le projet et le tour est joué. Je confirme, ça fonctionne: Tomcat démarre, ainsi que l’application Svelte. Bonheur? Pas. Du. Tout. Tomcat étant un serveur Web, les appels HTTP sont traités à travers son mécanisme et pas celui mis en place dans l’application Svelte. Du coup, soit l’application affiche un message d’erreur car la page n’est pas connue soit c’est Tomcat qui retourne une 404.

Conclusion

Svelte est un framework prometteur mais le fait que le code ne fonctionne qu’avec Node.js est pénible. Pour une application complète (comprendre “avec un back-end bien costaud”), il faudrait faire cohabiter Node.js avec Tomcat (ça ressemble à pédaler pour charger les batteries d’une voiture électrique) et sans doute utiliser des urls absolues (ou sur un port différent).
Le prochain candidat sera, sans doute, Knockout.