Warum sind Web-Frameworks nicht einfach, elegant und unterhaltsam wie Programmiersprachen? [geschlossen]

10

Wenn ich an so ziemlich jede Programmiersprache denke - wie C, C ++, PHP, SQL, JavaScript, Python, ActionScript, Haskell, Lua, Lisp, Java usw. -, würde ich gerne eine Computeranwendung mit einer beliebigen entwickeln dieser Sprachen.

Aber wenn ich an Web-Frameworks denke (ich mache hauptsächlich PHP) - wie Cake, CI, Symfony, Laravel, Zend, Drupal, Joomla, Wordpress, Rails, Django usw. - bin ich wie Gott nein.

Warum gibt es keine Web-Frameworks, die mir einfache, unterhaltsame und leistungsstarke Konstrukte wie eine Programmiersprache bieten?

Ryan
quelle
2
"Ich bin großartig, ich würde gerne eine Computeranwendung mit einer dieser Sprachen entwickeln." Und beherrschen Sie eine dieser Sprachen? Denn jeder, der weiß, was er tut, wird Ihnen sagen, dass keine Sprache elegant ist oder Spaß macht. Sie sind nur Werkzeuge, um Ihre Ziele zu erreichen, und als Werkzeuge haben sie ihre Probleme und Mängel.
Euphoric
14
@Euphoric Mit 10 Jahren Erfahrung bin ich anderer Meinung. Einige Sprachen sind Spaß an der Arbeit mit; andere sind ein Schmerz. Und es gibt einige gut gestaltete, die auch elegant sind. Ich stimme jedoch zu, dass sie alle ihre eigenen Probleme haben.
Izkata
@ Izkata 10 Jahre mit jedem von ihnen?
Euphoric
5
@Euphoric Ungefähr 10 Jahre in einer Handvoll Sprachen, aber alle ziemlich unterschiedlichen Typen (in der Größenordnung von C gegenüber Javascript) und ungefähr 3 Jahre einer ganzen Reihe mehr. Ich habe ein Drittel der in der Frage genannten verwendet und viele weitere nicht erwähnt (einschließlich meines Favoriten Rebol). Für mich zum Beispiel sind Javascript und Rebol "lustige" Sprachen, während Rebol und Lisp "elegant" sind (und ich habe gehört, dass Haskell es auch ist, aber ich weiß es nicht). Wenn Sie eine Sprache genug verwenden und auf ihre Stärken und Schwächen stoßen, bilden sich diese "lustigen" und "eleganten" Meinungen schnell von selbst.
Izkata
4
Die Anzahl grundlegender atomarer Konzepte in einer Programmiersprache ist gering und leicht zu verstehen, daher ist es einfach, elegante Werkzeuge um solche Konzepte herum aufzubauen. Die Anzahl der irreduziblen Konzepte, die für die einfachste Webinteraktion erforderlich sind, ist viel größer. Komplexe Probleme führen unvermeidlich zu komplexen, hässlichen Lösungen.
SK-Logik

Antworten:

19

Ich hatte diese Frage auch jahrelang, obwohl ich auf Python-Seite bin. Ich habe keine einzige Erklärung für dieses Phänomen, aber hier sind meine Gedanken zu diesem Thema:

  • Web-Frameworks müssen sich mit XML-Markup-Sprache - HTML, einem Teil der aktuellen Web-Triade HTML-CSS-JavaScript - auf Client-Server-Weise befassen. Es bedeutet drei Sprachen, die miteinander interagieren, ein Browser-DOM und ein Ausführungsmodell (und ein Sicherheitsmodell). Tatsächlich sollte jede Funktionalität (ein "Modul") ihren Code in allen drei Sprachen haben. Hinzu kommt, dass die Auswahlsprache von jQuery zu einer weiteren Sprache wird, um die man sich kümmern muss.

  • In HTML + CSS fehlt ein intuitives und mathematisch fundiertes Modell zum Platzieren von Objekten. Sogar Tcl / Tk ist meiner Meinung nach besser darin, Geometriemanager zu definieren. Dies verhindert, dass Programmierer HTML-Rendering streng definieren und sich stattdessen auf das Glück verlassen: "Vielleicht funktioniert dieses Div die meiste Zeit in den meisten Browsern." Auf dieser Seite gibt es jedoch einige positive Entwicklungen, zum Beispiel HTML5 und Twitter Bootstrap.

  • Die Web-Technologie ist organisch gewachsen und die Frameworks sind mitgewachsen, so dass ihre Form nicht unbedingt elegant sein muss. Dies bedeutet, dass sich Programmierer die APIs merken sollten, die nicht optimal sind, veraltet sind und so weiter

  • Webbrowser weisen immer noch leichte Inkompatibilitäten auf und erhöhen die Komplexität von Web-Frameworks unnötig

  • Die Gesamtarchitektur ist ein Chaos. Es ist ein Split-Thinking von Back-End und Frontend, die mit Request / Response auf der Backend-Seite und datengesteuertem Rendering auf der Frontend-Seite verknüpft sind. Die Ausführungsreihenfolge ist nicht sehr genau definiert (die Synchronisierung erfordert Aufwand) und das Platzieren von Stilen, Skripten in geeigneten Slots ist erforderlich (fast alle js-Skripte müssen vor dem Ende des Body-Tags platziert werden usw.). Caching ist ein weiterer Aspekt, der sich vom Backend über den / die Proxy (s) bis zum Frontend erstreckt. Und ich erwähne nicht einmal den Umgang mit Formularen!

  • Das Web-Framework behandelt die meisten dieser Komplexitäten notwendigerweise, indem es viele Konzepte und Verarbeitungspipes hinzufügt.

  • In der Webbranche wird die Arbeit normalerweise zwischen Grafikdesigner, Webdesigner / Webprogrammierer und Backend-Programmierer als Mindestsatz von Rollen aufgeteilt. Die beiden ersteren verfügen nicht unbedingt über Programmierkenntnisse, daher benötigen sie unterschiedliche Abstraktionen und Werkzeuge, und Frameworks sollten diese ebenfalls erleichtern

