Warum sind HTML/JavaScript/CSS keine kompilierten Sprachen und werden sie es jemals sein?

Warum werden HTML/JavaScript/CSS nicht zu kompilierten Sprachen (oder verschmelzen vielleicht sogar zu einer einzigen kompilierten Sprache)? Was wäre, wenn Browser “Browser Virtual Machine” ausführen würden und HTML/Javascript/CSS-Quellen zu einem “Browser-Bytecode” kompiliert werden könnten. Würde es Entwicklern und Benutzern nicht sehr helfen?

Ich sehe ein paar Herausforderungen:

1. Was tun mit Millionen vorhandener Seiten? Machen Sie diese Kompilierung optional, also können Sie, wenn Sie möchten, einfaches altes HTML verwenden. Wenn Sie einen Browser mit einer kompilierten Seite füttern möchten, verwenden Sie zum Beispiel einfach .chtml.

2. Wie würden Suchanbieter Seiten indizieren? Erstellen Sie einen Decompiler, der Bytecode in exakte Originalquellen dekompiliert (z. B. wie Flash dekompiliert werden kann). Oder Suchanbieter können dieselbe virtuelle Maschine verwenden und die benötigten Daten von dort abrufen.

3. Wie macht man es mit allen Browsern kompatibel? Lassen Sie einen zentralen Entwickler (sagen wir w3c) diese virtuelle Maschine entwickeln, und dann würde jeder Browser sie einbetten.

Aber was ist mit den Vorteilen:

1. Geschwindigkeit.
2. Größe.
3. Kein “lockeres” und “halbkorrektes” HTML mehr. Entweder ist es richtig oder es lässt sich nicht kompilieren.
4. Sieht in jedem (unterstützten) Browser gleich aus.

Wenn es kein Bytecode ist, dann haben Sie zumindest eine native Komprimierung, HTML ist wahrscheinlich nicht die effizienteste Art der Datenspeicherung. Ich weiß, dass es gzip gibt, aber warum Seiten jedes Mal auf einem Server komprimieren und in einem Browser dekomprimieren, wenn wir sie einmal komprimieren und einem Browser zuführen können?

Was hält uns also davon ab, diesen Weg zu gehen (naja, abgesehen von einem enormen Aufwand, um alles zu verwirklichen)?

Ah, aber Javascript wird zu einer kompilierten Sprache. Testen Sie Firefox 3.5 mit TraceMonkey. Es ist wahnsinnig schnell im Vergleich zu dem Browser von ähm du-weißt-schon-wem. Es stimmt, dass JS niemals C sein wird, aber es ist eine viel dynamischere Sprache als C, und das macht sie in vielerlei Hinsicht ausdrucksstärker und leistungsfähiger.

Was HTML angeht, glaube ich nicht, dass die fehlende Validität von HTML ein großer Nachteil für die Geschwindigkeit ist. Ich denke, die Engines, die die visuelle Darstellung zusammenstellen und das DOM manipulieren, müssen viel besser werden (ähm, IE, ich schaue in Ihre allgemeine Richtung …). CSS-Compliance muss besser werden, und CSS selbst muss leistungsfähiger werden. (Steigen Sie mit CSS 3 Personen in den Bus!)

Aber ich denke, dass die Geschwindigkeit bei Firefox und Chrome in einem solchen Ausmaß besser werden wird, dass die Leute wirklich anfangen werden, sie für die Entwicklung von Mainstream-Anwendungen zu verwenden. Es ist lustig. Adobe scheint Flash als Plattform für dynamische Webinhalte zu verkaufen, MSFT verkauft Silverlight für dynamische Webinhalte und Google möchte HTML und Javascript wirklich verbessern, um dynamische Webinhalte anzuzeigen. Und Google macht das bisher ziemlich gut, muss ich sagen…

