Se précipiter côté client dans le développement Web


10

Au cours des derniers mois, j'ai reconnu une grande excitation à propos des scripts côté client dans le développement Web. Mais alors que les technologies côté serveur sont matures, stables et bien acceptées par les développeurs d'arrière-plan, les technologies côté client sont immatures (c.-à-d. Par rapport aux grandes infrastructures côté serveur) et détestées par de nombreux développeurs de longue date. Néanmoins, tout le monde fait du développement côté client ces jours-ci. Personnellement, je m'attends à ce que ces grands cadres côté serveur disparaissent dans 2 à 5 ans, en observant la tendance actuelle.

Pourquoi est-ce si? Comment le développement côté client nouveau et "diffus" en HTML5 / JS pourrait-il être supérieur aux solutions côté serveur grandes et bien pensées?


4
Avez-vous des sources pour vérifier vos hypothèses? Javascript est presque aussi ancien qu'Internet lui-même, et je ne vois pas de programmation côté serveur aller de si tôt.
tdammers

1
Pour clarifier, mes hypothèses se limitent au front-end. Je vois un changement vers le côté client, dans la logique de l'interface utilisateur, le rendu et des trucs comme ça. Bien sûr, le côté serveur ne disparaîtra jamais, mais réduit à une API REST (ou SOAP d'ailleurs).
Bruno Schäpper

3
Ce changement va et vient. Habituellement, le développement frontal devient plus populaire une fois que de nouvelles technologies intéressantes sont introduites (Shockwave, Flash, JavaFX, Flex) ou que de nouveaux frameworks js tentent de "conquérir le monde" (motools, jquery, etc.)
Andrzej Bobak

1
@VainFellowman: Vous ne voulez vraiment pas utiliser SOAP dans un script côté client. Il y a beaucoup trop de frais généraux, l'analyse est une douleur, et vous ne gagnez pas beaucoup parce que Javascript avec sa discipline de typage dynamique ne sera pas en mesure de faire grand usage des informations de type de SOAP de toute façon.
tdammers

1
@tdammers Je ne veux pas, vraiment pas. Je ne vois aucun intérêt à utiliser SOAP sur HTTP. REST convient à presque tout.
Bruno Schäpper

Réponses:


7

C'est vrai:

Se précipiter côté client dans le développement Web

Mais il ne se limite pas au côté client, c'est un mouvement de pile complète.

Je sais que cela peut être surprenant. S'il vous plaît, écoutez-moi.

Pourquoi est-ce si? Comment le développement côté client nouveau et "diffus" en HTML5 / JS pourrait-il être supérieur aux solutions côté serveur grandes et bien pensées?

Tout d'abord, les deux sont bien pensés.

Deuxièmement, parce que c'est mieux.

Bonne question.

Mais «mieux» est subjectif, donc la réponse à votre question est: qu'est-ce qui est mieux en particulier?

Revisitez la question:

Comment le développement côté client "diffus" en HTML5 / JS pourrait-il être supérieur aux grandes solutions côté serveur?

Because small is nimble.
And big is clunky.

C'est la flexibilité.

Cela ne semble pas être un gros problème. Le fait-il? Souplesse.

Cependant, la flexibilité sous-tend tout. Une amélioration de la flexibilité - améliore tout.

Maintenabilité. Extensibilité. Évolutivité. Modularité. Convivialité. UX.

Et il est plus rapide à mettre en œuvre. C'est la réalité. Plus vite et mieux.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, n'est pas une mode et il ne disparaîtra pas. Nous ne voyons que les germes d'une technologie qui se développera pour fournir du contenu informatique et des comportements d'interaction aux tablettes. Comprimés.

Les téléphones intelligents ont été l'adoption des médias de masse la plus rapide depuis la télévision dans les années 1950. Maintenant, non seulement nous avons des smartphones, mais aussi des tablettes.

