Pourquoi les bases de code dans le développement à plusieurs niveaux ont-elles autant, sinon plus, de code JavaScript?

Je fais de la programmation Web depuis longtemps maintenant, et quelque part, je ne sais plus pourquoi nous faisons ce que nous faisons aujourd'hui (ou comment en sommes-nous arrivés à faire les choses de cette façon)?

J'ai commencé avec le développement Web ASP de base et très tôt, la logique d'affichage et de gestion a été mélangée sur la page. Le développement côté client variait énormément (VBScript, différentes versions de JavaScript) et nous avions reçu de nombreux avertissements concernant les validations côté serveur (et je me suis donc tenu à l'écart de la logique côté client).

Je suis ensuite passé à ColdFusion pendant un moment. ColdFusion était probablement le premier framework de développement Web qui séparait l'affichage et la logique métier à l'aide de leurs balises. Cela me semblait très clair, mais très verbeux, et ColdFusion n’était pas très demandé, et j’ai donc poursuivi.

J'ai ensuite sauté sur le wagon du groupe ASP.NET et ai commencé à utiliser leur approche MVC. J'ai aussi réalisé que Java semblait être un langage de tour d’ivoire des systèmes d’entreprise, et j’ai également essayé leur approche MVC. Ultérieurement, ASP.NET a développé ce modèle de conception MVVM et Java (précisément J2EE ou JEE) a également rencontré des difficultés et a mis au point ses approches MVC2.

Mais aujourd’hui, ce que j’ai découvert, c’est que la programmation d’arrière-plan n’est plus le lieu de l’enthousiasme et du progrès. De plus, les pratiques MVC basées sur le serveur semblent être obsolètes (les gens utilisent-ils vraiment plus JSTL?). Aujourd'hui, dans la plupart des projets sur lesquels je travaille, j'ai découvert que les frameworks JavaScript et le développement côté client sont le lieu où tous les progrès excitants et innovants sont réalisés.

Pourquoi ce passage du développement serveur au client a-t-il eu lieu? J'ai fait un simple comptage de lignes de l'un de mes projets JEE et il y a plus de lignes de code en JavaScript que Java (à l'exclusion des bibliothèques tierces). Je trouve que la plupart des développeurs utilisant des langages de programmation tels que Java ou C # ne font que produire une interface de type REST, et que tous les efforts importants d'affichage, de visualisation, d'entrée / sortie de données, d'interaction utilisateur, etc. via un framework côté client comme Angular, Backbone, Ember, Knockout, etc ...

Avant l'ère pré-jQuery, j'ai vu beaucoup de diagrammes où il existait une ligne conceptuelle claire entre M, V et C dans MVC dans le développement multiniveau. Post-jQuery, où sont ces lignes tracées? Il semble que MVC et MVVM sont tous là dans le code JavaScript, côté client.

Ce que je veux savoir, c’est pourquoi nous avons opéré une telle transition (de l’importance accordée à la programmation côté serveur au côté client, de privilégier les langages compilés aux langages de script, de la programmation impérative à la programmation fonctionnelle, tout cela semble s’être produit simultanément. ) et quels problèmes cette transition / ce changement a-t-il résolus?

Le transfert de la charge informatique entre le serveur et le client est un phénomène cyclique, et ce depuis assez longtemps.

Quand j'étais au collège communautaire, l'ordinateur personnel commençait à prendre de l'ampleur. Mais Ethernet n’était pas encore très répandu et personne n’avait de réseau local. À l'époque, le collège disposait d'un ordinateur central qui gérait les dossiers des étudiants et servait de plate-forme pour la programmation. L’administration disposait de terminaux connectés à l’ordinateur central sur une base de temps partagé, mais les étudiants devaient perforer des cartes pour effectuer leurs tâches de programmation, un processus ardu. Finalement, ils ont mis dans un laboratoire où les étudiants pouvaient s'inscrire pour gagner du temps sur un terminal, mais il a peut-être fallu environ une demi-heure pour obtenir une impression d'erreurs d'un demi-pouce d'épaisseur. Tout le traitement a été effectué sur l’ordinateur central (le serveur).

Mais les ordinateurs centraux coûtant cher, les entreprises ont commencé à mettre en place des réseaux locaux et la charge de traitement a été transférée du serveur aux machines clientes, suffisamment puissantes pour exécuter des applications de traitement de texte, de tableur et de ligne de produits individuelles, mais pas assez pour partager leur puissance de traitement avec d'autres. Le serveur était une machine similaire avec des fonctionnalités similaires (peut-être davantage de mémoire et d'espace sur le disque dur), mais était principalement utilisé pour partager des fichiers. Cela s'appelait Client / Serveur. La plupart des traitements ont été transférés sur les ordinateurs clients.

L'un des inconvénients de la totalité du traitement sur les ordinateurs clients est que vous avez été pris au piège de ce cycle perpétuel d'installation et de mises à niveau de logiciels, ainsi que de tous les maux de tête qui vont avec. Le modèle de programmation de ces machines (interfaces utilisateur basées sur des événements et code-behind) a encouragé la création de programmes désordonnés et difficiles à gérer (grosses boules de boue). La plupart des utilisateurs finaux n'avaient pas les compétences nécessaires pour entretenir correctement leur matériel et leurs logiciels, ce qui nécessitait des armées de personnel de maintenance informatique.

À mesure que les ordinateurs devenaient de plus en plus puissants, les divisions du travail devenaient possibles. Vous pouvez maintenant avoir des serveurs de fichiers, des serveurs de base de données, des serveurs Web, des serveurs d'impression, etc. Chaque machine peut être quelque peu optimisée pour la tâche qui lui a été fournie et entretenue par une personne possédant les compétences requises. Les programmes peuvent être écrits dans le navigateur Web, de sorte que les installations client ne sont plus nécessaires. Cela s'appelait Multi-Tier ou n-Tier. Les navigateurs étaient essentiellement utilisés comme des terminaux stupides, comme à l’époque des grands systèmes, bien que la méthode de communication avec le serveur soit plus sophistiquée, moins propriétaire et reposant sur des mécanismes d’interruption plutôt que sur le partage de temps et la scrutation. Le traitement avait été transféré sur le ou les serveurs.

Cependant, le développement Web est venu avec une nouvelle série de maux de tête. La plupart des applications métiers écrites pour le navigateur étaient des formulaires et des rapports statiques. Il y avait très peu d'interactivité disponible dans l'interface utilisateur. Javascript n'avait pas encore trouvé son second souffle, et l'incompatibilité des navigateurs posait de gros problèmes, ce qui décourageait son adoption généralisée. Cependant, les choses se sont beaucoup améliorées. HTML5 et CSS3 apportent de nouvelles fonctionnalités substantielles au modèle de programmation du navigateur, jQuery est sorti et a aidé toute une génération de programmeurs à découvrir l'utilité de Javascript. De nouveaux cadres d'interface utilisateur frontaux ont émergé. Il est devenu possible d'écrire des interfaces utilisateur hautement interactives dans le navigateur, même des jeux complets. Le traitement est de nouveau transféré vers le client.

Aujourd'hui, vous pouvez acheter autant que vous le souhaitez une puissance de traitement dans le cloud et exécuter des programmes sur le serveur. Je dirais que nous sommes maintenant à un endroit où, en tant que développeur de logiciels, vous avez beaucoup de choix quant à l'endroit où vous pouvez utiliser votre puissance de traitement, à la fois sur le client et sur le serveur.

Vous semblez mélanger deux concepts très différents:

1. Séparer la présentation et la logique métier (MVC) => augmenter la maintenabilité
2. Assigner l'exécution à un noeud => augmenter l'efficacité

À l'époque, l'informatique client / serveur était souvent confuse d'impliquer la première, car les clients n'offraient généralement pas beaucoup de puissance de calcul par rapport aux serveurs. Il semblait donc naturel de déplacer le calcul "lourd" de la logique métier (M) vers les serveurs, tout en conservant le traitement de la vue "légère" (V) aux clients. À son tour, vous deviez mettre en place une sorte d'arbitre (C) pour assurer la traduction entre les deux.

Avec les clients maintenant facilement dotés de prouesses de processus qui impliquaient jadis un matériel de serveur coûteux, les lignes sont floues quant à l'endroit où exécuter la logique métier - côté client ou côté serveur. En réalité, la réponse dépend de votre cas d'utilisation spécifique et de votre choix de compromis, par exemple:

• latence du client vs complexité: le traitement côté serveur simplifie les systèmes car aucun code ne doit être déployé / téléchargé sur le client, mais il entraîne un coût en latence lors du calcul.

• complexité par rapport à la charge du serveur: l'informatique côté client peut augmenter la complexité du système, mais elle peut également contribuer à réduire la charge du serveur.

• Résilience des applications décentralisée et exécution centrale: dans un monde d'applications mobiles, il peut être important de garder les clients actifs malgré la déconnexion du réseau. Toutefois, cela se fait au prix de la gestion de plusieurs versions déployées de la logique métier.

Ceci est une liste non exhaustive de nombreux compromis.

Parce que les utilisateurs ont toujours souhaité les mêmes fonctionnalités et les mêmes sifflets avec leurs applications Web (pas seulement les sites Web) qu’ils avaient avec les applications de bureau. Rendre tout cela exécuté dans un navigateur (en fait, plusieurs navigateurs) n'est pas comme à l'époque où vous pouviez lier un formulaire VB à une base de données avec peu de code. Ceci est plus facile à accomplir lorsque vous n’avez pas à retourner au serveur.

la plupart des développeurs utilisant des langages de programmation tels que Java ou C # consistent simplement à produire une interface de type REST, et que tous les efforts importants d'affichage, de visualisation, d'entrée / sortie de données, d'interactions utilisateur, etc. sont adressés via client cadre latéral comme Angular, Backbone, Ember, Knockout, etc ...

Peut-être que les programmes / services d’arrière-plan semblent être la même chose, mais c’est le cœur de l’application. Les pratiques de codage peuvent être plus efficaces dans ces domaines. Les outils, les langages, les navigateurs et les frameworks évoluent toujours, il est donc difficile de développer UI / UX. Ce sont les nouvelles choses que l'ancien ASP n'avait pas. Si nous pouvions sortir avec des interfaces utilisateur avec des formulaires simples et des tableaux HTML, il n'y aurait pas beaucoup d'intérêt / battage publicitaire dans ces domaines non plus, mais les utilisateurs veulent du glisser-déposer, des animations, des transitions, des pop-ups, etc.

Aujourd'hui, dans la plupart des projets sur lesquels je travaille, j'ai découvert que les frameworks JavaScript et le développement côté client sont le lieu où tous les progrès excitants et innovants sont réalisés.

Pourquoi ce passage du développement serveur au client a-t-il eu lieu?

Il y a en fait deux questions ici:

1. Pourquoi la programmation côté client est-elle un progrès?
2. Pourquoi les applications écrites pour s'exécuter sur le client plutôt que sur le serveur?

Les deux sont en réalité distincts.

Pourquoi la programmation côté client est-elle un progrès?

Parce que le temps d'exécution, l'environnement et l'écosystème ont considérablement évolué au cours des trois dernières années, de nouvelles niches ont été ouvertes que les innovateurs attendent d'exploiter.

Le développement frontal était difficile . Vous deviez programmer pour les navigateurs - toujours dans un environnement hostile - en utilisant les fonctionnalités restreintes de ECMAScript 3, dans un écosystème sans art antérieur ni outil permettant de créer des applications client lourd. Il n'y avait pas de chargeurs de modules. Vous ne pourriez pas gérer les dépendances correctement. Il y avait une pénurie d'outils à charpie. Les cadres étaient immatures et la réputation médiocre du client en amont permettait aux innovateurs distants de résoudre ces problèmes.

À mesure que ces facteurs ont changé progressivement, ils ont créé une masse critique pour le développement rapide d'applications client riches et leur exécution cohérente.

En réponse à votre question, ce ne sont donc pas tant les nouvelles technologies frontales qui ont fait progresser les progrès, mais elles ont permis de dégager des goulets d'étranglement et de permettre aux clients de répondre aux aspirations des utilisateurs.

Pourquoi les applications écrites pour s'exécuter sur le client plutôt que sur le serveur?

Il existe de nombreuses causes immédiates, mais la plus nette de ces dernières années est la montée des smartphones.

Les smartphones rendent l'informatique modérément puissante peu coûteuse, omniprésente et utile. Ils appartiennent à des milliards de personnes sur la planète et ont essentiellement apporté l'informatique aux classes moyennes des économies émergentes. Mais les réseaux de téléphonie mobile sont lugubres, inégaux et limités par des problèmes géographiques, techniques et politiques difficiles. Dans cet environnement, il est inévitable que les applications stockent l’état localement et corrigent les données vers le haut à contrecœur et lors d’opérations sans état.

Comment pourrait-il en être autrement? Imaginez si votre smartphone était juste un terminal stupide. Chaque mutation d'état devrait être asynchrone et faillible. Chaque chargement de contenu coûterait des cents précieux. Vous devrez investir dans d’énormes batteries de serveurs avec une disponibilité de cinq-neuf. Les coûts informatiques seraient directement à votre charge, de sorte qu'un regain de popularité pourrait en réalité ralentir votre activité.

Les applications côté client vous permettent de gérer rapidement et de manière synchrone les états appartenant à chaque utilisateur. Ils vous permettent de décharger vos coûts informatiques sur vos utilisateurs. Ils vous laissent sortir avec des temps d'arrêt et une connectivité réseau médiocre. Ils rendent le code de serveur si stupide qu'il peut être mis en cache dans l'infrastructure réseau elle-même - fichiers HTML et JS statiques, ou réponses prédéfinies pour les applications mobiles.

En termes très généraux: le développement côté client exploite les faibles coûts de l'informatique personnelle de moyenne puissance et évite les coûts élevés de l'informatique centralisée de grande puissance.

Vous avez posé plusieurs questions, dont certaines ont déjà de bonnes réponses. Quelques-uns n'ont pas encore eu leurs réponses:

Ce que je veux savoir, c’est pourquoi avons-nous fait une telle transition (de l’importance accordée à la programmation côté serveur au côté client, tout semble avoir eu lieu simultanément) et quels problèmes cette transition / ce changement at-il résolus?

Robert Harvey a donné une excellente réponse.

... de privilégier les langages compilés aux langages de script,

Les langages de script offrent de nombreux avantages ( également ) par rapport aux langages compilés, par exemple:

• sont plus faciles à apprendre et à utiliser
• éliminer le temps de compilation (développement plus rapide)
• fournir plus de fonctionnalités (contrôle d'application haut de gamme)
• permettre des changements rapides dans le code en cours d'exécution
• etc.

... de la programmation impérative à la programmation fonctionnelle,

Voici une bonne comparaison, mais je résumerais en disant que dans les logiciels distribués (pensez au cloud computing), la gestion des changements d'état (synchronisation sur de nombreux nœuds) peut être un énorme problème. En programmation fonctionnelle, le besoin de gérer les changements d'état est beaucoup moins important.