Expérience réalisée avec .

Forces et faiblesses du framework UIkit v3

Attention: je vais mettre en garde par rapport à un certain nombre de défauts de conception du projet qu’il convient de rattacher au contexte d’utilisation dans lequel je souhaite l’intégrer. Je recherche une bibliothèque de composants front-end:

  • suffisamment documenté, autant pour les utilisateurs type webmaster que pour les développeurs front-end avec au moins 3 ans d’expérience)
  • dont la partie Javascript est écrite en natif/Vanilla JS (i.e.: n’a pas recours à un framework tiers type Angular, React, VueJS, jQuery…)
  • …mais qui sit tout-de-même capable d’accueillir avec facilité des composants tiers écrits en VueJS (pas testé à l’heure ou j’écris ces lignes, mais la documentation nous assure que c’est possible
  • dont la partie Styles est écrite au format SCSS (exit: LESS)
  • dont les composants sont suffisamment séparés pour générer des bundles à la carte (via Webpack ou autre) et ne soumettre au serveur que du code nécessaire

Si vous recherchez une bibliothèque front-end proposant un choix large de composants, qui soit légère et facile à poser et que vous ne l’utiliserez que depuis des pages en HTML (i.e.: sans chercher à l’étendre vous-même), UIkit dans sa version 3 est un bon challenger.

Dans un cas plus proche du mien, voir ci-dessous.

Défauts majeurs d’UIkit v3 pour réaliser un bundle pertinent et à la carte avec Webpack

UIkit a beau se targuer d’être bundle-able via Webpack dans sa documentation officielle, à y regarder d’un peu plus près sa conception va poser un certain nombre de problèmes:

  • La doc propose un bundle à partir des fichiers présents dans le dossier dist du framework, soit des fichiers déjà compilés!. En effet, le projet inclut un certain nombre de scripts de génération/compilation des assets CSS, JS et icônes à exécuter via NPM/Yarn.
    En d’autres termes, vos possibilités de bundle se limitent:
    • Pour le JS et les icônes: à exclure à la carte une petite dizaine de composants non présents dans le core (117,6 kB de gagnés au total lorsque le code est minifié) et le fichier uikit-icons.min.js (65,0 kB) qui contient la bibliothèque d’icônes en SVG. Le reste des composants est indissociable du core et inclus dans le fichier uikit-core.min (88,2 kB).
    • Pour le CSS: à choisir entre uikit-core.min.css (256,1 kB (et perso je trouve ça lourd pour un framework…) ou uikit.min.css (271,9 kB) qui exclut la dizaine de composants non présents dans le core (pas de bundle à la carte possible pour les styles).

    Sans modifier ou surcharger (encore faut-il pouvoir le faire!) directement des fichiers du framework (oui, oui, ceux qui sont dans votre dossier node_modules et par définition pas modifiables) pour commenter les composants JS et CSS qu’on ne souhaite pas utiliser dans notre projet et lancer une compilation avec les scripts fournis par UIkit, impossible de faire un build vraiment à la carte…

  • Les sources SCSS fournies sont obtenues à partir d’une compilation des sources LESS. En d’autres termes, vous pouvez modifier les fichiers SCSS fournis autant que vous voulez: ils ne seront jamais pris en compte si vous effectuez une compilation via les scripts fournis par le framework!
    Donc si j’ai bien tout compris: les sources LESS sont vos sources de référence que ce soit:
    • pour effectuer un bundle à la carte via les scripts fournis par le framework
    • ou pour écrire vos propres composants UIkit-friendly.

Personellement, après avoir été séduit par la documentation et les démos en ligne d’UIkit v3, mais après quelques tests d’intégration à mon projet, je me sens un peu refroidi à l’idée d’utiliser UIkit dans sa version 3…

Sources en Vanilla Javascript, oui mais…

Si les sources JS n’ont bien recours à aucun framework tiers, il convient de noter que les développeurs d’UIkit on repris un certain nombre de méthodes et de logiques issues de jQuery qu’ils ont converti en fonctions.

Vous rencontrez le système d'import/export propre aux modules E6+. Mais si vous êtes familier avec jQuery, vous retrouverez notamment un certain nombre d’événements (.on()) et de méthodes pour traverser le DOM (.empty(), .html(), .prepend(), .append(), .before(), etc…) qui vous seront familières.
Vous retrouverez aussi le fameux dollar $ de jQuery.

Chacun trouvera du pour et du contre à cette philosophie. Pour ma part:

  • La documentation développeur est inexistante (la documentation utilisateur, par contre, est plutôt bien faite et on parvient rapidement à mettre en place les composants en utilisant les exemples et en tripatouillant un peu de code HTML… dans la mesure où on est un profil d’intégrateur HTML un minimum expérimenté).
  • Nous ne sommes PAS débarrassés de jQuery
  • …et à ce moment là, il faut se poser les questions suivantes:
    • Si je veux écrire des composants custom pour mon projet, est-ce que ça vaut le coup de les intégrer à UIkit?
    • Est-ce que la learning curve en vaut la chandelle sachant qu’une fois intégrés à UIkit, mes composants custom ne fonctionneront sur d’autres projets qu’à condition d’être rattachés par, au minimum, le code core du framework?
    • Est-ce que (toujours pour mon code custom) ça vaut le coup de se traîner des concepts qui nécessitent une connaissance des concepts de jQuery (dont tout le monde à désormais l’air de vouloir se défaire au plus vite) au détriment de l’utilisation des événements et méthodes natifs ES6+? (penser à faciliter l’intégration d’autres développeurs front-end au projet)