Suche
Was herauskommt, wenn man den Browser mal ganz anders benutzt!

RISC-HTML: Web Frontends für Geschäfts- und Industrieanwendungen

Björn Müller

(c) Shuttertsock / Profit_Image

Es muss nicht immer der ganze Blumenstrauß an HTML5-Features sein. Gerade für Geschäftsanwendungen sind Dinge wie geringer Wartungsaufwand, Browser/Device-Kompatibilität, Update-Stabilität oft wichtiger als die Nutzung der brandneuesten UI-Spielerei. Björn Müller, W-JAX-Speaker und Geschäftsführer von CaptainCasa, stellt in diesem Artikel einen Ansatz vor, mit dem sich auch in der schnelllebigen Welt der Web-Entwicklung robuste Geschäftsanwendungen fürs Web realisieren lassen, die nicht bei jedem JavaScript-Framework-Update umgebaut werden müssen.

Take the „RISC“

Benutzeroberflächen für Geschäfts- und Industrieanwendungen haben einen wichtigen Anspruch: Sie sollen langfristig stabil laufen! Der Lebenszyklus solcher Anwendungen beträgt gerne 10 Jahre und mehr – und die Lust, hier Kernteile des Frontends alle drei bis vier Jahr neu zu entwickeln und sie permanent an wechselnde Browser bzw. wechselnde Frameworks anzupassen, ist gering.

Die CaptainCasa, ursprünglich zuhause im Bereich von Java-basierten Frontends, hat hier unter dem Namen “RISC-HTML” eine neue Web-Technologie entwickelt, die auf genau diese Belange von Unternehmens- und Industrieanwendungen eingeht.

Der Name “RISC” ist dabei Programm – und eine Analogie zur Prozessor-Diskussion der 90er Jahre (“reduced instruction set computer”). Das HTML des Browsers wird nämlich nicht in seiner vollen Bandbreite genutzt, sondern im Gegenteil: Die Nutzung beschränkt sich auf zwei Primitiv-Elemente (DIV und INPUT), die noch dazu auf allereinfachste Art und Weise angesprochen werden.

iamge1

RISC-HTML – Prinzip

Der Zugriff auf diese Primitiv-Elemente wird durch eine JavaScript-Schnittstelle (“Microkernel”) abgeriegelt. Auf Basis dieses Microkernels wurden nun die gewohnten “normalen” Controls – vom Button über das Grid über Layout Container bis hin zu Dialogen – als JavaScript-Bibliothek erstellt.

image2

Client-seitige Architketur

Vorteile der RISC-HTML-Methode

Diese Herangehensweise ist eine signifikant andere als die innerhalb gewohnter Frameworks angewendete: Versuchen diese, die Komplexität des Browsers handhabbar zu machen und dabei Kompatibilitätsprobleme innerhalb der zahlreichen HTML-Elemente durch eine darüber liegende Schicht auszumerzen, so wird bei “RISC-HTML” das HTML des Browsers nur zu einem Bruchteil genutzt. Der Browser wird zu einer “Rendering Execution Engine” und malt betreffende Primitiv-Elemente an die vorgesehene Stelle. Warum und wie sie dorthin kommen, das bestimmen die betreffende Control-Implementierungen.

 

Naheliegendes Resultat der RISC-HTML-Methode: zunächst eine Browser/Device-Kompatibilität, die nicht auf “testen, testen, testen” (compatiblilty by resources) beruht sondern konstruktiv bedingt ist (compatiblilty by design). Die Abhängigkeit zum Browser ist in einer minimalen „Microkernel-Implementierung“ enthalten – noch dazu werden vom Browser nur allereinfachste Dinge erwartet: das Zeichnen absolut positionierter DIV- und INPUT-Elemente.

image3

(Online) Demo Workplace

