Comment accélérer le développement de logiciels avec JavaScript ?

Définition du développement rapide des applications

L'expression "développement rapide" peut être interprétée de nombreuses façons erronées. Pour éviter cela, expliquons quelles sont nos attentes. L'élément le plus important est le budget. Pour créer plusieurs versions d'une même application, nous avons besoin de nombreux développeurs issus de différentes technologies et nous devons payer chacun d'entre eux. Pour créer des applications mobiles natives, nous devons dupliquer notre code pour fonctionner correctement sur les deux plateformes - Android et iOS. Une approche commune consiste à garder les deux applications similaires, à utiliser la même API, à maintenir le même comportement, etc. En conséquence, nous devons dupliquer le code pour construire deux versions de la même application. JS est un langage qui nous permet de créer des applications mobiles et des applications web en même temps. Cela semble impossible ? Laissez-moi vous expliquer de quoi je parle.

Mobile ? Web ? Je m'en moque.

Supposons que nous voulions créer une application qui utilise la bibliothèque React. Cette bibliothèque peut être utilisée pour créer des applications web et des applications mobiles avec React native. Les mécanismes logiques de l'application, tels que l'autorisation, le calcul, le filtrage des données, etc., peuvent être réalisés à l'aide de crochets React. L'intérêt est que ces crochets peuvent être partagés par les deux versions de l'application - web et mobile. Grâce à cette option, nous avons les économies suivantes :

• Il n'est pas nécessaire de dupliquer le code responsable de la même chose,
• Il n'est pas nécessaire d'engager des développeurs mobiles natifs pour mettre en œuvre la même partie des applications,
• Il n'est pas nécessaire de mélanger différents langages pour mettre en œuvre la même application sur différentes plateformes mobiles (Android/iOS),
• Un développeur peut être chargé de mettre en œuvre des fonctions d'application spécifiques sur toutes les plateformes.

Pour résumer ce paragraphe, ce n'est pas une seule base de code qui alimentera toutes les versions de l'application, bien que nous puissions diviser le code partagé et l'utiliser dans chaque version pour rendre le processus de développement vraiment plus rapide.

Conclusion - si vous souhaitez créer une application web et une application mobile en même temps, pensez à la bibliothèque React qui peut partager une base de code dans les versions web et mobile de l'application.

Mais qu'en est-il du backend ?

Il y a quelques années, lorsque l'on parlait du backend, peu de gens imaginaient que sa maintenance pouvait être possible à l'aide d'un langage tel que le JS. Le développement de cette langue est étonnant et ses fruits peuvent être récoltés jusqu'à aujourd'hui.

De quoi s'agit-il ? Si vous engagez le bon Développeurs JSIl s'avère qu'ils peuvent écrire non seulement la partie frontale de l'application, mais aussi la partie dorsale - c'est-à-dire être responsables du traitement des données sur le serveur, de la communication avec la base de données, de divers types d'intégrations, etc. Vous hésitez encore ou n'êtes pas convaincu par ce langage ? Il n'y a aucune raison d'avoir cette attitude ! Backend utilisant JS peut être mis en œuvre de deux manières : dans un mode extensible et configurable, que express.js peut nous fournir, et dans un mode structuré utilisant le modèle DI - nest.js.

Ces deux solutions sont extrêmement populaires et alimentent de nombreuses applications de production dont les propriétaires sont des "géants de la technologie" dans leur secteur d'activité. Je pense qu'elles ont suffisamment évolué pour vous convaincre de choisir l'une ou l'autre.

Ce n'est toujours pas suffisant ? À l'instar du partage de code entre les applications web et mobiles, le backend peut partager des ressources à la fois avec les premières et les secondes. Le mot clé à utiliser ici est TypeScript - entre autres choses, il nous permet de partager une base de code, c'est-à-dire une définition de type de données commune à toutes les plateformes.

