> Du müsstest ausreichend genau festlegen, auf welche Weise du Webanwendungen > heute entwickeln > möchtest.
Damit habe ich mich noch nicht ausreichend beschäftigt. Oder andersrum: ich weiß, daß mich Rails irgendwann so sehr nerven wird, daß ich vielleicht wirklich mal mal einen Notizzettel mit meinen Anforderungen schreibe. Du hast natürlich recht, lediglich zu kritisieren ist etwas uncool. > Wenn dir das gelingt, dann könnte man dafür auch ein Framework > bauen. Noch ein Framework? Das war's eigentlich nicht ;-) > Ich finde diese Behauptung in zweierlei Hinsicht fragwürdig. Du > unterstellst erstens, Rails sei ein Monster geworden. Zweitens > behauptest du, dies wäre durch eine Integration der gebotenen > Funktionalität in eine Programmiersprache vermeidbar. Ich hatte das vorhin mal so ins Blaue reingeschrieben. Die Aufblähung wäre halt nur vermeidbar, wenn andere Funktionalitäten weggelassen würden. Wenn HTML5 es fertig bringt, Semantik in die Präsentation zu bekommen, dann sollte es doch auch möglich sein, daß sich ähnliches auch auf der Datenseite und im Flow niederschlägt. HTTP bringt doch z.B. Beispiel eine Definition von bestimmten Verhaltensweisen oder Verben mit. Nur mußte die Reaktion auf diese Verben, sofern sie implenentiert waren, immer programmiert werden. _Das_ wäre für mich so ein Fall, der definitiv in einer speziellen Web-Programmiersprache verdrahtet sein müßte. Gut, wenn's der Browser nicht unterstützt, dann ist's auch mit den HTTP-Methoden nicht weit her. Aber war ja nur ein Beispiel. Waren nur meine 5 Cent. Am 26.03.2012 um 14:36 schrieb Michael Schuerig: > On Monday 26 March 2012, rubyonrails...@galt.de wrote: >> Willkommen im 21. Jahrhundert! >> >> Rails ist ok, aber es ist eben ein Framework, das man sich vor zehn >> Jahren für die Web-Entwicklung gewünscht hätte. > > Mit dieser Aussage provozierst du die Frage, was man sich denn heute > (anderes) für die Web-Entwicklung wünscht. Weiter gedacht: Was müsste > Rails leisten, um diese Wünsche zu erfüllen? > > >> Das ist jetzt vielleicht etwas unorthodox, aber jedes Framework ist >> ein aufgeblähtes Monster, eine Behelfslösung, ein Übergangslösung, >> für etwas, das eigentlich eine spezialisierte Sprache mit ihren core >> libraries erfüllen sollte. Das gilt für so etwas wie JQuery oder Moo >> im JS-Bereich oder im Ruby-Bereich für Rack mit Rails oder Sinatra. >> >> Daß Ruby im Moment so beliebt ist, und daß Javascript auf der >> Client-Seite so beliebt ist, das hängt doch wohl hauptsächlich damit >> zusammen, daß die Web-Frameworks so ausgefeilt sind. Und wenn >> Frameworks so fundamental für den Erfolg einer Sprache >> verantwortlich sind, dann ist es in meinen Augen klar, daß man sich >> mal über die Kernfunktionaliäten der entsprechenden Sprachen >> Gedanken machen sollte. > > Exkurs: Framework bezeichnet ein sehr allgemeines Konstrukt und sagt > zunächst einmal nichts über die Größe oder Komplexität aus. Gegeben > einen technischen Gegenstandsbereich, dann zeichnet sich ein Framework > gegenüber einem Toolkit vor allem dadurch aus, dass es den Rahmen für > eine Anwendung (eine Library, ein Modul, ein Plugin) vorgibt, in dem die > Lücken gefüllt werden. Meist werden dabei vorgegebene Interfaces mit der > spezifischen Funktionalität implementiert. Das etwas ein Framework ist, > sagt dabei nichts über die Größe aus. > > Dir geht es aber um Frameworks für die Web-Entwicklung, Server- wie auch > Client-seitig. Wenn ich dich richtig verstehe, behauptest du, dass Rails > inzwischen zu groß und unübersichtlich geworden ist und beizeiten durch > eine spezialisierte Sprache abgelöst wird, oder werden sollte. > > Ich finde diese Behauptung in zweierlei Hinsicht fragwürdig. Du > unterstellst erstens, Rails sei ein Monster geworden. Zweitens > behauptest du, dies wäre durch eine Integration der gebotenen > Funktionalität in eine Programmiersprache vermeidbar. > > Ich stimme zu, dass Rails mit der Zeit immer umfangreicher geworden ist. > Wenn jemand heute Rails komplett verstehen will, dann ist das zweifellos > mehr Arbeit als es vor fünf Jahren gewesen wäre. Allerdings ist das kein > Selbstzweck, sondern folgt den gestiegenen Anforderungen der Leute, die > mit Rails arbeiten. Man sollte den Rails-Core-Entwicklern durchaus > zugute halten, dass die Modularität von Rails mit der Zeit sogar besser > geworden ist. Es ist heute möglich, Rails-Anwendungen ganz ohne > Persistenzschicht zu schreiben, indem man nur ActiveModel für die Model- > Schicht verwendet und ActiveRecord einfach ignoriert. Man muss nicht > alle Teilframeworks im Detail kennen, sondern kann sich auf die > konzentrieren, die man tatsächlich benötigt. > > Aber die meisten Entwickler wollen ja Persistenz in ihren Webanwendungen > nutzen. Das hat einen Preis an Wissen über die verwendeten Mittel, ob es > nun ActiveRecord ist oder Bestandteil einer spezialisierten > Programmiersprache. > > Es geht einfacher, wenn man sich auf Anwendungen beschränkt, die einer > bestimmten Schablone entsprechen. Auch dann braucht man keine neue > Programmiersprache, sondern dank der Ausdrucksfähigkeit von Ruby könnte > man die gewünschte Funktionalität in ein geeignetes Framework giessen. > > Und damit bin ich wieder am Anfang angekommen: Du müsstest ausreichend > genau festlegen, auf welche Weise du Webanwendungen heute entwickeln > möchtest. Wenn dir das gelingt, dann könnte man dafür auch ein Framework > bauen. > > Michael > > -- > Michael Schuerig > mailto:mich...@schuerig.de > http://www.schuerig.de/michael/ > _______________________________________________ > rubyonrails-ug mailing list > rubyonrails-ug@headflash.com > http://mailman.headflash.com/listinfo/rubyonrails-ug > _______________________________________________ rubyonrails-ug mailing list rubyonrails-ug@headflash.com http://mailman.headflash.com/listinfo/rubyonrails-ug
