Retour en arrière sur les frameworks Javascript ?

Shopify a écrit un article intéressant (Rebuilding the Shopify Admin: Improving Developer Productivity by Deleting 28,000 lines of JavaScript).
Iils avaient fait le choix d’utiliser un framework JavaScript (batman.js) pour leur interface d’admin afin de la rendre plus réactive. Hors, lors de leur dernière refonte, ils ont choisi de ne plus utiliser batman.js et de réduire de manière assez importante la quantité de code JS qu’ils avaient.
Ils ont compensé en utilisant Turbolink (intégré dans Ruby on Rails) qui met à jour uniquement la balise body lorsqu’on clique sur un lien au lieu de rafraîchir toute la page.

Que pensez-vous de cette démarche ? Pensez-vous que ça peut se généraliser ?

5 « J'aime »

C’est une bonne démarche dans le sens où ils essayent d’optimiser intelligemment la navigation.

Quand je vois sur certains sites où ils font appels à plus de 5 frameworks JS pour un rendu qui auraient pu être fait avec juste un peu de JS “maison” , de CSS (vraiment le minimum) et du HTML, je me dis que le course à la technologie est parfois insensée.

Dans le cas que tu présentes, au moins la technologie est réfléchie, testée, remise en cause … c’est une bonne démarche qui je le souhaite se généralisera.

3 « J'aime »

Tout a fait d’accord, c’est une bonne démarche. En fait , quelque soit le choix de techno, ce qui compte c’est qu’il soit justifié . Soit pour des raisons techniques, ou des contraintes peu importe, mais qu’il y ait eu un vrai moment de réflexion avant. Que la réponse ne soit pas juste : “je ne connais que ça” ( manque de veille / de motivation ) , “je ne sais pas faire autre chose” (manque d’expérience/compétence/formation) .

La remise en question une des clés du processus et dans le cas de Shopify cela semble le cas. Finalement le meilleur framework qui existe, toute technos confondues , c’est le cerveau !

1 « J'aime »

L’article pose aussi la question du bien fondé du développement d’un framework “maison”. Aujourd’hui les solutions sont très nombreuses pour éviter d’avoir à développer un framework interne, mais ce n’était certainement le cas pour Shopify au moment ou ils ont lancé Batman.

Autre point intéressant : Il ne faut pas avoir peur par moment de tout jeter pour recommencer à zéro. Le temps passé sur la première version n’est pas perdu, on en garde l’expérience, les bonnes et mauvaises idées, pour aller plus vite sur la nouvelle version et gagner du temps à long terme en maintenabilité.

Pour parler des framework opensource actuel, aujourd’hui AngularJS fait des heureux, mais aussi de plus en plus de déçus. Le développeur se retrouve souvent à éviter l’utilisation de certaines features du framework, car elles rendent l’interface parfois très lente. Souvent, il faut écrire des optimisations ou modifier son architecture dans quelque chose de moins direct et beaucoup moins lisible, juste pour contourner les faiblesses du framework. Ce sont pourtant ces features qui ont encouragé le choix du framework, et on se retrouve à les contourner. Ces features sont à la fois la force et la faiblesse du framework, et il vaut mieux en avoir conscience dés le début.

Beaucoup de gens se tournent vers des framework alternatifs, comme ReactJS ou même Mithril. Ces frameworks se focalisent uniquement sur la partie Vue du MVC (Virtual DOM et Templating), et laissent le développeur libre de faire comme il veut pour le reste, quitte à intégrer les librairies minimalistes pour chaque feature dont il a besoin.

2 « J'aime »

C’est une excellente démarche. Sur les choix techniques on assiste souvent au bureau à des “guerres de religions”, l’esprit critique étant resté sur la banquette du bus. On voit fleurir un peu partout des articles qui remettent fortement en cause le choix du “tout javascript”. Un article très intéressant dans la même veine (en anglais) : http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript-in-2015/.

Voilà également un autre article très bien écrit, qui remet en fortement en cause AngularJS, qui, bien étant le framework ayant le plus de succès, n’est pas forcément un choix idéal. Je partage nombre de point de vue de l’auteur, ayant croisé les mêmes remarques chez plusieurs personnes expérimentées sur ce framework. http://www.fse.guru/2-years-with-angular. En un mot : toujours garder les avantages et inconvénients dans un coin de la tête, il n’existe pas de solution parfaite mais un ensemble de compromis.

2 « J'aime »

J’allais poster le même article (“The State of JavaScript in 2015”), très intéressant !

J’ai fait exactement la même chose dans http://mipise.com, il y a 1 an et demi :) On est parti d’un projet open source et il y avait du javascript en masse, avec backbone, etc., et j’ai purement et simplement supprimé le dossier javascripts pour tout reprendre en serveur :)

Et j’ai ajouté quelques petites touches de js quand vraiment on en avait besoin, et franchement, je suis super satisfait du résultat !

Je pense que si j’investi en revanche un peu de temps dans un framework js, ce sera ember.

Human Coders - Le centre de formation recommandé par les développeur·se·s pour les développeur·se·s