Peux tu développer sur comment éviter le piège de réinventer son “petit” framework maison en suivant cette stratégie ?
Ajd tout ce que jQuery fait, dans la plupart des cas css3 peut le faire (et suffit)
et je crois que j’ai écrit “autant que possible”.
Je peux ajouter “tant que mtn”, “vu les changements à venir” et “suivant les besoins de chacun et la situation professionnel de chacun”… (bref, restez pragmatique, je suis pas #Gooroogle…)
Cordialement,
Laurent
Bonjour,
la source qui est dans la section “développement” et non js (et de toute façon, quand on lit c’est la direction que la discussion prend)
Cordialement,
Laurent
Je m’étais posé la question aussi, et depuis j’ai plusieurs éléments de réponse.
Première raison : éviter de reproduire le fiasco d’une lib qui plante : http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how-to-program/
Mais ça n’est pas la seule.
- si tu as l’habitude de bosser avec une librairie, il est très difficile de s’en passer (eg. lodash en ce qui me concerne). Or il n’est pas toujours possible de la rajouter. Soit parce que tu n’as pas la main sur les dépendances extérieures, soit parce que tu as un réel soucis de légèreté. Tout ce qui est natif au contraire, sera toujours à disposition.
- une librairie, c’est de nombreux soucis de versioning, de bugs potentiels etc.
- une librairie pollue souvent le global namespace. Elle rend donc le code JS moins stateless et cela peut devenir un réel cauchemar à démêler ensuite.
Conclusion, je dirais qu’il faut utiliser ce avec quoi on est à l’aise parmi ce qu’il est possible de faire, mais il est essentiel d’encourager javascript à devenir un langage plus complet et plus riche en fonctionnalités et pour cela, ne pas considérer que “le JS ça le fait avec la librairie XX” c’est aller dans le bon sens !
4 « J'aime »
Le problème est que JS à en lui-même une bibliothèque standard pauvre ce qui a conduit la communauté à décentraliser l’équivalent d’une bibliothèque standard. Même le développement des runtime est décentralisé (… pour le front en tout cas). Comment envisager de revenir vers un langage avec une stdlib riche développée par une entité de référence (une entre prise comme oracle avec Java, une fondation comme la PSF avec Python ou un project leader) ?
Les alternatives sont peut-être certains langages qui compilent en JS, comme ClojureScript ou elm qui eux proposent une bibliothèque standard dont le développement est centralisé.
Enfait, à mon avis, tout dépend de ce que l’on souhaite faire.
Mais ce qui m’étonne dans cette démarche c’est que Javascript est un langage “comme un autre” et que pour les autres langages, l’utilisation de frameworks et de bibliothèque ne se pose pas.
On en fera pas d’application en C++ (native ou pas) sans un frameworks dédié (à la rigueur Qt si l’on souhaite être Os indépendant). On ne fera pas de Java pour application Web sans dépendance (Spring, Struts) …
Donc pourquoi cela ne devrait pas être pareil pour javascript ? Alors ok, l’IHM arrive via le navigateur … mais pour tous le reste, utiliser des composants validés par des personnes dont c’est le métier, est quand même un gain de temps (et de standardisation) plus qu’intéressant. Après, quelque soit le langage, prendre une obscure librairie, maintenu par un groupe limité de développeur … et une prise de risque trop important si on a pas la capacité de la maintenir soit même par la suite. (et encore que, tout dépend la durée de vie du développement).
1 « J'aime »
J’ai appris le JS à travers ses nombreuses bibliothèques ; effort que je n’avais jamais fait de but en blanc pour aucun langage. Pourquoi comprendre les mécanismes profond de fonction bas niveau fourni par PHP.exe ?
jQuery était quand même un truc formidable de simplicité et était fait en JavaScript mais sa syntaxe ne ressemblait à rien de ce que j’avais pu croiser sur EditeurJavaScript (haha).
Je suis rentré dans ses méandres et me suis aperçu que contrairement au idée reçu, il fourmille de fonction bas niveau comme n’importe quel langage ce JavaScript et comme dans n’importe quel langage « la productivité » impose des abstractions pour rendre les choses plus simples, et plus abordables. Les abstractions… qui code en assembleur ici ?
Alors oui, il y a des écosystèmes fermés avec une unique bonne façon de faire, et des écosystèmes ouvert avec des pléthores de façon de faire, et toujours de nouvelles idées, ou de nouvelles façons d’aborder les choses pour les rendre plus simple, plus performante, moins coûteuse, etc et basé sur des idées/mécanisme. C’est comme ça. Pourquoi arrêter ? Hum… voyons.
J’ai fini par accepter le fait que le JavaScript, c’est un écosystème complet de bibliothèque fournit librement via npm and co et c’est dans cette optique qu’il évolue aujourd’hui.
Ce que je veux dire, c’est que je ne le vois pas comme un problème. Je connais les concepts fondamentaux que l’on retrouve en parallèles d’une bibliothèque à l’autre, chacun cherchant des mises en oeuvre soit plus performante, soit plus simple, soit plus versatile, soit plus verbeuse, soit moins…
La vrai question pour moi est « Pourquoi devrait t-on creuser au delà des bibliothèques pour faire du Vanilla JavaScript ? Quand cela à du sens ! »
Un exemple de jQuery vers le DOM VanillaJS: https://blog.lesieur.name/vanilla-js-france/
Vouloir se passer de jQuery là où il est utile serait tout autant inutile que de l’utiliser là ou il ne l’est pas, non ?
1 « J'aime »
- Il y a des améliorations à faire dans la stdlib javascript et le language lui meme; cela dit il faut reconnaitre que ES6 (et encore plus ES7 avec l’arrivé de async/await) sont des avancées significative
- Par stdlib tu veux dire l’API DOM et HTML5, je vois pas en quoi elle est pauvre.
- La solution n’est pas clojurescript
- elm est particulier dans le sens ou elm impose un framework de dev front
Pour moi on utilise des framework dans le dev front comme on utilise des framework en backend (à qui ça viendrais à l’idée de dev un backend au dessus de gunicorn ou n’importe quelle autre server WSGI? pourquoi pas faire simplement du CGI dans cas?). Ça étonne personne qu’il y a N framework pour faire des jeux…
Sinon, les autres raisons pour les nombreux framework qui sont lié:
- Il n’y a pas de consensus sur comment faire une UI bien.
- Les besoins pour tel ou tel produit (site vritrine, CMS, application metier etc…) sont différent d’où des approche differentes
Je me permets de rectifier 2 pétouilles :
- async / await débarque en Juin de cette année, donc ES2017 (ES8)
- la lib standard de JS n’a rien à voir avec son environement hote. Donc ce n’est pas DOM le soucis ici, mais plutot la pauvreté de Array.prototype et String.prototype pour ne citer qu’eux.
2 « J'aime »
En fait je suis d’accord #girouette