Gerald: Web-Applikationen ohne Javascript

Wer Web-Applikationen erstellen will, scheint heute nicht mehr an Javascript herum zu kommen. Ich denke, es geht aber auch ohne. Und wenn man an so böse Dinge wie XSS denkt, ist das auch gut so.

Ich habe ein Online-Werkzeug dazu entwickelt, das unter http://www.ReinHTML.eu kostenlos zur Verfügung steht und mit dem man Dialoge, Formulare bzw. Applikations-Fenster generieren kann, die allein auf HTML und CSS beruhen. Natürlich funktioniert der ReinHTML Dialog Designer selbst auch ohne Javascript. ;-)

Würde mich sehr interessieren, was die SelfHTML Community dazu sagt.

Gerald

  1. hi,

    Würde mich sehr interessieren, was die SelfHTML Community dazu sagt.

    Folgendes: Mal angenommen, Du hast eine vielbesuchte Anwendung mit nachgelagerten Serverprozessen. Das Frontend (HTML) möge 20 kB haben, die Antwort-Daten jedoch nur 5 kB. Ohne Ajax-Unterstützung schickst Du bei jeder Response das Frontend plus die Daten, also 25 kB. Die Ajax-Response schickt jedoch nur 5 kB.

    Das sind nur mal eben angenommene Datenmengen, aber solche Beispiels lassen sich bestimmt noch mehr finden, die sehr für Javascript sprechen.

    Hotti

    1. Hallo,

      Mal angenommen, Du hast eine vielbesuchte Anwendung mit nachgelagerten Serverprozessen. Das Frontend (HTML) möge 20 kB haben, die Antwort-Daten jedoch nur 5 kB. Ohne Ajax-Unterstützung schickst Du bei jeder Response das Frontend plus die Daten, also 25 kB. Die Ajax-Response schickt jedoch nur 5 kB.

      die Überlegung ist durchaus richtig, aber solange wirklich nur wenige kB unnötigerweise übertragen werden, macht das nicht viel aus. Bezüglich der gefühlten Geschwindigkeit nicht, denn angesichts typischer Latenzzeiten von einer halben bis einer Sekunde für einen HTTP-Request fällt das "Mehr" erst auf, wenn es einige 100kB sind - außer man hat einen ausgesprochen langsamen Internet-Zugang, etwa mit einem Mobilgerät.
      Und angesichts des überschüssigen Traffics würde ich sagen, der Anbieter solcher Dienste ist selbst schuld, wenn er die effizientere Methode mit Javascript nicht als Alternative, womöglich sogar als bevorzugte Lösung anbietet.

      Das sind nur mal eben angenommene Datenmengen, aber solche Beispiels lassen sich bestimmt noch mehr finden, die sehr für Javascript sprechen.

      Ja, mag sein. Aber wie gesagt: Ich sehe die Javascript-freie Variante in diesem Fall auch eher als Fallback-Lösung.

      Was mir bei Gerhards Angebot nicht gefällt, ist eher die Tatsache, dass man von der auf *seinem* Server installierten Anwendung abhängig ist, anstatt sie sie auf dem eigenen Webspace installieren zu können.

      Ciao,
       Martin

      --
      Wichtig ist, was hinten rauskommt.
        (Helmut Kohl, 16 Jahre deutsche Bundesbirne)
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Was mir bei Gerhards Angebot nicht gefällt, ist eher die Tatsache, dass man von der auf *seinem* Server installierten Anwendung abhängig ist, anstatt sie sie auf dem eigenen Webspace installieren zu können.

        Dann wäre aber meiner Meinung der Sinn einer Onlineanwendung erst recht hinüber.
        Ich finds schon überflüssig wenn man kleine Tools nicht einfach zu auspacken kriegt, sondern als Installationsdatei mir Registry und allem möglichen. Und dann ein Tool in dieser Größenordnung auf nen Server packen müssen?

        Ich finde allgemein die ganze Show um Webanwendungen zu übertrieben. Die haben ganz klar ihren Sinn, da wo sie taugen und ihre Vorteile ausspielen können. Aber es gibt einiges was man gescheiter als Desktopanwendung realisieren würde. Gerade wenn es innerbetriebliche Software ist, mit komplexen Abläufen. Da macht man teilweise die wildesten Kopfstände, um irgendwas im Browser zu erreichen das in einem eigenständigen Programm simpelst zu machen wäre. Einmal "zurück" klicken und schon wird was längst ungültiges angezeigt... na gratuliere.
        Und das nur weil irgendeiner aus der (meist fachlich wissensfreien) Führungsetage irgendwo was von Web gehört hat.

      2. hi,

        Ja, mag sein. Aber wie gesagt: Ich sehe die Javascript-freie Variante in diesem Fall auch eher als Fallback-Lösung.

        Ich sehe das so wie Pflicht und Kür:
        -Pflicht: Die Anwendung funktioniert ohne Javascript.
        -Kür: Die Anwendung spart Bandbreite mit Javascript.

        Btw., wo ich grad dabei bin, mein kleines Framework zu überarbeiten: Es tut mit einem Template like this:

        text/html:
         %name
         %vname
         %ort

        Die Schablone für eine Ajax-Response sähe dann so aus:

        text/plain
         name=%name;vname=%vname;ort=%ort

        Meine Idee von heute nachmittag: Die Schablone für die Ajax-Response wird automatisch erstellt aus dem HTML-Template heraus. Diese Aufgabe wird mein Template-Modul übernehmen-> weniger Arbeit für einen möglichen Ajax-Aufsatz ;)

        Hotti

        1. Hallo,

          Aber wie gesagt: Ich sehe die Javascript-freie Variante in diesem Fall auch eher als Fallback-Lösung.
          Ich sehe das so wie Pflicht und Kür:
          -Pflicht: Die Anwendung funktioniert ohne Javascript.
          -Kür: Die Anwendung spart Bandbreite mit Javascript.

          eben, so sehe ich es auch. Aber man möchte ja nicht den Nutzer zwischen Pflicht- und Kür-Lösung auswählen lassen, sondern die Auswahl soll nach Möglichkeit automatisch geschehen. Das geht nur so, dass man die "bessere" Lösung erstmal als Default anbietet. Und erst wenn diese scheitert oder sonstwie nicht funktioniert, fällt man automatisch auf die sichere Basis-Lösung zurück.
          Das ist es ja auch, was der Begriff "Fallback" impliziert.

          Umgekehrt kann es nicht gehen, weil die Pflicht-Lösung ja per definitionem in jedem Fall funktionsfähig sein soll. Also wird man von dort niemals auf die komfortablere Kür-Lösung zurückfallen können.

          Ciao,
           Martin

          --
          Man sollte immer wissen was man sagt
           - aber auf keinen Fall alles sagen, was man weiß.
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          1. hi,

            eben, so sehe ich es auch. Aber man möchte ja nicht den Nutzer zwischen Pflicht- und Kür-Lösung auswählen lassen, sondern die Auswahl soll nach Möglichkeit automatisch geschehen.

            Genau!!! Hab jetzt, zwischen Weltspiegel und Sonntagsessen mal in die Tasten gegriffen und meine Idee vom Mittagsspaziergang umgesetzt:

            Die Template-Engine expandiert zum Einen das Template wie gehabt als Scalar-Referenz. Hinzugekommen ist ein JSON-String als Rückgabewert, der wird in das Response-Objekt eingebaut und kann auf Anforderung mit dem passenden Content-Type ausgeliefert werden.

            Ein bischen "Arbeit" bleibt jedoch: Das Template selbst muss entsprechend designed werden, und wie das geht, habch hier im Forum gelernt ;)

            Grüße an Alle,
            Hotti

      3. Was mir bei Gerhards Angebot nicht gefällt, ist eher die Tatsache, dass man von der auf *seinem* Server installierten Anwendung abhängig ist, anstatt sie sie auf dem eigenen Webspace installieren zu können.

        Ciao,
        Martin

        Das ist ein Mißverständnis. Am Server des Tools gibt es zwar einen pre-view aber das ist nicht der endgültige Sinn der Sache. Wenn das Layout fertig ist, wird der generierte HTML File auf den eigenen Rechner herunter geladen.

        Und diese Datei kann man natürlich auch ganz ohne Tool weiterbearbeiten. Ist ja normales HTML.

        Oder man lädt den HTML File später wieder hinauf um sie zu überarbeiten.

        Es gibt also keine Abhängigkeit - weder vom ReinHTML Server noch vom Tool.

        Gerald

        1. Hallo,

          Was mir bei Gerhards Angebot nicht gefällt, ist eher die Tatsache, dass man von der auf *seinem* Server installierten Anwendung abhängig ist, anstatt sie sie auf dem eigenen Webspace installieren zu können.
          Das ist ein Mißverständnis.

          das glaube ich nicht - erst recht nicht, nachdem du es nochmal erklärt hast.

          Am Server des Tools gibt es zwar einen pre-view aber das ist nicht der endgültige Sinn der Sache. Wenn das Layout fertig ist, wird der generierte HTML File auf den eigenen Rechner herunter geladen.

          Ja, aber das Tool selbst läuft ausschließlich auf deinem Server. Das bekomme ich nicht, so dass ich es mir installieren könnte, wo ich möchte. Richtig?

          Es gibt also keine Abhängigkeit - weder vom ReinHTML Server noch vom Tool.

          Okay, Abhängigkeit ist vielleicht übertrieben. Sagen wir's anders: Ich kann diesen Web-Service nur online auf deinem Server nutzen.

          Ciao,
           Martin

          --
          Most experts agree: Any feature of a program that you can't turn off if you want to, is a bug.
          Except with Microsoft, where it is just the other way round.
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    2. hi,

      Würde mich sehr interessieren, was die SelfHTML Community dazu sagt.

      Folgendes: Mal angenommen, Du hast eine vielbesuchte Anwendung mit nachgelagerten Serverprozessen. Das Frontend (HTML) möge 20 kB haben, die Antwort-Daten jedoch nur 5 kB. Ohne Ajax-Unterstützung schickst Du bei jeder Response das Frontend plus die Daten, also 25 kB. Die Ajax-Response schickt jedoch nur 5 kB.

      Das sind nur mal eben angenommene Datenmengen, aber solche Beispiels lassen sich bestimmt noch mehr finden, die sehr für Javascript sprechen.

      Hotti

      Ja wenn die Seite bei den meisten Benutzeraktionen in der Struktur gleich bleibt (wie beim Blättern durch eine Datenmenge; z.B. bei einer Suchmaschine), klingt das Argument gut. Hängt eben von der Art der Anwendung ab. Es gibt natürlich auch andere, wo es dann mehr Rolle spielt, dass man sich den JS Code spart.

      Gerald

  2. Hi there,

    Würde mich sehr interessieren, was die SelfHTML Community dazu sagt.

    Definiere "Applikation". Eine komplexe Anwendung ohne Javascript oder eine äquivalente Programmiersprache ist imho nicht möglich. Du kannst ja auch mit Photoshop keine Applikation erstellen, die diesen Namen verdient, nicht einmal mit einem x-beliebigen Formulargenerator wäre das möglich...

    1. Definiere "Applikation". Eine komplexe Anwendung ohne Javascript oder eine äquivalente Programmiersprache ist imho nicht möglich. ...

      Ja, HTML allein macht nicht viel her. Gemeint ist natürlich HTML *plus* PHP, Java oder Perl am Server.

      Gerald

  3. Ich hab mir jetzt mal das Tutorial angesehen. Für mich ist das nichts anderes als ein extrem kompliziert zu bedienender HTML-Editor.

    Wenn später dann serverseitiger Code generiert wird, mag das Sinn machen.Aber aktuell halte ich dieses Tool für absolut unnötig, kompliziert und technisch überholt.

    1. Ich hab mir jetzt mal das Tutorial angesehen. Für mich ist das nichts anderes als ein extrem kompliziert zu bedienender HTML-Editor.

      Wenn später dann serverseitiger Code generiert wird, mag das Sinn machen.Aber aktuell halte ich dieses Tool für absolut unnötig, kompliziert und technisch überholt.

      Die HTML Generierung ist nur der erste Schritt. Es wird in Zukunft auch möglich sein, PHP code zu generieren, der das Handling der Dialoge übernimmt und auch Interfaces zum Datenbank Backend bereitstellt.

      Bitte beachten, dass das Tutorial nur einen Ausschnitt der jetzt schon vorhandenen Möglichkeiten zeigt.

      Wenn man beurteilen möchte, ob es sinnvoller ist, HTML Forms Dialoge manuell ohne Tool zu entwickeln, sollte man allerdings auch an die Überarbeitung und die Wartung denken. Auch sorgt das Tool dafür, dass i.a. immer gültiger HTML Code rauskommt. Was manuell natürlich nicht unbedingt garantiert ist.

      Gerald

      1. Die HTML Generierung ist nur der erste Schritt. Es wird in Zukunft auch möglich sein, PHP code zu generieren, der das Handling der Dialoge übernimmt und auch Interfaces zum Datenbank Backend bereitstellt.

        Und wo liegt der Vorteil zu der "üblichen" dynamischen generierung, z.B. per CMS?

        Bitte beachten, dass das Tutorial nur einen Ausschnitt der jetzt schon vorhandenen Möglichkeiten zeigt.

        Dann ist das Tutorial eine sehr shclechte Werbung für dein Projekt. Es zeigt keinen echten Nutzen und verschweigt evtl. nützliche Funktionen.

        Wenn man beurteilen möchte, ob es sinnvoller ist, HTML Forms Dialoge manuell ohne Tool zu entwickeln, sollte man allerdings auch an die Überarbeitung und die Wartung denken. Auch sorgt das Tool dafür, dass i.a. immer gültiger HTML Code rauskommt. Was manuell natürlich nicht unbedingt garantiert ist.

        Es ist auch online nicht garantiert, da es ebenfalls von einem Menschen abhängig ist.
        Und was die Wartung betrifft, halte ich es für wesentlich einfacher, eine Software auf dem eigenen Server zu pflegen anstatt immer wieder die Seiten neu von einem externen Anbieter generieren zu lassen, was massiv zeit kostet.

        Ich habe immer noch nicht verstanden, wo der Sinn deines Tools liegt. Und weder die Webseite noch dein Tutorial hat das geändert. Ich denke, das ist das erste, was du ändern solltest.

  4. Hi,

    Würde mich sehr interessieren, was die SelfHTML Community dazu sagt.

    den non-JavaScript-Fall so gleichwertig wie möglich zu behandeln, ist in fast allen Fällen unumgänglich - nach wie vor. Wozu aber der Rückschritt, auf die hochgradigen Verbesserungen, die mittels JavaScript möglich sind, zu verzichten?

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
  5. Lieber Gerald,

    je nach Art der Applikation hat "graceful degradation" beim Nichtvorhandensein von JavaScript im Browser einen Sinn - oder eben nicht. Für ein simples Gästebuch, Forum, Wiki usw. kann ich ein Kompensieren des Mangels an verfügbarem JavaScript unterstützen. Bei einem komplexen Datenbank-Frontend, bei dem die Verknüpfung verschiedenster Daten in einem interaktiven GUI mittels AJAX-Funktionalitäten für den User visuell griffig und übersichtlich aufbereitet wird, kann ich es dagegen nicht, da hier eine wesentlich umfangreichere und noch komplexer zu bedienende JS-lose Version implementiert werden müsste, deren Erstellung vom Aufwand und Preis her in keinem Verhältnis zum erwarteten Nutzen stünde.

    Beantwortet das Deine Frage?

    Liebe Grüße,

    Felix Riesterer.

    --
    ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
    1. Beantwortet das Deine Frage?

      Ja, wenn es so wäre, dass der Einsatz von JS, DB-Anwendungen kleiner, einfacher und billiger machen würde. Ist das aber tatsächlich so?

      Einleuchtend, übersichtlich und einfach zu bedienen können jedenfalls auch HTML-only Anwendungen sein.

      Gerald