Un petit partage ; mes connaissances sont limitées, juste un modeste aiguillon pour inciter d'autres personnes à apporter de précieuses contributions.

Ajax

En 2003, j'étais en sixième. À cette époque, les cybercafés commençaient tout juste à apparaître dans les coins des petites villes de comté. The Legend of Mir, Westward Journey Online et d'autres jeux en ligne de première génération faisaient fureur. J'ai donné deux yuans au patron du cybercafé, pensant que j'allais essayer et créer un compte pour jouer. Puis, pendant l'heure suivante, je suis resté bloqué sur la création d'un compte.

À cette époque, le cybercafé avait une bande passante de 512k. Pendant l'inscription, j'ai rempli un tas d'informations, j'ai validé, la page a sauté, boum : « Les informations que vous avez saisies sont incorrectes, veuillez les remplir à nouveau. » Puis elle est revenue à la page d'inscription, et cette boucle s'est répétée. Je pense souvent aujourd'hui : si AJAX avait été répandu à l'époque, j'aurais pu économiser deux yuans.

Alors, qu'est-ce qu'AJAX ?

Tout d'abord, AJAX est une technologie. Dans les anciens modèles d'interaction web, après qu'un utilisateur avait cliqué sur un bouton, comme un bouton d'envoi, il devait attendre un long échange de données avec le serveur, pendant lequel il ne pouvait rien faire d'autre que fumer une cigarette. Ce que fait AJAX, c'est que, lorsqu'on envoie une requête au serveur, on n'a pas besoin d'attendre le résultat ; on peut plutôt faire d'autres choses en même temps, et lorsque le résultat arrive, on peut revenir le traiter.

En fait, la technologie AJAX avait déjà été implémentée par Microsoft dès 1998. Cependant, ce n'est qu'en février 2005, lorsque Jesse James Garrett d'Adaptive Path a publié l'article « Ajax: A New Approach to Web Applications », et que les gens l'ont lu et ont pensé : « Oh, pas mal, c'est génial », qu'AJAX a été largement adopté à grande échelle.

L'apparition d'AJAX a grandement amélioré l'expérience utilisateur du web. À ce jour, quel que soit le retard du développement informatique national, la connexion et l'inscription sur tous les sites web ont mis en œuvre une interaction AJAX. Une fois que les utilisateurs ont fini de remplir les informations, ils peuvent savoir si l'envoi a réussi sans rafraîchir la page, et corriger là où se trouvent les erreurs.

De plus, AJAX, en tant que solution de séparation du front-end et du back-end, a été adopté par la plupart des entreprises nationales qui ne sont pas trop médiocres, et il a indirectement conduit au déclin des langages de script web tels que PHP.

jQuery

Au début de la programmation JavaScript, l'efficacité du code était extrêmement faible, en particulier dans la manipulation du DOM. Si un développeur voulait ajouter un événement à un bouton, il devait écrire un long morceau de code répétitif pour récupérer le bouton, puis un autre long morceau de code répétitif pour ajouter l'événement. Bien que les développeurs chevronnés encapsulent les opérations courantes, pour les novices qui ne pouvaient pas les encapsuler, c'était sans aucun doute une chose douloureuse, surtout lorsqu'on y ajoutait toutes sortes de problèmes de compatibilité entre navigateurs.

En 2006, dans le but d'épargner les débutants et de leur permettre de « faire plus », jQuery est né. L'importance de la naissance de jQuery résidait d'abord dans le fait qu'il assurait la compatibilité avec IE6, 7, 8 et divers navigateurs qui se partageaient le marché ; ensuite, il simplifiait grandement les opérations DOM et améliorait considérablement l'efficacité du développement. jQuery était si populaire que certains développeurs front-end ne savaient écrire que du jQuery et non du JavaScript natif. Aujourd'hui encore, il n'est pas exagéré de dire que jQuery « s'écrit une fois, se voit partout ».

