Adopter Vuetifyjs ou Material.io ?

Bonjour,

Avez-vous déjà dû choisir entre : Material.io et Vuetifyjs ? Avec comme principale critère le rendu visuel et les fonctionnalités/éléments disponibles ?

J’ai comparé le code source d’un élément visuellement identique, prenons la topbar de material.io et la topbar de vuetifyjs, je trouve que le code source des éléments de material.io est plus simple.

Que pensez-vous de Vuetifyjs ? Est il facile à prendre en main ? Est-ce-qu’avec le temps vous avez obtenu des réflexe pour mettre en place des éléments sans regarder dans la documentation ?

Bon vol,

A.

EDIT : Material avec un a et non un e.

Les deux ne sont pas comparables !

• Material.io te fournit des composants CSS ou des composants Recat (à voir si vuematerial.io te fournit les composant material.io pour VueJS… ou si c’est autre chose)
• Vuetify te fournit des composant VueJS

Vu que j’utilise ni React, ni VueJS actuellement sur mon projet c’est plus ou moin comparable, ça me demandera le même coup de mise en place si je choisi soit l’un, soit l’autre.

Nan c’est pas vraiment comparable. Y a une différence entre écrire le code d’une table,devoir faire soi même l’itération pour écrire les tr/td, et simplement passer ton tableau JavaScript à manger à un composant v-simpletable.

La solution saine, à mon sens, est celle où tu choisis d’abord ton framework JS pour ses qualités intrinsèques, puis où tu choisis ton jeu de composants compatible avec ton framework.

Je regarde principalement pour restructurer visuellement mon application avec un framework CSS material design. Mon code est déjà structuré en module, je n’ai que très peu d’intérêt à adopter un nouveau framework reactif. Mes données ne changent pas d’état (je n’ai pas besoin d’actualiser les éléments de la page), j’ai seulement un flux constant de nouvel élément.

Du coup ce que tu recherches, c’est plus un framework CSS comme Bootstrap, Materialize ou material.io que tu cites au-dessus. Quelque chose qui te donne une feuille CSS et des balisages à respecter, donc.

Parce que les frameworks de composants imposent que tu utilise le framework JS pour lequel ils sont conçus.

Personnellement j’ai utilisé Bootstrap et aussi Materialize plus récemment (les liens donnent des retours rapides d’utilisation).

Les finitions de materialize ne me conviennent pas je vais forcement passer derrière.

Pour Bootstrap c’est une solution sans plus (autant niveau possibilité que rendu).

J’ai quasiment fini l’intégration de react dans mon projet mais il y a toujours un mais… Je me hurte à un mur, j’ai un temps de build en développement avec ma fonction de watch est de 5 secondes ! Ce qui est immonde (je ne suis pas habitué à ce délais, ce qui me fait souvent actualiser la page avant le changement).

En faisant ma transition j’ai été obligé de passer à une structure en type=module ce qui a un intérêt limité (face à l’avancement de l’implémentation des class qui n’est pas complète). Donc j’importe react et ses composants avec :

import React from 'react'
import ReactDOM from 'react-dom'

Ce qui est la méthode parfaite avec l’environnement de production (ce que la doc ne cesse de rappeler)… Mais pour le watch (environnement de développement) ce n’est pas la méthode recommandé. En faisant import React from 'react', je suis obligé d’intégrer browsersify pour que les importes fonctionnent mais j’explose le chrono et je passe d’un build de 300 ms à 5 sec…

Je ne sais pas quoi faire des imports de module sans utiliser browsersify ou webpack :

import React from 'react'

Sans browsersify/webpack je me prends :

Failed to resolve module specifier "react". Relative references must start with either "/", "./", or "../".

Mais si j’utilise browsersify mon temps de build en développement explose, il n’y a pas une alternative babel pour régler le soucis ?

L’alternative que propose la doc en version de développement est :

<script src="https://unpkg.com/react@16/umd/react.production.min.js"></script>
<script src="https://unpkg.com/react-dom@16/umd/react-dom.production.min.js"></script>

Mais ça oblige à enlever les imports à la main, je n’ai pas trouvé de module babel qui fait ça…

La doc est contradictoire, elle expose deux moyens de coder différent pour l’environnement de production / développement qui dépasse la simple changement de configuration, à les écouter il faudrait coder/importer le code différemment, je ne peux pas me permettre d’avoir deux versions de code pour prod/dev, ça n’a pas de sens.

Un temps de build de plusieurs secondes sur un projet JS est quelque chose qui me semble du domaine du normal par les temps qui courent. Surtout si tu passes par des compilateurs lourds, genre webpack et/ou babel.

Je trouve ça dingue qu’avec Babel on est obligé de passer avec Browsersify pour importer react et react-dom via un import (et ça à chaque build !)… Il doit bien y avoir une version pré-compilé pour cet usage…

Tout mon code fonctionne sans Browsersify… J’ai du mal à comprendre comment ça se fait qu’une lib n’est pas compatible avec les imports sachant qu’il y a des outils comme Babel qui permettent de compiler en ES valide.

J’ai vu : es-module-shims via cet article ça semble faire ce que je veux.

Si es-module-shims ne fonctionne pas, j’ai quelques idées de HACK pour faire ce que je veux faire, si j’ai la possibilité de modifier les path de mes imports avec un plugin comme : babel-plugin-module-rewrite (git), je suis persuadé qu’on peut proprement abrogé l’utilisation de browsersify et les 5 secondes de build.

Un temps de build de plusieurs secondes sur un projet JS est quelque chose qui me semble du domaine du normal par les temps qui courent. Surtout si tu passes par des compilateurs lourds, genre webpack et/ou babel.

Ca dépend on parle d’un build de prod ou de watch. En watch, pour dev donc (ici le cas si j’ai bien lu) c’est super long ! En prod' avec les optimisations etc ca me choque moins

Ça dépend de quel temps on parle en fait.

Personnellement, en watch, le build initial est long, mais les rebuilds partiels suite à des modifications de code sont rapides (sauf sur certains fichiers, mais là on est dans des cas avancés).

Les builds de prod sont toujours longs par contre.

Ouai on est d’accord !

Ma fonction watch, c’est celle qui agit après chaque modification de fichier

Apparemment il faut utiliser webpack, ce qui m’oblige à jeter tout mon script gulp. Webpack se veut être un remplacement/concurrent de gulp mais il n’a pas tous les équivalences des plugins gulp que j’utilise. Ce qui veut dire recoder certain passage de zéro (-> comprendre retrouver le package qui fait ça et l’implémenter) : Génération de la doc, génération de site map, génération des fichiers LESS, compression des SVG, copier des fichiers précis dans le dossier build.

Je pense partir de Zéro avec RCA et migrer mon app dans mon nouveau projet, plutôt qu’aménager mon projet pour implémenter REACT.