Das Angebot an umfassenden JavaScript-Frameworks ist in den vergangenen
drei Jahren sehr vielfältig geworden. Anfangs waren Prototype +
Scriptaculous der “eingebaute” Standard und die Konkurrenz noch nicht
der (großen) Rede wert.
Inzwischen sieht das anders aus, Prototype ist ein Framework unter
vielen und sticht auch nicht mehr durch besondere
Alleinstellungsmerkmale heraus. Auch einige der anderen Frameworks sind
brauchbar mit Rails integriert, wenn auch nicht so gut dokumentiert.
Konkret fallen mir an interessanten Frameworks ein
Prototype + Scriptaculous
jQuery + Plugins
Dojo
YUI
Mochikit
Mootools
ExtJS
Meine Erfahrung ist, dass ich mit P+S eigentlich ziemlich gut klar
komme, jQuery aber vielfach schöner ist und ein reichhaltigeres Angebot
and qualitativ hochwertigen Plugins hat. Mit YUI bin ich bei meinen
wenigen Versuchen nicht richtig warm geworden, vieles kam mir
umständlich vor. Von Dojo habe ich nur den vagen, möglicherweise
falschen, Eindruck, dass es eine recht steile Lern- und
Komplexitätskurve hat, die sich erst bei Anwendungen lohnt, die einen
sehr umfangreichen Browser-seitigen Anteil haben; dann bringt es aber
richtig was.
Mich interessiert, welche Frameworks ihr einsetzt und aus welchen
Gründen. Insbesondere auch, ob und wie das mit der besonderen Art der
Anwendung zu tun hat.
Eine weitere Überlegung ist für mich, was ich anderen Entwicklern, die
vielleicht nach mir kommen, zumuten kann. P+S setze ich bei
Rails-Entwicklern einfach voraus. Wenn ich statt dessen etwa jQuery
nehme, weil es mir geringfügig besser gefällt, dann habe ich meinen
Spaß, der nächste aber vielleicht beträchtlichen Ärger.
Ja, und wenn wir gerade dabei sind, dann würde mich auch die Frage
interessieren, ob viele Leute diese tiefe prototype-Integration über
rjs in größeren Projekten benutzen und wie die Erfahrungen damit sind.
Ich bin kürzlich über diesen Artikel http://metaskills.net/2008/5/24/the-ajax-head-br-design-pattern
gestolpert: Statt rjs-responses geben die Controller im wesentlichen
nur noch :ok zurück - und das ganze javascript ist handgebaut.
Was ich interessant fand, weil sich das im wesentlichen mit meinen
Erfahrungen mit auch nur ein bisschen komplexerem JavaScript deckt:
Man ist da doch ziemlich schnell am Ende mit dem, was man per RJS
machen kann und kommt ziemlich schnell zu Client-Code, der über
Controller, View und div. Helper + handgebautes javascript verschmiert
ist. Daher gleich anschließend meine nächste Frage: Wenn p+s nicht
mehr allein selig machend ist, und die rails-Integration über RJS
für komplexere, Client-seitige Anwendungen nicht wirklich funktioniert
(oder mach ich da nur was falsch?) - ist dann das Festhalten an p+s
noch zeitgemäß (Merb trifft diese Entscheidung ja auch mit Absicht nicht)?
GrüßeStefan
PS:
Zu den Frameworks:
Ich bin da bislang eher konservativ verfahren und habe vor allem p+s
benutzt, um nicht noch ein weiteres Framework einzuführen - ich denke
immer noch, wichtiger als tausend Funktionen zu haben, ist eine
handvoll ständig benutzter Funktionen gut zu kennen - daher schrecke
ich vor allzuvielen neuen Sachen meistens zurück. Aber p+s ist
ziemlich schlecht was wdigets angeht. Da schaut man dann schon
manchmal neidisch auf jquery oder extjs.
Reingefallen bin ich nur zwischendurch mal auf YUI, eben wegen der
Komponenten: Aber davon bin ich ziemlich schnell wieder weggekommen,
neben der krautigen Namensgebung erschlägt einen das mit Features und
einer nicht besonders gut geordneten API, sodass sich die Rails-
Integration (wie krieg ich meine Daten in dieses Widget rein?!) am
Ende als zu mühselig erwiese.
Am interessantesten von den Frameworks find ich nach wie vor ExtJS -
vor allem wegen der hübschen widgets: aber auch hier tue ich mich
momentan schwer damit, das in eine existierende Seite einzuführen, nur
um auf einer Seite ein einziges Widget einzubauen…
Das kann man sicher machen, ist aber eine Entscheidung von
beträchtlicher Trageweite. Im wesentlichen gibt es dann nur noch
jeweils einen GET-Request, um das Gerüst der Seite aufzubauen, von da
an agieren die Skripte wie eine Client-Anwendung, die die Controller
als Webservice nutzt.
Kann man alles mit Prototype machen; evtl. unterstützt durch LowPro,
Jester und JavaScript Routes (o.ä.).
nee, klar, sicher, machen kann man ja immer vieles: Nur, ist es eine
gute Idee? Werden bald alle Anwendungen so aussehen (Return of the
Evil Client-Server-Architecture)? Von da aus ist der Weg dann
leichter, statt prototype/scriptaculous einfach gwt zu nehmen. oder
flex. oder was auch immer.
Hat aber mit meiner ursprünglichen Frage nicht mehr viel zu tun.
hmm. ja. Aber wenn die Frage war, ist es sinnvoll, weiter bei P+S zu
bleiben, dann macht es Sinn, vorher drüber nachzudenken, wie tief sich
prototype in die Anwendung eingegraben hat. und einen Moment an die
Überlegung zu verschwenden, wohin einen rails mit rjs geführt hat.
Alle rjs-basierten Sachen und die ganzen remote-helper binden die
Anwendung an prototype, da würd ich dann immer dreimal überlegen, ob
man noch was dazu tut . Während es mit diesem Head-Pattern sicher
leichter fällt, zu anderen Frameworks zu wechseln.
Sorry, wollte deinen Thread nicht hijacken, aber ich suche momentan
nach einer auch architektonisch sauberen Lösung, andere Frameworks zu
benutzen - die rails-Bordmittel mit anderen Frameworks zu mixen hat
bei uns nur zu einem wenig glücklichen Mischmasch aus
handgebautem&generiertem Code geführt.: Das wäre dann die Frage vor
der Frage: Wenn andere Frameworks, wie baut ihr die ein? Wie ko-
existieren die mit p+s? Benutzt ihr das zusammen oder die eingebauten
Sachen dann gar nicht mehr?
Ja, und wenn wir gerade dabei sind, dann würde mich auch die Frage
interessieren, ob viele Leute diese tiefe prototype-Integration über
rjs in größeren Projekten benutzen und wie die Erfahrungen damit
sind. Ich bin kürzlich über diesen Artikel 301 Moved
gestolpert: Statt rjs-responses geben die Controller im wesentlichen
nur noch :ok zurück - und das ganze javascript ist handgebaut.
Das kann man sicher machen, ist aber eine Entscheidung von
beträchtlicher Trageweite. Im wesentlichen gibt es dann nur noch
jeweils einen GET-Request, um das Gerüst der Seite aufzubauen, von da
an agieren die Skripte wie eine Client-Anwendung, die die Controller
als Webservice nutzt.
Kann man alles mit Prototype machen; evtl. unterstützt durch LowPro,
Jester und JavaScript Routes (o.ä.).
Hat aber mit meiner ursprünglichen Frage nicht mehr viel zu tun.
ich suche momentan
nach einer auch architektonisch sauberen Lösung, andere Frameworks zu
benutzen - die rails-Bordmittel mit anderen Frameworks zu mixen hat
bei uns nur zu einem wenig glücklichen Mischmasch aus
handgebautem&generiertem Code geführt.: Das wäre dann die Frage vor
der Frage: Wenn andere Frameworks, wie baut ihr die ein? Wie ko-
existieren die mit p+s?
Kurz gesagt: Eine Kombination von Prototype + Scriptaculous mit jQuery,
YUI oder Dojo ist eine sehr schlechte Idee, weil sich die
Funktionalitäten zu weit überschneiden.
Für jQuery gibt es jq4r, das einen großen Teil der in Rails enthaltenen
Prototype-Abhängigkeiten auf jQuery umbiegt. Ob das auch für RJS
funktioniert, weiss ich aus dem Kopf nicht mehr.
Ja, und wenn wir gerade dabei sind, dann würde mich auch die Frage
interessieren, ob viele Leute diese tiefe prototype-Integration über rjs
in größeren Projekten benutzen und wie die Erfahrungen damit sind. Ich
bin kürzlich über diesen Artikel 301 Moved gestolpert:
Statt rjs-responses geben die Controller im wesentlichen nur noch :ok
zurück - und das ganze javascript ist handgebaut.
Ich mache das so, dass RJS oftmals nur eine Methode aufruft, d.h. die
Logik ist clientseitig definiert aber serverseitig getrieben. Zumindest,
wenn es komplexer wird und man mehrere Widgets ansprechen muss.
Einfache hide/show/highlight Funktionalitäten ruft bie mir RJS noch
direkt auf.
Mich interessiert, welche Frameworks ihr einsetzt und aus welchen
Gründen. Insbesondere auch, ob und wie das mit der besonderen Art der
Anwendung zu tun hat.
Ich nutzte P+S für alle Basis-Sachen und ExtJS sobald es um komplexe,
widgetlastige Seiten geht. ExtJS setzt wunderbar auf P+S auf und ist
IMHO sehr durchdacht und hat eine fantastische API Dokumentation.
Wenn man das Komponenten-Modell einmal verstanden hat, ist ExtJS sehr
einfach zu bedienen und erweitern.
jQuery mag eine etwas schönere Syntax als P+S haben, die Widgets finde
ich aber bei ExtJS besser. YUI ist irgendwie schlecht/komisch
dokumentiert und klingt für mich nur auf dem Papier gut. Dojo habe ich
immer wieder versucht, war mir aber zu umständlich, man kann den
Java/IBM Einfluss gut erkennen.