Une autre importance de jQuery (selon moi) est qu'il a catalysé l'intérêt et l'exploration du front-end. Comparé à Linux, à très faible coût, on pouvait écrire un effet qui faisait dire à une fille ne connaissant rien à la programmation : « Oppa, tu gères ! », donnant aux gens l'impression : « Ah (encore), pas mal, c'est génial. » Par la suite, de nombreuses bibliothèques et plugins basés sur jQuery ont surgi comme des champignons après la pluie. L'industrie du front-end était florissante et prospère, et le développement web est entré dans une nouvelle ère.

Chrome

Tous les arts martiaux sous le ciel viennent de Google. À l'époque d'IE6, 7, 8, bien que Firefox contestait aussi lentement la position d'IE, il était loin d'être à la hauteur de l'impact perturbateur de Chrome, que Google a commencé à promouvoir en 2009. Chrome utilisait le moteur open source d'Apple, WebKit, avec de bonnes normes de conception et une bonne réponse du marché ; il a favorisé une itération rapide des navigateurs et a fait complètement disparaître IE dans Windows 10.

Le lancement du navigateur Chrome a encore simplifié le seuil d'entrée dans le développement front-end. Ses outils de débogage intégrés sont faciles à utiliser et à l'épreuve des erreurs. Nous pouvons facilement consulter l'état du réseau, l'ordre de chargement, effectuer du débogage par points d'arrêt, etc. En même temps, la fonctionnalité de plugins de Google offre une grande commodité aux développeurs.

Actuellement, la dernière version de Chrome a commencé à utiliser le moteur Blink. Dans les versions de test, il peut déjà suivre et déboguer les animations CSS3. Avant même que je ne l'imagine, Chrome l'avait déjà implémenté.

En une phrase : sans Chrome, il n'y aurait pas de nouvelle Chine, et nous ne pourrions utiliser que Firefox.

GitHub

Avec l'accélération de l'itération des projets logiciels, les outils de gestion de versions de projet ont également évolué en continu, passant par CVS, SVN et GIT. À ce jour, CVS a presque disparu de l'industrie internet, SVN subsiste pour le stockage de fichiers et de documents, et GIT, l'outil de gestion de versions créé par Linus, l'inventeur du noyau Linux, est désormais la norme pour la gestion de versions de code. GitHub, s'appuyant sur Git, est devenu une communauté de collaboration pour les équipes de développeurs ! En janvier 2015, GitHub comptait plus de dix millions de développeurs enregistrés et des dizaines de millions de projets open source. Parmi eux, les développeurs chinois ont connu la croissance la plus rapide sur GitHub en 2014. Vous pouvez y trouver presque n'importe quel code que vous voulez... par exemple, nom d'utilisateur..mot de passe..

OAUTH

La différence entre OAuth1 ou OAuth2 et les méthodes d'autorisation précédentes est que l'autorisation OAuth ne permet pas à des tiers de toucher aux informations de compte de l'utilisateur (comme le nom d'utilisateur et le mot de passe).
Contexte : dans le scénario de service le plus courant, un utilisateur doit utiliser les services de deux entreprises différentes : se connecter et s'authentifier auprès de l'entreprise A pour télécharger du contenu ; puis se connecter et s'authentifier auprès de l'entreprise B pour téléverser du contenu vers le service de l'entreprise B, ce qui est complexe et chronophage. Qu'il s'agisse de l'utilisateur ou des entreprises A et B, tous souhaitent des services interopérables. Cela crée la nécessité de vérifier l'identité. L'ancien mécanisme nom d'utilisateur/mot de passe donnerait à l'entreprise A ou B la permission de consulter, voire de modifier, les ressources utilisateur de l'autre partie. Afin de confirmer l'identité et de permettre l'interopérabilité des services, Google, Yahoo et Microsoft ont été les premiers à promouvoir la création d'OAuth 1.0. Par la suite, OAuth 2.0 a été un nouveau projet des grandes entreprises internet reposant sur la sécurité HTTPS.

Actuellement, le scénario d'application le plus courant est principalement la connexion par autorisation, comme WeChat, QQ, Weibo, etc.

JSON

Bien que JSON soit une norme apparue dès 2001, il n’a été largement utilisé qu’après 2008, après la popularisation de diverses applications AJAX, de l’iPhone et des appareils Android. Les anciens systèmes de services étaient pour la plupart de niveau entreprise, de sorte que XML était avantageux pour un positionnement de services de niveau entreprise de style Java. Mais pour les services API avec des contraintes de trafic et une sémantique simple, XML est encombrant, redondant, difficile à apprendre et consomme de la bande passante.