Déjà en développement chez Mozilla et Windows, le système d'exploitation qui fonctionnera sur les futurs appareils de leurs marchés -> HTML / JS.

De nombreuses solutions et innovations restent.

Une pile complète de JS émerge, basée sur la flexibilité.

J'espère que ça aide.


1
Très bonne réponse! Mais les frameworks côté serveur promettent les mêmes avantages, n'est-ce pas?
Bruno Schäpper

1
Oui Monsieur, les frameworks côté serveur promettent les mêmes avantages, oui. Ce qu'il faut savoir, c'est qu'il y a des avantages supplémentaires, trouvés de manière inattendue, dans les technologies émergentes. Il se situe au niveau le plus bas (c) de l'io. Les threads attendent. Dans JS, il a un rappel. Ça n'attend pas. Il y a donc une optimisation io au niveau le plus bas. Cette réalisation est désormais, discrètement, adoptée de façon large par Microsoft. C'est pourquoi leur système d'exploitation est JS. Dernier point, cela donne une optimisation et des méta optimisations - à tous les niveaux. Parce que la langue est flexible. Une chose simple et invisible. Pas connu. J'espère que cela pourra aider.
Jack Stone

1
J'ai choisi d'accepter cette réponse, car elle est la plus complète. Tous les autres ont de bons points, mais c'est le plus concluant. Merci tout le monde!
Bruno Schäpper

9

Cette histoire a toujours eu deux côtés; Le code côté serveur et côté client a ses avantages et ses inconvénients.

Les avantages des scripts côté client incluent:

  • Peut être rendu plus réactif, des modifications importantes sont possibles sans aller-retour sur le serveur.
  • Le code s'exécute sur le client, ce qui réduit l'utilisation des ressources sur le serveur.
  • La séparation entre logique et présentation devient physique.
  • Parfois plus facile à équilibrer la charge, surtout si l'authentification par demande est utilisée.

Mais le script côté serveur présente également de nombreux avantages:

  • Vous contrôlez la machine sur laquelle le code s'exécute.
  • Presque tout est possible - si votre serveur peut le faire, votre script aussi.
  • Les utilisateurs ne peuvent pas modifier votre script avant de l'exécuter.
  • Les utilisateurs ne peuvent pas utiliser de bloqueurs de scripts pour empêcher l'exécution de votre script.
  • Les utilisateurs ne peuvent pas voir ce que fait votre script, ils peuvent uniquement observer la sortie.
  • Le code fonctionnera de manière fiable avec tous les clients que vous pouvez imaginer, y compris les lecteurs d'écran, les navigateurs Web textuels, les araignées des moteurs de recherche, les grattoirs, les accumulateurs, les robots IRC, les machines super bas de gamme, les navigateurs bloqués par script, vous l'appelez.
  • Les plugins utilisateur sont moins susceptibles de se casser.

Pour les applications Web hautement dynamiques, l'approche centrée sur le client a toujours été un choix populaire, car c'est le seul moyen de fournir une expérience utilisateur de type bureau réactive et décente: sans script côté client, chacune des actions de l'utilisateur nécessite une ronde- voyage, ce qui signifie au moins une demi-seconde de retard, généralement plus. Mais pour un site d'information qui n'est fondamentalement qu'un tas de pages statiques servies à partir d'une base de données (par exemple, wikipedia), l'avantage est marginal, tandis que les avantages des scripts côté serveur sont toujours écrasants.

Le battage médiatique observé provient d'une combinaison de deux développements récents:

  1. HTML5 et sa couronne de technologies connexes. Cela a pris trop de temps, mais maintenant nous avons enfin une norme qui contient tout ce dont vous avez besoin pour créer ces applications Web dynamiques de type bureau sans empiler de hacks, et des navigateurs traditionnels qui les implémentent correctement.
  2. Puissance de traitement disponible. Les PC de bureau actuels sont tout aussi puissants qu'un serveur Web d'entrée de gamme, les téléphones portables de qualité client sont pratiquement des ordinateurs de bureau de 2005, et les implémentations javascript modernes sont suffisamment efficaces pour faire pencher la balance des performances: désormais, les ressources côté client sont moins chères que le serveur Ressources.

