Que ce soit nos clients, nos candidats ou nos stagiaires, on nous pose souvent la question : "Pourquoi React ?".
L’importance de la stack technique et la règle PPEA
Lorsqu'un nouveau projet démarre chez Cardiweb, la stack technique est majoritairement React coté client et Java coté serveur. La stack serveur privilégiée est Java depuis la création de Cardiweb il y a 20 ans. Mais coté front, la stack a évolué au cours du temps, avec l'évolution des technologies.
Tout d'abord, il faut savoir que Cardiweb a une approche pragmatique du développement qui n'est pas du tout influencée par la mode. Nous surveillons bien sûr les nouveautés, mais avant de se déployer sur un projet, une technologie doit répondre à certains critères :
Pérennité : Il n'est pas envisageable d'adopter une technologie dont nous ne sommes pas persuadés qu'elle sera toujours présente dans les 5 prochaines années. Nous devons à nos clients le fait de pouvoir maintenir leurs projets sur le long terme.
Popularité : C’est une évidence, nous avons besoin de développeurs pour ces projets. Nous aurions sans doute eu un peu plus de mal à recruter ou à motiver nos développeurs si nous avions opté pour Scala, par exemple. Ce n'est pas une critique à l'encontre de Scala, qui est un langage fantastique, mais notre approche pragmatique des projets nous empêche de l'utiliser à l'heure actuelle. (Par contre, si vous ne connaissez pas Scala, je vous recommande vivement la formation en ligne sur Coursera donnée par Matin Odersky, le créateur du langage.)
Efficacité : Le code produit doit être maintenable et performant. Il doit permettre par exemple d'utiliser l'approche programmation fonctionnelle et être facilement testable.
Agréabilité : Lié à l'efficacité, mais critère à part entière tant il est important. La technologie doit être agréable à utiliser pour nos développeurs. Il n'est pas envisageable qu'intervenir sur un projet soit une souffrance du fait de la stack technique.
Coté serveur, le choix de Java n'a jamais été remis en cause. Et ce, même si nous incorporons de plus en plus de Kotlin que nous pensons être un langage qui répond également à ces critères (sans doute même davantage que Java sur le côté efficacité). Mais nécessairement, le passage de Java à Kotlin prendra un peu de temps.
Coté front, par contre, l'équation est différente.
Un peu d’histoire : du Web au Mobile
Pour les clients web, il y a 20 ans, le rendu des pages était fait côté serveur. On utilisait principalement des jsp ou des moteurs de rendu, comme freemarker. Chaque changement de page impliquait un rechargement intégral du contenu de la page. On utilisait éventuellement des librairies comme jQuery pour dynamiser un peu l'interface mais c'était de la cosmétique.
Pour le mobile, apparu il y a environ 13 ans (2007 pour l'iPhone et 2008 pour le premier Android, le G1), il n’y avait pas énormément de choix : ObjectiveC coté iOS et Java coté Android.
Nous étions alors dans une situation où il fallait :
Un développeur serveur pour produire les JSP,
Un intégrateur pour produire le front (html, css, ...)
Un développeur mobile Java pour faire l'appli Android
Un développeur ObjectiveC pour l'appli iOS
Et je vous passe le Blackberry sous J2ME que Cardiweb avait aussi à son arc à l'époque...
Autant dire que les projets étaient compliqués et coûteux, aussi bien en termes de développement que de recette, maintenance, ... Bref, pas toujours facile.
Puis, les navigateurs se sont améliorés. On a pensé qu'on allait pouvoir réaliser des applications html/javascript aussi performantes que des applications mobiles, qui pouvaient accéder aux api du téléphone, jusqu'alors inaccessibles aux applications web (géolocalisation, bluetooth, caméra, ...) et mutualiser tout le code entre web et mobile. On faisait des coques vides comprenant simplement une application web embarquée avec BackboneJS, que l’on peut considérer comme le prédécesseur de React ou Angular. Il y avait aussi des frameworks comme PhoneGap par exemple.
Mais rien n'y a fait ! Malgré tous nos efforts nous n'étions pas entièrement satisfaits du résultat. Et 10 ans plus tard, c'est toujours le cas : on reconnaît généralement très rapidement une application web par son manque de réactivité et d'intégration par rapport à une application mobile. Jusqu'à aujourd'hui, une application web ne peut généralement pas rivaliser avec une application mobile. On le déplore et on espère que ça changera un jour, mais c'est un fait.
2016 : l’avènement de React Native
C'est alors qu'est apparu React Native en 2016, avec l'idée de prendre le dom virtuel de React qui existait depuis 2 ans et de produire des objets natifs au lieu de produire du html. Je ne vais pas rentrer dans le détail de ce qu'est un dom virtuel ici mais si vous voulez en savoir plus, je ne peux que vous recommander la présentation de Sophie Bit qui travaillait sur React chez Facebook à l'époque (et qui faisait partie de l'équipe qui a produit les hooks).
React Native permet d'utiliser le même paradigme qu'avec ReactJS, mais de "piloter" de véritables vues natives et donc d'avoir les performances correspondantes. Et ce, parce que React a été initialement conçu pour pouvoir remplacer n'importe quel système de vue.
Si ça vous intéresse, voilà la toute première vidéo de Tom Occhino début 2015 à la première conférence React qui parle pour le première fois de React Native : https://www.youtube.com/watch?v=KVZ-P-ZI6W4
Il annonce React Native vers 22 minutes après avoir lui aussi fait le constat qu'une webview ne sera jamais "not even close" d'une application native. Nous sommes donc arrivés à React via React Native. Puis, de React Native nous sommes passés à ReactJs et avons appliqué le même paradigme au web. C'est donc vraiment la promesse d'utiliser le même "langage" pour les développements web et mobiles qui nous a fait nous intéresser à React.
Le partage de code entre React Native et ReactJs (et donc, entre les applications mobiles et les applications web) était d'environ 30 à 40% à l'époque : on pouvait globalement tout partager, sauf les vues qui étaient spécifiques.
Puis est arrivé ReactNativeWeb sous l'impulsion d'un employé de Twitter (à l'époque) : Nicolas Gallagher. RNW permet de mutualiser en plus les vues entre mobiles et web. L'application Twitter Lite a été réalisée avec (C'est donc une application mobile native qui incorpore une webview et qui exécute du ReactNative ... pourquoi pas.). RNW a ensuite été intégré par défaut sur Expo par Bacon Brix (présenté l'année dernière à App.js conf : https://www.youtube.com/watch?v=jt7NCutWcUU) Avec RNW, le taux de mutualisation est passé à 80%, voire 90%.
Et cette progression s'accompagne par une réduction dans la même mesure de la charge nécessaire à la recette ou à la maintenance. React n'est pas la seule option, bien sûr. Il y a également Vue, Angular mais aussi des projets comme preact ou inferno qui sont 100% compatibles avec React mais qui promettent de meilleures performances. Vue a VueNative pour faire du mobile, et Angular a NativeScript. Il y a Flutter aussi, qui depuis 1 an permet aussi de faire du web. Ce sont toutes d'excellentes solutions aussi.
Et nous, pourquoi React Native spécifiquement ?
Principalement le partage de code Android/iOs/Web
La facilité de découpage en composants
React en lui-même et la nouveauté apportée au développement web (mode reactif, dom virtuel, hooks, ...)
Les performances toujours aussi bluffantes
La bonne intégration avec Typescript qui nous permet d'améliorer la qualité du code produit
La taille de la communauté.
Et pourquoi Cardiweb reste fidèle à React et ne passe pas sur une technologie compatible (preact, inferno voire Vue) ? :
On le voit, React c'est avant tout des développeurs de talent. Et comme pour le Bitcoin qui est LA cryptomonnaie de référence car les plus grands talents sur le sujet travaillent sur bitcoin core, React est LA référence sur React, de par l'équipe de Facebook et par la communauté qu’il a fédérée.
L'équipe React chez Facebook en particulier est fantastique. Citons par exemple Dan Abramov le créateur de Redux (Son blog ici). Ce sont eux qui ont introduit les Hooks fin 2018 à React Conf (et je vous conseille la vidéo qui explique ce que c'est et pourquoi ils en sont arrivés là. ). Les hooks ont été un fantastique outil pour améliorer la qualité et la lisibilité du code. Ça fait partie de ce genre d'outil dont on n’aurait même pas imaginé qu'ils puissent exister mais dont on ne peut plus se passer une fois qu'on y a gouté.
L'avenir s'annonce bien, avec toujours plus de possibilités ! Je n'ai pas parlé par exemple de l'intégration à Windows et MacOS portée par Microsoft, qui permet de faire des applications de bureau en React Native, ou de React360, qui permet de faire de la réalité virtuelle. Les possibilités semblent infinies.
Sur un aspect plus pragmatique, Cardiweb a lourdement investit sur React pour former les équipes et s'assurer de garantir la qualité des projets produits pour nos clients. Rester avec React permet d'assurer la continuité des projets dans les meilleures conditions.
Enfin, un argument plus personnel : utiliser React est un plaisir de tous les jours, réellement. Personnellement, je fais du développement Java depuis 23 ans et je commençais à m'en lasser. La fraicheur qu'a apporté React a permis de retrouver l'intérêt et le plaisir que j'ai à développer. Rien que pour ça, je leur en serais à jamais reconnaissant. (Et donc en particulier à Jordan Walke, l'auteur original) !
Vous l’aurez compris : de par son histoire et ses expertises, Cardiweb est fan de React, et ce n'est pas prêt de changer.
Merci de m'avoir lu.
Mike
Comments