Avec des applications construites uniquement sur le JavaScript / TypeScript En utilisant le monolithe, nous économisons de nombreuses lignes de code que nous devrions dupliquer dans les langages de programmation natifs. D'autre part, en utilisant le même langage sur tous les fronts, nous pouvons partager une grande quantité de logique entre toutes les applications, ce qui accélère considérablement le temps de développement d'une application particulière. N'est-ce pas formidable ?

Le langage JS peut-il alimenter des applications de bureau ?

Il s'avère que les technologies de construction d'applications pour navigateur sont excellentes pour la maintenance des applications que nous utilisons sous leur forme de bureau - un bon exemple ici est Slack. Slack est une application utilisée pour équipe la communication - outre la messagerie standard, il offre de nombreuses fonctionnalités différentes et divers types d'intégrations externes. Tout cela en fait l'une des applications les plus populaires, utilisée principalement dans le secteur des technologies de l'information.

Il s'avère que Slack utilise également des technologies web (et donc JavaScript) pour construire son interface d'application. La base qui permet d'exécuter de telles applications sur votre bureau est l'électron. La création d'interfaces graphiques à l'aide de technologies web rend le développement d'applications pour différentes plateformes beaucoup plus facile, rapide et généralement possible en même temps.

La JS est-elle assez mûre ?

