Welchen Vorteil hat die Sprachhomogenität in Web-Apps?

Nun, ich habe ein Jahr mit Parenscript und ht-ajax programmiert und schließlich aufgegeben und das Javascript nur von Hand generiert (immer noch mit hunchentoot auf dem Server). Ich fand, dass das Ergebnis viel vorhersehbarer war und es, wie Sie in Ihrer Frage andeuten, viel einfacher war, herauszufinden, was bei der Verwendung von Firebug vor sich ging. (Ich wechselte auch zu jquery, was viel besser war als ht-ajax, aber das ist nicht wirklich das, was du verlangst).

Das heißt, ich kann cl-who ( Ссылка ) nur wärmstens empfehlen, was die dynamische HTML-Generierung wesentlich angenehmer macht.

  

Die Frage ist, wie wertvoll ist diese Homogenität in der realen Welt?

Wahrscheinlich ziemlich bedeutungsvoll: Schau dir all die Leute an, die serverseitiges JavaScript in diesen Tagen machen. Javascript ist nichts Superlatives und seine Bibliotheks-Unterstützung für serverseitigen Code ist überhaupt nicht so toll, aber es gibt große Vorteile, wenn man es benutzt.

  

Wenn etwas schief geht, müssen Sie die Seite in Firebug laden,

Hängt davon ab, was das "Alles" ist. Ich kann mich nicht wirklich an das letzte Mal erinnern, als ich Firebug öffnen musste, um zu sehen, was schief läuft - ich habe sicherlich Phasen durchgemacht, in denen es war, aber es gibt auch viele Male, wenn es nicht ist.

Wenn Sie zum Beispiel Ihr CSS von s-exps generieren, können Probleme mit Ihrem CSS dazu führen, dass Sie sich nur das "kompilierte" CSS für seltsame Syntaxprobleme (wie IE6-Tricks) ansehen müssen. Wenn Sie nur auf die Seite schauen und entscheiden, dass Sie einen zusätzlichen Rahmen benötigen, können Sie (:border 1) hinzufügen und fertig sein. (Wenn Sie das verarbeiten, um eine ganze Reihe von CSS-Regeln für den Client zu generieren, ist das natürlich ein noch größerer Gewinn.)

Eine andere Möglichkeit, darüber nachzudenken: In sehr seltenen Fällen musste ich einen Paket-Sniffer und einen Disassembler herausziehen, wenn ich an einer modernen Web-App arbeite. Ja, es ist scheiße, aber mit guten Bibliotheken ist es auch sehr ungewöhnlich. Ich würde nicht lieber Low-Level-Code den ganzen Tag schreiben, nur um die Impedanz-Fehlanpassung des Umschaltens zu einem Paket-Sniffer in seltenen Fällen zu vermeiden, wenn ich diese Ebene von Informationen brauche.

Dies setzt voraus, dass Sie zu einem Level gelangen wollen und können, auf dem Sie (V) HLL-Code schreiben. Common Lisp kann C nicht mit C übertreffen, und wenn Sie nur versuchen, einen einfachen Blog in HTML auszuspucken, dann sind Sie auch nicht in der besten Lage: Rails ist schon sehr gut in dieser Art von Sache. Aber es gibt eine Menge experimentelle Programmierung, bei der es möglich ist, ein Flag zu ändern und Code auf dem Client statt auf dem Server auszuführen.

  

und dann sehen Sie sich das generierte HTML, CSS und Javascript an, nicht die Lisp-Quelle, also müssen Sie das Mapping in Ihrem Kopf halten. Löst die Homogenität, die von Lisp bereitgestellt wird, wirklich irgendetwas aus, oder tapeziert nur das Problem, das schließlich wieder flussabwärts auftaucht?

Ich habe all-Lisp und all-Javascript-Web-Apps geschrieben, und ich denke, die beste Antwort, die ich jetzt geben kann, ist: es könnte . Ich habe Parenscript verwendet, und das Hauptproblem ist, dass Parenscript eine Lisp-y-Sprache ist, aber es ist nicht Common Lisp, noch ist es eine andere vollständige Sprache, die Sie auf der Serverseite verwenden können. (Wenn es einen Common-Lisp-zu-Javascript-Compiler gäbe, wie GWT für Java, dann wäre es großartig. Ich sehe jedoch niemanden, der ernsthaft versucht, einen zu erstellen.) Sie haben also immer noch, wie Sie beobachten, zwei Sprachen.

