it-swarm.com.de

Warum sollte ich Inline-Scripting vermeiden?

Ein sachkundiger Freund hat sich kürzlich eine Website angesehen, die ich beim Start unterstützt habe, und etwas wie "sehr coole Website, schade um das Inline-Scripting im Quellcode" kommentiert.

Ich bin definitiv in der Lage, das Inline-Scripting dort zu entfernen, wo es auftritt. Mir ist vage bewusst, dass es "eine schlechte Sache" ist. Meine Frage ist: Was sind die wirklichen Probleme mit Inline-Scripting? Gibt es ein signifikantes Leistungsproblem oder ist es meistens nur eine Frage des guten Stils? Kann ich meinen Vorgesetzten sofortige Maßnahmen in Bezug auf Inline-Skripte rechtfertigen, wenn andere Dinge zu bearbeiten sind, die offensichtlichere Auswirkungen auf die Website haben könnten? Wenn Sie zu einer Website gegangen wären und einen Blick auf den Quellcode geworfen hätten, welche Faktoren würden Sie dazu bringen, "hmm, professionelle Arbeit hier" zu sagen, und was würde Sie veranlassen, sich von einem offensichtlich amateurhaften Job zurückzuziehen?

Okay, diese Frage wurde zu mehreren Fragen beim Schreiben. Aber im Grunde genommen Inline-Scripting - was ist los?

47
thesunneversets

was sind die wirklichen Probleme mit Inline-Scripting? Gibt es ein signifikantes Leistungsproblem oder ist es meistens nur eine Frage des guten Stils?

Die Vorteile sind nicht leistungsbasiert, sondern haben (wie Michael in seinem Kommentar hervorhob) eher mit der Trennung von Ansicht und Controller zu tun. Die HTML/CSS-Datei sollte im Idealfall nur die Präsentation enthalten, und für Skripte sollten separate Dateien verwendet werden. Dies erleichtert Ihnen (und Ihren Kollegen) das Lesen und Verwalten der visuellen und funktionalen Aspekte.

Kann ich meinen Vorgesetzten sofortige Maßnahmen in Bezug auf Inline-Skripte rechtfertigen, wenn andere Dinge zu bearbeiten sind, die offensichtlichere Auswirkungen auf die Website haben könnten?

Nein wahrscheinlich nicht. Es kann sehr schwierig sein, die Kräfte, die von reinen Wartungsarbeiten stammen, zu überzeugen, selbst wenn Sie glauben, dass sie dadurch langfristig Geld sparen. In diesem Fall halte ich es jedoch nicht für so wichtig, dass Sie alles stoppen und Ihre Inline-Skripte loswerden. Stellen Sie stattdessen sicher, dass Sie sich bewusst bemühen, Bereiche zu korrigieren, während Sie aus anderen Gründen daran arbeiten. Refactoring-Code sollte etwas sein, das Sie regelmäßig tun, aber immer nur ein bisschen.

Wenn Sie zu einer Website gegangen wären und einen Blick auf den Quellcode geworfen hätten, welche Faktoren würden Sie dazu bringen, "hmm, professionelle Arbeit hier" zu sagen, und was würde Sie veranlassen, sich von einem offensichtlich amateurhaften Job zurückzuziehen?

Der wichtigste Faktor, der mir sagen würde, dass es nicht professionell ist, ist die übermäßige Verwendung von Tabellen oder Divs. Hier ist ein Artikel , der erklärt, warum keiner von beiden überbeansprucht werden sollte.

36

Ich werde nicht der Anwalt des Teufels sein, aber es gibt keine strikte Beziehung zwischen amateurhaftem Job und Inline-JavaScript. Sehen wir uns den Quellcode einiger der bekanntesten Websites an:

  • Google,
  • Wikipedia,
  • Microsoft,
  • Adobe,
  • Dell,
  • IBM.

Jede ihrer Homepages verwendet Inline-JavaScript. Bedeutet das, dass all diese Unternehmen Amateur-Leute einstellen, um ihre Homepages zu erstellen?


