Zehn Jahre Entwicklung der Webtechnologie

Ein kleiner Beitrag; mein Wissen ist begrenzt, nur ein bescheidener Anstoß, andere dazu zu bewegen, mit wertvollen Beiträgen hervorzutreten.

Ajax

Im Jahr 2003 war ich in der sechsten Klasse. Damals entstanden Internetcafés gerade in den Ecken kleiner Kreisstädte. The Legend of Mir, Westward Journey Online und andere Online-Spiele der ersten Generation waren der letzte Schrei. Ich gab dem Besitzer des Internetcafés zwei Yuan und dachte, ich probiere es mal aus und registriere ein Konto, um zu spielen. Dann steckte ich die nächste Stunde damit fest, ein Kon-to zu re-gis-trie-ren.

Damals hatte das Internetcafé eine Bandbreite von 512k. Bei der Registrierung füllte ich einen Haufen Informationen aus, schickte sie ab, die Seite sprang, bumm: „Die von dir eingegebenen Informationen sind falsch, bitte fülle sie erneut aus.“ Dann sprang sie zurück zur Registrierungsseite, und diese Schleife wiederholte sich. Ich denke jetzt oft: Wenn AJAX damals weit verbreitet gewesen wäre, hätte ich zwei Yuan sparen können.

Also, was ist AJAX?

Zunächst einmal ist AJAX eine Technologie. In früheren Web-Interaktionsmodellen musste der Benutzer, nachdem er auf eine Schaltfläche geklickt hatte, z. B. auf eine Absende-Schaltfläche, einen langen Datenaustausch mit dem Server abwarten, während dessen er nichts anderes tun konnte, als sich eine Zigarette anzuzünden. Was AJAX macht, ist: Wenn wir eine Anfrage an den Server senden, müssen wir nicht auf das Ergebnis warten; stattdessen können wir gleichzeitig andere Dinge tun, und wenn das Ergebnis eintrifft, können wir zurückkommen und es bearbeiten.

Tatsächlich wurde die AJAX-Technologie bereits 1998 von Microsoft implementiert. Sie wurde jedoch erst im Februar 2005, als Jesse James Garrett von Adaptive Path den Artikel „Ajax: A New Approach to Web Applications“ veröffentlichte und die Leute ihn lasen und dachten: „Oh, nicht schlecht, das ist großartig“, in großem Umfang übernommen.

Die Entstehung von AJAX hat die Benutzererfahrung im Web stark verbessert. Bis heute, egal wie rückständig die inländische IT-Entwicklung ist, haben alle Websites die AJAX-Interaktion für Anmeldung und Registrierung implementiert. Nachdem Benutzer die Informationen ausgefüllt haben, können sie wissen, ob die Übermittlung erfolgreich war, ohne die Seite neu zu laden, und Fehler dort korrigieren, wo sie sind.

Darüber hinaus wurde AJAX als Lösung zur Trennung von Frontend und Backend von den meisten inländischen Unternehmen, die nicht zu primitiv sind, übernommen und hat indirekt zum Niedergang von Web-Skriptsprachen wie PHP beigetragen.

jQuery

In der frühen JavaScript-Programmierung war die Code-Effizienz extrem niedrig, besonders bei der DOM-Manipulation. Wenn ein Entwickler einer Schaltfläche ein Ereignis hinzufügen wollte, musste er ein langes, sich wiederholendes Stück Code schreiben, um die Schaltfläche zu holen, und dann noch ein langes, sich wiederholendes Stück Code, um das Ereignis hinzuzufügen. Obwohl erfahrene Entwickler gängige Operationen kapselten, war dies für Anfänger, die nicht kapseln konnten, zweifellos eine schmerzhafte Sache, besonders in Kombination mit all den Browser-Kompatibilitätsproblemen.