Javascript ist in dieser Hinsicht ein bisschen besser, weil Sie an beiden Orten genau denselben Code ausführen können. Es ist nicht ziemlich ideal, weil Ihr serverseitiges JavaScript wahrscheinlich Funktionen hat, von denen Sie nicht garantieren können, dass sie auf der Client-Seite existieren (es sei denn, Sie beschränken Ihre Benutzer beispielsweise auf neuere Firefox-Versionen). Wenn Sie wie ich sind, möchten Sie Ihren Server-Code nicht auf JS beschränken, das in jedem Browser ausgeführt wird. Daher unterscheiden sich Ihre serverseitigen JS- und clientseitigen JS subtil. Es ist kein Dealbreaker - es ist immer noch schön - aber es sind immer noch zwei leicht verschiedene Sprachen.

Ich denke, es wäre ziemlich cool, wenn es ein Programm gäbe, das Code im neuesten Javascript (1.8.5) schreiben könnte, und generiertes Javascript, das in jedem Browser lief. Ich glaube nicht, dass ein solches Programm existiert, aber ich weiß nicht, wie schwierig es sein würde.

Es gibt Schema-Implementierungen für Javascript, und daher ist die Situation mit Schema möglicherweise besser. Ich sollte wahrscheinlich in diesen Tagen schauen.

Ich bin oft frustriert, wenn ich eine serverseitige Sprache verwenden muss, die sich komplett von meiner clientseitigen Sprache (Javascript) unterscheidet. Aber dann bin ich auch frustriert, wenn ich eine Sprache verwenden muss, die niedriger als Lisp ist (was die meisten von ihnen sind). Ist es ein größerer Gewinn, mehr Lisp-artig oder mehr Javascript-ähnlich zu sein? Ich weiß es nicht. Ich wünschte, ich hätte nicht wählen müssen.

Dies ist nicht so sehr eine Antwort als eine starke Meinung, aber das grundlegende Problem ist, dass HTML und CSS einfach schrecklich sind (1). Es ist auch nicht gut, was es angeblich tun soll. Javascript ist besser und wird oft in den Dienst gedrückt, um die Mängel dieser beiden (2) auszugleichen, aber es ist keine ideale Lösung (3). Und als Ergebnis werden serverseitige Sprachen benötigt, um HTML und CSS zu erzeugen, was das Chaos noch weiter verkompliziert. Es ist lächerlich, dass die einfachste Webanwendung in nicht weniger als vier verschiedenen Sprachen programmiert werden muss.

Ja, ja, Ihr Wunsch, eine gute, zuverlässige Sprache zu haben, die Sie anstelle der anderen verwenden können, ist verständlich, aber solange Sie Code schreiben, der HTML / CSS generiert, so dass Sie sich um die Details kümmern müssen von HTML und CSS, dann trägst du nur Fäustlinge, die sich (wenn du "wahrscheinlich" liest) störend auswirken, wenn du zum Klavierspiel gehst. Wenn Ihr Lisp-Code so aussieht: (: body (: div (: @ (: style (: border "1"))) (: p "hallo"))), dann sind Sie nicht wirklich frei von den Sorgen das plagen dich.

Persönlich denke ich, dass wir etwas anderes brauchen, um die Suppe, die wir jetzt haben, zu ersetzen, und sie zu HTML / CSS / JS kompilieren sollte, aber den Benutzer von ihren Sorgen frei halten sollte. C kompiliert zur Assembly, aber der C-Programmierer sieht die STA-, MOV-, LDX-Opcodes, die er kompiliert, nie in seinem eigenen geschriebenen Code. Und sollte es populär sein, könnten die Browser es direkt unterstützen. Wie auch immer, es ist nur eine Idee. Ein Schimmer.

Viel Glück,

Chris Perkins
medialab.com

(1) HTML-Dokumente sind zusammengesetzte Dokumente mit Bildern, Skripten, Stylesheets usw., die alle in anderen Dateien gespeichert sind. Aber die eine Sache, die ein HTML-Dokument nicht tun kann, ist die flüssige Einbettung eines anderen HTML-Dokuments - die eine Sache, die es am meisten braucht. Iframes / Objekt-Tags haben eine feste Größe und beide beeinträchtigen die SEO. Diese eine triviale Aufgabe ist oft der einzige Grund, warum eine serverseitige Sprache wie PHP auf vielen Websites verwendet wird.
Du brauchst mich nicht, um dir zu sagen, wie schlecht CSS ist.

(2) Beispiele sind zahlreich: LESS (lesscss.org), document.write, AJAX und mehr.