Dadurch, dass die Logik des Anordnens nicht mehr im HTML liegt, sondern in betreffenden JavaScript Controls, entfallen auch die Limitierungen, die man vom Browser in diesem Bereich kennt. Einfache Herausforderungen (z.B. vertikale Bereiche, die fix sind und vertikale Bereiche, die variabel gesized werden – und dies über mehrere Schachtelungsebenen), die über normales HTML nur unbefriedigend gelöst werden können, sind deswegen im RISC-HTML-Ansatz problemlos umzusetzen.

Am Überraschendsten aber ist die Performance des RISC-HTML-Ansatzes. Urheblich dafür sind zwei Dinge: Zum einen führt der Browser das simple Rendering “wahnsinnig” schnell aus. Zum anderen ist die Abarbeitungsgeschwindigkeit von JavaScript mittlerweile extrem hoch.

Der RISC-HTML-Ansatz ist überall dort geeignet, wo Frontends eher programmiert als designed werden. Typisches Einsatzgebiet ist die Entwicklung der operativ genutzten Dialoge einer Geschäfts- / Industrieanwendung (z.B. Sachbearbeiterdialoge).

Die CaptainCasa hat den Client ihres Rich Client Frameworks “Enterprise Client” mittlerweile komplett auf RISC-HTML umgestellt. Downloads, Online-Demos und weitere Informationen gibt es über http://www.CaptainCasa.com.

Verwandte Themen:

