Share
Es ist der Browser, den jeder gerne hasst - manchmal zu Recht. Der einst innovativste Browser wurde für jeden Frontend-Entwickler zum Dorn im Auge. Inmitten der Turbulenzen und Beschwerden, die die heutigen Entwickler heute mit dem Internet Explorer unternehmen, wird oft nicht gehört, wie Microsoft nicht nur die Front-End-Entwicklung, sondern die Webentwicklung insgesamt verändert hat.
IE's Fall ist keine ungewöhnliche Geschichte; Es ist tatsächlich die gleiche Geschichte wie Netscape. Das Unternehmen hinter dem führenden Browser wird zufriedener, der Browser stagniert und ein neuer Champion entsteht. Es ist ein sich wiederholender Zyklus, dem sich Mozilla bis zu einem gewissen Grad erneut gegenüber sieht (aber das ist eine andere Geschichte für eine andere Zeit).
Vor den Browsern der Version 4 wurde JavaScript hauptsächlich für die einfache Datenverarbeitung (Formularvalidierung) verwendet. Daher waren Webseiten hauptsächlich statisch. Während eine Seite von serverseitigen Anwendungen dynamisch generiert werden konnte, konnte die Seite nicht mit dem Benutzer interagieren. Diese Einschränkung bestand aufgrund des unzureichenden Document Object Model (DOM) des Browsers. Hierbei handelt es sich um die Anwendungsprogrammierschnittstelle (API), mit der JavaScript-Entwickler auf einzelne Elemente auf der Seite zugreifen und diese bearbeiten. Das DOM, das vor den Browsern der Version 4 existierte, wird häufig als DOM Level 0 bezeichnet. DOM Level 0-Implementierungen ermöglichen Entwicklern Zugriff auf , , und
"Microsoft bringt den Internet Explorer wieder auf Kurs."
Erst als Netscape Mitte 1997 Navigator 4 (NS4) veröffentlichte, erlaubte das DOM eines Browsers es Webentwicklern, eine Seite mit JavaScript zu ändern. Die Technik der Manipulation von Elementen mit JavaScript und dem DOM wurde Dynamic HTML (DHTML) genannt. DHTML von NS4 war sicherlich ein Schritt nach vorne, aber sein proprietäres und schlecht entworfenes, schichtbasiertes DOM und das begrenzte Cascading Style Sheet (CSS) unterstützen eingeschränkte Entwickler bei dem, was sie tatsächlich erreichen können.
Netscape implementierte kein vollständiges Objektmodell. Abgesehen von der DOM Level 0-Funktionalität waren die einzigen Elemente, auf die ein Entwickler zugreifen konnte, absolut positionierte Elemente, Schicht Objekt in DOM von NS4. Netscape entworfen Schicht Objekte, die Frame-Objekten (und damit Fensterobjekten) sehr ähnlich sind. Jeder Schicht Objekt hatte eine dokumentieren Eigenschaft, die im Grunde ein weiteres HTML-Dokument war. Wie Rahmen, a Schicht Objekt könnte in einem anderen verschachtelt sein Schicht object, um den Code für den Zugriff auf diese Ebenen äußerst ausführlich zu machen, wie folgt:
var myLayer1 = document.layers ["myLayerId"]. document.layers ["mySecondLayerId"]; // oder var myLayer2 = document.myLayerId.document.mySecondLayerId;
Diese beiden Codezeilen machen dasselbe: Sie greifen auf die Schicht Objekt mit einem Ich würde von mySecondLayerId das ist in einer Ebene mit einem verschachtelt Ich würde von myLayerId. Ja, Entwickler mussten den Layer "Baum" durchlaufen, um auf verschachtelte Layer zugreifen zu können.
Das DOM von NS4 erlaubte nicht das Erstellen, Einfügen, Verschieben und Entfernen von DOM-Objekten, sondern weil jede Ebene a ausgesetzt war dokumentieren Objekt kann ein Entwickler den Inhalt einer Ebene dynamisch ändern, indem er die schreiben(), Belastung(), und schließen() Methoden. Dies verleiht dem Ebenenmodell zwar eine gewisse zusätzliche Leistung, schränkte Entwickler jedoch ein, wie sie eine Seite dynamisch aktualisieren konnten. Neuer Inhalt muss geschrieben oder in eine Ebene geladen werden, wodurch der vorhandene Inhalt der Ebene effektiv entfernt wird. Es ist unnötig zu erwähnen, dass die meisten Entwickler die Inhaltsmanipulation vermieden haben und sich stattdessen auf die Änderung des Stils einer Ebene konzentrierten.
Die Webentwicklung mit DOM von NS4 war schmerzhaft und frustrierend.
Aber der Stil in NS4s DOM war eine lustige Sache. Während der Browser CSS bis zu einem gewissen Grad unterstützte, Schicht Objekte haben keine API für Entwickler bereitgestellt, um direkt auf eine Ebene zuzugreifen Stil Attribut wie heute Stil Objekt. Stattdessen, Schicht Für Objekte wurde ein sehr begrenzter Satz von Eigenschaften angezeigt, durch den die Position, Sichtbarkeit, das Beschneiden und die Hintergrundfarbe / das Bild einer Ebene geändert wurden. Der Wert, den diese Eigenschaften akzeptierten, war ebenfalls recht begrenzt. Zum Beispiel akzeptieren die Positionierungs- und Clipping-Eigenschaften nur numerische Werte. Ein Entwickler konnte keine Einheit angeben (z. B. px, em, pt usw.). Ein Beispiel für einen solchen Code folgt:
var myLayer = document.myLayerId.document.mySubLayerId; myLayer.top = 10;
Es ist unnötig zu erwähnen, dass die Webentwicklung mit NS4's DOM schmerzhaft und frustrierend war. Die extrem eingeschränkten DHTML-Funktionen von NS4 beruhen auf den Einschränkungen der Rendering-Engine von NS4 (die Seite konnte nicht umfließen). Warum aber so viel Zeit mit Netscape's DOM verbringen, vor allem in einem Artikel, der sich mit IE beschäftigen soll? Hätte Netscape den Browserkrieg gewonnen, wäre das heutige DOM ein evolutionärer Schritt aus dem von Netscape in NS4 vorgestellten DOM. Während das heutige DOM ein Standard des W3C ist (und einige Netscape-Ideen werden im heutigen Standard umgesetzt), wird das heutige DOM stark vom IE4 des DOM beeinflusst.
Nur wenige Monate nach der Veröffentlichung von Navigator 4 durch Netscape veröffentlichte Microsoft die vierte Version von IE. Es enthielt auch Unterstützung für DHTML, aber Die Implementierung von Microsoft unterschied sich stark und war NS4 überlegen. IE4 bot eine viel bessere CSS-Unterstützung und ein umfassenderes Objektmodell, um auf Elemente und Inhalte der Seite zugreifen und diese bearbeiten zu können. Die Wirkung von IE4s DOM war weitreichend; Tatsächlich kann ein Entwickler viele Ähnlichkeiten zwischen dem IE4-DOM und dem Standard-DOM finden.
"Microsoft hat nicht nur das Gesicht der Frontend-Entwicklung verändert, sondern auch die gesamte Webentwicklung?"
Die Entwickler von IE4 wollten den Browser zu einer Plattform für Webanwendungen machen. Also näherten sie sich der IE4-API wie ein Betriebssystem an, das ein nahezu vollständiges Objektmodell bereitstellte, das jedes Element (und die Attribute eines Elements) als Objekt darstellte, auf das mit einer Skriptsprache zugegriffen werden konnte (IE4 unterstützte sowohl JavaScript als auch VBScript)..
In DOM des IE4 war das proprietäre Element das wichtigste Mittel, um auf ein bestimmtes Element auf der Seite zuzugreifen alles[] Sammlung, die jedes Element im Dokument enthält. Entwickler können auf Elemente mit einem numerischen Index oder durch Angabe eines Elements zugreifen Ich würde oder Name, so was:
var myElement1 = document.all ["myElementId"]; // oder var myElement2 = document.all.myElementId;
Mit diesem Code könnten Entwickler auf das Elementobjekt mit einer ID von zugreifen myElementId unabhängig davon, wo es auf der Seite vorhanden war. Dies steht in krassem Gegensatz zum Netscape-Ebenenmodell, bei dem Entwickler nur über die Hierarchie der Ebenen auf Ebenen zugreifen konnten. Die Funktionalität von document.all ["elementId"] zum Standard entwickelt document.getElementById () Methode. Aber nicht nur auf diese Weise konnte ein Entwickler auf Elemente zugreifen. man könnte durch den DOM-Baum gehen und jedes Element mit der Kinder[] Sammlung und parentElement Eigenschaftsvorläufer zum Standard childNodes [] und Elternknoten Eigenschaften.
Zusätzlich zum Laden von Elementen als Objekte repräsentierte das DOM des IE4 die Attribute eines Elements als Eigenschaften des Elementobjekts. Zum Beispiel die Ich würde, Name, und Stil Eigenschaften, die direkt einem Element zugeordnet sind Ich würde, Name, und Stil Attribute. Dieses Design wurde zum Standard.
Microsoft hat das erfunden
innerHTMLEigentum.
Wie Netscape hat Microsoft keine umfassende API zum dynamischen Hinzufügen, Verschieben und Entfernen von Knoten mit JavaScript bereitgestellt. Sie haben jedoch das erfunden innerHTML Eigenschaft, um den Inhalt eines Elements abzurufen oder festzulegen. Im Gegensatz zu Netscape Schicht Objekt ist schreiben() und Belastung() Methoden, die innerHTML property war keine Alles-oder-Nichts-Lösung, um den Inhalt eines Elements zu ändern. ein Entwickler könnte verwenden innerHTML um den Inhalt eines Elements vollständig zu löschen, zu ersetzen oder hinzuzufügen. Mit dem folgenden Code wird beispielsweise der Inhalt eines Elements abgerufen und geändert:
var el = document.all.myElementId, html = el.innerHTML; el.innerHTML = html + "Hallo, innerHTML";
Bis heute die innerHTML Eigenschaft ist ein Eckpfeiler von DHTML. Dies ist ein effizientes Mittel, um einem Element große Inhaltsmengen hinzuzufügen. Obwohl es in keinem DOM-Standard formal enthalten ist, implementiert jeder größere Browser eine innerHTML Eigentum.
Microsoft hat mehrere Werkzeuge und Designs erfunden, die sich zu Teilen des Standard-DOM entwickelt haben. Die Arbeit mit der IE4-Stil-API wurde jedoch mit nur wenigen Modifikationen zum Standard. Der Schlüssel zum Ändern des Stils eines Elements in IE4 war der
StilEigenschaft, dieselbe Eigenschaft (und Syntax), die heute von Entwicklern verwendet wird.
DHTML hat die Webentwicklung für immer verändert. Es war jedoch das DOM des IE4, das die Technologie (und die Webentwicklung) vorantrieb, indem es den primären Einfluss auf die DOM Level 1 und 2-Spezifikation des W3C ausübte. IE4 revolutionierte die Webentwicklung 1997, und IE würde dies einige Jahre später erneut tun.
Ajax öffnete die Türen für die Webentwicklung.
Bevor Ajax Ajax war, wurde es als Remote Scripting bezeichnet. Entwickler nutzten die Möglichkeiten des Remote Scripting, um versteckte Frames und Iframes für die Client-Server-Kommunikation zu nutzen. Ein versteckter (i) -Frame enthielt normalerweise ein Formular, das dynamisch ausgefüllt und über JavaScript übermittelt wurde. Die Antwort des Servers wäre ein weiteres HTML-Dokument, das JavaScript enthält, das der Hauptseite mitteilt, dass Daten empfangen wurden und einsatzbereit sind. Es war grob, aber es hat funktioniert.
Es gab jedoch eine Alternative: ein wenig bekannter Edelstein, der in der MSXML 2.0-Bibliothek von Microsoft vergraben wurde. Der im März 1999 veröffentlichte IE5 enthielt MSXML 2.0, und die Entwickler fanden eine aufgerufene Komponente XMLHttp (Der tatsächliche Name der Schnittstelle lautet IXMLHTTPRequest). Sein Name ist irreführend wie der XMLHttp object funktioniert eher wie ein einfacher HTTP-Client als alles andere. Entwickler können nicht nur Anforderungen mit dem Objekt senden, sondern auch den Status der Anforderungen überwachen und die Antwort des Servers abrufen.
Natürlich, XMLHttp begann, die verborgene (i) -Frame-Technik für die Client-Server-Kommunikation zu ersetzen. Ein paar Jahre später erstellte Mozilla ein eigenes Objekt nach dem Vorbild von Microsoft XMLHttp, und nannte es XMLHttpRequest. Apple folgte ihr mit XMLHttpRequest object im Jahr 2004 und Opera implementierte das Objekt im Jahr 2005.
Trotz seines wachsenden Interesses ist die Popularität von
XMLHttp/XMLHttpRequest(zusammenfassend als XHR hier bekannt) explodierte nicht, bis Jesse James Garrett seinen Artikel "Ajax: Ein neuer Ansatz für Webanwendungen" veröffentlichte.?
Ajax öffnete die Türen für die Webentwicklung, und an vorderster Front standen JavaScript, XHR und DHTML - zwei davon waren Microsofts Erfindungen. Also was ist passiert? Was führte dazu, dass ein Browser, der buchstäblich das Schreiben von Webanwendungen durch Webentwickler verändert hat, zum Fluch des modernen Webs wurde?
Bis 2003 betrug der Marktanteil von Internet Explorer rund 95%; Microsoft hat den Browserkrieg offiziell gewonnen. Da es im Web-Bereich keine echte Konkurrenz gab, verlagerte Microsoft seinen Fokus vom Browser auf .NET. Dies wird durch Zitate von vielen Microsoft-Mitarbeitern bestätigt, aber das Beste aus einem CNET-Artikel mit dem Titel? Wird Ajax Google beim Aufräumen helfen? Charles Fitzgerald, General Manager von Microsoft für Plattformtechnologien, wurde darin mit folgenden Worten zitiert:
?Es ist ein bisschen deprimierend, dass die Entwickler sich gerade mit diesen Dingen beschäftigen, die wir im späten 20. Jahrhundert ausgeliefert haben [ed: DHTML und Ajax], aber XAML gehört zu einer ganz anderen Klasse. Dieses andere Zeug ist sehr kludig und sehr schwer zu debuggen. Wir haben einige ziemlich beeindruckende Hacks gesehen, aber wenn Sie sich anschauen, was XAML zu lösen beginnt, ist das ein großer Schritt nach oben.?
Im Mai 2003 kündigte Microsoft an, dass der IE nicht mehr getrennt von Windows veröffentlicht werden sollte (das ausgezeichnete IE5 für Mac wurde ebenfalls in die Dose aufgenommen). Der Browser würde immer noch als Teil des sich entwickelnden Windows-Betriebssystems entwickelt, aber Microsoft würde keine eigenständigen Versionen von IE veröffentlichen. Sie hatten vor allem auf ClickOnce gesetzt, eine Technologie, mit der Entwickler herkömmliche Anwendungen (natürlich mit .NET) schreiben und über das Web verteilen können.
Das Web entwickelte sich jedoch weiterhin auf dem Weg, den Microsoft ursprünglich mit IE4 und IE5 festgelegt hatte, und Microsoft verlor an Marktanteil an Netscows Erben: Firefox. Die Entwickler haben Webanwendungen geschrieben, die im Browser lebten, nicht in herkömmlichen Anwendungen über ClickOnce. Dies zwang Microsoft, IE aufzugreifen, abzuwischen und Stand-Alone-Versionen erneut zu veröffentlichen.
IE9 umfasst eine weitaus bessere Unterstützung für Standards.
Die nächsten beiden Versionen 7 und 8 waren weitgehend evolutionär. IE7 enthielt verschiedene Fehlerkorrekturen XMLHttpRequest Bezeichner (obwohl noch ein erstellt wurde XMLHttp Objekt aus der MSXML-Bibliothek) sowie Verbesserungen der Benutzeroberfläche und der Sicherheit.
IE8 war größtenteils mehr gleich, nur dass es für jeden Tab einen Sandkasten gab - eine Funktion, die Google auch in Chrome implementierte (Microsoft kündigte es zuerst an). Es isoliert jeden Tab in seinem eigenen Prozess und erhöht so die Sicherheit und Stabilität. Sandboxing wird in heutigen Browsern zum Standard (Firefox ist immer noch nicht in der Lage, diese Funktion zu nutzen), und es geht auch in den Bereich der Add-Ons und Plug-Ins.
Microsoft bringt den Internet Explorer wieder auf Kurs.
Die neueste Version, IE9, bietet eine weitaus bessere Unterstützung für Standards auf breiter Front. Mit der neuen JIT-kompilierenden JavaScript-Engine (die, falls verfügbar, einen separaten CPU-Kern verwendet und auf die GPU zugreifen kann) und ihrer hardwarebeschleunigten Rendering-Engine wird auch innovativ. Während JIT-kompilierende JavaScript-Engines nicht neu sind, ist die Fähigkeit des IE9, die Kompilierung parallel zum Seiten-Rendering auf einen separaten Kern zu verlagern, eine Leistung, die die dringend benötigte Leistung für Webanwendungen anspornt. Seine Hardwarebeschleunigungsfähigkeiten erwiesen sich beim Debütieren als nützlich, und jetzt bieten Firefox und Chrome in gewissem Umfang Hardwarebeschleunigung.
Es ist nicht zu leugnen, dass Internet Explorer Kopfschmerzen für Webentwickler verursacht hat. Die fünfjährige Pause zwischen IE6 und IE7 führte dazu, dass Microsoft weit hinter der Konkurrenz zurückblieb und die Front-End-Entwicklung nicht ideal war. Aber Microsoft bringt den Internet Explorer wieder auf Kurs. Sie prägten die Webentwicklung so, wie sie heute ist. Hier hoffen wir, dass sie es wieder tun.
Die nächste Version von Internet Explorer, Version 9, soll am 14. März 2011 offiziell veröffentlicht werden.
Accentsconagua