(3) Der Unterschied zwischen den Javascript DOM und CSS Regeln ist fast unglaublich. Wie viele Höhen hat ein Div im DOM (scrollHeight, offsetHeight, clientHeight und mehr)? 4 oder mehr, vielleicht? Wie viele davon sind über CSS adressierbar? 0 oder 1. Auch wenn Javascript viele Lücken schließen kann, tut es dies oft auf Kosten von SEO

Javascript ist wirklich in einer separaten Kategorie von css und html, wenn Sie etwas wie parenscript machen. Es klingt, als könnte es gut sein, wenn es wirklich gut gemacht wird. Ein solches Beispiel habe ich jedoch nicht erlebt. Ich habe es nicht probiert, aber Ruperts Antwort spricht nicht gut darüber. Persönlich benutze ich coffescript, das anstatt eine vorhandene Sprache auf Javascript abzubilden, eine bessere aufbaut. Sie wissen, was es generiert, weil es sehr sauber zu Javascript mappt, und das macht es einfach zu debuggen.

Wenn Sie nur Werte aus Ihrer Anwendung in Javascript einfügen möchten, dann sind die Prinzipien denen für HTML und CSS ähnlich. Im Folgenden werde ich meine Erfahrung als Ruby-Web-Entwickler und als Beitrag zum Haskell-Web-Framework Yesod ansprechen - aber ich denke, es verallgemeinert sich darauf Webentwicklung in jeder Sprache.

Stellen Sie sich eine HTML-Vorlage als DSL zum Erzeugen von HTML vor. Gibt es eine Reihe von Doppelpunkten vor den Tag-Namen (oder in anderen Sprachen / Systemen, die Tag-Namen-Funktionsaufrufe machen) wirklich eine Verbesserung der DSL? Offensichtlich ist es horning HTML in die Sprache, wo man leicht die Vorlage manipulieren kann, anstatt die Templating-Sprache besser zu machen.

Der Lisp-Code erfordert keine abschließenden Tags, aber es gibt keinen Grund, warum eine Vorlage dies tun sollte. HAML ist eine sehr mächtige und DRY-Templating-Sprache, die ursprünglich in Ruby geschrieben wurde und deren Konzepte nun portiert wurden andere Sprachen, und es gibt andere Template-Sprachen mit unterschiedlicher Syntax, die das wichtige Konzept eines White-Space-basierten Layouts beibehalten, anstatt abschließende Tags zu schreiben. Mein Problem mit HAML ist, dass es die HTML-Syntax komplett verwirft. Ich habe das Gefühl, dass es in HAML statt in Code html ist. Im Yesod-Web-Framework haben wir das HAML-Konzept verwendet, aber die normale HTML-Syntax DRY verwendet - wir nennen es hamlet .

Einer der Gründe dafür, all html im Code zu generieren, ist, dass es andernfalls umständlich wäre, einige Ihrer Template-Snippets direkt in Code zu stecken - das haben wir gut gelöst in Hamlet mit Haskells Quasiquotes - in anderen Sprachen benötigen Sie möglicherweise einen Funktionsaufruf und eine mehrzeilige Zeichenfolge, die je nach mehrzeiliger Zeichenfolgensyntax in unterschiedlichem Maße umständlicher ist.

Diese Konzepte funktionieren genauso gut mit CSS. HAML-Benutzer verwenden SASS oder SCSS (die wir jetzt im Wesentlichen auch auf Jessod portieren). Hier sind Python-Entsprechungen

So stellen Vorlagen eine Syntax dar, die für alle frei ist, die HTML als Code nicht zusammenbringen kann. Wenn Sie mit einer Vorlage eine Hilfsfunktion aufrufen können, die HTML generiert, haben Sie nicht viel Energie verloren.

Ein Aspekt der Generierung von html, css und js aus Code ist die einfache Möglichkeit, sie zu gruppieren und mit der Anwendungslogik zu interagieren. Wenn Sie beispielsweise ein Datumsfeld haben möchten, das ein JavaScript-Kalender-Popup verwendet, benötigen Sie HTML, CSS und JS, die alle zusammen funktionieren. Sie möchten, dass sich diese direkt nebeneinander in Ihrer Quelle befinden , aber in der HTML-Seite voneinander oder in separaten Dateien, wenn sie vom Client empfangen werden. In Yesod haben wir Widgets , um das im Code oder mit 3 separaten Dateien zu erreichen. In HAML kann man Teile desselben Templates als html, javascript oder css deklarieren, obwohl man eigene Helfer aus dem Framework oder der Anwendung benötigt, wenn man sie intelligenter kombinieren möchte.