Jan 01, 1970
1,052 Lesungen
Die Geschichte der Webentwickler im Zusammenhang mit der Browserentwicklung
Zu lang; Lesen
Webentwickler sind die Ersteller von Webseiten. Lassen Sie uns darüber nachdenken, wie sie entstanden sind und welche Verbindungen sie zur Geschichte von Browsern wie Mosaik, Netscape, Mozilla und Firefox haben.Webentwickler sind die Ersteller von Webseiten wie dieser. Überlegen Sie, wie wir hier zusammenarbeiten: Sie als Leser und ich werden mit der Unterstützung eines Redakteurs von HackerNoon ein besserer Autor.
Sehen Sie die Entwickler? Wahrscheinlich nicht, denn sie haben gute Arbeit geleistet. Wir werden sie wahrscheinlich beim Lesen über die Zukunft der Webentwicklung finden.
Was ich mit diesem Artikel hingegen anbiete, ist eine Gelegenheit, innezuhalten und über die Entstehung von Webentwicklern nachzudenken, wie diese mit der Geschichte der Browser zusammenhängt und wie ihre Zusammenarbeit die Zeitachse der Browserentwicklung neu belebt hat.
Eine neue Art von Ingenieur für das Web
+
In den Anfängen des Webs schenkten viele Softwareentwickler der Webentwicklung im Hinblick auf Webseiten keine große Aufmerksamkeit. Warum sollten sie das tun? Wenn Sie Ingenieur wären, wären Sie beeindruckt vom ersten Fahrgast, der aus der Lokomotive kommt, oder von der Lokomotive selbst?
Jason Kottke vom Home of Fine HyperText Products hat es gut geschrieben:
Das erste Mal, dass ich im Physiklabor im Keller des Colleges mit NCSA-Mosaik im World Wide Web surfte, kam einem religiösen Erlebnis so nahe wie nie zuvor. Es war ein Blitz, der mein Leben völlig veränderte.
Dieser erste Eindruck ermöglichte es Hackern (und Malern) jedoch auch, sich dem Thema unter dem Aspekt der Benutzeroberfläche zu nähern. Daher markieren die Erfindung und Innovation des Mosaik-Browsers den Beginn der Möglichkeiten der Webentwicklung:
Anfang 1993 wurde die
Nationales Zentrum für Supercomputing-Anwendungen (NCSA) an der University of Illinois hat eine erste Version seines Mosaik-Browsers veröffentlicht. Diese Software lief in der in der Forschungsgemeinschaft beliebten X Window System-Umgebung und bot eine benutzerfreundliche fensterbasierte Interaktion. Kurz darauf veröffentlichte die NCSA Versionen auch für die PC- und Macintosh-Umgebungen. Die Existenz zuverlässiger, benutzerfreundlicher Browser auf diesen beliebten Computern hatte unmittelbare Auswirkungen auf die Verbreitung des WWW.
Beachten Sie, wie der Browser als Tool zunehmend Sinn machte, als die Infrastruktur dahinter das Potenzial zeigte:
Es war eine surreale Erfahrung aufgrund der benutzerfreundlichen Oberfläche, die das Potenzial zeigte, von überall auf Wissen zuzugreifen. Vielleicht nicht anders als das, was ich empfand, als ich ChatGPT als benutzerfreundliche Schnittstelle nutzte, die das Potenzial zeigte, von überall auf Wissen zuzugreifen. Lesen Sie im folgenden Artikel etwas über die Geschichte von Mosaic und die Erfindung des Webs:
Quelle anzeigen: Lernen Sie durch Kopieren von Beispielen
Aber Webseiten waren recht einfach. Damals erkannten wir – Informatikstudenten – kluge Leute daran, wie einfach ihre Seiten waren, wie diese von Dennis Ritchie von Bell Labs .
Da ich als neugieriger Benutzer dort war, also nicht an den Informatikvorlesungen teilnahm und nicht mit dem Web spielte, stieß ich auch auf eine im Browser integrierte Menüoption, die es uns ermöglichte, die Quelle von Webseiten anzuzeigen. Und übrigens, fast über Nacht wurde dieser Mosaik-Browser Netscape genannt.
Jim Nielsen hat in „The Spirit of View-Source“ darüber nachgedacht und herausgefunden, wie der Netscape-Browser eine sofortige Lernmöglichkeit für jede Seite im Web ermöglicht hatte.
In seinem Artikel zitierte er eine Beobachtung von Clive Thompson aus dem Buch Coders
Versuchen Sie nun, sich „das Web“ als die heißeste Sache überhaupt vorzustellen, und stellen Sie sich vor, wie viele von uns die Quellen von Seiten überprüften, um Ideen von anderen zu kopieren und schließlich zu lernen. Dies waren die „View-Source-Tage“, an denen wir die Magie sehen konnten.
Obwohl wir immer noch die Option „Seitenquelle anzeigen“ im Menü moderner Browser haben, werden Sie beim Anzeigen der Quelle einer Webseite wahrscheinlich etwas Mysteriöses sehen:
JavaScript: Kontrolle und Interaktion
Ein weiterer wohlbekannter Wendepunkt kam, als Netscape (erneut) JavaScript – die Programmiersprache – aktivierte, die es Webentwicklern ermöglichte, Skripte zu erstellen, um bestimmte Aspekte von Webseiten zu steuern und die Interaktion zu steuern.
Brendan Eich , der Erfinder von JavaScript und heutiger CEO von Brave Software The Browser That Cares about your Privacy , hat uns eine Folie gegeben, die die Reise des Helden mit JavaScript im Land des Webs zusammenfasst. Seine Punkte zeigen uns, dass JavaScript nicht immer als elegant galt, aber letztendlich stark genutzt wurde – und sich weiter verbesserte.
Der folgende Screenshot zeigt ein Warnfeld, das über die Browseroberfläche von Netscape 2 aufgerufen wird. Webentwickler verwendeten JavaScript, um visuelle Warnungen auszulösen (um ihren Code zu debuggen) und unmögliche Dinge zu tun, wie zum Beispiel Webformulare zu steuern, den Wert eines Eingabeformulars zu validieren und andere Anwendungsfälle.
Es versteht sich von selbst, dass ein neugieriger Benutzer über die „Quelle anzeigen“ auf einer Seite mehr über JavaScript erfahren kann. Die HTML-Seite war die Hülle, die durch ihre HTML-Elemente, Hyperlinks, Bilder, Stile und JavaScript-Code einen Großteil der Präsentation und logischen Struktur von Websites vermittelte.
Dynamisches HTML: Layoutanpassungen und Animationen
Und eine weitere Möglichkeit wurde durch ein neues Tag in HTML mit dem Namen <layer> ermöglicht. Damals, etwa 1997, brachte Netscape die Netscape Communicator Preview Release mit neuen APIs für Entwickler auf den Markt. In einer Pressemitteilung heißt es: „ Dynamic HTML ist ein bedeutender Meilenstein für HTML, da es Designern mehr Flexibilität und Kontrolle über das Webseitenlayout bietet und Benutzern gleichzeitig ein höheres Maß an Interaktivität bietet.“ ”
Später wurde aus dem Tag <layer /> das Tag <div />. Die damalige technische Innovation hatte mit der Möglichkeit zu tun, ein visuelles Stück HTML, ein Element, über einem anderen zu positionieren, wie die folgende 3D-Abbildung aus einer der frühesten DHTML-Technotes zeigt.
Die folgende Demonstration aus dem Jahr 1997 können Sie vorerst nicht miterleben, aber stellen Sie sich den Zug (der nur ein Bild war) vor, der sich bewegt, als würde er auf Sie zukommen.
Der Trick bestand darin, mithilfe von JavaScript die Sichtbarkeit von Bildern unterschiedlicher Größe umzuschalten und so die Illusion einer Animation zu erzeugen. Auf der Seite wurde auch das Geräusch einer Lokomotive mit einigen anderen Methoden gestartet.
Zu diesem Zeitpunkt, als der Browserkrieg seinen Höhepunkt erreichte, begannen Entwickler, die wie ich begonnen hatten, Seiten für Netscape zu schreiben, im Gegensatz zu mir, Seiten für Internet Explorer zu erstellen. Diese Unterschiede – und die erforderlichen Fähigkeiten – waren Gründe dafür, dass Entwickler als Webentwickler eingestellt wurden. Das Ausmaß und die Komplexität der DHTML-Bewegung korrelieren mit dem Inhalt dieses beliebten, über 1000 Seiten umfassenden Buches .
Webstandards
Ein wichtiges Ergebnis der Browserkriege ist, dass Netscape seinen Quellcode als Open Source veröffentlichte. Hier taucht der Name Mozilla auf, wie in Project Code Rush dokumentiert. Dieser Prozess war strategisch, komplex und riskant. Es war ein mutiger Schritt, wie der damalige CEO Jim Barksdale anerkannte:
„Nun, ich hoffe auf jeden Fall, dass die enorme Menge neuer Leute, die sich kein Unternehmen leisten kann, an einem Produkt zu arbeiten – die jetzt zum Netscape Navigator Communicator beitragen – einen erheblichen Unterschied bei der Verbesserung des Produkts machen wird. Wie das gegen einen Konkurrenten funktioniert, bleibt abzuwarten.“ Jim Barksdale @ Code Rush 2013
Abgesehen von der Open-Source-Grundlage erregte eine Schlüsselstrategie von Mozilla die Aufmerksamkeit von Webentwicklern – die Unterstützung von Webstandards. Um dabei zu helfen, hat Netscape ein neues Team von Technologie-Evangelisten zusammengestellt. Unter ihnen Eric Meyer , der CSS-Guru, der unter Entwicklern Berühmtheitsstatus erlangte. Ihr Anliegen entsprach den Bedürfnissen von Webentwicklern – die proprietären Unterschiede zu beenden und eine gemeinsame Grundlage für die Implementierung von Seiten zu schaffen, die mit allen Browsern funktionieren. Eric hat unseren Kampf gefeiert:
Bedenken Sie, dass es sich bei dem obigen Bild um einen kleinen Ausschnitt eines größeren Fotos handelt. Ein weiterer Teil davon waren die Dokumentationsbemühungen von Mozilla, das später zum Mozilla Developer Network wuchs.
Single-Page-Anwendungen und die AJAX-Methode
Während Entwickler sich selbst dabei halfen, Webseiten auf standardkonforme Weise zu reparieren, brachten sie die Seiten auch an ihre Grenzen. Dies waren die Tage, als Anwendungsfälle wie Gmail aufkamen und Initiativen wie Web Services es uns ermöglichten, über die Idee von Single-Page-Anwendungen nachzudenken – was wäre, wenn eine Webseite wie Softwareanwendungen funktionieren könnte? Die folgenden Artikel zeigen, was die Evangelisten damals schrieben:
- Zugriff auf Webdienste in Netscape 7.1/Mozilla 1.4 mithilfe von WSDL-Proxying (06. Juni 2003)
- Standardbasiertes zusammenklappbares Inhaltsverzeichnis-Widget (CTOCWidget) (20. Mai 2003)
- Inner-Browsing: Erweiterung des Web-Browsings um das Navigationsparadigma (16. Mai 2003)
Trotz dieser Bemühungen kam auch im alten Westen ein Wendepunkt. Im Jahr 2005 schrieb Jesse James Garrett aus San Francisco einen wegweisenden Artikel mit dem Titel „ Ajax: Ein neuer Ansatz für Webanwendungen“. Jesse war ein User Experience Designer, der die Webentwicklung weltweit beeinflusste. AJAX wurde zu einem beliebten Begriff, der von Entwicklern verwendet wurde, um die Absicht auszudrücken, Interaktivität hinzuzufügen und das Verhalten von Webanwendungen zu verändern.
Wenn Sie jemanden mit der Erstellung einer Single-Page-Anwendung beauftragen würden, müssten Sie einen Webentwickler engagieren, der sich mit AJAX auskennt:
Der beste Freund des Entwicklers – Entwickler-Add-on-Tools und Seiteninspektion
Das Mozilla-Projekt setzte die Saga fort, jetzt mit Firefox. Firefox knüpfte an die Vorzüge von Mozilla an und hat hinsichtlich Leistung, Sicherheit und Standardunterstützung einen Reifegrad erreicht. Der Wendepunkt war jedoch, dass das Vertrauen der Entwickler nicht durch Marktanteile, sondern durch integrierte Tools gewonnen wurde, die ihnen beim Testen und bei der Fehlerbehebung von Seiten halfen.
Die Firebug- Erweiterung – geschrieben von Joe Hewitt , der bei Netscape gearbeitet hatte – kam 2006 auf den Markt und trug dazu bei, dass Browser-Add-ons zunehmend verwendet wurden, um Webentwicklern beim Debuggen von Seiten zu helfen. Die Verwendung von Firebug steht auch im Zusammenhang mit dem Aufstieg der berühmten jQuery-Bibliothek von John Resig, die 2007 von Mozilla angeheuert wurde.
Den Produktmanagern war nicht verborgen geblieben, dass Entwickler Firefox zum Testen ihrer Seiten und zur schnelleren Bereitstellung verwendeten, auch wenn der Hauptbrowser im Hinblick auf Markeshare der Internet Explorer war. Firefox als Tool zum Erstellen von Seiten – das von Webentwicklern verwendet wird – war ein weltweites Phänomen, das besser verstanden werden kann, wenn man sich eine Präsentation der Mozilla-Mitarbeiter Clauber und Mario aus dem Jahr 2008 mit dem Titel „Firefox – Developer's Best Friend“ ansieht.
Auf einer wichtigen Folie betonten sie die Bedeutung der Verwendung von Firefox als Entwicklungsframework aufgrund seiner Unterstützung für Webstandards und Entwicklungs-Add-ons zum Debuggen von JavaScript und mehr.
Der Rest ist Geschichte – JS-Bibliotheken und Frameworks
Bin ich jetzt verrückt danach, darüber zu reden, was als nächstes kommt?
Auf keinen Fall. Wenn Sie Webentwickler sind, spüren Sie möglicherweise die Hitze und die Komplexität dessen, was Ihrer Meinung nach passiert ist. Lassen Sie uns diese Party hier beenden mit: Browser haben sich weiterentwickelt, Seiten haben sich weiterentwickelt, Entwickler auch. Und zu sagen, dass alle Spieler gleichermaßen schnell ihren Beitrag leisten – zu schnell –, bis zu dem Punkt, dass ich lieber in die Vergangenheit schaue und feiere.
Ein paar Hinweise sind wichtig. Einer davon ist, dass ich die Aspekte im Hinblick auf die Serverseite nicht erwähnt habe. Es wäre schwierig, diese Überlegung in eine Struktur zu integrieren, obwohl ich anerkenne, dass Webentwickler in Front-End, Back-End oder Fullstack verzweigt sind.
Ein weiterer Grund ist, dass der als „Firefox als bester Freund des Entwicklers“ bezeichnete Moment mit dem Aufkommen von Bibliotheken einherging, die zusammen mit Webseiten ausgeliefert wurden. Ein gutes Beispiel ist die Bibliothek jQuery . Daher waren die „jQuery + Firefox als beste Freunde des Entwicklers“-Tage wirklich ein Phänomen, bei dem der Code der Seiten immer komplexer wurde und mehr Ingenieursarbeit erforderte – mehr Fehler auf der Clientseite der Seiten.
Diese Beobachtung würde die Tür öffnen, um über die Entstehung von Bibliotheken wie React und unter anderem über die komplexe Welt nachzudenken, wie sie in The Great Gaslighting of the JavaScript Era aufgezeigt wird.
Das Leitbild für diesen Artikel wurde vomAI Image Generator von HackerNoon über die Eingabeaufforderung „früher Internetbrowser“ generiert.
L O A D I N G
. . . comments & more!
. . . comments & more!