Im Jahr 2006, mit dem Ziel, Neulinge zu schonen und sie „mehr machen“ zu lassen, wurde jQuery geboren. Die Bedeutung von jQuerys Geburt war erstens, dass es die Kompatibilität mit IE6, 7, 8 und verschiedenen Browsern herstellte, die den Markt aufteilten; zweitens vereinfachte es DOM-Operationen erheblich und verbesserte die Entwicklungseffizienz stark. jQuery war so populär, dass einige Frontend-Entwickler nur jQuery und kein natives JavaScript schreiben konnten. Bis heute ist es keine Übertreibung zu sagen, jQuery „einmal schreiben, überall sehen.“

Eine weitere Bedeutung von jQuery (meiner Meinung nach) ist, dass es die Neugier und Erkundung des Frontends bei den Leuten katalysierte. Im Vergleich zu Linux konnte man mit sehr geringen Kosten einen Effekt schreiben, der ein Mädchen, das nichts über Programmierung wusste, dazu brachte zu sagen: „Oppa, du bist der Hammer!“, wodurch Leute dachten: „Oh (wieder mal), nicht schlecht, das ist großartig.“ Danach schossen zahlreiche Bibliotheken und jQuery-basierte Plugins wie Bambussprossen nach dem Regen aus dem Boden. Die Frontend-Branche blühte und gedieh, und die Webentwicklung trat in eine neue Ära ein.

Chrome

Alle Kampfkünste unter dem Himmel stammen von Google. In der Ära von IE6, 7, 8, obwohl Firefox auch langsam IEs Position herausforderte, war es dem disruptiven Einfluss von Chrome, den Google 2009 zu fördern begann, weit unterlegen. Chrome verwendete Apples Open-Source-Engine WebKit, mit guten Designstandards und Marktreaktion; es förderte schnelle Browser-Iterationen und ließ IE in Windows 10 vollständig verschwinden.

Die Einführung des Chrome-Browsers vereinfachte die Einstiegshürde für die Frontend-Entwicklung weiter. Seine integrierten Debugging-Tools sind benutzerfreundlich und idiotensicher. Wir können problemlos den Netzwerkstatus, die Lade-Reihenfolge einsehen, Breakpoint-Debugging durchführen usw. Gleichzeitig bietet Googles Plugin-Funktion Entwicklern großen Komfort.

Derzeit hat die neueste Version von Chrome begonnen, die Blink-Engine zu verwenden. In Testversionen kann sie bereits CSS3-Animationen verfolgen und debuggen. Bevor ich es mir überhaupt vorgestellt hatte, hatte Chrome es bereits umgesetzt.

In einem Satz: Ohne Chrome gäbe es kein neues China, und wir könnten nur Firefox verwenden.

GitHub

Mit der beschleunigten Iteration von Softwareprojekten haben sich auch Projekt-Versionskontrollwerkzeuge kontinuierlich weiterentwickelt und durchliefen CVS, SVN und GIT. Bisher ist CVS aus der Internetbranche fast verschwunden, SVN existiert für die Datei- und Dokumentenspeicherung, und GIT, das von Linux-Kernel-Erfinder Linus entwickelte Versionskontrollwerkzeug, ist heute der Standard für die Codeversionierung. GitHub, das auf Git aufbaut, ist zu einer Community für die Zusammenarbeit von Entwicklerteams geworden! Stand Januar 2015 verfügte GitHub über mehr als zehn Millionen registrierte Entwickler und Dutzende Millionen Open-Source-Projekte. Darunter wuchsen chinesische Entwickler im Jahr 2014 auf GitHub am schnellsten. Dort findet man fast jeden Code, den man sucht... z. B. Benutzername..Passwort..

OAUTH