En fait, rien n'a changé en ce qui concerne les approches centrées sur le serveur et centrées sur le client; ce qui a changé, c'est que le centré sur le client est désormais plus facile et moins cher à faire et fonctionne mieux qu'il y a quelques années, ce qui en fait un choix viable pour beaucoup plus d'applications qu'auparavant.


vérités dures ... +1.
Jack Stone

8

Le côté serveur sera toujours là. Vous ne pouvez pas vous asseoir côté client pour tout. Par exemple, vous ne voudrez pas utiliser une conception MVC Backbone.js pour votre microcontrôleur en vous envoyant des paramètres en temps réel à partir d'un pont roulant de plancher de production.

Ne croyez pas le battage médiatique.


Dîtes-moi. JS est-il dans Windows 8, hype? -1. Je suis d'accord avec le premier point, mais votre deuxième point sur le battage médiatique doit être clarifié.
Jack Stone

JS n'est pas exclusif au côté client et ne l'a pas été depuis un certain temps.
Erik Reppen

@ClintNash ya, en fait. Mme a permis à j de créer des applications win8 pour augmenter le nombre potentiel de développeurs pour leur plate-forme. C'est une réponse aux personnes qui choisissent d'apprendre ces technologies par rapport aux technologies de bureau. Mais en tant que rev connaissant déjà c # / wpf, je ne vois aucune raison de construire une application win8 avec html / js.
Andy

@ErikReppen c'est vrai, mais js seul ne le coupe pas sur le serveur, vous avez besoin d'un framework pour l'intégrer. Franchement, le désir d'utiliser un script sur le serveur me déconcerte. Nous l'avons déjà fait, c'était un ASP classique, et je n'ai pas vraiment envie de répéter cette expérience.
Andy

@Andy Sur ASP classique (formulaires Web en particulier), vous ne trouverez pas de fin d'accord avec tout développeur JS qui a eu le malheur d'avoir un rodage avec ces outils que nous ne voulons certainement pas y retourner. Mais c'est l'outil de script côté serveur basé sur les balises le moins apprécié de yesterdecade et probablement la solution de client léger la plus méprisée avec le plus de popularité. En comparant cela à quelque chose comme Python et maintenant JS côté serveur, c'est presque dire aux gens de prendre un cheval.
Erik Reppen

6

J'ai fait le passage en 2009 d'un framework PHP côté serveur à une solution ExtJS côté client liée aux services web côté serveur.

Les raisons de la migration pour moi étaient:

  1. Meilleure sécurité en réduisant la quantité de points de terminaison et de code sur le serveur.
    En passant aux services Web, vous validez l'entrée à la frontière du service Web et contrôlez plus précisément les E / S de votre serveur. Il n'y a pas de couche d'interface utilisateur côté serveur pour brouiller votre architecture de sécurité.
  2. Performances améliorées en raison du nombre moins important d'allers-retours sur le serveur
    L'architecture change, de sorte que les récupérations de données peuvent se produire moins souvent et les données peuvent être mises en cache localement, le rendu de l'interface utilisateur ne nécessitant aucun aller-retour. Les allers-retours sont ce qui tue les performances des applications Web.
  3. Amélioration des performances grâce à la mise en cache de l'interface utilisateur
    La couche d'interface utilisateur peut être entièrement hébergée sur un CDN. J'ai même créé des applications Web hors ligne en insérant le code de l'interface utilisateur dans le cache d'applications HTML5.
  4. Haute fidélité de l'interface utilisateur (riches contrôles côté client)
  5. Les développeurs tiers peuvent utiliser la même API que mon propre front-end, et je peux facilement réutiliser les API entre les modules s'ils partagent des fonctionnalités.
    Cela signifie moins de développement, d'assurance qualité, de documentation, ...
  6. J'aime mieux la programmation en JavaScript que PHP, Python ou Java

