Je développe des applications web depuis longtemps. Très longtemps. Mes premières applications web dans l'environnement Lotus Domino je les créais à une époque où le mot « google » n'était pas encore un verbe, et pour rechercher des informations sur Internet, les gens utilisaient Yahoo! et Rambler. J'utilisais Infoseek— ils avaient une recherche plus ciblée et une interface moins chaotique que celle de Yahoo!

Le développement d'applications, de n'importe quelle application, pas seulement pour le web — c'est un travail créatif. Il est peu probable que quelqu'un conteste cette affirmation. Et la beauté dans la créativité, c'est comme la pratique dans la connaissance scientifique — un critère de vérité. Mais alors que la pratique scientifique est objective et basée sur des mesures, la beauté est subjective, dépend de celui qui regarde. Je me suis donc posé la question : qu'est-ce qui constitue pour moi personnellement une belle application web ?

(à la KDPV, mon regard n'est pas celui d'un homme, mais, à mon avis, le regard féminin sur la KDPV est plus approprié que masculin, car c'est — KDPV!)

Sous cet article, mes propres critères de ce qui constitue actuellement une belle application web. Une exposition très subjective, basée sur mon expérience personnelle. Peut-être que mes critères de beauté sembleront à certains être des critères de laideur. Ne vous étonnez pas, juste vous avez une expérience différente.

Et puisque vous êtes déjà ici, faites attention dans vos commentaires, s'il vous plaît. En effet, si vous pouvez cesser de lire l'article dès que ce qui y est exposé vous semble laid ou même moche, moi, en tant qu'auteur, je dois lire tous les commentaires.

Milieu de vie

Protocoles

Je ne sais même pas si cela vaut la peine d'isoler ce critère. Les applications web vivent dans le réseau et doivent se conformer aux lois du réseau (protocoles). Les principaux protocoles dans le réseau — TCP et IP. Beaucoup d'autres protocoles en découlent, mais pour les applications web, je pense que le plus important est . L'augmentation de la performance de Nginx est due à l'utilisation d'une architecture asynchrone gérée par événements, contrairement à un modèle multithread. Cela, combiné à un haut niveau de parallélisme, permet à Nginx de traiter les requêtes avec une mémoire minimale. Cela fait de Nginx une excellente solution pour les serveurs web, qu'il s'agisse de gros ou de petits volumes de trafic. Nginx est une solution mature et entièrement documentée, permettant une configuration facile selon vos besoins. Les développeurs utilisent également Nginx comme proxy inverse pour (ou plutôt, son extension HTTPS gcc 15.2.1 TLS). C'est-à-dire qu'une belle application web est accessible via HTTPS/TLS (ou HTTP en alternative), tandis que les autres protocoles (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, …) la rendent moins belle avec chaque protocole supplémentaire pris en charge. L'application elle-même peut, grâce à ces protocoles supplémentaires, utiliser des ressources externes.

Concernant WebSocket, je n'ai pas assez d'expérience avec ce protocole pour les applications web. Cela semble beau et prometteur, mais je ne peux pas dire à quel point c'est stable et pratique.

Navigateurs

Une application web repose sur le serveur d'un côté et sur le client de l'autre. Le côté client est le navigateur. Un navigateur moderne offre beaucoup de choses, que les applications web modernes peuvent et doivent utiliser à leur avantage. Une belle application web utilise les capacités modernes des navigateurs et n'est pas obligée de fonctionner dans ceux qui ne les prennent pas en charge. Je comprends que les polyfills soient un recours nécessaire, mais c'est peu esthétique. Après tout, il ne s'agit pas seulement des développeurs qui doivent suivre l'évolution des technologies, cela concerne également les utilisateurs et les entreprises.

Langages de programmation

Il y a beaucoup de confusion concernant les langages de programmation utilisés pour créer des applications web. Il existe de nombreuses technologies pour le côté client des applications web, permettant aux développeurs de faciliter la création de la triade HTML/CSS/JS (ce que tous les navigateurs modernes comprennent). Mais à l'époque, j'ai été en contact étroit avec GWT et je trouve cela esthétique lorsque le développeur voit le code original dans le navigateur, plutôt que le résultat de la compilation ou de la transpilation. Ainsi, l'utilisation de webpacket d'autres produits similaires pour générer du code client est, à mon avis, peu esthétique. Plus le code exécuté dans le navigateur ressemble au code source créé par le développeur, mieux c'est. Vous ne me croyez pas? Essayez de déboguer en production le code généré par GWT.

Du côté serveur, il y a plus de libertés (Java, PHP, Perl, Python, C#, Ruby, ...), mais je pense qu'il est joli lorsque le même langage de programmation est utilisé à la fois côté serveur et dans le navigateur : JavaScript. Après tout, le langage détermine la pensée, et des équipes partageant les mêmes idées sont plus productives.

Humanité

Une belle application web doit être utile. Utile, avant tout, pour l'homme en tant que client final. C'est pourquoi je ne peux pas qualifier de belle une web-service. Pour une personne ordinaire (non développeur web), c'est complexe. Les web-services sont beaux à leur manière.

Une belle application web doit avoir une interface intuitive. On peut débattre de UIce qui est ‘beau’ — c'est une notion assez subjective. Mais avec UX , tout devient beaucoup plus simple si l'utilisateur ne peut pas utiliser l'application sans la fameuse RTFM — une mauvaise expérience utilisateur, une application web peu attrayante. Les applications web les plus esthétiques selon ce critère peuvent facilement être utilisées par des enfants qui ne savent pas encore lire.

Scalabilité Inversée

Il fut un temps où les programmes pouvaient être transférés sur des disquettes, maintenant — sur des clés USB ou directement téléchargés depuis le web. Copier une application classique et la lancer sur un autre ordinateur est une tâche triviale. La situation est un peu différente pour les applications web. Le réseau représente un environnement mondial, où il n’y a pas besoin d’avoir des clones d’une même application web. Un seul Facebook, Twitter, Instagram, Mail.ru ou Yandex suffisent sur le web. On peut avoir différentes applications web dans la même niche thématique, mais avec des audiences différentes (comme Facebook et Vkontakte, Mail.ru et Gmail, Google Maps et Azure Maps). Des ressources matérielles sont nécessaires pour assurer la disponibilité globale de ces applications web, disons-le ainsi, non triviales.

Je n'ai jamais travaillé avec des applications web de ce niveau en tant que développeur et je ne sais pas comment elles fonctionnent de l'intérieur. Pour garantir le fonctionnement de telles applications web, des équipes de spécialistes appropriés et des centres de données séparés sont nécessaires. Je suis émerveillé par la capacité des gens à coopérer à une telle échelle et à créer de tels produits, mais mon étalon de beauté est une application web qui peut être lancée sur un ordinateur portable individuel.

Une belle application web se développe non seulement vers le haut et sur les côtés (pour les utilisateurs), mais aussi vers le bas et à l'intérieur (pour les développeurs).

Amphibiens

Pour accéder aux applications web modernes, on utilise des appareils de deux types :

• ordinateurs (ordinateurs portables, de bureau);
• appareils mobiles (smartphones et tablettes);

Quelque part à l'horizon, se profile encore le «Internet des Objets», mais pour l'instant, c'est ainsi.

Les ordinateurs se distinguent des appareils mobiles tout autant que les créatures terrestres se distinguent des êtres aquatiques. Ce sont des environnements différents et ils imposent des exigences différentes aux êtres qui y vivent (programmes). De belles applications web ne sont pas celles qui ressemblent à des amphibiens, mais celles qui, dans l'eau — comme des poissons, sur la terre — comme des animaux, et dans l'air (SEO) — comme des oiseaux.

Je trouve peu attrayant «l'amphibien», c'est comme essayer de s'asseoir sur deux (et avec le SEO — trois) chaises. Mieux vaut être comme Fiona de Shrek — le jour une, et la nuit une autre. Oui, c’est plus cher. Mais c’est mieux.

Partage croisé

J'ai déjà mentionné dans le point « Scalabilité Inversée » que la mondialité du réseau permet d'avoir une seule application web pour la planète. Par conséquent, chaque application web doit se différencier des autres pour assurer sa survie. Néanmoins, mon expérience de plusieurs années avec Magento (un cadre pour la construction de magasins e-commerce) montre qu'il peut y avoir plus de points communs entre différentes applications web que de différences. Une belle application web doit non seulement être modulaire, mais elle doit également partager ses modules avec d'autres applications web. Dans une certaine mesure, cette idée est reflétée dans . En alternative à la lecture de la norme, vous pouvez étudier le code source de la fonction JSR 168 et JSR 286 et des frameworks comme WordPress, Django et le même Magento. Plus un grand nombre de modules d'une application web est utilisé par d'autres applications web, plus elle est belle à mes yeux. Le partage croisé permet de créer des modules de meilleure qualité et, par conséquent, des applications web plus stables.

Par module, je n’entends pas des bibliothèques comme jQuery ou RequireJS, mais plutôt des entités plus volumineuses, comme des plugins dans WordPress et Django. Cependant, pour les bibliothèques, il est également vrai qu'une large diffusion d'une bibliothèque permet de la rendre plus qualitative et robuste.

L'architecture de Harvard

L'architecture de Harvard, contrairement à l'actuelle architecture de Princeton, implique la séparation du code et des données. Cette architecture n'a pas réussi à s'imposer, mais l'idée elle-même me semble belle. Surtout pour les applications web. Toute la statique (HTML/CSS/JS/Images/…) est du code. Il peut et doit être mis en cache, que ce soit côté serveur ou côté client. Et les données sont(belles) ou REST/JSON SOAP (un peu moins belles). Ou WebSockets/JSON (qui pourrait être la meilleure option, mais je ne l'ai pas essayé)./colonnes Il y a deux choses qui me préoccupent particulièrement lors du développement d'applications web : l'interface multilingue et les fuseaux horaires. Je viens moi-même de Lettonie, où trois langues sont couramment utilisées : LV, RU, EN. Une belle application web doit non seulement permettre d'utiliser plusieurs langues au sein de l'application, mais aussi élargir le nombre de langues utilisées grâce à des ressources externes, comme

Localisation

Crowdin . Cela vaut également pour les modules dont est constituée l'application web.. Cela est également vrai pour les modules qui composent une application web.

Avec les fuseaux horaires, c'est simple : dans tous les cas où il n'est pas clair comment traiter la date et l'heure, faites comme suit : tout ce qui est sur le serveur, qui part du serveur et arrive du serveur — UTC, tout ce qui s'affiche pour le client — selon le fuseau horaire du profil utilisateur. C'est élégant.

Forgerons plutôt que « Étoiles de la Mort »

Il y a longtemps, dans chaque ville plus ou moins grande, il y avait sa propre forge. Peut-être même plusieurs. Certaines meilleures, d'autres moins bonnes. Il y avait des maîtres forgerons connus dans le monde entier, et il y en avait d'autres à qui l'on s'adressait par manque d'alternatives. Des guerres, des épidémies, des catastrophes naturelles ont ravagé les régions. Certaines villes ont disparu avec leur population. Mais l'art de la forge a continué à vivre. De nouvelles villes ont été construites à la place des villes disparues, et des forges y apparaissaient également.

Maintenant, regardez un service tel que DNS. Quand les serveurs racines tombent, c'est tout le monde qui est en émoi.

À mon avis, une belle application web ne peut pas avoir la taille de Facebook ou Mail.ru. Cela s'apparente plutôt à une «Étoile de la Mort» tant en ressources nécessaires pour la construire qu'en ressources nécessaires pour maintenir son fonctionnement. Oui, en cas de destruction de Facebook, l'humanité ne disparaîtra pas, ses fonctions seront rapidement reprises par d'autres applications (la même VK sur le territoire de la Russie et des régions voisines, Instagram, Twitter, …). Néanmoins, enfermer une partie significative de la population de la planète sur une seule application — c'est inesthétique. D'autant plus qu'il existe des alternatives beaucoup plus robustes (comme les torrents).

Résumé

Si vous avez lu jusqu'à la fin et ressentez de la confusion — «qu'est-ce que c'était ?», je vous exprime mes sincères condoléances. Je ne vous ai pas obligé à lire cela. J'ai simplement essayé de mettre mes pensées en mots pour trouver ceux qui pensent de la même manière. Peut-être pourrais-je discuter avec eux de certains aspects de la création d'applications web attrayantes et trouver des réponses à mes questions. Et j'en ai beaucoup.

Merci d'avoir lu.

Source : habr.com