Zusammenfassend lässt sich sagen, dass Web-Frameworks versuchen, eine Menge Komplexität zu abstrahieren (selbst komplex zu werden), dies ist jedoch aufgrund der schnellen Entwicklung von Standards und anderen beweglichen Teilen sehr schwer zu erreichen. Programmiersprachen sind viel ausgereifter, da es normalerweise kein Problem ist, keine neuen Funktionen zu verwenden.

Ich denke, dass die Erstellung eines praktischen Web-Frameworks erst möglich sein wird, nachdem GUI-Standards eingeführt wurden (die verschiedene Betriebsmodi wie mobile Geräte abdecken) und die zugrunde liegenden Technologien stabil genug sind.

Web-Frameworks fehlen einfache Konstrukte, da es im Bereich der Web-Technologie keine derartigen Dinge gibt. Abstraktionen auf niedrigerer Ebene gelangen notwendigerweise auf eine höhere Ebene.

Roman Susi
quelle
3

Ich denke, vieles hat mit den Einschränkungen des WWW zu tun. Insbesondere gibt es keine integrierte Möglichkeit zum Speichern des Status zwischen Server und Client. Ein Client fordert einige Daten an, der Server stellt sie bereit und die Verbindung wird geschlossen. Daher müssen alle diese Webplattformen ihre eigene Methode zum Aufrechterhalten des Status zwischen Serveraufrufen zusammenstellen.

Ich musste einmal eine kleine Web-App erstellen und hatte zu diesem Zeitpunkt noch nie eine Server- / Client-Programmierung durchgeführt. Ich brauchte ein paar Wochen, um alles herauszufinden, und das Schwierigste war, mich darum zu kümmern, wo sich Client und Server befanden.

Wird sich das jemals ändern? Das bezweifle ich. Dies würde eine grundlegende Änderung der Webarchitektur erfordern.

Justin
quelle
2

Im Allgemeinen können die Ursachen vielfältig sein:

  1. Die Abstraktionslücke ist im Framework-Fall größer. Eine moderne prozedurale / OOP-Sprache bietet Abstraktion über eine Maschine, behält jedoch einige Maschinenkonstrukte bei (z. B. Zuweisen einer Variablen zu Daten / Schreiben einiger Daten in eine Speichereinheit oder Aufrufen einer Prozedur usw.). Die Lücke ist nicht so groß, während ein Framework versucht, eine Abstraktion für die Entwicklung einer Webanwendung bereitzustellen, die mit viel mehr Konzepten arbeitet.
  2. Frameworks können aus Sicht des Programmierers komplexer sein. Dies ist wie eine Folge des ersten Punktes. Eine Programmiersprache ist ziemlich einfach, sie hat einfache Konstrukte (wenn, für, Variablen, Prozeduren usw.). Die Standardbibliothek abstrahiert auch einfache Dinge wie das Schreiben in E / A oder die Verwendung von Sammlungen. Die Standardbibliothek ist auch sehr modularisiert, mit wenigen oder keiner Verbindung zwischen einem Modul und einem anderen; Sie müssen IO nicht kennen, um Sammlungen verwenden zu können oder umgekehrt. Zu beachten ist, dass einige Teile der Standardbibliothek, wenn sie recht komplex sind, in einem Mini-Framework (z. B. Java Collections Framework oder Executors Framework) abgelegt werden. Im Framework-Fall müssen Sie den gesamten Ablauf und alle Teile kennen, um das Framework in seiner vollen Stärke nutzen zu können. Ein Framework ist auch eine bereits erstellte Anwendung.
  3. Nicht so viele Ressourcen werden in ein Framework gestellt wie in eine Programmiersprache. Ich glaube, das bedarf keiner Erklärung.
m3th0dman
quelle
0

Ah, aber Sie sehen, das ist genau das Problem. Frameworks sollen nicht vollständig sein. Sie sollen aus eingeschränkteren Abstraktionen bestehen, die zusammengesetzt werden können, um eine bestimmte Reihe von Aufgaben auf prägnante Weise auszuführen. Alle diese Frameworks, die Sie erwähnt haben, machen keinen Spaß, gerade weil sie keine eingeschränkten Abstraktionen enthalten. Sie liefern undichte Abstraktionen, als an und für sich eine abstrakte Maschine bilden, die höchstwahrscheinlich vollständig ist. Das Konzept der " seltsamen Maschinen " ist das, woran ich am nächsten denke. Alle diese Frameworks sind "seltsame Maschinen" für Webanwendungen, und eine "seltsame Maschine" ist das Gegenteil von dem, was ein Framework sein sollte.

davidk01
quelle
1
Ich gebe +1, weil es trotz des weitläufigen Charakters des Beitrags richtig ist, dass Frameworks nicht unbedingt Turing-vollständig sind. Das ist einer der Vorteile einer vollständigen Allzwecksprache, der Fähigkeit, alles zu tun, wenn Sie wissen, wie.
Izkata