Ich bin einer dieser Entwickler, die keinen JavaScript-Code in HTML einfügen können. Ich mache es nie in den Projekten, an denen ich arbeite (außer wahrscheinlich einigen Aufrufen wie <a href="javascript:..."> für Projekte, bei denen unauffälliges JavaScript von Anfang an nicht erforderlich war, und ich entferne immer Inline-JavaScript, wenn ich den Code einer anderen Person umgestalte. Aber lohnt sich die Mühe? Nicht so sicher.

In Bezug auf die Leistung erzielen Sie nicht immer bessere Leistungen, wenn Sie JavaScript in eine separate Datei einfügen. Normalerweise sind wir versucht zu berücksichtigen, dass Inline-JavaScript Bandbreite verschwendet, da es nicht zwischengespeichert werden kann. (außer wenn Sie sich mit statisch zwischengespeichertem HTML befassen). Im Gegenteil, eine externe .js-Datei wird nur einmal geladen.

In Wirklichkeit ist dies nur ein weiteres vorzeitige Optimierung: Sie haben vielleicht Recht, wenn Sie glauben, dass die Externalisierung von JavaScript Ihre Website beeinträchtigen würde, aber Sie können sich auch völlig irren:

  • Was ist, wenn die meisten Ihrer Benutzer einen leeren Cache haben?
  • Haben Sie in Betracht gezogen, dass bei einer externen .js-Datei bei jeder Seitenanforderung eine Anforderung an diese Datei gestellt wird, wenn die Website nicht ordnungsgemäß konfiguriert ist (und normalerweise nicht)?
  • Wird die .js-Datei wirklich zwischengespeichert (mit IIS ist dies möglicherweise nicht so einfach)?

Sammeln Sie also vor einer vorzeitigen Optimierung Statistiken über Ihre Besucher und bewerten Sie die Leistung mit und ohne Inline-JavaScript.

Dann kommt das letzte Argument: Sie haben JavaScript und HTML in Ihrer Quelle gemischt, also saugen Sie. Aber wer hat gesagt, dass Sie beide gemischt haben? Der vom Browser verwendete Quellcode ist nicht immer der von Ihnen geschriebene Quellcode. Beispielsweise kann der Quellcode komprimiert, minimiert oder mehrere CSS- oder JS-Dateien zu einer Datei zusammengefügt werden bedeutet nicht, dass Sie Ihre Variablen wirklich benannt haben a, b, c ... a1 usw. oder dass Sie eine riesige CSS-Datei ohne Leerzeichen oder Zeilenumbrüche geschrieben haben. Auf die gleiche Weise können Sie externen JavaScript-Quellcode beim Kompilieren oder später über die Vorlagen problemlos in HTML einfügen lassen.


Abschließend: Wenn Sie JavaScript und HTML in den von Ihnen geschriebenen Quellcode mischen, sollten Sie in Betracht ziehen, dies in Ihren zukünftigen Projekten nicht zu tun. Dies bedeutet jedoch nicht, dass der an den Browser gesendete Quellcode Inline-JavaScript enthält. es ist immer schlecht.

  • Es kann schlecht sein.
  • Es kann im Gegenteil ein Zeichen dafür sein, dass die Website von Fachleuten geschrieben wurde, die sich um die Leistung kümmerten, bestimmte Tests durchführten und feststellten, dass es für ihre Kunden schneller sein würde, Teile von JavaScript zu integrieren.
  • Oder es kann überhaupt nichts bedeuten.

schämen Sie sich also eher für die Person, die "sehr coole Website, Schande über das Inline-Scripting im Quellcode" sagt, indem Sie sich nur die an den Browser gesendete Quelle ansehen, ohne etwas darüber zu wissen, wie die Website erstellt wurde.

48

Es ist im Allgemeinen gut zu versuchen, HTML und JS im Allgemeinen getrennt zu halten. HTML ist für die Ansicht, JS ist für die Anwendungslogik. Aber meiner Erfahrung nach macht eine extreme Entkopplung von HTML und Javascript (aus Gründen der Reinheit) die Wartung nicht einfacher. es kann tatsächlich weniger wartbar sein.

Zum Beispiel verwende ich manchmal dieses Muster (von ASP.net entlehnt) beim Einrichten von Ereignishandlern:

<input type="button" id="yourId" onclick="clickYourId()" />

oder

<input type="button" id="yourId" onclick="clickYourId(this)" />

Es ist kein Rätsel, was ein Ereignis auslöst. Der Grund dafür ist, dass Sie sechs Monate später das Element überprüfen können (z. B. in Chrome) und sofort sehen können, welches Javascript-Ereignis ausgelöst wird.

Stellen Sie sich andererseits vor, Sie lesen den Code eines anderen, der hunderttausend Zeilen umfasst, und stoßen auf ein magisches Element, das ein Javascript-Ereignis auslöst:

<input id="yourId"  />

Wie können Sie mir leicht sagen, welche Javascript-Methode dies aufruft? Chrome hat dies einfacher gemacht, aber vielleicht ist das Ereignis an die ID gebunden, oder vielleicht ist es an das erste untergeordnete Element des Containers gebunden. Vielleicht ist das Ereignis an das übergeordnete Objekt angehängt. Wer weiß? Viel Glück beim Finden. :)

