Pendant mes années universitaires, en tant qu'étudiant en génie logiciel, Java était le nouveau venu. Heureusement, j'ai eu quelques professeurs visionnaires désireux de considérer le C++ comme appartenant au passé et de passer à l'univers merveilleux du « codez une fois, déployez n'importe où ». La plupart des missions étaient en Java, mais nous avons également essayé d'autres technologies telles que C, C++, Cobol, OCAML... et JavaScript.
Dès que j'ai commencé à travailler avec JavaScript, j'ai immédiatement eu l'impression qu'il avait été conçu avec une approche « hack & slash » pour faire avancer les choses et qu'il ne devrait pas survivre plus longtemps que quelques prototypes. À l'époque, personne n'était prêt à parier sur la ferme en JavaScript, mais nous ne pouvions pas nous tromper davantage. Vingt ans plus tard, notre secteur a autorisé la migration de JavaScript vers le back-end et il est désormais omniprésent.
Les années qui ont suivi l'obtention de mon diplôme ont été, comme l'avaient prévu les professeurs d'université, consacrées au codage en Java. J'ai adoré la façon dont Sun a conçu le langage et la machine virtuelle Java, mais j'ai toujours remis en question leur manière trop complexe de concevoir le kit de développement standard (SDK). Il semblait qu'ils étaient impatients d'utiliser tous les motifs du célèbre réserver écrit par Gang des Quatre, et le premier contact avec J2EE m'a donné l'impression que Martin Fowler a offert à Sun le brouillon de son livre qui n'a pas encore été publié Modèles de conception d'entreprise, et ils en ont fait une liste de choses à faire.
L'écosystème Java était tellement surdimensionné qu'il est devenu courant de prévoir deux semaines dans un plan de projet juste pour démarrer un produit légèrement complexe. Pire encore, l'ensemble de la communauté Java a commencé à publier des frameworks conçus, et le monde a donné naissance à des choses merveilleuses comme Entretoises et RCP Eclipse.
Vous ne pouvez pas imaginer à quel point j'étais heureuse quand je suis tombée sur Ruby on Rails, quelque part dans la version 1.x. Il était facile de prévoir que cela allait être important, d'où la raison pour laquelle nous avons utilisé Rails à plein régime au démarrage Imaginary Cloud.
Je n'ai jamais aimé les langages scriptés car j'apprécie beaucoup le travail effectué par un compilateur pour détecter les fautes de frappe et les erreurs de type de données, mais je cherchais depuis si longtemps un bon framework Web que j'ai pleinement adhéré à la promesse de Ruby on Rails. Il y avait enfin quelque chose qui permettait à une bonne équipe de développement de fournir rapidement quelque chose de plus complexe qu'un ensemble de pages Web statiques créées dans Dreamweaver.
Ruby on Rails a adopté une approche tellement disruptive que la communauté a explosé et que presque tous les nouveaux projets du monde des startups l'utilisaient. Certaines de ces startups ont connu une croissance assez rapide et ont confirmé que Rails était prête à évoluer. Vous pouvez toujours trouver des gens qui disent que Ruby est lent et que Rails nécessite beaucoup de ressources de calcul, mais d'ici là, si vous vouliez arriver rapidement sur le marché tout en utilisant la même base de code tout en explorant une croissance en forme de bâton de hockey, augmenter le nombre de serveurs était toujours une bonne solution. Oui, ils étaient chers, mais cette option était tout de même moins chère que la réécriture de l'intégralité de la base de code. Et il est toujours possible de remanier les composants lents d'un système dans un langage plus performant. Ruby s'est toujours assez bien intégré, soit via une API Web, soit via une bibliothèque partagée.
Malgré les grands avantages de l'utilisation de Rails dans un nouveau projet, Ruby n'était pas en mesure de pénétrer dans un domaine, et même Rails n'était pas un bon ambassadeur. Je parle du monde de l'entreprise. Il y a bien sûr quelques exceptions, et on peut toujours citer des cas d'utilisation réussis en entreprise où Ruby a été adopté soit pour de nouveaux projets, soit pour réécrire des projets existants. Mais nous n'assistons toujours pas à une adoption massive de cette technologie par des entreprises bien établies. Il y a plusieurs raisons à cela, mais cette opinion a été développée uniquement sur la base de mon intuition et je n'ai aucune donnée claire pour la valider. Je ne vais donc pas m'étendre sur les raisons pour lesquelles Ruby n'est pas massivement utilisé sur le marché des entreprises.
Tout bien considéré, je pense que c'était une occasion manquée et l'industrie du logiciel propose désormais de nombreuses options viables à Ruby on Rails. Certains sont largement utilisés par les startups (par ex. Phénix), tandis que d'autres ont une certaine pénétration sur les entreprises parce qu'ils s'appuient sur des technologies que les entreprises utilisent déjà (oui Django, je parle de toi). Mais si vous voulez pouvoir aider à la fois les entreprises et les startups, vous ne pouvez pas vous tromper avec JavaScript et Node.js. Je ne dis pas que Rails n'est pas adapté à son objectif.
La plupart du temps, il est en effet adapté à l'objectif, mais pas au contexte. Et par contexte, j'entends notre contexte, c'est-à-dire le fait de pouvoir travailler dans un environnement dans lequel les startups et les entreprises sont prêtes à parier sur leur avenir. Bien que cela soit vrai pour le premier, cela ne l'est pas pour le dernier. Les startups et les entreprises adorent JavaScript. Et à mon avis, l'écosystème JavaScript est suffisamment mature pour livrer toutes les bonnes choses que Ruby and Rails nous a apportées, et bien plus encore dans des domaines où Ruby and Rails n'a jamais réussi à briller. Jetons un coup d'œil aux résultats.
Nous avons effectué une recherche approfondie sur l'écosystème Node.js (par le biais d'enquêtes et de travaux de terrain sur un bon nombre de projets) afin d'identifier les composants de notre pile de référence. Vous pourriez considérer que certains de ces résultats jouent en faveur ou en défaveur de Node.js, en fonction de vos objectifs. Votre kilométrage peut varier, mais nous avons pu trouver de bonnes solutions pour des domaines tels que les migrations de bases de données, les bibliothèques d'authentification, les extensions d'administration/back-office, les tests automatisés, la simulation d'objets, etc. Jusqu'à présent, rien de ce que nous avons pu faire dans Rails n'était difficile à réaliser dans Node.js. Nos résultats indiquent qu'il existe un remplacement pour presque toutes les fonctionnalités de Rails ou toutes les gemmes Ruby.
Contrairement à Ruby, JavaScript domine le front-end Web, et avec Node.js, il est devenu célèbre sur le back-end. Il est facile de comprendre pourquoi JavaScript est plus populaire, mais je pense également que la communauté traverse une phase « cool », similaire à ce qui est arrivé à Rails au début. Il y a beaucoup d'accaparement de terres dans la communauté, ce qui entraîne de nombreuses innovations. Mais je pense également que nous assisterons à une certaine consolidation dans les années à venir, les bibliothèques et les frameworks étant laissés pour compte. La communauté Ruby on Rails est également grande et très active. Mais au fur et à mesure que Rails a mûri, elle a perdu son côté cool et la communauté s'est stabilisée. Cela signifie également que nous devons nous attendre à moins d'innovation.
Nous avons utilisé Ruby Motion depuis ses débuts et a publié plusieurs applications sur l'App Store. Je dois dire que c'était un excellent cadre, développé par des personnes très brillantes. La prise en charge des tests automatisés a été remarquable. C'était pré-Swift et la diffusion pour iOS dans Ruby était bien plus agréable que d'utiliser Objective-C. Mais RubyMotion a mis énormément de temps à prendre en charge Android, et la promesse « construire une fois, déployer partout » n'était pas possible au moment de la sortie de Swift. La syntaxe de Swift est bien meilleure que celle d'Objective-C, et c'était une raison suffisante pour arrêter d'utiliser RubyMotion sur de nouveaux projets. Vous pouvez toujours l'utiliser aujourd'hui, même si les fondateurs ont vendu leur entreprise et cela s'est en quelque sorte arrêté à temps. Je pense que le framework n'a pas réussi à obtenir suffisamment de succès pour lui permettre de suivre l'innovation préconisée par Apple et Google sur les plateformes iOS et Android respectivement.
Et dans le coin JavaScript, vous avez React Native. Il vous permet de proposer des applications natives pour iOS et Android. Il est développé par Facebook et largement soutenu par une grande communauté. De plus, son utilisation est gratuite (RubyMotion ne l'est pas).
Pour en revenir à ce que j'ai dit au début de cet article, je parie que JavaScript connaîtrait une mort douloureuse. Je ne pourrais pas me tromper davantage. Il est remarquable de voir comment il a réussi à rester pertinent pendant toutes ces années, jusqu'à ce que quelqu'un ait pu exécuter son plan directeur et le transférer au back-end. Je pense toujours qu'il y a de gros problèmes avec le langage, mais là encore, Rails est devenu célèbre et Ruby souffre également de quelques défauts de conception.
Des efforts considérables sont déployés pour améliorer la conception du langage avec les dernières versions d'ECMA Script. Mais il faut encore attendre une large adoption des nouvelles versions pour en tirer parti. Il est également possible d'utiliser un transpileur comme Babel, pour utiliser les nouvelles fonctionnalités disponibles dans les nouvelles normes de script ECMA sans sacrifier la rétrocompatibilité pour les anciens navigateurs.
En fait, vous pouvez désormais publier un projet web et mobile complexe sans avoir besoin d'utiliser plusieurs langues, ce qui contribue à réduire les coûts de développement et, si vous êtes dans le secteur depuis longtemps, vous devez l'admettre. C'est une belle réussite.
Tout bien considéré, pour nous, JavaScript est adapté à l'objectif et au contexte. Nous avons officiellement cessé de recommander Ruby on Rails pour les nouveaux projets et opterons pour une architecture basée sur JavaScript par défaut. Néanmoins, nous soutiendrons les projets Rails existants, car je pense que la technologie est mature, prête à être produite et qu'elle ne mourra pas de sitôt grâce à sa communauté mature et stable.
CEO @ Imaginary Cloud et co-auteur du livre Product Design Process. J'aime la nourriture, le vin et le Krav Maga (pas nécessairement dans cet ordre).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
