Deux ans après ce post, je viens de faire ce qui suit 3 trois fois, sur trois projets totalement différents :

– développement d’un serveur Web Django/Python

– développement d’un échange REST / JSON

– une boîte à côté a fait l’application mobile (une fois Cordova une fois Ionic une fois React)

– j’ai refait à côté pour voir si j’arrivais, la solution Unity

Le constat est sans appel :

Cordova / Ionic / React :

– 5 jours pour développement

– à chaque nouvelle évolution, minimum une journée (facturée) pour les implémenter + déployer

– certaines évolutions on coûté 3 jours voire plus (car c’étaient juste des plugins installés, et il fallait les analyser pour les faire évoluer selon le besoin du client)

– esthétique : laide

– problèmes sous-jacents : énormes : selon les mobiles, problèmes de CSS. A tel point qu’ils ont décidé d’embarquer le navigateur dans le livrable (de 6Mo l’appli tu passe à 23Mo)

Unity :

– 20 jours pour développement (oui, 4 fois plus !)

– à chaque nouvelle évolution, durée entre 2 et 10 fois MOINS que les solutions Cordova / Ionic / React (oui, une évolution m’a pris moins d’une heure à être implémentée contre une journée sur React)

– je n’ai jamais eu de problème des responsive. Jamais. Sur tous les mobiles sur lesquels j’ai installé l’appli, sans aucune exception. J.a.m.a.i.s.

– aucun problème sous-jacent. Pas un ou deux : aucun.

Et je n’ai pas du tout parlé du monde incroyable qui s’ouvre en plus de mon appli qui n’est qu’en 2D avec des UI basiques : la 3D.

Bref, si, mon post ici avait tout son sens, et question pérennité, une application mobile sur deux est développée en Unity aujourd’hui.

La solution pérenne pour moi = l’opposé de créer la dette technique, est :

– côté serveur : Django / Python

– côté client : pas de JavaScript du tout, mais du Unity / C# (sachant que, notez bien, la courbe d’apprentissage est très longue et fastidieuse, mais rien, absolument rien dans le monde professionnel, ne vaut le plaisir de voir la mâchoire du client qui tombe par terre lorsqu’on présente l’application Unity juste après qu’il ait vue l’application en Cordova / Ionic / React).

Je comprends que tu puisse penser ça car j’ai déjà eu le même genre de raisonnement lorsque j’avais moins d’expérience.

En fait ce qu’il faut comprendre c’est que les bénéfices de React par rapport à du pure JS se révèlent sur le long terme,

sur des projets complexes et dont le code se doit d’être évolutif.

Certe, ce qu’avant on pouvais faire en 1 ligne, il nous en faut maintenant 15,

mais lorsque qu’on est sur un projet qui comporte 50 000 lignes de code JS rien que côté navigateur, là où on aurait dû patcher de partout et rajouter 500 lignes de code en se rapprochant toujours un peu plus d’une impasse totale à certaines nouvelles fonctionalités futures, avec React, on va pouvoir résoudre ça proprement et en 5 lignes de code seulement.

Et je ne parle même pas de la ré-usabilité des composants développés, car ce pourrait être le sujet de plusieurs articles.

Il est vrai qu’il n’est pas évident d’utiliser React sans avoir l’impression qu’il complique pour beaucoup des problématiques simples, sans avoir eu auparavant affaire aux problématiques qu’il résout de manière magistrale.

Et c’est d’ailleurs pareil pour n’importe quel outil un peu complexe.

Pour avoir codé pendant 10 ans avec jQuery et avec du JS pure (de plus en plus à mesure que les problèmes de cross-compat et de rétro-compat s’amenuisaient), je peut te dire que depuis que je suis passé à React, je m’émerveille tous les jours de la flexibilité et de la simplicité de résolutions de certains problèmes qui auparavant m’auraient fait m’arracher les cheveux.

L’expérience de nombreux cauchemards durant plusieurs années en développement web me permet d’apprécier correctement la valeur d’une approche déclarative par rapport à une approche impérative.

Bien sure cela est particulièrement pertinent sur des interfaces entièrement générées en javascript, le serveur ne retournant que de la data pure (en général du json).

Il est certain que si on parle d’ajouter trois events à un plugin wordpress, il n’y a aucun intérêt à utiliser React.

En revanche lorsque l’on développe un CRM complet sur mesures pour un client, le temps et la performance gagnés sont quasi-infini!

