> 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.
Und wenn ich damit auch noch mal wieder zum Ausgangspunkt der Diskussion zurück kommen darf: Mehr als dieses diffuse Bauchgrummeln, das an Rails "etwas" fehlt oder "etwas" zu viel ist, ist es ja momentan auch noch nicht - wobei man den Finger noch nicht wirklich genau auf dieses "etwas" legen kann. Ein vages Grummeln habe ich (und wenn ich das zaghafte Rauschen im Blog-Wald richtig interpretiere, auch noch andere...) an den Stellen, an denen sich die Webarchitekturen über den Punkt hinaus weiter entwickelt haben, an dem Rails damals entstanden ist.
Nur als Beispiel: Das hier gab es damals noch nicht als Rails und seine Clone entstanden sind, oder zumindest längst nicht so ausgeprägt:
A _javascript_-MVC-Frameworks(wie backbone), die über json-Schnittstellen mit der Anwendung reden. Was dann zu Doppelungen und teilweise zu komischen MVC-MVC-Gebilden führt.
B keine Anwendung mehr ohne API! Was quasi A auf die Spitze treibt aber zumindest sind dabei die Doppelungen nicht mehr unser Problem.
C json-stores, bei denen zusammen mit A oder B Rails als ein Kreuzung aus Durchreiche und einer Art "DDL" funktioniert (z.B. mit mongoids field :name usw.)
Es haben sich mittlerweile verschiedenste Ansätze entwickelt solche Sachen __innerhalb__ und/oder __außerhalb__ von Rails zu entwickeln, von daher gibt es da schon viele verschiedene Antworten auf diese Fragen: Da denke ich, kann man zumindest mal drüber nachdenken, welche Rolle Rails in diesen Architekturen einnimmt oder noch futuristischer: einnehmen sollte. Lieber Vielstimmigkeit oder lieber ein Framework, sie alle zu binden? Mehr als diese zugegeben diffusen Fragen habe ich momentan auch noch nicht - ich seh' auch nicht, dass es da draußen schon Antworten darauf gäbe und vielleicht ist es auch einfach gut so, wie es ist: Rails im Wesentlichen als Integrations-Hub und alle anderen Sachen sind nicht und sollten nicht Teil des Frameworks sein...
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.
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.
Als Node und
Go aufkamen, da waren die ersten Fragen in den entsprechenden Foren, ob
es Web-Frameworks dazu gibt. Warum dann diese Sprachen nicht gleich als
mit, zumindest einigen grundlegendenden, aber eben higher-level,
Web-Funktionalitäten bereitstellen?
Warten wir mal noch zehn
Jahre ab.
Viele Grüße
Michael Kastner
Liebe RUGler,
es ist still geworden auf dieser Liste und ich frage mich momentan,
woran das liegt. Vielleicht gibt es ja noch Leben da draußen und ich
fände es spannend von euch zu hören, wie Ihr die Lage der
Ruby/RoR-Nation einschätzt: Ich habe mal ein paar Punkte/Hypothesen
zusammengefasst, über die ich in der letzten Zeit öfter gestolpert bin:
- alle Rails-Probleme sind gelöst. Oder alle sind zu anderen
Listen abgewandert entweder zu den englisch-sprachigen Listen oder zu
den Listen für Spezial-Themen wie deployment/cloud, mongoDB/Mongoid
usw.? Oder viele haben mittlerweile Rails wieder aufgegeben?!
- die Verbreitung von Ruby/RoR beschränkt sich weitgehend auf die
Startup- und Webszene: Es gibt sehr viele Social-Something-Anwendungen,
CMS-Lösungen, Backends für Mobile-Apps aber ich habe noch nicht viel
davon gehört, dass eine Versicherung jetzt Ihre Fallbearbeitung auf
Rails umgestellt hätte oder ein Logistik-Konzern seine Lagerverwaltung
mit Rails macht. Natürlich ist Rails nicht für alles geeignet, aber ich
habe genügend Projekte in diesen altmodischen
Brick-and-Mortar-Unternehmen gesehen, bei denen reflexartig Java/JEE
eingesetzt wird und nicht mal eine Millisekunde über irgend etwas
anderes nachgedacht wird - von Rails bei BMW oder Allianz oder Siemens
habe ich noch nix gehört. Man kann diese Projekte vielleicht
langweiliger als Social-Somethings finden, aber sie sorgen für einen
erheblichen Teil des IT-Job-Markts. Und hier findet Ruby/RoR einfach
nicht statt: Oder täuscht mich mein Eindruck da?! Oder ist das auch gut
so und Rails gehört da auch gar nicht hin und wenn Versicherung dann
bitte COBOL oder wenigstens Java?!
- wohin entwickelt sich Rails? In letzter Zeit stolpere ich immer
mal wieder über Rants mit so schönen Überschriften wie "The Sun is
setting on Rails style MVC Frameworks"
(http://caines.ca/blog/programming/the-sun-is-setting-on-rails-style-mvc-frameworks/),
dann gibt es ein paar, die sich darüber beschweren, dass der
Merb-Merger alles nur langsamer und unübersichtlicher gemacht hat, dann
gibt es LightRails (https://github.com/lightness/lightrail/),
das Rails
wieder verschlanken will, oder die Leute, die sagen, dass man sowieso
nur noch APIs braucht und deswegen am besten gleich alles mit Sinatra
machen sollte. Oder gleich mit node, weil ist schneller und in 2 Jahren
reden wir sowieso alle nur noch _javascript_
(http://gilesbowkett.blogspot.de/2012/02/rails-went-off-rails-why-im-rebuilding.html
oder http://blog.nodejitsu.com/scaling-isomorphic-_javascript_-code).
Ist
da was dran? Taugt Rails noch für die schöne neue
App/HTML5/1-Page-App-Welt? Oder ist es mittlerweile Bloat-ware, weil es
versucht alles für alle zu sein?
- Ich selber ertappe mich dabei, dass ich Features, die ich
zuerst noch zweifelhaft fand, plötzlich nicht mehr missen möchte. Die
Asset-Pipeline ist so ein Fall: Ich fand das dubios und hatte das Gefühl
das gehört eigentlich nicht da rein&es gibt schon tausend
Alternativen dazu, aber mittlerweile sind fast alle größeren
_javascript_-Libraries in gems eingepackt (z.B.
https://github.com/anjlab/bootstrap-rails),
natürlich ist coffeescript
netter als rohes JS, precompiler für _javascript_s-Templates (z.B. für
handlebars) gibt's als Bonus und rails funktioniert so als
Rundum-Sorglos-build-System für _javascript_-Apps. Es ist praktisch, aber
ist es auch der richtige Weg? Oder sieht für mich die ganze Welt wie ein
Nagel aus weil ich nur einen Hammer habe? Ist das nur ein temporärer
Hack, der den Umstand kaschiert, dass es für _javascript_ (noch) kein
Modul-Konzept gibt und ist node.js nicht auf lange Sicht besser als
Build-System geeignet, wenn sowieso alles nur noch JS ist?! Oder ist das
Ganze wirklich eine gute Idee und Rails entwickelt sich zu einer Art
Integrations-Ökosystem für Webtechnologien (und klärt dann auch
irgendwann die Frage welche Version der _javascript_-Bibliothek in dieser
Version des gems verbaut ist)?
Wie seht Ihr das? Geht es Rails gut oder müssen wir uns Sorgen machen,
schreiben wir in 2 Jahren alle nur noch JS (oder GOtt bewahre GO oder
Dart... ) und die Ratten suchen sich jetzt alle schon mal ein Node-Floß,
um das sinkende Schiff zu verlassen?!
Viele Grüße
Stefan
|