Der Unterschied zwischen OAuth1 oder OAuth2 und früheren Autorisierungsmethoden besteht darin, dass die OAuth-Autorisierung Dritten nicht erlaubt, auf die Kontoinformationen des Benutzers zuzugreifen (wie Benutzername und Passwort).
Hintergrund: Im gängigsten Service-Szenario muss ein Benutzer Dienste von zwei verschiedenen Unternehmen nutzen: sich bei Unternehmen A anmelden und authentifizieren, um Inhalte herunterzuladen; dann sich bei Unternehmen B anmelden und authentifizieren, um Inhalte in den Dienst von Unternehmen B hochzuladen, was komplex und zeitaufwändig ist. Ob der Benutzer oder die Unternehmen A und B – sie alle wünschen sich interoperable Dienste. Daraus entsteht die Notwendigkeit, die Identität zu überprüfen. Der alte Benutzername/Passwort-Mechanismus würde Unternehmen A oder B die Berechtigung geben, die Benutzerressourcen der anderen Partei einzusehen oder sogar zu ändern. Um die Identität zu bestätigen und die Interoperabilität der Dienste zu ermöglichen, trieben Google, Yahoo und Microsoft die Entwicklung von OAuth 1.0 maßgeblich voran. Später war OAuth 2.0 ein neuer Plan großer Internetunternehmen auf Basis der HTTPS-Sicherheit.

Derzeit ist das häufigste Anwendungsszenario hauptsächlich die Autorisierungsanmeldung, wie z. B. WeChat, QQ, Weibo usw.

JSON

Obwohl JSON ein Standard ist, der bereits 2001 entstand, wurde es erst nach 2008 weitverbreitet genutzt, nachdem verschiedene AJAX-Anwendungen, iPhone- und Android-Geräte populär geworden waren. Die alten Servicesysteme waren meist unternehmensweit, daher war XML vorteilhaft für die Positionierung von Services im Java-Stil auf Unternehmensebene. Doch für API-Services mit Verkehrsbeschränkungen und einfacher Semantik ist XML sperrig, redundant, schwer zu erlernen und verbraucht Bandbreite.

Letztes Jahr, als ich gerade erst angefangen hatte zu arbeiten, gab mir das Backend ein Array zurück. Ohne Mitspracherecht kämpfte ich lange damit, ob ich über das Array iterieren oder es in das JSON-Format konvertieren sollte.

Die Beliebtheit von JSON spiegelt aus einem anderen Blickwinkel einen Vorteil der Webentwicklung wider: Egal, ob dein Backend Java, Ruby, PHP oder Python ist, solange du mir eine Schnittstelle im JSON-Format gibst, kann ich die ganze Erde stemmen.

DJANGO&RAILS

Agile Entwicklung brach das F&E-Modell für Projekte. In der WEB-2.0-Ära nach 2010 setzte sich HTML5 durch, die Frontend-Arbeit wurde ausgelagert, und die Vorteile von Webskripting wie PHP waren nicht mehr so offensichtlich, obwohl es immer noch Vorteile bei CMS- und Forenvorlagen hatte. Der größte Vorteil von Django und Rails ist, dass sie es einer Einzelperson oder einem kleinen Team von zwei oder drei Leuten ermöglichen, ein vollständiges Produkt umzusetzen. Nehmen wir Instagram als Beispiel: Anfangs setzten zwei Python-Ingenieure Django ein, um schnell alle serverseitigen Funktionen umzusetzen, und als das Nutzerwachstum eintrat, lagerten sie Dienste mit großem Traffic und großem Datenvolumen aus.

Trotz der grausamen Realität und des täglichen Niedergangs von Rails ist es nur eine Frage der Zeit, ob IE8 oder Rails zuerst verschwindet, aber die Lösungen, die es bot, werden noch von vielen jüngeren Generationen nachgeahmt. Die Menschen werden sich an diese kurze Blüte erinnern.

Bootstrap

2011 stellte Twitter ein Web-GUI-Framework als Open Source bereit. jQuery kümmerte sich um die JavaScript-Kompatibilität über verschiedene Browser hinweg, während Bootstrap die CSS-Kompatibilität über verschiedene Browser hinweg übernahm. Es ging so weit, dass man als Backend-Entwickler kein CSS verstehen musste, keinen Frontend-Entwickler brauchte, keinen Designer brauchte; solange man die Dokumentation von Bootstrap ansah, konnte man ein schönes und elegantes Backend-Verwaltungssystem bauen. Ähnliche gängige GUI-Frameworks sind Zurb's Foundation und Google's Materialize. Baidu veröffentlichte außerdem einmal ein mobiles Framework namens GMU.