Si l'on en croit la partie frontale de l'application, il n'y a pas d'illusion à se faire sur le fait que l'application est en cours de développement. JS est le seul et unique langage qui alimente l'écosystème ici. Pour l'instant, il n'y a pas d'alternatives viables qui peuvent remplacer cette partie de l'application (bien que je pense que WebAssembly pourrait nous surprendre à l'avenir). Ainsi, en ce qui concerne la maturité de JS sur le frontend, il ne fait aucun doute qu'il s'agit du seul langage royal.

En ce qui concerne le backend, de nombreux développeurs peuvent sembler choqués ou nier immédiatement que JS est un langage de programmation adapté au backend. Cependant, la question doit être analysée objectivement.

De nombreux fournisseurs de services en nuage proposent des kits de développement logiciel (SDK) qui vous permettent d'utiliser directement les services en nuage. nuage méthodes. Curieusement, l'un des onglets les plus populaires, juste à côté de C#, Go et Java, est Node.js. Il s'avère que cette plateforme est idéale pour la mise à l'échelle et la construction d'applications basées sur des microservices ou une architecture sans serveur. Conclusion - JS est l'un des langages les plus populaires pour développer des applications basées sur des microservices/une architecture sans serveur. Sur les écrans ci-dessous, nous pouvons voir que la sainte trinité (Google Computing Services, AWS, Azure) des fournisseurs de cloud nous permet de créer des applications en utilisant nœud.js.

En ce qui concerne l'écosystème node.js, tout le monde est probablement familier avec une bibliothèque appelée express.js - c'est un outil simple et direct qui vous permet de définir des chemins et de leur fournir ensuite des données appropriées qui ont été correctement traitées du côté JS. De plus, le modèle utilisé parmi les requêtes HTTP traitées dans express.js est devenu l'un des plus populaires dans l'ensemble de l'écosystème et constitue une sorte de modèle pour diverses autres bibliothèques utilisant, par exemple, l'architecture sans serveur.

Conclusion - JS est un langage suffisamment mature pour mettre toutes les cartes en place et construire à la fois le frontend et le backend. De plus, c'est un langage assez récent qui trouve facilement sa place dans les architectures d'applications modernes. C'est formidable qu'un programmeur qui connaît un langage puisse maîtriser les deux côtés (full stack) d'une application.

La JS est-elle assez rapide ?

Le moteur le plus souvent utilisé pour l'exécution du code JS est le v8, basé sur le langage C++. Ce moteur développé par Google est dédié à l'exécution d'applications pour les plateformes web. Il est intéressant de noter que ce moteur n'interprète pas le code JS. Au lieu de cela, il effectue ce que l'on appelle la "JIT" - "compilation juste à temps". Grâce à cela, nous n'avons pas besoin d'interpréter le code JS ligne par ligne, nous le compilons et l'exécutons. C'est encore plus rapide et cela permet d'obtenir de très bons résultats en termes de performances.

La JS est-elle assez juste en ce qui concerne les performances ? Oui, il l'est. Tant que vos algorithmes sont suffisamment justes, il n'y a aucun problème à utiliser JS côté serveur. L'autre chose est de garder votre code aussi asynchrone que possible. Grâce à ces pratiques, votre code peut gérer des requêtes parallèles sans aucun problème. Vous n'avez pas à vous soucier du changement de technologie en raison des performances - en particulier lorsque l'architecture de l'application est évolutive.

J'ai déjà discuté en détail des performances et des critères d'évaluation dans cet article.

Le JS n'est-il pas une bizarrerie parmi d'autres langues ?

Eh bien, ce sont des dizaines d'opinions selon lesquelles le langage JS se comporte bizarrement dans certains cas et sa manipulation est quelque chose qui vous fera exploser la tête pendant le processus de développement. Je ne suis pas d'accord 🙂 Tout comme n'importe quel autre langage, il a plusieurs patterns/comportements qui ne sont pas élégants, mais avec la compréhension de leur fonctionnement et de leurs objectifs, développer des applications avec JS n'est pas désagréable.

La remarque "asynchrone" juste avant JS fait particulièrement frémir certains développeurs. C'est difficile à comprendre quand on n'a pas d'expérience en la matière. Cependant, c'est une partie de JS qui nous permet de construire des solutions modernes de manière simple. Jetons un coup d'œil aux websockets : comme elles sont basées sur les événements, chacune des unités connectées - l'utilisateur et le serveur - peut émettre et recevoir des événements en parallèle. Si le code qui alimente cette application est suffisamment asynchrone et ne bloque pas le thread principal, nous pouvons facilement gérer des milliers de requêtes en peu de temps.

Comparons JS et PHP dans le contexte des websockets. Le PHP est un langage de programmation synchrone, c'est pourquoi la résolution des problèmes liés aux websockets est un véritable casse-tête. Nous pouvons voir que le PHP s'inspire des modèles de JS pour construire des applications backend interactives qui peuvent utiliser des technologies modernes, telles que webrtc ou websockets.

Mélanger le tout

En rassemblant tous les paragraphes, nous pouvons constater quelques faits :

JavaScript est un langage qui peut être utilisé pour créer toutes sortes d'applications, qu'il s'agisse d'applications web, d'applications mobiles ou d'applications de bureau ;
Les applications écrites en JS peuvent partager différents fragments de code entre elles, tels que ceux responsables du formatage des données ou des types en Typescript ;
Grâce à la croissance du web, les performances offertes par le langage JS sont suffisamment bonnes pour que l'on opte pour le développement d'applications frontales et dorsales ;
Grâce à sa conception inhabituelle, le JavaScript est capable de prendre en charge des infrastructures d'application modernes, telles que les websockets et le WebRTC ;
En faisant appel à un développeur compétent, vous pourrez exploiter le potentiel de ce langage sur tous les frontend disponibles ;
Le JS est un langage qui gagne en popularité depuis plusieurs années, et rien n'indique que cela va changer.

Pour donner mon avis, certes partial, tirer parti de l'option de JavaScript qui permet de réutiliser le même code sur tous les fronts disponibles est quelque chose qui accélérera certainement le développement d'applications et réduira le nombre de développeurs impliqués dans la maintenance du backend d'applications écrites dans d'autres technologies. Pour le confirmer, rappelons qu'un grand nombre de soi-disant géants de l'informatique suivent ce modèle et partagent une bonne partie de leur base de code entre les différentes plates-formes. Malgré les divergences d'opinion sur ce langage, il faut tenir compte du fait que les statistiques d'utilisation et de satisfaction quant à l'utilisation de JS se développe d'année en année, et ses développeurs peuvent facilement s'inscrire dans la tendance de la pile complète.

En savoir plus :

Pourquoi vous devriez (probablement) utiliser Typescript

Comment ne pas tuer un projet avec de mauvaises pratiques de codage ?

Stratégies de récupération des données dans NextJS