Le développement frontend repose principalement sur des framework JS. Ces frameworks peuvent imposer l'architecture à suivre mais aussi le style de développement à suivre, et la question qui vient à l'esprit d'un minimaliste est : Existe-t-il une solution plus légère ? Comment développer ("prototyper") en frontend en utilisant JS sans avoir à faire appel à une framework ?
Cette question me vient toujours à l'esprit à chaque fois que j'essaie de faire une démo rapide et je me trouve déboguer un code JS perdant ainsi un temps précieux en classe.
Ces derniers jours, je me suis retourné vers une technologie (si on peut dire) Oracle à laquelle j'ai tourner le dos depuis longtemps. C'est Oracle JET (Oracle JET). Comme étant intéressé exclusivement par Java et à la limite J2EE (maintenant EE4J), je n'ai pas pas trop concentré sur les autres technologies Oracle. Aujourd'hui, je me suis retourné pour voir est ce que je pourrais trouver une réponse à ma question.
Est-ce que Oracle JET est bel et bien la réponse à la question que j'ai posée ? Oui et Non.
Oui, parce que à la base, Oracle JET est un ensemble de composants et non pas une framework (selon l'explication). Vous pouvez suivre toujours vos propres méthodes, architectures et approches de développement et au même temps avoir une large gamme de composants que vous pouvez intégrer facilement à votre application (liste).
Non, pour les raisons suivantes :
Mais malheureusement, ce n'est jamais aussi simple que ça.
Premièrement, n'oubliez pas de donner le droit d’administrateur à la commande (sudo).
Deuxièmement, si Node n'est pas à jour, alors vous risquez d'avoir des erreurs de syntaxe sur le code généré. L'erreur qui m'est arrivée :
$ ojet build
/home/tarek/JavaPlayground/firstJet/MyFirstJET/node_modules/winston/lib/winston.js:11
const { warn } = require('./winston/common');
^
SyntaxError: Unexpected token {
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:374:25)
...
Comme vous voyez, cette erreur n'a rien à voir avec Oracle JET mais avec "winston", et à vrai dire, je n'ai jamais entendu parlé de ce "winston" avant ce message d'erreur. Une erreur commune qui nécessite la mise à jour de Node (l'issue). Là c'est pas aussi simple aussi (propositions "théorique", et n).
npm peut rendre npm inutilisable (Oui, apparemment ça arrive)
Ensuite, il faut une installation presque manuelle pour mettre à jour Node et pour récupérer npm qui a tenté de mettre à jour Node.
Une fois tous les problèmes sont résolus, l'application fonctionne à merveille.
Cette question me vient toujours à l'esprit à chaque fois que j'essaie de faire une démo rapide et je me trouve déboguer un code JS perdant ainsi un temps précieux en classe.
Ces derniers jours, je me suis retourné vers une technologie (si on peut dire) Oracle à laquelle j'ai tourner le dos depuis longtemps. C'est Oracle JET (Oracle JET). Comme étant intéressé exclusivement par Java et à la limite J2EE (maintenant EE4J), je n'ai pas pas trop concentré sur les autres technologies Oracle. Aujourd'hui, je me suis retourné pour voir est ce que je pourrais trouver une réponse à ma question.
Est-ce que Oracle JET est bel et bien la réponse à la question que j'ai posée ? Oui et Non.
Oui, parce que à la base, Oracle JET est un ensemble de composants et non pas une framework (selon l'explication). Vous pouvez suivre toujours vos propres méthodes, architectures et approches de développement et au même temps avoir une large gamme de composants que vous pouvez intégrer facilement à votre application (liste).
Non, pour les raisons suivantes :
- Oracle JET est basé sur un grand nombre de librairies JS et bien sûre sur Node. Malgré la facilité d'utilisation, le tout doit être à jour et l'outil effectue (presque) à chaque fois des actions de téléchargement; cela devient (avec un peu d'exagération de ma part) inutilisable dans un contexte d'enseignement.
- Le code généré par l'outil ojet-cli est incroyablement grand puisque il intègre le tout, non pas seulement les composants que vous voulez utilisés, par conséquent, un grand travail de nettoyage est nécessaire avant le déploiement (cela reste toujours acceptable dans le cadre d'un prototype).
npm install -g @oracle/ojet-cli
Mais malheureusement, ce n'est jamais aussi simple que ça.
Premièrement, n'oubliez pas de donner le droit d’administrateur à la commande (sudo).
Deuxièmement, si Node n'est pas à jour, alors vous risquez d'avoir des erreurs de syntaxe sur le code généré. L'erreur qui m'est arrivée :
$ ojet build
/home/tarek/JavaPlayground/firstJet/MyFirstJET/node_modules/winston/lib/winston.js:11
const { warn } = require('./winston/common');
^
SyntaxError: Unexpected token {
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:374:25)
...
Comme vous voyez, cette erreur n'a rien à voir avec Oracle JET mais avec "winston", et à vrai dire, je n'ai jamais entendu parlé de ce "winston" avant ce message d'erreur. Une erreur commune qui nécessite la mise à jour de Node (l'issue). Là c'est pas aussi simple aussi (propositions "théorique", et n).
npm peut rendre npm inutilisable (Oui, apparemment ça arrive)
Ensuite, il faut une installation presque manuelle pour mettre à jour Node et pour récupérer npm qui a tenté de mettre à jour Node.
Une fois tous les problèmes sont résolus, l'application fonctionne à merveille.