Für mich persönlich mag ich diese GUI-Frameworks nicht, obwohl sie CSS vereinfachen und einige coole Effekte erzielen, obwohl ich sie in Projekten verwendet habe, obwohl ich nicht zugeben möchte, dass ich ein „grüner Tee“ (Heuchler) bin. Der größte Nachteil dieser Frameworks ist, dass sie alle gleich sind. Alle Seiten sehen gleich aus: dieselbe Navigation, dieselbe Sidebar, dieselben Formulare und sogar dasselbe Leuchten, wenn man mit der Maus darüberfährt. Es ist, als hätte ich drei Beine (obwohl ich tatsächlich drei Beine habe), würden die Leute sagen, ich sei einzigartig und mein Aussehen bringe ihre Augen zum Leuchten. Aber wenn jeder drei Beine hätte, würde das Web seinen Charme verlieren. Ein weiterer Nachteil ist die Aufblähung: Eine einzige CSS-Datei verbraucht über 100 KB Traffic, und die meisten ihrer JS-Plugins hängen von jQuery ab. Kannst du das ertragen?

Natürlich ist die Idee von rasterbasiertem HTML, die zur Lösung von Responsive Design vorgeschlagen wurde, immer noch nachahmenswert.

Die Popularität von IOS- & ANDROID-Systemen

Nach 2009 führte die rasante Entwicklung von iOS und Android zu folgenden Veränderungen in der Webentwicklung:
1. HTML5 wurde zuerst in mobilen Browsern implementiert. Android- und iOS-Geräte unterstützten HTML5 und CSS3 vollständig, wodurch das Verschwinden von IE beschleunigt wurde.
2. Internetzugang erfolgt jederzeit und überall. Mausklick-orientierte, inhaltsreiche Webseiten wurden zunehmend prägnanter, und Responsive Design wurde schnell populär.
3. Die Interaktion zwischen Apps und Servern basiert größtenteils auf dem HTTP-Protokoll wie bei Webseiten. Die Konzepte Webapp und Hybrid-App wurden vorgeschlagen.

Was Webapp betrifft, werde ich hier kurz die Vorteile des Webs im Vergleich zu nativen Apps erläutern.

Plattformübergreifend: das oft gesagte "einmal kompilieren, überall ausführen".
Installationsfrei: Browser öffnen und nutzen.
Schnelle Bereitstellung: Bei Upgrades muss nur der Code auf dem Server aktualisiert werden, anders als bei Client-Apps, die Versionsupdates benötigen.
Hyperlinks: können mit anderen Websites verknüpft werden und von Suchmaschinen indexiert werden.

Klingt beeindruckend, aber diese Vorteile halten einer genaueren Prüfung nicht stand. Erstens haben Nutzer verschiedener Systeme unterschiedliche Gewohnheiten: iOS-Nutzer sind an die Zurück-Schaltfläche oben links gewöhnt, während Android-Nutzer gewohnt sind, sie unten auf dem Bildschirm zu haben. Der Produktmanager fragt: Wo soll sie also platziert werden? Hehe, ich weiß es nicht. Zweitens habe ich einmal einen Umfragebericht gesehen, in dem Nutzer gefragt wurden, ob sie lieber einen Client oder das Web verwenden.