Außerdem würde ich argumentieren, dass das vollständige Ausblenden von Javascript vor dem Designer die Wahrscheinlichkeit erhöhen kann, dass sie es bei einem Update beschädigen. Wenn jemand Code für ein magisch aktives Element bearbeitet, welche Anzeige im Code weist ihn darauf hin, dass es sich um ein aktives Element auf der Seite handelt?

Kurz gesagt, die beste Vorgehensweise besteht darin, HTML und Javascript zu trennen. Aber auch verstehen, dass Faustregeln manchmal kontraproduktiv sind, wenn sie bis zum Äußersten getragen werden. Ich würde mich für einen Mittelweg aussprechen. Vermeiden Sie große Mengen an Inline-Js. Wenn Sie Inline verwenden, sollte die Funktionssignatur sehr einfach sein:

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)
21
Kevin Seifert

Ein Argument, das mir hier fehlt, ist die Möglichkeit eines erhöhten Schutzes vor Cross Site Scripting Angriffen.

Es ist möglich, die Ausführung von Inline-JavaScript in einem modernen Browser über Content Security Policy zu deaktivieren. Dies verringert das Risiko, dass Ihre Website Opfer von XSS wird. Dies kann ein überzeugenderes Argument für Ihr Management sein, um in das Entfernen von Inline-Skripten zu investieren.

11
MvdD

Hier sind einige Gründe.

  1. Inline-Skript kann nicht minimiert werden (durch Symbolreduzierung in eine kürzere Version konvertiert). Kein Problem mit Breitband, aber ein mobiles Gerät in einem Gebiet mit geringer Bandbreite oder Benutzer mit globalem Datenroaming - jedes Byte kann zählen.

  2. Inline-Skripte können vom Browser nur zwischengespeichert werden, wenn die Seite selbst zwischengespeichert werden kann (was zu einer sehr langweiligen Seite führen würde). Externe Javascript-Dateien müssen nur einmal abgerufen werden, auch wenn sich der Seiteninhalt jedes Mal ändert. Kann die Leistung bei Verbindungen mit geringer Bandbreite ernsthaft beeinträchtigen.

  3. Inline-Skript ist schwieriger zu debuggen, da die mit einem Fehler verbundene Zeilennummer bedeutungslos ist.

  4. Inline-Skripte beeinträchtigen angeblich die Überlegungen zur Barrierefreiheit (508/WAI), obwohl dies nicht bedeutet, dass alle Inline-Skripte Probleme verursachen. Wenn Sie am Ende einen Bildschirmleser haben, der Skriptinhalte ankündigt, haben Sie ein Problem! (Ich habe das allerdings noch nie gesehen).

  5. Inline-Skript kann nicht unabhängig von seiner Seite getestet werden. Externe Javascript-Dateien können durch unabhängige Tests, einschließlich automatisierter Tests, ausgeführt werden.

  6. Inline-Skripte können zu einer schlechten Trennung von Bedenken führen (wie in vielen anderen Antworten hier beschrieben).

9
John Wu