Puis je lis ton post, et je vois qu’au bas mot pour faire un truc qui serait un “bon stack” il faut au mini 11 systèmes à apprendre :O

Ben je me dit : ReactJS je fini le tuto parce que c’est la mode et que comme Angular ça fleuri sur les offres d’emploi…

Mais pour coder ce que je vois au quotidien sur les sites, pas besoin d’une usine à gaz ! Au pire une lib maison de JS pure, ou un aggrégat de libJS sans dépendances pour des choses basiques. Mais pas 1Mo de JS pour gérer des event de click en JS !

un bon stack:

serveur: node + babel + di-ninja + express + graphql

navigateur: webpack + babel + di-ninja + react + relay + redux

C’est vrai qu’il faut compter un sacré temps d’apprentissage et d’expérimentation pour mettre en place ne serait-ce que le socle,

mais au final c’est très gratifiant, je recommande !

Tu prends effectivement, comme l’ont fait remarquer certains, un ton condescendant des plus pénibles, et ça dessert ton propos… parce que ni toi, ni moi, ni l’auteur de cet article ne détenons la Vérité Ultime™.
J’approuve totalement Sam quand il dit, en réponse à ton argument que “le bordel c’est bien”, qu’avec JS ça atteint un degré jamais vu ailleurs. Non ce n’est pas “bien” d’en arriver à un tel niveau de bordel. Ce n’est enviable en aucune façon, quoi que tu puisses te dire pour essayer de t’en convaincre toi-même.

C’est pour cela que personnellement j’attend que les choses se tassent un peu avant de m’y mettre sérieusement. Mais pour critiquer comme vous le faites l’extrême vivacité de la communauté JS, il faut vraiment ne RIEN avoir compris à la nature du développement OpenSource.

Bah désolé vieux, mais “que les choses se tassent”, j’ai une mauvaise nouvelle pour toi : ça ne va jamais arriver tel que c’est parti. Mon 1er framework front a été Ember.js. Que j’aime beaucoup par ailleurs, mais que je délaisse parce que contribuant à l’indécente obésité des pages et applis web (btw comme quelqu’un l’a dit, riotjs is the way to go!). J’avais commencé un projet perso avant qu’Ember et Ember Data ne se stabilisent en 1.0, puis j’ai suivi l’évolution pendant un temps, jusqu’à 1.5 environ (c’était il y a longtemps !). Je reste 6 mois sans toucher au projet, je me dis “tiens passons à la 1.7”, et ça me pète littéralement tout. Des heures pour adapter mon appli au nouveau modèle. Les gens qui ont investi dans Angular 1.x ont la même déconvenue avec l’arrivée du 2. Et ça c’est pour ne parler que d’un framework. Là on en a littéralement qui dégueulent de partout, ça continue, chaque putain de jour, quelqu’un de par le monde pond un nouveau framework JS en se disant “tiens, y en a aucun autre qui fait ce que je veux”.
L’argument comme quoi ce “dynamisme” de la communauté (“hystérie” serait-il un terme approprié, je vous laisse juger) serait payant à long terme est à mon avis, douteux totalement démenti par la réalité. On a probablement tous espéré qu’un jour Linux botterait le cul de Windows. Et ça n’arrivera jamais. J’en rêvais quand j’ai découvert Linux (en 97 pour ma part). Et certes les choses ont progressé, même une distro un peu “geek friendly” comme Debian a un installeur graphique. Mais la dispersion des efforts fait que c’est mort, absolument mort, pour espérer concurrencer Windows ou OS X pour le grand public. Qu’en a-t-on à foutre d’avoir le choix entre 10 environnement desktops ? Si tu en as un qui marche bien tu vas le choisir, non ? Le pire c’est que les raisons qui motivent les moults forks et autres sont le plus souvent douteuses et motivées par des raisons dont le quidam moyen – voire le geek moyen – se fout éperdument (comme Devuan le fork de Debian motivé par le passage de celle-ci à systemd).

En conclusion, je veux bien défendre JS parce que j’aime ce langage, mais parfois il faut arriver à avoir un minimum d’examen critique honnête sur nos pratiques. Moi-même je plaide coupable pour m’être créé mon propre petit “boilerplate/framework à mon goût” pour node, et je me dis que si on en est arrivé à un tel bordel, c’est parce que tout le monde fait pareil dans son coin. Et ce n’est pas la direction à prendre à mon avis.