Deutlich mehr Nutzer bevorzugen den Client gegenüber dem Web. Frag mich, was mir gefällt, ich bevorzuge auch den Client. Frag mich, warum: Ich habe das Gefühl, er gibt mir ein Gefühl von Sicherheit, und Versionsupdates geben mir ein großartiges Gefühl und ein Gefühl von Präsenz, lassen mich wissen, dass ich nicht von der Welt vergessen wurde, lassen mich wissen, dass dein Produkt aktualisiert wird und dass du dich um mich kümmerst. Außerdem: Hyperlinks ... warum sollte ein Client SEO brauchen? Und das ist noch nicht alles; Web-Apps haben eine Reihe weiterer Nachteile. Der größte ist das Fehlen von GPU-Beschleunigung. Eine etwas komplexe Animation zu implementieren ist für den Browser eine echte Qual. Zweitens sind Webseiten single-threaded; das Laden des DOM blockiert JavaScript, was zu Verzögerungen führt. Verzögerungen führen zu Ärger, Ärger führt zum Schließen der Seite, und die Nutzerzahl sinkt um eins.

Hybrid ist anders. Eine Hybrid-App bezeichnet eine gemischte native Anwendung, die häufig aktualisierte Seiten als Webinhalte auf einem Remote-Server ablegt, um sie zu aktualisieren. Das ist eine zuverlässige Lösung. BAT hat viele Beispiele, wie etwa das von WeChat, Baidu Mobile und der Android-Version des Taobao-Clients veröffentlichte JS SDK.

Natürlich gibt es hier viele Fallstricke. Wenn ich die Gelegenheit bekomme, erzähle ich euch von den Fallstricken, in die ich getappt bin.

NodeJS

Ich war eine Weile hin- und hergerissen, ob Node zum Frontend-Bereich gehört. Ich denke schon.

Die Lösung hoher Nebenläufigkeit war schon immer ein Thema, über das Backend-Entwickler gern diskutieren. In unserem Echtzeit-Überwachungssystem erzeugt beispielsweise theoretisch jede Verbindung einen neuen Thread, und jeder neue Thread benötigt möglicherweise 2 MB unterstützenden Speicher. Auf einem System mit 8 GB RAM liegt die theoretische maximale Anzahl gleichzeitiger Verbindungen bei 4,000 Nutzern. Wenn die Nutzerzahl wächst, möchten wir, dass das Überwachungsprogramm mehr Nutzer unterstützt, was bedeutet, mehr Server hinzuzufügen. Natürlich erhöht das die Geschäftskosten, insbesondere die Serverkosten. Neben steigenden Kosten gibt es auch ein technisches Problem: Nutzer verwenden möglicherweise für jede Anfrage einen anderen Server, sodass alle gemeinsam genutzten Ressourcen über alle Server hinweg geteilt werden müssen. An diesem Punkt stößt die Technologie an eine Grenze. Node wurde ursprünglich geboren, um dieses Problem zu lösen. Nodes Lösung besteht darin, die Art und Weise zu ändern, wie Verbindungen zum Server hergestellt werden. Statt für jede Verbindung einen neuen OS-Thread zu erzeugen und dafür unterstützenden Speicher zuzuweisen, löst jede Verbindung ein Ereignis aus, das innerhalb des Prozesses der Node-Engine ausgeführt wird.

Node.js ist eine serverseitige Sprache. In der Einzäunungsbewegung zur Trennung von Frontend und Backend ist es eine mächtige Waffe für das Frontend. Gleichzeitig bietet es eine große Anzahl programmierbarer Werkzeuge für die Frontend-Automatisierung (grunt, bower, gulp usw.). Taobao und Baidu waren schon immer begeistert von Node.js, also denke ich natürlich, dass dies ein Trend ist. Letztes Jahr gründete Meituan ein Meituan-Hotel-Team und wählte Node als Backend-Sprache, wodurch der Großteil der Backend-Arbeit übernommen wurde. Ich frage mich: Mit Frontend-JS plus Node plus der Anforderung an UI-Fähigkeiten – sollte man Frontend-Engineers heutzutage nicht Full-End-Engineers nennen?

BIG DATA

