Ich erinnere mich, diesen Tweet von Tom Dale vor einer Weile gesehen zu haben. Er handelt buchstäblich von der Fähigkeit des Browsers, den HTML-Code des Dokuments zu betrachten, wie er ursprünglich ankam. Nun regt der Tweet eine neue Diskussionsrunde an.
Jonathan Snook hat eine Art "Babybär"-Ansicht
Wir haben die Möglichkeit, den ursprünglichen HTML-Quelltext zusammen mit seiner interpretierten Darstellung zu inspizieren. Wir haben die Möglichkeit, den Quelltext von JavaScript- und CSS-Dateien zu inspizieren, die von ihren minifizierten und optimierten Versionen abgebildet werden. Wir haben die Möglichkeit, Rendering-Pipelines zu inspizieren. Wir haben die Möglichkeit, die JavaScript-Ausführung Zeile für Zeile zu stoppen und durchzugehen.
Die zunehmende Komplexität der Werkzeuge negiert jedoch nicht die Notwendigkeit früherer, einfacherer Werkzeuge.
Die von manchen erstellten Websites können einfache statische Websites sein, die einer einfachen Quelltextansicht entsprechen. Die von manchen erstellten Websites können kompiliert und gebündelt sein und Werkzeuge erfordern, die uns erlauben, tiefer zu graben. Nur weil Sie diese Werkzeuge nicht benötigen, heißt das nicht, dass *jemand* sie nicht benötigt.
Und Chris Heilmann
Für eine einfache Website mit allem in einem Dokument oder wenigen verlinkten Skripten und Stylesheets war das ausreichend.
Ich glaube aber nicht mehr, dass das der Fall ist. Selbst das Navigieren durch einfachen Quelltext einer Website macht in den Entwicklertools mehr Spaß als in einem riesigen Textblock. Wir können heutzutage mit der rechten Maustaste auf ein Element klicken und direkt dorthin gelangen. Wir sehen, wie die Kaskade funktioniert, wenn wir uns das CSS ansehen, und wir können sogar angehängte Events und Hover-Zustände sehen.
Sicher, Entwicklertools sind schwerer zu erlernen als das Betrachten eines Dokuments, aber man lernt auch viel mehr daraus. Das Schöne an der Quelltextansicht war, dass sie kostenlos mit einem Browser geliefert wurde. Das machte sie zu einem Werkzeug der Wahl für jeden, der Webentwickler wurde. Es gab keine Notwendigkeit, eine IDE herunterzuladen und zu erlernen – Ihre Entwicklungsumgebung war die Konsumumgebung.
Nun, genau das sind die Entwicklertools heutzutage. Sie sind kostenlos, sie werden mit dem Browser geliefert, und sie sind nicht unmöglich zu verstehen. Wenn überhaupt, dann mag ich die Tatsache, dass sie Ihnen mehr Einblicke in das geben, was der Code tut, anstatt was er ist.
Ich nehme eine harte Haltung ein, nur zum Spaß hier: Mir ist die Quelltextansicht buchstäblich völlig egal und ich würde sie nicht vermissen, wenn sie aus den Browsern entfernt würde. Ich lebe in DevTools, und ich wette, Sie auch. Sie ersetzt die Quelltextansicht vollständig, da Sie dort buchstäblich den Quelltext anzeigen können, wenn Sie möchten. Aber das ist nebensächlich.
Ich möchte nicht, dass mein Quelltext lesbar ist, nicht aus Schutzgründen, sondern weil mir die Web-Performance wichtiger ist. Ich möchte, dass meine Website mit Lichtgeschwindigkeit auf einem winzigen Staubpartikel magischer Netzwerkpakete ankommt und sich zu einer vollständigen Website entfaltet. Oder was auch immer die Informatik als den absolut schnellsten Weg bestimmt, Website-Daten zwischen Computern zu senden. Ich mache mir mehr Sorgen um den Zustand der Web-Performance als um die Web-Bildung. Aber selbst wenn ich mir Sorgen um die Web-Bildung machen würde, glaube ich nicht, dass es die Aufgabe des Netzwerks ist, Lehrbarkeit zu liefern.
Korrigieren Sie mich, wenn ich falsch liege, aber mit den Entwicklertools inspizieren Sie das DOM, nicht den Quelltext. Und Browser machen lustige Dinge mit dem DOM, wie das automatische Schließen von vergessenen Tags, was manchmal zu ziemlich seltsamen Fehlern führt. Dann wechsle ich zur Quelltextansicht. Zählen von öffnenden & schließenden Tags
Sie liegen nicht falsch. Typischerweise betrachten Sie das DOM, weil das am nützlichsten ist. Aber der Quelltext ist auch da.
Wahr, der Quelltext kann aus den Entwicklertools abgerufen werden, aber es ist mehr eine Qual als ein einfaches
cmd+opt+uoderctrl+u— oder sogar ein Rechtsklick > Quelltext anzeigen. Manchmal möchte ich einfach nur einen schnellen Blick auf den ursprünglichen HTML-Code werfen, ohne in den Entwicklertools suchen und Bäume erweitern zu müssen.Ich lebe hauptsächlich in den Entwicklertools, aber ich benutze "Quelltext anzeigen" absolut. Aber ich bin hauptsächlich ein Backend-Entwickler. Ich muss sehen, was mein Server über die Leitung gesendet hat, bevor der Browser damit anfing, herumzuspielen. "Quelltext anzeigen" ist für meine Arbeit äußerst wichtig, denn wenn etwas schief geht, muss ich sehen, ob mein Server etwas sendet, das die gerenderte Seite durcheinander bringt.
Obwohl ich, da ich immer mehr APIs erstelle, fast genauso oft Postman oder HTTPie verwende wie "Quelltext anzeigen".
Dafür halte ich den Netzwerk-Tab für nützlicher, da er mehr Informationen darüber liefert, was gesendet wurde und wie.
Es ist entscheidend zu wissen, was über die Anfrage hereinkommt, im Gegensatz zur Interpolation des Inspektionswerkzeugs.
View-source bietet einen schnellen Einblick in die Methoden und Einstellungen der Entwickler der Website. Webentwickler schreiben keine DOM-Teile, sie schreiben Markup. Das Betrachten von Markup ist für die Betrachtung von Entwicklertools wie die Inspektion des Wohnzimmers einer Person ist für das Lesen einer detaillierten Liste seines Inhalts.
Ich finde es immer noch nützlich, wenn man ein bestimmtes Code-Stück finden möchte (ist es ein WordPress? Cmd+Opt+U + Cmd+F wp, fertig! – funktioniert natürlich auch mit den Entwicklertools, ich finde es nur nicht so "knackig"), oder wenn man sich den Quelltext auf seinem Mobilgerät ansehen möchte. Das ist schon mehr als einmal passiert, z.B. wenn ein Freund mich bittet, mir den Quelltext einer Website anzusehen, während ich unterwegs bin und keine schicken Apps/Tools dafür habe. Es ist eine sehr geringe Nutzung, die ich davon mache, aber trotzdem finde ich es nützlich und wäre ein wenig traurig, wenn es verschwinden würde.
Ja, ich benutze die Quelltextansicht, wenn ich Probleme mit der Reihenfolge der WordPress-Skript- und Stil-Ladungen habe. Ich öffne zwei Tabs, aktualisiere einen nach einer Codeänderung und vergleiche sie A/B-weise, um zu sehen, ob sich eine Zeile geändert hat.
Ich bin sicher, ich verpasse hier etwas.
Was bewirkt die Entfernung einer Funktion aus dem Browser, die zur Inspektion von rohem HTML-Quelltext hilfreich ist, für die Benutzer?
Was lesbaren vs. nicht lesbaren Code betrifft – das Minifizieren von HTML und CSS-Klassennamen reduziert die Nutzlastgröße um einen trivialen Betrag. Tatsächlich sollte dies mit GZIP kein Problem darstellen. Wahrscheinlich hat man eine Menge CSS, wenn das Minifizieren von Klassennamen eine spürbare Ersparnis bringt, in diesem Fall ist das eigentliche Problem eindeutig etwas anderes.
Ich versuche nur zu verstehen, woher das kommt. Das Unlesbar-Machen des Quelltextes (mit Ausnahme von JavaScript-Uglifying) als Kompromiss für die Performance scheint nicht sehr praktikabel zu sein.
Quelltext anzeigen für immer. Ich kann nicht glauben, dass Leute für seine Entfernung argumentieren würden. Es ist eine einfache, aber sehr aufschlussreiche Funktion, deren Entfernung niemandem nützen würde.
Eigentlich benutze ich beide Werkzeuge. Je mehr Javascript-Widgets Websites verheddern, die ich betreuen muss, desto mehr muss ich wissen, wie die Seite aussah, bevor ein Remote-Skript sich die Mühe machte, neue DOM-Knoten einzufügen, Klassen einzufügen oder Attribute zu ändern.
Es hängt wirklich davon ab, was ich tun möchte. Wenn ich mir ansehe, welches CSS auf einen bestimmten Bereich der Website angewendet wird, dann sind die Entwicklertools die richtige Anlaufstelle. Wenn ich versuche zu erklären, wie eine Website zusammengestellt wurde, beginne ich mit "Quelltext anzeigen" und gehe dann zu den Entwicklertools über.
Ich möchte das rohe Dokument inspizieren, das an den Browser gesendet wurde. Wie Chris erwähnte, möchte er, dass sein Quelltext schnell ist, nicht menschenlesbar. Wenn man den Leuten erlaubt, diesen rohen Output zu sehen, hilft ihnen das zu verstehen, wie wir Dinge schnell gemacht haben, bevor sie in den Entwicklertools in das DOM überführt werden.
Es gibt einen großen Unterschied zwischen view-source:https://www.nasa.gov/ und der Version der Entwicklertools.
Ich kann nicht zählen, wie oft ich versucht habe, einem anderen Entwickler zu helfen, und ich bitte ihn, den Quelltext anzuzeigen... er schaut sich den DOM-Baum an... und ich muss ihm sagen, dass er CTRL+U verwenden soll, um den vollständigen rohen Quelltext in einer schnellen und einfachen Vollbildansicht zu erhalten (ggf. auf einen zweiten Monitor gezogen) – OK, jetzt legen wir los! Sehen Sie diesen fehlerhaften HTML-Code oder das Link/Skript/Basis/Style-Tag, das vor dem Meta-Tag eingefügt wurde... ja, deshalb schlägt IE fehl... oder dieser div/span/? vor dem Body-Tag... ja, deshalb haben Sie Probleme. Ich liebe den DOM-Baum, aber das ist das Ergebnis der Parsen des vollständigen DOM. Kann ich im Grunde die gleichen Inhalte sehen, wenn ich mich durch die Entwicklertools wühle? Ja, irgendwie... aber in einem kleineren Fenster und ohne Hotkey. In Firefox & Chrome ist es auch ein Live-Fenster (F5/CTRL+F5) zum Neuladen, und alle Links sind navigierbar (z. B. zu eingebundenen Skripten, Styles, Iframes). In Firefox wird ungültiger Inhalt rot hervorgehoben, mit Tooltips, die erklären, warum er ein Problem darstellt. Endlich kann ich tatsächlich auf den Quelltext zugreifen, ohne die Entwicklertools überhaupt zu benötigen, indem ich einer URL "view-source:" voranstelle, z. B. view-source:https://www.google.com/ Dies ist sehr nützlich, wenn es Umleitungen/Selbstschließungen oder andere fehlerhafte JavaScript auf der Seite gibt, die dazu führen, dass der Inhalt sich ändert oder schließt, bevor Sie die Entwicklertools öffnen können. #LongLiveViewSource!
Wie Chris bereits erwähnte, kann man den Quelltext immer noch aus den Entwicklertools anzeigen. Warum nicht einfach diese Ansicht öffnen, wenn auf "Seitenquelltext anzeigen" geklickt wird? Das Beste aus beiden Welten.