Geschrieben von
Björn Müller
Björn Müller
Björn Müller ist seit 2001 im Bereich von UI-Frontend-Architekturen aktiv – sowohl auf der HTML-/Ajax-Seite als auch auf der Java-Swing- und JavaFX-Seite. Seit 2007 entwickelt er aktiv innerhalb der CaptainCasa-Community ein Java-basiertes Rich-Client-Framework für umfangreiche Geschäftsanwendugen, den CaptainCasa-Enterprise-Client. Wurde bis 2016 clientseitig auf Java-basierte Technologien gesetzt, so erfolgte nun der geräuschlose Umstieg auf einen HTML5-basierten Client, basierend auf der sog. „RISC-Methode“.
Kommentare
  1. Frank2016-08-05 13:20:29

    Die ganze Architektur erinnert ein wenig an JSF. Es ist sicherlich nicht schlecht und einfach zu nutzen.

    Wer Oberflächen mehr programmieren als designen will, sollte vielleich dann auf Rich Client Frameworks wie Vaadin oder direkt auf GWT zurückgreifen.

    Vaadien: https://vaadin.com/home

  2. Björn Müller2016-08-05 15:23:41

    ...am besten mal vergleichen, was an HTML im Browser so rauskommt (per F12 in die Elementesicht). Und dann sieht man ziemlich signifikante Unterschiede zwischen - Dein Beispiel... - GWT basierten Ansätzen und RISC-HTML. - LG Björn

  3. Jens Grochtdreis2016-08-11 19:47:59

    Der Artikel und der darin beschriebene Ansatz ist in vielerlei Hinsicht falsch. Und es ist bedauerlich, dass es im Jahr 2016 noch immer Entwickler gibt, die solche Thesen in den Raum stellen.

    Grundproblem scheint mir zu sein, dass ein Backend und Frontend vermixt werden, die gleichen Anforderungen an die beiden Ebenen gestellt werden. Das ist fahrlässig. Backendentwickler scheitern deshalb immer wieder im Frontend, weil ihnen die Klarheit und Verlässlichkeit ihrer Welt fehlt. Wir haben im Frontend nicht den einen Endgegener, gegen den entwickelt wird. Ein Backendentwickler weiss, dass auf seinem Server Java 6 oder PHPn6 läuft und kennt den Sprachumfang, der er zu 100% ausnutzen kann. Es ist dabei gewährleistet, dass die Runtime diesen Code auch immer brav und korrekt interpretiert.

    Im Frontend gibt es diesen paradiesischen Zustand nicht. Es wird ihn auch nie geben. Wir wissen nicht, wer mit welchem Browser unsere Seiten besucht. Der Besucher hat meist die Kontrolle über den Browser (ausser bei iOS), kann die Fenstergröße verändern, Schriftarten installieren und deinstallieren usw.
    Und noch viel wichtiger: es gibt keinen Browser, der HTML, CSS oder JavaScript zu 100% verstünde. Jeder Browser hat zudem andere Fehler. Es gibt ausserdem viele Teile der Spezifikationen, die der Interpretation freien Raum lassen. Frontend und Backend unterscheiden sich also grundlegend in allen Belangen voneinander. Deshalb ist es auch selten eine gute Idee, wenn ein Entwickler in beiden Sphären intensiv arbeitet.

    Eine viel schlechtere Idee ist es, wenn ein Backendentwickler versucht, das Frontend neu zu erfinden. Dann soll programmiert werden, wo nichts programmiert wird und da werden Sicherheiten gewünscht, die es nicht gibt. Genau in diese Kategorie scheint mir RISC-HTML zu fallen. Der Sprachschatz von HTML wird dabei auf DIV und INPUT reduziert. Keine Semantik mehr. Das soll die Arbeit vereinfachen und das Ergebnis sichern.

    Nun, ich hoffe, die Kunden dieser Firma haben niemals eine Behinderung, bei der sie auf Hilfsmittel angewiesen sind. Sie werden sich nicht zurechtfinden. Der Ansatz hat also schonmal eine Diskriminierung von Blinden eingebaut.

    Die Behauptung, die Firma habe eine neue Webtechnologie entwickelt, ist selbst in Sachen PR eine extrem dreiste Nummer. Es wurde nichts entwickelt, sondern zurückgebaut. Ein stolzes Gebäude wurde auf die Grundmauern runtergebrannt und diese noch auseinandergetreten.

    Dabei wird gerne vergessen, dass Frontendentwicklung in einem ersten und zweiten Schritt nichts mit Programmierung zu tun hat. Es handelt sich erst einmal um schlichtes Handwerk. Es geht darum, Inhalte so zu verpacken, dass die Verpackungen den Sinn des Inhalts wiedergeben. Also markiert man Absätze mit den dazu passenden Tags, genauso wie ein Videoelement oder eine Liste. Dann malt man das ganze hübsch an (Design) und arrangiert es auf einer Webseite (Layout). Dafür nutzt man dann CSS, das wiederum nichts mit Programmierung zu tun hat.

    Erst wenn man Inhalte live aktualisieren will oder etwas auf- und zuklappen will, benötigt man JavaScript. Erst dann kommen wir in den Bereich der Programmierung. Die beiden vorherigen Schichten lassen sich zudem nicht durch JavaScript ersetzen, wie uns der Autor offenbar weiss machen will. HTML muss entweder geschrieben oder nachgebildet werden. CSS muss mit JS geschrieben werden. Wo ist da der Nutzen?

    In einem Kurs zu Angular JS und zwei anderen Frameworks habe ich der Entstehung einer Platzreseervierungs-Applikation beigewohnt. Am Ende kam ich zu dem Schluss - und konnte ihn mit einer Testseite beweisen -, dass für diese "Applikation" keine Zeile JS erforderlich war. Anstatt DIVs zu verschachteln und mühsam zu klickbaren Objekten zu wandeln, nahm ich ein Formular und Checkboxen sowie deren Label. Checkboxen bringen kostenlos Zustände mit sich, die wir über CSS auslesen und visualisieren können und die automatisch alle wichtige Infos an das Formular übergeben. Aus der Sicht eines Programmierers mag dieser Ansatz langweilig sein, er ist aber der einzig vernünftige.

    Auch das hier vorgestellte RISC-HTML würde diesen falschen Weg gehen. Anstatt einfach die mit HTML schon mitkommenden Controls und Sprachelemente zu nutzen, werden neue Konstrukte erstellt. Tausende Zeilen sinnlosen JS-Codes, die die endgültige Anwendung schön langsam werden lassen. Und es gibt kein Fallback für den Fall, dass das JS nicht komplett geladen wurde. Last but not least bedeutet diese Bibliothek einen Haufen Arbeit, den niemand bezahlen sollte. Denn es werden Elemente nachgebaut, die schon existieren.

    Für eine Beispielapplikation unterstellt der Autor einen Lebenszyklus von 10 Jahren und mehr. Kritisch scheint ihm hier das Frontend zu sein. Es ist aber doch eigentlich nur die Darstellung der Aufbereitung, die auf dem Server passiert. Richtig entwickelt, habe ich eine Trennung von Geschäftslogik und Struktur. Die optische Aufbereitung kommt mit CSS sowieso separat. Dieser Ansatz der Trennung ist weder neu noch revolutionär. Deshalb kann ich darin keinen Grund dafür entdecken, HTML auf zwei Elemente einzudampfen und unnötig kompliziertes JS zu schreiben.

    Ein Verkaufsargument scheint die Abwesenheit von Tests zu sein. Mich würde interessieren, ob der Autor auch auf Tests in seinen Java-Codes verzichtet und dies gegenüber seinen Kunden anpreist.

    Der hier gezeigte Screenshot weist für mich auch nicht auf die Notwendigkeit der Verkrüppelung der Frontendtechniken hin. Das Design ist nicht besonders herausfordernd, nichts, was man nicht schon tausendfach gesehen hätte. Eventuell gibt es auch schon ein Fertigtemplate irgendwo, das man ein weing anpassen kann. Wenn man sich mit Frontendtechniken auskennt.

    Und auch wenn "die Logik des Anordnens nicht mehr im HTML liegt, sondern in betreffenden JavaScript Controls", wird am Ende immer HTML geschrieben. In diesem Falle halt ein wenig umständlich mit JS, anstatt einfach HTML direkt zu schreiben. Und natürlich kann man Oberflächen sortierbar und arrangierbar machen. Alles schon gesehen. Aber es gibt keine Notwendigkeit, deshalb alles in JS zu schreiben.

    Der Autor schreibt auch, dass bestimmte Layoutansätze über HTML nur ungefriedigend gelöst werden können. Das untestütze ich zu 100%. Denn HTML macht da gar nichts. HTML sieht nicht aus, es gibt nur einem Datenstrom Sinn. Der Autor meint CSS. Doch wie es der Zufall will: auch mit JS muss man am Ende CSS schreiben. Es kann sein, dass man nur mit JS noch ein paar Zusatzbedingungen einfügen kann, die man mit CSS nicht managen könnte. Aber für die Gestaltung ist am Ende immer CSS zuständig. Auch wenn der ganze Kram in Typescript oder Babel oder sonstwas geschrieben wird.

    Offenbar werde ich auch in Zukunft noch viele Möglichkeiten haben, Programmierern die Eigenarten, Schönheiten und Abgründe des Frontends zu erklären. Denn auch im Jahr 2016 hat sich noch nicht überall die Erkenntnis durchgesetzt, dass das Frontend eine eigene Disziplin ist, die mit den Augen eines Backendentwicklers falsch aussieht. Das liegt aber nicht an den Frontendtechniken.

  4. Peter2016-08-12 08:39:53

    Auf einen Blick u.a.

    - Kein valider Quelltext,
    - Bedienung der Seite ohne Maus schwierig, da ohne sichtbaren Focus
    - Diveritis vom Feinsten
    - fehlende Semantik an vielen Stellen
    - aufgeblähter Quältext

    Darüber hinaus muss man dem Kommentar von Jens zu 100% zustimmen.
    TBL wird bestimmt beim Lesen des "innovativen Beitrags" schlecht.

  5. Marc2016-08-12 10:54:15

    Wenn man nur einen Hammer hat, sieht alles aus wie ein Nagel.

    Von hinten durch die Brust ins Auge, sagt man bei uns. Wäre ja alles nicht so schlimm, wenn man damit die wesentlichen Vorteile der diversen HTML-Elemente (Semantik, Zugänglichkeit, eingebaute clientseitige Validierungen usw - alles in einer dem Nutzer bekannten Form) nicht verlieren würde - alles nachbauen in JavaScript? Wozu, wenn es bereits funktioniert?

    Im Übrigen sind es für gewöhnlich nicht die nächsten zehn Jahre, die Probleme machen - Millionen "alter" Webseiten funktionieren bis heute - und wenn nicht, dann liegt es nicht am HTML!

    Ist die Erfindung von RISC-HTML nun der Unwissenheit seiner Entwickler geschuldet? Ist es eine perfide Masche um unbedarften Auftraggebern das Geld aus der Tasche zu ziehen? Oder der bösartige Versuch, das Web schlechter nutzbar zu machen?

    Man weiß es nicht.

    Womöglich ist es einfach nur der naive Traum eines Backend-Programmierers, mit seinem JavaScript-Hammer Web-Frontends zimmern zu können...

  6. Dan2016-08-15 10:59:11

    @Jens:
    Dir muss ich in vielen Punkten zustimmen, gerade wenn man Deine Aussagen im Kontext einer Website betrachtet. Dann ist der Ansatz mit RISC-HTML nicht sinnvoll.

    Wenn man den Kontext von einer Website zu einem Web Frontends für Geschäfts- und Industrieanwendungen (B2B) verschiebt, dann macht das durchaus Sinn.

    - Browser kompatibel: Sieht auf allen (modernen) Browser gleich aus (zero-installation, zero-maintenance)
    - Performance: auch bei der Darstellung sehr großer Eingabemasken oder langen Tabelleninhalten
    - Investitionssicherheit: denn neben HTML unterstützt das Framework CaptainCasa auch JavaFX und Swing. Man kann jederzeit (mit sehr wenig Aufwand) zwischen den Technologien wechseln
    - Umfangreiche Komponenten Bibliothek (http://captaincasa.org/online-demo-server)
    - Entwickler-Effizienz: Benutzeroberflächen können sehr schnell (auch mit einem WYSIWYG Editor) intuitiv erstellt und mit dem Backend verbunden werden

    Der HTML-Quelltext ist nicht besonders schön, interessiert den (Backend-) Entwickler und den Anwender (Sachbearbeiter) in erster Linie auch nicht. Denn damit haben sie tatsächlich nichts zu tun! Das Ergebnis zählt ;-)

    Für den Anwender zählt ob die Eingabemasken funktional sind, dazu muss eine GUI nicht sexy aussehen oder irgendwelcher HTML-Semantik folgen.
    Wie gesagt die "Zielgruppen" sind Anwendungen in der Industrie und der B2B-Welt (KEINE klassischen Webseiten). Für Webseiten gibt es durchaus schon genug und bessere GUI- Frameworks.

    Wir selbst nutzen CaptainCasa als Frontend für eine Java EE7 Anwendung und sind damit hoch zufrieden. :-)
    Dass die Entwicklung neben Swing und JavaFX auch in Richtung HTML geht, hat uns natürlich sehr gefreut...

  7. Björn Müller2016-08-16 10:42:54

    Danke für Eure bisherigen Kommentare, die zeigen, dass Ihr Euch inhaltlich mit meinem Artikel auseinandergesetzt habt!

    RISC-HTML ist aus meiner Sicht ein Paradigmenwechsel bei der Verwendung von HTML. Ihr reagiert hierauf mit einer "gesunden Empörung" - weil Ihr augenscheinlich zu einer anderen Sichtweise und Schlussfolgerung kommt.

    Mit Empörung beim "Verstoß gegen Denkstandards" kenne ich mich zum Glück aus. Ein dickes Fell habe ich auch - bin aber trotzdem immer etwas erstaunt, wenn Kommentatoren die eigene Sicht der Dinge so über die des anderen stellen, dass sie sich für herablassende Äußerungen nicht zu schade sind.

    Nun zu den Inhalten, hier vor allem in Richtung Jens, deswegen ein paar Zitate aus Deiner Rückmeldung:

    >>>>>
    "[Das Frontend] ist aber doch eigentlich nur die Darstellung der Aufbereitung, die auf dem Server passiert", "...markiert man Absätze mit den dazu passenden Tags ... Dann malt man das ganze hübsch an (Design) und arrangiert es auf einer Webseite (Layout)", "Anstatt einfach die mit HTML schon mitkommenden Controls und Sprachelemente zu nutzen, werden neue Konstrukte erstellt."
    <<<<

    Mir scheint, und das ist nicht abwertend gemeint!, die Szenarien, in denen Du Dich bewegst, sind andere als die, in denen ich mich bewege. HTML deckt weiterhin nur einen recht überschaubaren Satz an Grundcontrols ab. Controls wie Slider, (etwas) komplexere Comboboxen (Autocomplete...), Calendar, Grids (Spalten tauschen, sortieren, Scrollen über große Datenmengen), Trees, Accordion, Tabbed-controls, Dialoge (modal/modeless), etc. etc. - da wirst Du etwas länger nach HTML Tags suchen müssen. Sprich: schon hier beginnt der Prozess, dass diese semantischen Controls (Tree) durch irgendein Framework (jQuery, etc. etc.) in ent-semantifizertes HTML dematerialisert werden und die Dynamik über JavaScript umgesetzt wird.

    Nun kann man den Standpunkt vertreten: "Solche Controls brauche ich nicht!" oder "Dann warte ich bis diese Controls auf allen gängigen Browsern durch entsprechende Tags zur Verfügung gestellt werden". Aber ich glaube, je mehr man mit HTML operative Bereiche erreicht, umso wackliger wird dieser Standpunkt.

    Eine Ent-Semantifizierung findet prinzipiell auf Control-Ebene auch nicht statt. Ein Tree bleibt ein Tree, ein Slider ein Slider, ein Button ein Button - alle Controls liegen im DOM Tree als identifizierbare Objekte vor! Die Schnittstelle zwischen semantischen Controls und entsprechenden Nutzern (z.B. Lesegeräte) muss sich aber ändern und kann (schon jetzt!) nicht mehr auf nativem HTML aufsetzen, denn das wird bereits heute gehörig ent-semantifiziert.

    Die Vergleiche zur CISC/RISC Diskussion im Bereich der Hardware sind aus meiner Sicht frappierend: bis ein neuer, komplexer Befehl im Befehlssatz (= in der Hardware) des CISC Prozessors aufgenommen wurde, dauerte es "ewig". Bis dann dieser Prozessor bei den Kunden eingesetzt wurde, dauerte es "noch ewiger". Jeder neue Befehl machte den Prozessor noch komplexer und damit fehleranfälliger. - Es machte also Sinn, Algorithmik aus dem Prozessor herauszunehmen und in eine flexiblere Schicht (Programm) vor dem Prozessor auszulagern. - Man ersetze nun das Wort "Prozessor" durch "Browser" und das Wort "Befehl" durch "Control".

    Zu guter Letzt: ich habe (zweitletzter Absatz meines Artikels) das Einsatzgebiet für RISC-HTML beschrieben. Ich bin weit davon entfernt zu behaupten, dass konventionelles HTML in anderen Einsatzgebieten nicht mehr zum Einsatz kommen dürfe.

    Freundliche Grüße! Björn

  8. Jens Grochtdreis2016-08-16 11:24:14

    Hallo Björn, hallo Dan.

    Mir ist schon klar, dass mit dem verkrüppelten HTML (a.k.a. RISC-HTML) keine normalen Webseiten, sondern Applikationen gebaut werden. Und es ist mir auch klar, dass es viele Widgets noch immer nicht gibt, obwohl man sich bei der Spezifizierung von HTML5 echt Mühe gab.

    Und all diese Widgets, die Björn genannt hat, gibt es schon in hundertfacher Ausfertigung, teilweise als Stand-Alone, teilweise als Bestandteil eines UI-Frameworks wie jQuery-UI.

    Eigentlich muss man also nur noch ein als gut befundenes UI-Element nehmen und einbauen. Stattdessen baut ihr alles selber, sicherlich als Closed-Source und vor allem nur für Euch. Bei jQuerUI oder ähnlichen beliebten Bibliotheken ist es einfach als Kunde, jemanden zu finden, der die Arbeit weiterführt. RISC-HTML ist also mehr eine Form der Kundenbindung.

    Die Panikmache, die Codebasis bliebe ohne RISC nicht stabil, man müsse ständig neuen Frameworks anpassen, kann ich nur mit einem Kopfschütteln lesen. Browser sind prima abwärtskompatibel. Eine Webseite/Applikation, die ich vor Jahren mal mit jQuery 1.3 entwickelt habe, funktioniert heute immernoch genauso gut. Alles andere wäre auch Wahnsinn. Es spricht also nichts dagegen, 8 oder 10 Jahre alten Code zu nutzen. Viele heutige Enterprise-Applikationen haben das Problem, dass sie sehr browserspezifischen Code genutzt haben. Doch aus dem IE6-Desaster haben Frontendentwickler schon lange gelernt. Leute wie ich habe darüber schon zu Zeiten der IE6-Dominanz geschimpft. Doch Kunden und IT-Entscheider (== keine Frontendkompetenz) haben im alten Trott weitergemacht. Eventuelle Fehlentwicklungen liegen also eher an Fehlentscheidungen von Ahnungslosen, als an den Browsern und den Frontendtechniken selber.

    Wenn ich die Ankündigung von Björn ernst nehme, bleiben von HTML bei RISC-HTML noch DIV und INPUT übrig. Mittels JavaScript muss also eine Liste nachgebaut werden, oder eine Tabelle. Das soll sinnvoll sein? Das soll Browserkompatibilität verbessern? Ein Select-Element muss nachgebaut werden, obwohl es schon fertig existiert? Warum? Ich kenne sowas nur von Designern, die darauf bestehen, dass ein Select-Feld in einer bestimmten Weise formatiert wird. Und Formularelemente kann man leider nur sehr zurückhaltend gestalten. Aber es geht.

    Mir will nicht in den Sinn, warum Elemente nicht genutzt und stattdessen mit JS nachgebaut werden. Und mir will vor allem nicht in den Sinn, warum offenbar Probleme mit dem Styling - also CSS - dazu führen, von HTML - das nichts mit Styling zu tun hat - nur noch zwei Elemente zu nutzen.

    Am Ende, wenn ihr alles schon in HTML existente nachgebaut habt, kommt HTML raus. Und das muss mit CSS gestaltet werden. Auch wenn ihr das vielleicht mittels JS macht, es ist und bleibt CSS.

  9. Jens Grochtdreis2016-08-16 11:27:25

    Noch ein Punkt zum Einsatzgebiet: ich finde es irrelevant, ob es sich um eine Webseite oder eine Applikation handelt. Beides basiert auf HTML. Das HTML nutzt man so weit es geht. Wenn HTML erweitert werden muss, nutzt man dafür JavaScript. Das ist kein neuer Ansatz, das machen wir schon immer so.

    Frontendentwicklung ist wie Softwareentwicklung ein Handwerk. Und genau, wie der Verzicht auf Klassen und die Einführung von Spaghetti-Code bei einem Java-Entwickler sicherlich zu großer Aufregung führen würde, regt es mich auf, wenn jemand ohne Not Frontendtechniken verkrüppelt.

  10. Stefan Tilkov2016-08-16 16:32:20

    Eigentlich wollte ich einen langen Kommentar schreiben, aber dann habe ich den von Jens gesehen und schreibe einfach nur: +1

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.