Big Data ist wohl der heißeste Begriff der letzten Jahre. Ein Haufen meiner Kommilitonen zog heulend los, um an Datenbanken zu arbeiten, als sie hörten, dass Data Mining ein Jahresgehalt von 300.000 einbringt.
Meistens, wenn wir über Big Data sprechen, sprechen wir eigentlich über Data Mining, Datenanalyse, intelligente Empfehlung, Echtzeitanalyse usw. unter massiven Datenmengen. Unterschiedliche Unternehmen haben unterschiedliche technische Lösungen. Ich nenne nur zwei erfolgreiche inländische Fälle:
• JD.coms personalisierter E-Commerce, mit Szenarien, die Dimensionen wie Verhalten, Vorlieben, Standort, Zeit und Freundschaftsbeziehungen umfassen; unterschiedlichen Nutzern unterschiedliche Produkte zu empfehlen; und dass unterschiedliche Nutzer unterschiedliche Produktrankings in der Suche sehen...
• Baidu Maps’ 8-Stunden-Migrationskarte für Dongguan; intelligente Erinnerungen von Baidu Search
• Die Anti-Belästigungs-Funktion für Telefonnummern von 360 Mobile Guard wählt anhand von Region, Identität und Belästigungstrends des Nutzers die 1,000 relevantesten Nummern aus den 256 Millionen markierten Telefonnummern aus und schreibt sie in eine 10k-Textdatei auf dem Telefon des Nutzers, um Anti-Belästigung ohne Internetverbindung oder jegliche Netzwerkinteraktion bereitzustellen.

HTML5+CSS3

Das ist ein Begriff, der in den letzten Jahren zu Tode geredet wurde. Alle reden über HTML5; wenn man sie fragt, was HTML5 ist, können sie es nicht klar erklären. Es ist einfach cool, einfach auffällig, einfach cool und auffällig.

Meiner Ansicht nach ist HTML5 nur ein Ding, das durch wiederholtes Hörensagen Wirklichkeit geworden ist. Es zieht weit mehr Aufmerksamkeit auf sich als die Funktionalität, die es bietet. HTML5 bietet lediglich einige neue APIs, ähnlich wie eine App, die von 1.0 auf 2.0 aktualisiert wird und eine Funktion „Personen in der Nähe“ hinzufügt. Darüber hinaus sind seine APIs auf Mobilgeräten nur ein Testlauf. Auf der PC-Seite wurde es aufgrund von Kompatibilitätsproblemen nie offiziell akzeptiert. Die Entwicklung auf der PC-Seite basiert weiterhin auf HTML 4.0 + CSS 2 mit Progressive Enhancement. Was CSS3 betrifft, ist seine am meisten beachtete Animationsfunktion auch etwas, das Flash bereits hinter sich gelassen hat.

Die rasante Entwicklung im Mobilbereich hat die Entwicklung von HTML5 katalysiert, und die Entwicklung von HTML5 hat wiederum die Browser in Richtung Standardisierung vorangetrieben.

Auf diesem Weg zur Standardisierung hat WeChat eine unverzichtbare Rolle gespielt. Seiten wie „1024“, „Die neurotische Katze umzingeln“, „Taobao-Jahrzehnt“ und „LEXUS NX“, die eine große Anzahl von HTML5+CSS3-Elementen enthalten, sind beeindruckend.

Darüber hinaus hat Microsoft den Codenamen IE aufgegeben und Edge entwickelt. Browser verschiedener Hersteller werden kontinuierlich standardisiert, der HTML5-Entwurf wurde finalisiert, und der ES6-Entwurf wird kontinuierlich umgesetzt und verbessert. Der Weg, der vor dem Frontend liegt, sieht wie eine breite, offene Straße aus, und ich bin voller Erwartung.

Future

3D-Browserspiele? WebOS? Virtuelle Realität?

Schließlich: Wird das Obige mit der Verbesserung der Hardware-Leistung der Nutzer, immer größerer Netzwerkbandbreite, Sensorsystemen, Retina und der wachsenden Reife der WebGL-Technologie sowie der boomenden Entwicklung von O2O Wirklichkeit werden?

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