Y0Gi hat geschrieben:
Das dürfte daran liegen, das SQLAlchemy im Sachen kann, von der das popelige Django-ORM nicht mal zu träumen wagt.
Was alles keine Rolle spielt, wenn dem ersten Autoren bereits Django zu groß und umfangreich erschien. Darauf zielte ich ab. Ob sqlalchemy mehr kann, spielt dabei keine Rolle. Zunächst ist es noch mehr zu lernen.
Y0Gi hat geschrieben:sma hat geschrieben:Doch statt Ruby würde ich dann lieber JavaScript lernen. Die Sprache ist einfacher.
Du warst auch mal in der Lage, deutlich besser zu differenzieren ;)
Was bitte ist an dieser Aussage falsch? Wenn er sich nicht mit JS beschäftigen will, aber Ajax machen will, wäre Rails dank eingebautem Ajax eine Alternative. Allerdings, so mein Tipp, halte ich es dann doch für einfacher, JS zu lernen, als Ruby, nur um Rails mit seinen Remote-Funktionen einsetzen zu können.
Vielleicht hast du es für einen Scherz gehalten, aber JS ist eine interessante, lernenswerte Sprache (wenn man über ein paar unschöne Details hinweg sieht), die funktionale und objektorientierte Programmierung erlaubt.
Y0Gi hat geschrieben:Django hat keine AJAX-Integration aus nachvollziehbaren Gründen - weil man keine JS-Lib vorschreiben will.
Sich festzulegen, erfordert Mut. Diesen - und da provoziere ich gerne noch weiter - vermisse ich häufig. Ich halte Flexibilität nicht automatisch für eine Stärke. Häufig ist es eine verkappte Schwäche. Und außerdem: Zu viel Auswahl schwächt die Community, weil sich dann nämlich alle Leute verteilen, statt hinter einem Rahmenwerk (wie bei Rails) zu stehen.
Ansonsten, weil man bei Rails nichts direkt mit Prototype und Scriptaculous zu tun haben muss, sollte es doch nicht schwer sein, intern es durch jQuery zu ersetzen. Letztlich wird das gewählte Rahmenwerk zu einem Implementationsdetail. Wenn die Leute aber an Rails vorbei direkt auf das JavaScript zugreifen wollen - und, dann muss ihnen auch die mögliche Konsequenz bewusst sein. Doch das ist immer noch besser, als gar keine Entscheidung zu treffen und in einem Möglichkeitsraum zu schweben.
Y0Gi hat geschrieben:Dein letzter Satz ist vollkommen fehl am Platze und passt auch nicht zu dir - du solltest es besser wissen. In Python gibt es Frameworks, die nicht zuviel vorschreiben, damit Entwickler ihre eigenen Stacks bauen können.
Ich spüre Verärgerung. War der Satz vielleicht doch wahr? ;) Aus welchem Grund man sich nicht festlegen will, ist mir schon klar. Ich finde den Grund nur nicht überzeugend. Statt jedem Entwickler sein persönliches Rahmenwerk, würde ich mir lieber weniger größere Rahmenwerke wünschen, die eine so starke Community aufbauen, dass etwas bei bei Rails passiert und interessante Köpfe angezogen werden, auch weil die Sprache und das Rahmenwerk auf einmal kommerziell interessant werden.
Y0Gi hat geschrieben:Also nehme ich eine Lösung die mir erlaubt, solche durchaus wichtigen Entscheidungen selbst zu treffen.
Wenn du das kannst, gehörst du zu einer ganz kleinen Gruppe von Entwicklern. Denn um die Qualität von Rahmenwerken beurteilen zu können, braucht es Erfahrung und einen Überblick, den man sich erarbeiten muss. Wenn das jeder machen muss, kostet das viel Zeit, die man lieber in Programme stecken sollte. In Javaposse #207 (ein empfehenswerter Podcast, nicht nur um bei Java auf dem aktuellen Stand zu bleiben) betrachtete dieses Problem aus Java-Sicht, denn auch dort gibt es ja Webrahmenwerke und Bibliotheken wie Sterne an einem klaren Sommernachtshimmel.
Stefan