L’année dernière, alors que je venais de commencer à travailler, le backend m’a renvoyé un tableau. Sans avoir mon mot à dire, j’ai longtemps hésité entre parcourir le tableau et le convertir au format JSON.

La popularité de JSON, sous un autre angle, reflète un avantage du développement web : peu importe que votre backend soit en Java, Ruby, PHP ou Python, tant que vous me donnez une interface au format JSON, je peux soulever la terre entière.

DJANGO&RAILS

Le développement agile a bouleversé le modèle de R&D des projets. À l’ère du WEB 2.0 après 2010, HTML5 a prévalu, le travail front-end a été séparé, et les avantages des scripts web comme PHP n’étaient plus aussi évidents, bien qu’il ait encore des avantages dans les CMS et les modèles de forums. Le plus grand avantage de Django et Rails est qu’ils permettent à un individu ou à une petite équipe de deux ou trois personnes de mettre en œuvre un produit complet. Prenons Instagram comme exemple : au départ, deux ingénieurs Python ont utilisé Django pour implémenter rapidement toutes les fonctions côté serveur, et lorsque la croissance des utilisateurs s’est produite, ils ont séparé les services à fort trafic et à gros volume de données.

Malgré la réalité cruelle et le déclin de Rails jour après jour, savoir lequel d’IE8 ou de Rails disparaîtra en premier n’est qu’une question de temps, mais les solutions qu’il a fournies sont encore imitées par de nombreuses jeunes générations. Les gens se souviendront de cette brève floraison.

Bootstrap

En 2011, Twitter a ouvert le code source d’un framework d’interface graphique web. jQuery gérait la compatibilité JavaScript entre les différents navigateurs, tandis que Bootstrap gérait la compatibilité CSS entre les différents navigateurs. On est arrivé au point où, en tant que développeur back-end, vous n’aviez pas besoin de comprendre le CSS, pas besoin de développeur front-end, pas besoin de designer ; tant que vous consultiez la documentation de Bootstrap, vous pouviez construire un système de gestion back-end beau et élégant. Parmi les frameworks d’interface graphique courants similaires, citons Foundation de Zurb et Materialize de Google. Baidu a aussi un jour publié un framework mobile appelé GMU.

Pour ma part, je n’aime pas ces frameworks d’interface graphique, même s’ils simplifient le CSS et permettent d’obtenir des effets sympas, même si je les ai utilisés dans des projets, même si je ne veux pas admettre que je suis une « green tea » (une hypocrite). Le plus grand défaut de ces frameworks est qu’ils se ressemblent tous. Toutes les pages se ressemblent : la même barre de navigation, la même barre latérale, les mêmes formulaires, et même la même lueur lorsque vous passez la souris dessus. C’est comme si j’avais trois jambes (même si j’en ai effectivement trois), les gens diraient que je suis unique et que mon apparence fait briller leurs yeux. Mais si tout le monde avait trois jambes, le web perdrait son charme. Un autre défaut est la lourdeur : un seul fichier CSS utilise plus de 100 KB de trafic, et la plupart de ses plugins JS dépendent de jQuery. Pouvez-vous le supporter ?

Bien sûr, l’idée d’un HTML basé sur une grille proposée pour résoudre le responsive design mérite encore d’être étudiée.

La popularité des systèmes IOS & ANDROID

Après 2009, le développement rapide d’iOS et d’Android a entraîné les changements suivants dans le développement web :
1. HTML5 a d’abord été implémenté sur les navigateurs mobiles. Les appareils Android et iOS prenaient pleinement en charge HTML5 et CSS3, ce qui a accéléré la disparition d’IE.
2. L’accès à Internet se fait n’importe quand, n’importe où. Les pages web axées sur le clic de souris et riches en contenu sont devenues de plus en plus concises, et le responsive design est rapidement devenu populaire.
3. L’interaction entre les applications et les serveurs repose principalement sur le protocole HTTP, comme pour les pages web. Les concepts d’application web et d’application hybride ont été proposés.