Es gibt mehrere Gründe, die es rechtfertigen würden, das Skript nicht inline aufzunehmen:

  • Zuallererst die offensichtliche Antwort: Sie sorgt für Code, der sauberer, prägnanter, leichter zu verstehen und zu lesen ist.

  • Aus praktischer Sicht möchten Sie häufig Skripte/CSS/etc. Wiederverwenden. Wenn Sie diese Teile auf Ihrer gesamten Website einbinden, müssen Sie jede einzelne Seite jedes Mal bearbeiten, wenn Sie eine kleine Änderung vornehmen.

  • Wenn Sie ein SCM für Ihr Projekt verwenden, erleichtert die gute Trennung Ihrer verschiedenen Komponenten die Nachverfolgung von Änderungen und Festschreibungen für alle Beteiligten.

Soweit ich weiß, wäre die Leistung kein Problem. Dies hängt von vielen Faktoren ab, die mit der Art Ihrer Website, den technischen Daten Ihres Servers usw. zusammenhängen. Wenn Ihre Webseite beispielsweise viel Javascript verwendet, kann Ihr Browser die Skripte zwischenspeichern, was zu einer besseren Leistung führen würde, wenn Der Code ist in mehrere Dateien unterteilt. Andererseits wäre ich versucht zu sagen, dass einige Server eine einzelne große Datei möglicherweise schneller bereitstellen als mehrere kleinere Dateien. In diesem Fall könnte man argumentieren, dass das Nicht-Trennen des Codes in Bezug auf die Leistung besser ist.

Mir sind keine formalen Tests in diesem Bereich bekannt, obwohl es sehr wahrscheinlich ist, dass jemand sie durchgeführt hat.

Am Ende würde ich sagen, dass es vor allem um bewährte Verfahren geht und dass die Vorteile in Bezug auf Lesbarkeit und Organisation (insbesondere Punkt 2) die Trennung des Codes in verschiedene Dateien zu einer viel besseren Option machen.

3
Bitgarden

Die Antwort hängt wirklich davon ab, wie der Inline-Code (unter der Annahme von Javascript) verwendet wird.

Wir haben eine Kombination aus Inline-Code, SSIs (serverseitige Includes), JS-Dateien und CSS-Dateien verwendet, um die gewünschten Effekte zu erzielen und die Server-Rückfahrten für onClick-Ereignisse zu reduzieren.

Es kann also irreführend sein, wenn jemand pauschal feststellt, dass die Verwendung von "Inline-Code" schlecht ist, ohne vollständig zu verstehen, wie er verwendet wird.

Wenn jedoch jede Seite dieselbe Kopie und denselben eingefügten Javascript-Code hat, anstatt eine js-Datei zu verwenden, sage ich, dass dies schlecht ist.

Wenn jede Seite eine eigene Kopie und einen eingefügten CCS-Abschnitt hat, anstatt eine CSS-Datei zu verwenden, sage ich, dass das schlecht ist.

Es ist auch sehr aufwändig, Ihre gesamte js-Bibliothek auf jeder Seite einzuschließen, insbesondere wenn keine der Funktionen auf dieser Seite verwendet wird.

Ich gehe hier von Inline-Javascript aus.

Ohne den Code zu sehen, ist es schwer, sicher zu sein. Ich vermute, er bezog sich auf eines von zwei Dingen:

  1. Sie haben <script> Auf der Seite verteilt
  2. Alles, was Sie JS ist, befindet sich in der Kopfzeile der Seite, nicht in externen Dateien

Das erste ist eine schlechte Designentscheidung. Durch das Verteilen von Skripten in einer Quelldatei ist die Seite viel schwieriger zu pflegen, da Sie nach einem bestimmten Skript suchen müssen. Es ist viel besser, den gesamten Code an einem Ort aufzubewahren (ich bevorzuge es oben in der Quelldatei).

Was die zweite betrifft - das ist nicht unbedingt eine schlechte Sache. Seitenspezifischer Code sollte auf dieser Seite sein. Wenn Sie doppelten Code zwischen den Seiten haben, sollten Sie ihn mit <script src> Externalisieren. Wenn Sie dann eine neue Seite erstellen, können Sie diese Datei einfach einfügen, und alle Fehler, die Sie dort behoben haben, müssen nicht erneut überprüft werden.

1
Michael K