Ihre Ideen haben Gültigkeit, wenn sie auf JavaScript angewendet werden. Wie andere angemerkt haben, versuchen mehrere Anbieter bis zu einem gewissen Grad, diese Prinzipien sogar jetzt auf JS anzuwenden. Ein weiterer großer Schritt in diesem Bereich wird wahrscheinlich das von Google angekündigte Chrome OS sein. Wenn es jedoch um (X)HTML und CSS geht, denke ich, dass Ihre Ideen den Punkt verfehlen.

Das World Wide Web ist keine fehlerhafte und inkonsistente Anwendungsplattform, sondern eine riesige und beispiellose Sammlung miteinander verbundener Dokumente. Die Stärke des Webs liegt in der Abstraktion der Daten von den oft starren (und zerbrechlichen) visuellen Layouts und den zunehmend komplexen In-Page-Funktionen, die größtenteils über JavaScript bereitgestellt werden. Die Kodierung dieser Seiten in (X)HTML ist ideal, um sie einem möglichst breiten Publikum zugänglich zu machen, sowohl in Bezug auf Browser als auch in Bezug auf das technische Wissen, das zum Verfassen einer Seite erforderlich ist.

Das Web wird immer mehr als Anwendungsplattform genutzt – was eine leistungsstarke und aufregende Nutzung dieser Technologie darstellt – aber wir dürfen nicht aus den Augen verlieren, dass diese Ajax-gesteuerten „Web 2.0“-Apps lediglich Dokumente mit erweiterter Funktionalität sind. Die Kompilierung ist für ein Dokument nicht sinnvoll und die Komprimierung findet bereits statt (über gzip und dergleichen).

Praktischerweise bewegt sich das W3C im Tempo eines Gletschers und die Browser-Anbieter wechseln sich ab, indem sie experimentelle Funktionen in unfertigen Spezifikationen unterstützen und sich die Zeit nehmen, andere Spezifikationen zu unterstützen, die seit Jahren auf dem Tisch liegen und allgemein verwendet werden . Der ganze Prozess ist wie das Hüten von Katzen. Ich würde nicht den Atem anhalten, damit sie die radikalen Änderungen vornehmen, die Sie in absehbarer Zeit vorschlagen.

Da HTML und CSS kein Code sind, können sie nicht kompiliert werden. Die V8-Engine von Google Chrome wandelt JS tatsächlich in Bytecode um, erwarten Sie, dass andere Rendering-Engines diesem Beispiel folgen werden!

http://code.google.com/apis/v8/design.html

Wir haben kürzlich ein PHP-Template-System überarbeitet, an dessen Erstellung ich mitgewirkt habe, um mit minify mehrere JS- und CSS-Dateien in jeweils eine Datei zu komprimieren, wobei wir feststellen mussten, dass unsere Dateigrößen auf etwa 20 % der ursprünglichen kombinierten Größen gesunken sind. Minify macht auch gzip und Caching, also ist es wirklich erstaunlich, um Websites zu beschleunigen.

http://code.google.com/p/minify/

Kurz gesagt, Sie können keinen Nicht-Code kompilieren, was HTML und CSS sind. JS kann kompiliert werden und beginnt damit, aber alles hängt davon ab, worauf der Browser Lust hat.

Browser müssen lediglich bezüglich der Unterstützung von Webstandards auf dem Laufenden sein. Je mehr Browser dies tun, desto weniger Kopfschmerzen haben wir Webentwickler. Ich war ziemlich zufrieden mit YouTubes sehr öffentlicher Einstellung der Unterstützung für IE6. Wir brauchen mehr solche Maßnahmen, damit das Web vorankommt.