Concernant l’application web, je vais ici parler brièvement des avantages du web par rapport au natif.

• Multiplateforme : le fameux « compiler une fois, exécuter partout ».
• Sans installation : ouvrez le navigateur et utilisez-le.
• Déploiement rapide : les mises à niveau nécessitent uniquement la mise à jour du code sur le serveur, contrairement aux applications clientes qui ont besoin de mises à jour de version.
• Hyperliens : peuvent s’interconnecter avec d’autres sites web et peuvent être indexés par les moteurs de recherche.

Cela semble impressionnant, mais ces avantages ne résistent pas à l’examen. Premièrement, les utilisateurs de différents systèmes ont des habitudes différentes : les utilisateurs d’iOS sont habitués au bouton retour dans le coin supérieur gauche, tandis que les utilisateurs d’Android y sont habitués en bas de l’écran. Le chef de produit demande : alors, où faut-il le placer ? Héhé, je ne sais pas. Deuxièmement, j’ai vu un jour un rapport d’enquête demandant aux utilisateurs s’ils préfèrent utiliser un client ou le web.

Bien plus d’utilisateurs préfèrent le client au web. Demandez-moi ce que j’aime, je préfère aussi le client. Demandez-moi pourquoi, je sens que cela me donne un sentiment de sécurité, et les mises à jour de version me font me sentir bien et me donnent un sentiment de présence, me faisant savoir que je n’ai pas été oublié par le monde, me faisant savoir que votre produit est mis à jour et que vous vous souciez de moi. Aussi, les hyperliens... pourquoi un client aurait-il besoin de SEO ? Et ce n’est pas tout ; les applications web ont une foule d’autres inconvénients. Le plus gros est l’absence d’accélération GPU. Mettre en œuvre une animation quelque peu complexe est un vrai calvaire pour le navigateur. Deuxièmement, les pages web sont mono-thread ; le chargement du DOM bloque JavaScript, ce qui provoque des ralentissements. Les ralentissements entraînent de l’agacement, l’agacement entraîne la fermeture de la page, et le nombre d’utilisateurs diminue d’un.

Le hybride est différent. Une application hybride désigne une application native mixte qui place les pages fréquemment mises à jour en tant que contenu web sur un serveur distant pour les mises à jour. C’est une solution fiable. BAT a de nombreux cas, comme le JS SDK publié par WeChat, Baidu Mobile, et la version Android du client Taobao.

Bien sûr, il y a beaucoup de pièges ici. Si j’en ai l’occasion, je vous raconterai les pièges dans lesquels je suis tombé.

NodeJS

J’ai longtemps hésité à savoir si Node appartient au domaine du front-end. Je pense que oui.

Résoudre la haute concurrence a toujours été un sujet que les ingénieurs backend adorent aborder. Par exemple, dans notre système de surveillance en temps réel, en théorie chaque connexion génère un nouveau thread, et chaque nouveau thread peut avoir besoin de 2 MB de mémoire de support. Sur un système avec 8 GB RAM, le nombre théorique maximal de connexions simultanées est de 4,000 utilisateurs. À mesure que le nombre d’utilisateurs augmente, nous voulons que le programme de surveillance prenne en charge davantage d’utilisateurs, ce qui signifie ajouter plus de serveurs. Bien sûr, cela augmente les coûts opérationnels, en particulier les coûts de serveur. Outre la hausse des coûts, il y a aussi un problème technique : les utilisateurs peuvent utiliser différents serveurs pour chaque requête, donc toute ressource partagée doit être partagée entre tous les serveurs. À ce stade, la technologie atteint un goulot d’étranglement. Node est né à l’origine pour résoudre ce problème. La solution de Node consiste à changer la manière dont les connexions sont établies avec le serveur. Au lieu de générer un nouveau thread OS pour chaque connexion et de lui allouer de la mémoire de support, chaque connexion émet un événement qui s’exécute dans le processus du moteur Node.