Ein Grund, InLine Javascript NICHT zu verwenden (nicht einmal onclick = "DoThis (this)" auf Schaltflächen), ist, wenn Sie beabsichtigen, Ihre Webanwendung zu einer Chrome App. Zu machen. Also, wenn Sie planen Um Ihre Web-App in eine native App zu portieren Chrome App, beginnen Sie damit, KEIN Inline-Javascript einzuschließen. Dies wird gleich zu Beginn erklärt, was Sie (obligatorisch) an Ihrer Web-App ändern müssen, wenn Sie beabsichtigen, es zu "verchromen".

1
FraCoinsuy

Was sind die wirklichen Probleme mit Inline-Scripting?

Inline-Skripte sind schlecht und sollten vermieden werden, da sie das Lesen des Codes erschweren.

Schwer lesbarer Code ist schwer zu pflegen. Wenn Sie es nicht leicht lesen und verstehen können, was los ist, können Sie Fehler nicht leicht erkennen. Wenn es schwierig zu warten ist, wird es später mehr Zeit verschwenden, wenn es Probleme gibt.

Die Schwierigkeit ergibt sich normalerweise aus verschachtelten Codierungen. In der nächsten Codezeile gibt es ein Problem. Können Sie es erkennen?

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

Im Idealfall ist Code so geschrieben, dass Fehler leicht erkannt werden können. Joel Spolsky hat bereits 2005 einen großartigen Artikel geschrieben, der diesen Punkt hervorhebt . Die Codebeispiele könnten erheblich verbessert werden, da sie ein Alter von 9 Jahren aufweisen. Das zugrunde liegende Konzept ist jedoch nach wie vor stark: Schreiben Sie Code so, dass Fehler leicht erkannt werden können.

Gibt es ein signifikantes Leistungsproblem oder ist es meistens nur eine Frage des guten Stils?

Inline-Scripting führt zu Wiederholungen. Anstatt eine Codezeile so zu ändern, dass sie 100 Seiten betrifft, müssen Sie wahrscheinlich 100 Seiten einzeln ändern. Dies zusammen mit einer schlechten Lesbarkeit beeinträchtigt die Leistung des Betreuers erheblich. Die Programmierzeit verursacht echte Kosten, die sich schneller als die wenigen Millisekunden nach den meisten Codeoptimierungen auf das Unternehmensergebnis auswirken. Natürlich ist es wichtig, Engpässe zu optimieren, aber der Leistungsunterschied des Codes ist in diesem Fall vernachlässigbar.

Kann ich meinen Vorgesetzten sofortige Maßnahmen in Bezug auf Inline-Skripte rechtfertigen, wenn andere Dinge zu bearbeiten sind, die offensichtlichere Auswirkungen auf die Website haben könnten?

Nein. Wenn es dumm ist und funktioniert, ist es nicht dumm.

Die Programmierfolge daraus ist: Wenn es dummer Code ist und funktioniert, ist es kein dummer Code. Konzentrieren Sie sich auf die eigentlichen Probleme, bevor Sie versuchen, etwas zu beheben, das nicht kaputt ist. Wenn der Inline-Code irgendwann aktualisiert werden muss, sei es in sechs Stunden, sechs Monaten oder sechs Jahren, korrigieren Sie den Code so, dass die zukünftige Wartung einfacher wird.

Welche Faktoren würden Sie dazu bringen, "hmm, professionelle Arbeit hier" zu sagen, und was würde Sie veranlassen, sich von einem offensichtlich amateurhaften Job zurückzuziehen?

Ich neige dazu, "professionell" nur als jemanden zu definieren, der für die Ausführung einer Aufgabe bezahlt wird, anstatt davon auszugehen, dass er über eine bedeutende Fähigkeit verfügt, für die er bezahlt wird. Viele Profis sind sicherlich in der Lage, gute Arbeit zu leisten, aber meistens bin ich entsetzt über die schreckliche Arbeit, die andere Profis geleistet haben, und nicht über etwas, das sich ein Amateur ausgedacht hat. Ein Großteil meiner bisherigen Arbeit bestand darin, Zugunglücksprojekte zu retten, die von den ursprünglichen Entwicklern verpfuscht wurden, sodass Ihre Kilometerleistung variieren kann.

Nach alledem ist es im Allgemeinen einfach, Programme in Unternehmensqualität auszuwählen

0
zzzzBov