Mais ne vous y trompez pas, ce qui se passe maintenant est un battage médiatique. Il explosera et de nombreuses applications Web utiliseront à nouveau une architecture d'interface utilisateur côté serveur.


Quoi, battage médiatique? -1 Bonne chance quand Windows 8 fait de JS un citoyen de première classe. Oui, l'architecture d'interface utilisateur côté serveur écrite dans node.js peut-être. Nous devons l'apprendre car il n'est pas bloquant.
Jack Stone

Je ne pense pas que nous reviendrons de sitôt sur des solutions client lourd. Mais si j'étais aux prises avec ExtJS pour tout problème qui est devenu plus compliqué que de caca l'interface utilisateur Web préfabriquée (c'est-à-dire tous les problèmes, quel que soit le plan d'origine), je pouvais voir pourquoi l'alternative pouvait sembler moins qu'idéale.
Erik Reppen

6

Un autre facteur qui stimule l'enthousiasme pour les solutions côté client est la croissance des applications mobiles. Si vous créez un site Web fortement basé sur JavaScript et AJAX côté client, et que vous créez également des applications iOS et Android natives, il y a de fortes chances que les trois puissent utiliser les mêmes services REST pour faire toutes leurs données de va-et-vient. .


Bien dit ... +1.
Jack Stone

Très bon point en effet.
Bruno Schäpper

4

