Rich Internet Applications

Rich Internet Applications

Posts 1-10 of 15
  • Hans Thomas Vogler
    Hans Thomas Vogler
    The company name is only visible to registered members.
    Ich mag keine Frameworks...
    Moin,

    das ist hier gleichzeitig meine Vorstellung.

    Mit DOM-Programmierung auf Basis asynchron zugeladener XML-Daten (AJaX ist bei mir nur eine 25-zeilige Subroutine) befasse ich mich seit 2001. Mein Augenmerk liegt auf Verwaltung und Präsentation ggf. kombinierter Datensätze, weniger bis gar nicht auf schicken Bildschirmzaubereien. Schnell, simpel und komfortabel zu bedienen ist meine Devise.

    Ich habe verschiedene Tools/Widgets (z.B. interaktiver Orientierungsplan, eBook usw.) entwickelt und tue das heute noch. Mein Ehrgeiz geht dabei in Richtung klaren, schlanken und autarken - also letztlich entsprechend schnellen - Codes. Dabei arbeite ich gänzlich ohne überladene Frameworks ausschließlich mit bedarfsangepaßten handgeschriebenen Routinen.

    Ständig wiederkehrenden Bedarf wie z.B. einen autarken DOM-Parser für beliebig dimensionierte und strukturierte XML-Daten (15 Zeilen, deswegen gibt's bei mir auch kein "innerHTML") habe ich natürlich in einer kleinen Toolbox zusammengefaßt, die ich aber nun wirklich nicht "Framework" nennen würde...

    Es ist unglaublich, was sich da mit wenigen hundert Zeilen alles bewerkstelligen läßt.

    Was ich hier suche, sind Kontakte zu Programmierern auf ähnlichem Level zum Gedankenaustausch und natürlich Auftraggeber, denen ich ihre Probleme lösen darf.

    Mal gucken, auf wen ich hier diesbezüglich so stoße.

    Schönen Abend noch!

    Hans Thomas Vogler
    • 16 Jan 2008, 9:05 pm
  • Mathias Aebischer
    Mathias Aebischer    Premium Member
    The company name is only visible to registered members.
    Re: Ich mag keine Frameworks...
    Grüezi Herr Vogler

    Grundsätzlich stimme ich mit Ihnen darin überein, dass die Skripts idealerweise für jede Site massgeschneidert werden sollten. Meiner Erfahrung nach fehlt dafür in der Praxis jedoch häufig die Zeit. Sicher, mit der Zeit wird man sich eine ganze Reihe kleiner Tools aneignen, welche gezielt anstelle grosser Frameworks eingesetzt werden können. Allerdings haben Frameworks auch den Vorteil, dass sie 1. gut dokumentiert sein sollten und 2. anderen Entwicklern teilweise bereits bekannt sind.

    Schöne Grüsse
    Mathias Aebischer
    • 18 Mar 2008, 5:44 pm
  • Hans Thomas Vogler
    Hans Thomas Vogler
    The company name is only visible to registered members.
    Re^2: Ich mag keine Frameworks...
    1. Nicht für jede Site, sondern für jeden speziellen Bedarf sollte programmiert werden.
    2. Natürlich habe ich auch so meine kleinen Tool-Boxen für die immer wiederkehrenden Aufgaben, aber das sind nicht viele. Braucht's auch nicht.
    3. Die verfügbaren Frameworks sind hoffnungslos überladen mit irgendwelchen aufwendigen Effekten und entsprechend groß, bieten also einerseits ein breites Gestaltungsangebot, gleichzeitig schränken sie die freie Gestaltungsmöglichkeit aber ein. Außerdem sind es wahre Codemonster. Geht alles viel einfacher, wenn man direkt arbeitet.
    4. Um den Umgang und den Einsatz eines der großen Frameworks zu "lernen", brauche ich ebensoviel Zeit wie zum selber Programmieren. Letzteres ist bei entsprechender Kenntnis auch nicht wirklich komplizierter. Der Unterschied: völlig freie Gestaltungs- und Einsatzmöglichkeit.
    5. Der Einsatz von Frameworks - im Gegensatz zu selbst entwickelten Toolboxen - hält nur davon ab, sich mit dem zu beschäftigen, was eigentlich abläuft.
    6. Der hauptsächliche Sinn von AJaX-/DOM-Technologie ist für mich Performance und Flexibilität. Beides geht durch Standardframeworks kaputt. Kunden, die lieber jede Menge Aufrollploppslidefadeschnickschnack wollen, müssen sich ja nicht an mich wenden.

    Also bleibe ich dabei: ich mag keine AJaX-Frameworks. Wer programmieren kann, braucht auch keine, und wer richtig programmieren lernen will, sollte die Finger davon lassen.

    So long und grüezi auch...
    T.
    • 18 Mar 2008, 6:33 pm
  • Post visible to registered members
  • Lars Pohlmann
    Lars Pohlmann    Premium Member
    The company name is only visible to registered members.
    Re^3: Ich mag keine Frameworks...
    Hans Thomas Vogler schrieb:
    4. Um den Umgang und den Einsatz eines der großen Frameworks zu "lernen", brauche ich ebensoviel Zeit wie zum selber Programmieren. Letzteres ist bei entsprechender Kenntnis auch nicht wirklich komplizierter. Der Unterschied: völlig freie Gestaltungs- und Einsatzmöglichkeit.
    Wenn Du alleine arbeitest und nicht im Team (und auch weißt, daß Du nie im Team an einem Projekt arbeiten mußt) magst Du recht haben.

    Sollte das allerdings nicht der Fall sein, ist es wesentlich weniger arbeitsaufwendig, neue Mitglieder ins Team zu holen, die bereits Erfahrung mit dem eingestezten Framwork haben, als jedes neue Teammitglied erstmal zu schulen...
    • 19 Mar 2008, 12:18 pm
  • Torsten Walter
    Torsten Walter    Premium Member
    The company name is only visible to registered members.
    Re^3: Ich mag keine Frameworks...
    Hans Thomas Vogler wrote:
    [...]
    3. Die verfügbaren Frameworks sind hoffnungslos überladen mit irgendwelchen aufwendigen Effekten und entsprechend groß, bieten also einerseits ein breites Gestaltungsangebot, gleichzeitig schränken sie die freie Gestaltungsmöglichkeit aber ein. Außerdem sind es wahre Codemonster. Geht alles viel einfacher, wenn man direkt arbeitet.
    Schon mal was von AJS gehört? (http://orangoo.com/labs/AJS/) Es ist klein, flexibel, schnell und elegant. Alles wichtige ist bereits drin, den ganzen Rest kann man sich dranbasteln. Es muss ja nicht immer Prototype sein.
    Auch scriptaculous ist an sich recht klein. Man muss janicht auf jdere Site jede der Bibliotheken verwenden. Bzw. man kann ja per Script immer nur die Sachen in eine Datei baken die auf der Site tatsächlich benutzt werden.

    4. Um den Umgang und den Einsatz eines der großen Frameworks zu "lernen", brauche ich ebensoviel Zeit wie zum selber Programmieren. Letzteres ist bei entsprechender Kenntnis auch nicht wirklich komplizierter. Der Unterschied: völlig freie Gestaltungs- und Einsatzmöglichkeit.
    Beispiel DOM: Um da alle Funktionen Browser unabhängig und halbweg elegant zu implementieren braucht man relativ lang. Ein Framework hat das alles intus und so kann ich einen Div beispielsweise so erstellen:

    AJS.DIV({id: "mydiv", className: "myClass", style: "backgroundImage:url(/path/to/image.gif")}, "hello world");

    Ich wüsste nicht was daran schwer ist eine Dokumentation zu benutzen...

    5. Der Einsatz von Frameworks - im Gegensatz zu selbst entwickelten Toolboxen - hält nur davon ab, sich mit dem zu beschäftigen, was eigentlich abläuft.
    Nur wenn man die Frameworks aus Faulheit einsetzt. Ich kenne mittlerweile jede Funktion von AJS in und auswendig. Da ich es auch mittlerweile um einiges erweitert habe...

    6. Der hauptsächliche Sinn von AJaX-/DOM-Technologie ist für mich Performance und Flexibilität. Beides geht durch Standardframeworks kaputt. Kunden, die lieber jede Menge Aufrollploppslidefadeschnickschnack wollen, müssen sich ja nicht an mich wenden.
    [...]     Ein gutes Framework bietet genau das, flexibilität und performance, damit der Programmierer sich der eigentlichen Aufgabe seines Programms widmen kann.
    • 19 Mar 2008, 12:51 pm
  • Hans Thomas Vogler
    Hans Thomas Vogler
    The company name is only visible to registered members.
    Re^4: Ich mag keine Frameworks...
    Torsten Walter schrieb:
    AJS.DIV({id: "mydiv", className: "myClass", style: "backgroundImage:url(/path/to/image.gif")}, "hello world");
    Was spricht z.B. dagegen vorher sowas z.B. selber zu schreiben:

    function D0() {
    var foo = document.createElement('div')
    text = function(helloworld){ foo.appendChild(document.createTextNode(helloworld));return foo}
    }

    with (new D0()){id='mydiv';style.background='url(/path/to/image.gif)';className='myClass';text('Hallo Mond!')}

    Dauert auch nicht wirklich länger, ist aber für einen beliebigen DOM-Programmierer (auch einen, der sich nicht mit AJS , JABBERWOCK oder WASWEISSICH auskennt) klar lesbar und verschleiert nicht überflüssigerweise die Funktionsweise mit künstlich kryptisierter Syntax. Voraussetzung: er muß halt das DOM kennen und sich nicht auf irgendein Framework spezialisiert haben, ohne DOM wirklich zu kennen.

    Für DOM-unkundige Aushilfsprogrammierer kann man ja was dazwischenschalten, und nichts anderes tun diese Frameworks letztenendes.

    Klar nachvollziehbarer und weltweit standardisierter Code ist für mich zudem ein Qualitätsmerkmal - und sollte es auch für Kunden sein. Nicht oder nur schwer nachvollziehbarer Code kann für den nämlich tierisch teuer werden. DOM ist standardisiert, weltweit und auch in zehn Jahren noch auf allen Plattformen gültig, anerkannt und implementiert. Verbesserung, Anpassung und Weiterentwicklung ist also auf lange Zeit sichergestellt.

    Des weiteren gerate ich auf diese Weise garantiert nie in Konflikt mit Urheberrechten und Lizenzbestimmungen, kann ggf. außerdem eigene geltend machen, was im kommerziellen Einsatz unerläßlich ist.

    Das alles gilt weder für AJS, JABBERWOCK noch für WASWEISSICH.

    Vorteil außerdem: ich hole oder baue mir nur genau die Tools und Konstruktoren, die ich wirklich brauche. Das bringt nicht nur Transparenz, sondern eben auch Performance.

    Wenn's was spezielleres sein soll, schreibt man sich halt vorher den passenden Konstruktor genau so, wie man ihn braucht und benutzt keinen von der Stange.

    Es sei denn... Naja - Konfektionsware war halt immer schon etwas billiger...

    mfg
    HTV
    • 20 Mar 2008, 9:55 pm
  • Hans Thomas Vogler
    Hans Thomas Vogler
    The company name is only visible to registered members.
    Re^4: Ich mag keine Frameworks...
    Lars Pohlmann schrieb:

    Sollte das allerdings nicht der Fall sein, ist es wesentlich weniger arbeitsaufwendig, neue Mitglieder ins Team zu holen, die bereits Erfahrung mit dem eingestezten Framwork haben, als jedes neue Teammitglied erstmal zu schulen...
    Prinzipiell mag das (noch) so sein, würde aber einen Standard voraussetzen, den es so nicht gibt und meiner Ansicht nach auch nie geben wird. Warum?

    1. Eines der heutigen Hauptargumente, mit Frameworks Browserinkompatibilitäten abzufangen, gilt in Zukunft nicht mehr. Der W3C-Standard setzt sich durch - angeblich sogar bei Microsoft mit dem IE 8.

    2. Weil die Zukunft XML gehört. HTML wird zunehmend ein temporäres XSLT-Produkt sein - sei es client- oder serverseitig. Warum also HTML-Attributverrenkungen, wenn ein angepaßter XML-Dialekt noch simpler herzustellen ist? Programmierer montieren dann nur noch via AJaX ausgelesenen XML-Content in fertige Layout-Schablonen ein.

    Für beliebig herstellbare Layout-Schablonen wiederum braucht es kein Framework.

    mfg
    HTV
    • 20 Mar 2008, 10:12 pm
  • Hans Thomas Vogler
    Hans Thomas Vogler
    The company name is only visible to registered members.
    Die Sache mit dem "innerHTML"
    Moin nochmal,

    nachdem hier einige Framework-Kenner versammelt sind, bringe ich die Sprache nochmal auf einen meiner Hauptkritikpunkte: in allen mir bekannten Frameworks finde ich irgendwo das verräterische "innerHTML" - das nicht DOM-gerecht ist - um ausgelesenen Content in den Bildschirm zu montieren. Oder soll ich sagen: irgendwo reinzukippen.

    Das ist meiner Ansicht nach AJaX auf primivstem Level und läßt eine der wesentlichsten Stärken der AJaX-Technologie außer acht, den Umstand nämlich, daß der Browser selbständig und völlig unabhängig mit eingelesenen Datenbäumen umgehen kann. Er kann sie parsen, durchsuchen und sich Einzeldaten rauspicken, damit temporäre Datenbanken anlegen usw.

    Mit AJaX kann man sich fast völlig unabhängig vom HTML-Code machen, also z.B. die XML-Ressourcen eines Servers direkt auslesen und damit den servergestützten und trafficerzeugenden XSLT-Prozessor umgehen. Das Datenhandling auf dem Client ist dann praktisch unbeschränkt mit Ausnahme der "Sandbox", in der der Scriptprozessor läuft.

    Nur: mit "innerHTML" geht das natürlich nicht...

    Welches Framework bietet dafür was? Ich kann sie nicht alle kennen und möchte mich auch nicht mit allen befassen. Vielleicht könnte mich das aber von meiner ablehnenden Haltung bekehren.

    mfg
    HTV
    • 20 Mar 2008, 11:06 pm
  • Torsten Walter
    Torsten Walter    Premium Member
    The company name is only visible to registered members.
    Re: Die Sache mit dem "innerHTML"
    Hans Thomas Vogler wrote:
    Moin nochmal,
     
    nachdem hier einige Framework-Kenner versammelt sind, bringe ich die Sprache nochmal auf einen meiner Hauptkritikpunkte: in allen mir bekannten Frameworks finde ich irgendwo das verräterische "innerHTML" - das nicht DOM-gerecht ist - um ausgelesenen Content in den Bildschirm zu montieren. Oder soll ich sagen: irgendwo reinzukippen. [...]
    Welches Framework bietet dafür was? Ich kann sie nicht alle kennen und möchte mich auch nicht mit allen befassen. Vielleicht könnte mich das aber von meiner ablehnenden Haltung bekehren.
     
    mfg
    HTV
    Ich bin nach einigen Versuchen bei AJS hängen geblieben. Das "innerHTML" kommt darin zwar vor, allerdings nur in Hilfsfunktionen um z.B. text in DOM umzuwandeln.

    Ansonsten ist alles soweit ich das überblicken kann Standardkonform und arbeitet mit den W3C Specs.

    Letzendlich liegts auch an der Implementation. wenn ich einen DIV mit Content erzeuge erstellt AJS einen TextNode. Wenn ich vom Server einen HTML String bekomme muss ich den natürlich erstmal in eien DOM Tree umwandeln, wozu hier innerHTML als Mittel zum Zweck benutzt wird.

    HTML vom Server zu lesen ist ja auch kein AJAX sondern einfach nur ein HTTP Request.

    XSLT ist mir bis jetzt in Frameworks noch nicht über den Weg gelaufen. Aber, ohne hier wie ein Evangelist wirken zu wollen, in AJS kann man das mit den DOM Methoden sehr leicht erstellen/erweitern.
    This post was modified on 26 Mar 2008 at 12:55 pm.
    • 26 Mar 2008, 12:42 pm