Das V8 Javascript-Engine (ebenfalls in Google Chrome eingebettet, aber Open Source und frei lizenziert, sodass Sie sie gerne im nächsten Browser, den Sie schreiben, verwenden können!) kompiliert Javascript in nativen Maschinencode – natürlich tut sie es “nur rechtzeitig“ (wie die meisten modernen Compiler – Java, C# usw.!), nicht „der Zeit voraus“ (wie es Fortran 1954 tat, als Computer einfach zu schwach waren, um die Kompilierung mitten in der Ausführung zu bewältigen). Ich wäre überrascht, wenn andere gute JS-Engines, wie die in den neuesten Versionen von Firefox und Safari, nicht dasselbe tun würden.

Sieht so aus, als würden Sie nicht “Javascript als kompilierte Sprache” befürworten (da es offensichtlich bereits kompiliert ist, wenn Sie eine gute JS-Engine verwenden), sondern eher eine “vorzeitige” Kompilierung dafür (gerade wenn die modernste Sprachen verzichten im Wesentlichen auf die vorzeitige Kompilierung). Maschinencode anstelle von kompilierbarem Code durch die Leitung zu schieben, klingt nach einer größtenteils schrecklichen Idee – viel größer, Schwierigkeiten bei der Unterstützung einer CPU im Vergleich zu einer anderen, Sicherheitsalpträume beim ordnungsgemäßen Sandboxing usw. usw.) mit nicht viel kompensierendem Nutzen.

Das heißt, wenn Sie wirklich daran interessiert sind, Maschinencode an den Client zu übertragen, probieren Sie es aus nativer Client (Solange der Client ein x86-Computer ist – vergessen Sie jedes Smartphone auf dem Planeten, viele Netbooks, gute alte Macs usw.) – zumindest verspricht es eine Lösung für die Sicherheitsalpträume. Wenn Sie mit nativeclient zufrieden sind, ist die Umwandlung eines Just-in-Time-Compilers in einen Ahead-of-Time-Compiler eine weitaus einfachere technische Herausforderung (wenn Sie natürlich weiterhin Javascript für die Quellen anstelle anderer Sprachen verwenden möchten). ).

Siehe hier für eine frühere Diskussion zu diesem Thema

Nicht alle der angegebenen Gründe sind unbedingt gültig, aber ein wichtiger ist, dass serverseitige CPU-Zyklen viel wertvoller sind als clientseitige Zyklen, es sei denn, Sie sind Google. Daher ist es einfacher, den Client was kompilieren/optimieren zu lassen ist ziemlich oft dynamisch generiertes HTML/JavaScript und nicht der Server.

Ken

Geschwindigkeit.

Sie gehen davon aus, dass das Parsen von HTML viel Zeit in Anspruch nimmt. Es kann jedoch sein, dass diese Zeit im Vergleich zu der Zeit, die für etwas anderes benötigt wird, unbedeutend ist, z. B. die Zeit, die zum Layouten des Textes im Fenster des Endbenutzers erforderlich ist.

Kein “lockeres” und “halbkorrektes” HTML mehr. Entweder ist es richtig oder es lässt sich nicht kompilieren.

Das bekommen Sie bereits, wenn Sie verwenden [X]HTML.

Sieht in jedem (unterstützten) Browser gleich aus.

Sie scheinen zu sagen, dass es nur einen Browser geben sollte oder dass alle Browser ihn gleichermaßen unterstützen würden.

Internetstandards entstehen nicht dadurch, dass eine einzige Stelle (das w3c) etwas implementiert und es zum Standard erklärt. Stattdessen entstehen Internetstandards, indem mehrere unabhängige Stellen mehrere Implementierungen erstellen. Eine Konsequenz ist:

• Einige Leute haben etwas entwickelt, das noch nicht Standard ist (dh sie sind dem Standard voraus).
• Einige Leute haben noch nichts Standardisiertes entwickelt (dh sie sind hinter dem Standard zurück)

Ich denke, Ihre Idee ist vernünftig, aber es gibt immer noch keine Möglichkeit, einen Standard durchzusetzen. Wenn es also eine nicht unterstützte Funktion gibt, besteht eine gute Chance, dass auf der gesamten Seite einfach nichts angezeigt wird. Im aktuellen Setup können noch kritische Informationen weitergegeben werden.