Tout d'abord, l'utilisateur ne voit pas (et parfois même ne s'en soucie pas) ce qui n'est pas le serveur. Peu importe à quel point le code côté serveur est bien écrit, les utilisateurs n'apprécieront pas l'application si la partie client n'est pas bien faite. Parfois, même la belle interface utilisateur est plus importante que la fonctionnalité.

Un hébergement de serveur gros et puissant coûte assez cher. Il est beaucoup moins cher d'implémenter une partie de la logique (sauf la validation) côté client. Vous pouvez donc utiliser un hébergement de serveur plus petit (donc moins cher), car il ne serait pas trop chargé.

C'est la raison pour laquelle, malgré l'instabilité, les technologies côté client gagnent en popularité. En outre, JS et HTML / CSS sont pris en charge par (presque) tous les navigateurs modernes.

Ces deux parties d'applications ne peuvent pas exister séparément. Et Internet ne semble quitter nulle part dans un avenir proche.
Je ne pense pas que cela big server-side frameworksrisque de disparaître non plus. Il y aura toujours des entreprises qui pourront se les permettre et utiliseront leurs avantages significatifs.


4

Le développement Web côté client est fortement associé aux navigateurs Web et à leur évolution au fil du temps. La solution que vous fournissez maintenant peut ne pas fonctionner dans quelques mois en raison de changements importants dans les moteurs de rendu de page des navigateurs Web. Certains navigateurs sont / étaient incompatibles avec les normes et nécessitaient donc encore plus d'efforts supplémentaires de la part des développeurs pour atteindre le résultat escompté.

Il existe des solutions pour résoudre ce problème. Par exemple, si vous utilisez jquery, vous êtes assuré que votre script fonctionnera sur les navigateurs pris en charge par cette bibliothèque jquery particulière. Mais c'est seulement à ses auteurs de vous fournir la compatibilité avec certains / la plupart / tous les navigateurs. La question est de savoir quelle équipe vous soutiendra le mieux. Sera-ce l'équipe motools, l'équipe jquery, l'autre équipe? S'ils ne prennent pas en charge un navigateur Web particulier, votre projet peut ne pas fonctionner dans ce navigateur.

L'excitation que vous semblez avoir existe depuis longtemps. Je l'ai vu lorsque Shockwave et son successeur Flash ont été introduits, il y a eu un "grand retour" d'interfaces utilisateur riches une fois les bibliothèques js complexes expédiées, d'abord avec motools, puis avec jquery (j'ai commencé à les utiliser dans cet ordre). Il y avait Flex et JavaFX. Mais aucun d'entre eux ne peut obtenir une grande part du marché. Certains nécessitent des plugins qui, à terme, exposent souvent l'utilisateur final à des vulnérabilités de sécurité, d'autres peuvent ne pas fonctionner côté client en raison de certains paramètres personnalisés (par exemple JavaScript désactivé dans le navigateur des clients).

D'un autre côté, la solution côté serveur n'est généralement écrite qu'une seule fois. Vous n'avez pas à vous soucier que tout échouera et devra être réécrit une fois que le nouveau Firefox / Chrome / IE / Opera sera expédié. Vous n'avez pas non plus à vous inquiéter du fait que le client tentera de falsifier votre application et / ou de corrompre les données.


1
N'est-ce pas pure imagination? Vous devrez peut-être changer vos trucs côté serveur lorsque les clients changent, car vous n'aurez pas à générer de code HTML / JS / CSS à un moment donné.
Bruno Schäpper

1
Une autre chose, `` le développement Web côté client est fortement couplé avec les navigateurs Web '' - les technologies Web sont des normes officielles, tant que vous vous en tenez à cela, vous implémentez une norme, pas en couplant votre application à un navigateur. Il n'y a pas si longtemps, ce n'était pas vraiment vrai, mais il semble que ce soit le cas actuellement.
Bruno Schäpper

Tout d'abord, lisez comment certains navigateurs ne respectent tout simplement pas les normes (Internet Explorer par exemple). Certaines choses ont changé au fil du temps, mais même avec IE7, j'ai eu d'horribles problèmes en raison de sa propre façon d'interpréter ce que j'ai écrit. Lisez également quelques articles sur les compatibilités entre navigateurs. Ce problème n'existerait pas si chaque fournisseur de navigateur Web respectait les normes. Deuxièmement, si l'ensemble de données change, vous devez changer votre logique métier, c'est évident, mais quand un nouvel IE est livré et que vous devez réécrire environ 30% du code juste pour que le code fonctionne sur le nouveau navigateur - quelque chose ne va pas
Andrzej Bobak

Bien sûr, je sais à quel point c'est douloureux et cela a été de tout faire fonctionner dans tous les navigateurs. Mais ce travail doit être fait indépendamment du côté serveur ou côté client (car vous devez utiliser un navigateur à la fin de toute façon). Je suis certainement d'accord sur votre deuxième point. Cependant, je ne vois pas 30% à réécrire. Certaines modifications sont peut-être nécessaires, mais je doute que ce soit aussi mauvais qu'auparavant. D'autre part, vous devez tout refaire en fonction de la couche de service, si vous souhaitez remplacer votre pile côté serveur. Vous êtes donc TRÈS étroitement couplé à votre implémentation côté serveur. Peut-être du haut de l'interface utilisateur au modèle.
Bruno Schäpper

-1

Entièrement d'accord avec vos sentiments. Je crois également qu'au-delà de ce que vous dites, nous allons voir une baisse spectaculaire du REST et une augmentation massive des websockets pour la principale façon dont nous voyons les sites communiquer avec leurs serveurs. Vert.x, Node.js etc. Le côté serveur tout entier, ainsi que le côté client, passe à la programmation événementielle. Java EE, PHP, Rails, etc. ils ont tous besoin de s'adapter ou ils vont perdre très rapidement.


Sans explication, cette réponse peut devenir inutile au cas où quelqu'un d'autre publierait une opinion différente. Par exemple, si quelqu'un publie une réclamation comme "nous n'allons pas voir une baisse spectaculaire du REST et une augmentation massive des websockets", comment cette réponse aiderait-elle le lecteur à choisir parmi ces opinions divergentes? Pensez à l' éditer sous une meilleure forme
moucher
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.