les liens du Colibri 20/04/2015
A lire !

"In addition, when you add code to said codebase, you usually end up wrapping every element or nodelist reference with $() as well, because you don’t know what input you’re getting. So, not only you’re locked in, but all future code you write for the same codebase is also locked in."
(Permalink)

Bookmark Bronco 20/04/2015
Tellement vrai: les "collisions" de code (traduisons, les prises de tête) dues au incompatibilités entre le code natif et jquery (nodelists vs jquery objects) sont souvent contre productives, surtout quand on apprend... déjà, la logique de javascript peut-être assez peu intuitive parfois mais si on la heurte à une autre façon de concevoir les choses... ^^

Ceci dit, j'aime bien la concision de jquery quand on l'utilise vraiment massivement dans son appli... mais à 100ko de lib, c'est pas juste pour cibler un objet...
J'avais commencé à me faire mes propres fonctions destinées à remplacer jquery et tout va bien... tant qu'on reste sur de petits projets dans lesquels on n'utilise aucune lib ou framework pour éviter les dépendances... sinon, ça revient à pondre absolument tout le code de 0: pas de plugins pour gérer directement des fenêtres modales par exemple...
Un framework permet quand même de gagner du temps que l'on peut investir sur les parties significatives du code...
au prix en effet d'une dépendance et d'un temps d'apprentissage inévitables.
(Permalink)

Les liens de Kevin Merigot > Bookmark Bronco 21/04/2015
De ce que les développeurs et architectes du taf disent, les bibliothèques et frameworks c'est très bien pour ne pas passer du temps à faire des choses qui ne sont pas valorisées/valorisables (on est en contexte entreprise), mais il faut toujours être prêt à les refaire from scratch à un moment donné.

Et donc coder de manière à pouvoir facilement les remplacer au besoin.
(Permalink)