Node.js est un langage côté serveur. Dans le mouvement d’enclosure de séparation du front-end et du back-end, c’est une arme puissante pour le front-end. En même temps, il fournit un grand nombre d’outils programmables pour l’automatisation du front-end (grunt, bower, gulp, etc.). Taobao et Baidu ont toujours été enthousiastes à l’égard de Node.js, donc naturellement je pense qu’il s’agit d’une tendance. L’année dernière, Meituan a créé une équipe Meituan Hotel et a choisi Node comme langage back-end, en prenant en charge la plupart du travail back-end. Je me demande : avec le JS front-end plus Node plus l’exigence de compétences UI, les ingénieurs front-end devraient-ils maintenant être appelés ingénieurs full-end ?

BIG DATA

Le big data est probablement le terme le plus en vogue de ces dernières années. Un tas de mes camarades de classe, en entendant que l’exploration de données rapporte un salaire annuel de 300,000, sont partis en hurlant travailler sur des bases de données.
La plupart du temps, quand nous parlons de big data, nous parlons en réalité d’exploration de données, d’analyse de données, de recommandation intelligente, d’analyse en temps réel, etc., sur des quantités massives de données. Les entreprises ont des solutions techniques différentes. Je ne citerai que deux cas nationaux réussis :
• Le e-commerce personnalisé de JD.com, avec des scénarios incluant des dimensions telles que le comportement, les préférences, la localisation, le temps et les relations d’amitié ; recommander différents produits à différents utilisateurs ; et différents utilisateurs voyant différents classements de produits dans la recherche...
• La carte des migrations de Dongguan sur 8 heures de Baidu Maps ; les rappels intelligents de Baidu Search
• La fonction anti-harcèlement des numéros de téléphone de 360 Mobile Guard sélectionne les 1,000 numéros les plus pertinents pour l’utilisateur parmi les 256 million de numéros de téléphone marqués, en fonction de la région, de l’identité et des tendances de harcèlement de l’utilisateur, et les écrit dans un fichier texte 10k sur le téléphone de l’utilisateur, afin d’assurer une protection anti-harcèlement sans se connecter à Internet ni effectuer d’interaction réseau.

HTML5+CSS3

C’est un terme dont on a parlé jusqu’à plus soif ces dernières années. Tout le monde parle de HTML5 ; si vous leur demandez ce qu’est HTML5, ils ne savent pas l’expliquer clairement. C’est juste cool, juste tape-à-l’œil, juste cool et tape-à-l’œil.

À mon avis, HTML5 n’est qu’une chose concrétisée par des on-dit répétés. Il attire bien plus l’attention que les fonctionnalités qu’il apporte. HTML5 ne fournit que quelques nouvelles API, comme une application qui passe de la version 1.0 à 2.0 en ajoutant une fonctionnalité « Personnes à proximité ». De plus, ses API ne font que tâter le terrain sur mobile. Côté PC, en raison de problèmes de compatibilité, il n’a jamais été officiellement accepté. Le développement côté PC repose encore sur HTML 4.0 + CSS 2 avec amélioration progressive. Quant à CSS3, sa fonctionnalité d’animation la plus suivie est aussi quelque chose que Flash a déjà laissé derrière lui.

Le développement rapide du mobile a catalysé le développement de HTML5, et le développement de HTML5 a en retour poussé les navigateurs vers la standardisation.

Sur ce chemin vers la standardisation, WeChat a joué un rôle indispensable. Des pages telles que « 1024 », « Encercler le chat névrosé », « Décennie Taobao » et « LEXUS NX », qui intègrent un grand nombre d’éléments HTML5+CSS3, sont impressionnantes.

De plus, Microsoft a abandonné le nom de code IE et a développé Edge. Les navigateurs de divers fabricants se standardisent continuellement, le projet HTML5 a été finalisé, et le projet ES6 est continuellement implémenté et amélioré. La route à venir pour le front-end ressemble à une large route ouverte, et je suis plein d’anticipation.

Future

Jeux 3D dans le navigateur ? WebOS ? Réalité virtuelle ?

Enfin, avec l’amélioration des performances matérielles des utilisateurs, une bande passante réseau toujours plus grande, les systèmes de capteurs, Retina, et la maturité croissante de la technologie WebGL, ainsi que le développement florissant de l’O2O, tout cela deviendra-t-il réalité ?

Source : http://www.cnblogs.com/sussski/p/4634595.html