headless ja oder nein?

[lottikarotti]

lottikarotti Nach etwas googeln werde ich nicht schlauer: Was bezeichnest du als simple React? Meinst du damit einen einfachen React App Aufbau oder ist das Fork vom React Framework?

Damit war gemeint, dass das React / Node.js Setup ein "simples" ist. Für einen Prototypen reicht es bspw. völlig aus create-react-app und express zu nutzen um binnen weniger Minuten (!) eine funktionsfähige Entwicklungsumgebung mit Frontend & Backend einzurichten. Wir nutzen dafür aber größtenteils eigene Vorlagen die bereits unseren Workflows (Deployment, etc.) angepasst sind, spielt aber fürs Thema keine Rolle.

[rkr]

Ich glaube, es gibt hier kein richtig und kein falsch.

Headless heißt ja nur, dass etwas keine GUI hat (bzw. dass man die Präsentation von der Businesslogik entkoppelt). Was ist denn da neu?
Wenn ich in meinen composer-/vendor-Ordner schaue, dann ist da mit an Sicherheit grenzender Wahrscheinlichkeit alles headless.

Es hat gewisse Vorteile sich die Arbeit zu machen, große Teile einer ehemals monolithischen Anwendung in unabhängige Teile aufzubrechen, die für sich genommen auch ohne eine Mutteranwendung funktionieren. Da gibt es ja auch haufenweise Beispiele für.

Wie kann man headless eigentlich griffig definieren? Der Wikipedia-Artikel ist für mich nicht griffig genug. Wenn etwas keine GUI hat... Was heißt denn das? Das ist doch im Software-Bereich keine Definition für etwas. Wenn in einer OOP-Anwendung Objekte über ein Interface miteinander kommunizieren, dass ist das doch auch schon eine Schnittstelle, wo man den Begriff "headless" platzieren könnte, oder? Ich meine, ist ElasticSearch headless und ist Lucene nicht headless?

Also, für mich war headless als Begriff bislang immer "hat keine GUI". Wenn ich irgendwo gelesen habe, dass etwas headless ist, dann kann man dieses Etwas mindestens optional so betreiben, dass man ohne den Einsatz einer GUI auskommt. Weil, ob für etwas eine GUI sinn macht, hängt ja auch immer vom Geschäftsziel ab. És könnte eine GUI für ElasticSearch geben, aber wir nutzen es Headless. Wir nutzen es aber auch nicht direkt, sondern haben da noch mal eine Middleware zwischen, welche die Facettensuche stark aufbohrt. Diese Middleware ist auch headless und wird von einem System mit GUI verwendet, dass über diese Middleware und über ElasticSearch auf Lucene sucht.

Objektive Kriterien für die Entwicklung von Headless-Komponenten sind für mich:

• Wenn sich Projekte mit ähnlichen oder unterschiedlichen Anforderungen Funktion teilen.
• Wenn man die Funktionsweise eines Anwendungsteils sinnvoll in Form einer Komponente zusammenfassen und das Interface für die Nutzer (User oder Progger) vereinheitlichen kann.
• Wenn die Komplexität einer Komponente ein Niveau erreicht hat, bei der eine isolierte Weiterentwicklung zu besseren Ergebnissen führt.

Oder so ähnlich

[ChristianK]

Ganz einfach:

1. Datei ist der "Controller", er enthält die Logik der Komponenente (laden, speichern, Interaktion mit anderen Komponenten, usw. usf.).
2. Datei ist das Template. Es enthält die Darstellungslogik sowie den HTML-Code.
3. Datei ist das Layout, also CSS, Sass oder Less
(4. Datei ist für Tests)

Genau das finde ich an Angular so toll, dass es von Grund auf schon mal gut durchstrukturiert und nicht alles auf ein Haufen zusammengeworfen ist.

Hier kannst du die Diskussion allerdings auch ewigs erweitern... Ich z.B. finde an VueJS super, dass eben Teile 1 bis 3 in einer Datei ist. Das ermöglicht Komponenten zu entwickeln, die wiederverwendbar sind (als Ganzes). Zudem macht es mir das sehr viel einfacher, den Scope zu denken, wenn ich wieder einmal an einer Komponente arbeiten. Für jemanden, der oft zwischen Tasks wechseln muss, ist es ein Vorteil, gleich alles an Ort zu haben.

Klar hat das auch Nachteile. Aber irgendwo beginnt es, philosophisch zu werden .

[hellbringer]

Hier kannst du die Diskussion allerdings auch ewigs erweitern... Ich z.B. finde an VueJS super, dass eben Teile 1 bis 3 in einer Datei ist.

Das geht in Angular auch, mach ich aber nie, weil das IMHO unübersichtlich wird.

Das ermöglicht Komponenten zu entwickeln, die wiederverwendbar sind (als Ganzes).

Dafür ist es egal ob es eine Datei oder drei Dateien sind. Bei mir ist eine Komponente ein Ordner. Alles, was zu dieser Komponente gehört, liegt in diesem Ordner.

Zudem macht es mir das sehr viel einfacher, den Scope zu denken, wenn ich wieder einmal an einer Komponente arbeiten. Für jemanden, der oft zwischen Tasks wechseln muss, ist es ein Vorteil, gleich alles an Ort zu haben.

Es ist eh alles an einem Ort, nur halt gegliedert in drei Dateien.

[tomBuilder]

Das geht in Angular auch, mach ich aber nie, weil das IMHO unübersichtlich wird.

Das geht bei jedem JS Framework mit MVC, wobei eine stärkere Aufteilung der Übersichtlichkeit wegen schon seit require.js und handlebars Sinn macht.

[ChristianK]

Das geht in Angular auch, mach ich aber nie, weil das IMHO unübersichtlich wird. [...]

Man könnte argumentieren, dass deine Komponenten zu gross sind. Wenn alles zusammen knapp 100 bis 150 Zeilen ist, ist das ja noch übersichtlich.

Wie gesagt, Geschmackssache...

[hellbringer]

Man könnte argumentieren, dass deine Komponenten zu gross sind. Wenn alles zusammen knapp 100 bis 150 Zeilen ist, ist das ja noch übersichtlich.

z.B. eine Komponente mit einer Übersichtstabelle (inkl. Filterung, Sortierung, usw.) hat schon über 500 Zeilen HTML-Code. Wüsste nicht, wie man die kleiner machen kann, außer alles in ewiglange Zeilen zu quetschen.

[lottikarotti]

Zwar ein wenig OT, aber sei's drum:

Hier kannst du die Diskussion allerdings auch ewigs erweitern... Ich z.B. finde an VueJS super, dass eben Teile 1 bis 3 in einer Datei ist. Das ermöglicht Komponenten zu entwickeln, die wiederverwendbar sind (als Ganzes). Zudem macht es mir das sehr viel einfacher, den Scope zu denken, wenn ich wieder einmal an einer Komponente arbeiten. Für jemanden, der oft zwischen Tasks wechseln muss, ist es ein Vorteil, gleich alles an Ort zu haben.

Wir nutzen fürs Styling einen deklarativen Ansatz, sprich wir arbeiten viel mit standardisierten CSS-Klassen und fürs Layout gibt es entsprechende Komponenten (bspw. für Flex, Dialoge, etc.) - d.h. das CSS ist in 90% der Fällen völlig uninteressant und wird auch gar nicht angefasst. Code & Markup betrachte ich dann meistens im Splitview. Ich persönlich mag die Trennung auf mehrere Dateien, denn sobald ich gleichzeitig an Code & Markup arbeite, brauche ich ohnehin einen Splitview, ansonsten müsste ich dauernd durch die Gegend scrollen (oder springen).

z.B. eine Komponente mit einer Übersichtstabelle (inkl. Filterung, Sortierung, usw.) hat schon über 500 Zeilen HTML-Code. Wüsste nicht, wie man die kleiner machen kann, außer alles in ewiglange Zeilen zu quetschen.

Wir haben mehrere eigenen DataGrid-Komponenten und beim kurzen durchgucken hat keine von denen mehr als 60-70 Zeilen pro Datei. Diese Komponenten sind aber auch sehr stark in ihre Einzelteile zerlegt, wodurch im Ausgleich umso mehr Dateien vorhanden sind.

[ChristianK]

Split View geht bei guten IDEs auch bei der gleichen Datei

[tomBuilder]

Sorry, aber wenn sich Software Desing nach den Möglichkeiten einer ide richtet,
dann ist es wirklich weit gekommen.

eine Komponente mit > 500 zeilen, welche sich nicht sinnvoll splitten lässt, halte ich für ein Märchen.

[lottikarotti]

Split View geht bei guten IDEs auch bei der gleichen Datei

Jup, habe auch nichts gegenteiliges behauptet

Sorry, aber wenn sich Software Desing nach den Möglichkeiten einer ide richtet,
dann ist es wirklich weit gekommen.

Diese Haltung finde ich etwas eintönig. Die IDE ist natürlich nicht *die* Entscheidungsgrundlage für das Design einer Software, aber durchaus ein wichtiges Werkzeug. Mir persönlich ist es wichtig, dass die IDE meinen Code so gut es geht versteht und mich bei der täglichen Arbeit so weit es geht unterstützt. Das kann sie in manchen Fällen (insbesondere bei PHP) aber nur indem ich meinen Code entsprechend formuliere (transparente Typisierung und Datenstrukturen) oder manuell mit Informationen anreichere (PhpDoc). Die IDE entscheidet also nicht über das Design, aber kann durchaus beeinflussen wie das Design sprachlich umgesetzt wird.

[wario]

Für headless spräche doch noch, dass man eine wie auch immer geartete Anwendnung (bspw. Brachenlösung mit wenig Individualisierung im Backend) hat und viele individuelle Frontends für unterschiedliche Kunden braucht.

Oder ganz banal so etwas wie Amazon, Youtube oder Zalando, Anwendungen wo ausgehend von User-Aktionen massig große Datenmengen dynamisch nachgeladen werden müssen, so etwas ist doch als reine Webserveranwendung gar nicht umsetzbar, ohne das die User-Experience zwangsläufig s****ße ist.

Würdet ihr bei der Auswahl des Architekturansatzes auch nach der Verwendung der Anwendnung durch die Zielgruppe gehen? Ich für meinen Teil surfe immer noch extrem ungerne mit dem (bzw. meinem alten Gurken-) Smartphone im Web. Ich meine damit die Auslierung statischer Seiten vs. die headless-Variante, je nachdem ob der Hauptteil der Zielgruppe eben Mobile oder Desktop benutzt.

[derwunner]

Würdet ihr bei der Auswahl des Architekturansatzes auch nach der Verwendung der Anwendnung durch die Zielgruppe gehen? Ich für meinen Teil surfe immer noch extrem ungerne mit dem (bzw. meinem alten Gurken-) Smartphone im Web. Ich meine damit die Auslierung statischer Seiten vs. die headless-Variante, je nachdem ob der Hauptteil der Zielgruppe eben Mobile oder Desktop benutzt.

Prinzipiell ja, macht aber keinen Sinn, da zum Beispiel auch Angular behauptet, es wäre mobile-first, bzw. mobile friendly. Leuchtet mir zwar nicht so ganz ein warum und wieso, aber gut...

[tomBuilder]

Prinzipiell ja, macht aber keinen Sinn, da zum Beispiel auch Angular behauptet, es wäre mobile-first, bzw. mobile friendly. Leuchtet mir zwar nicht so ganz ein warum und wieso, aber gut...

Hab ich dort noch nicht gelesen, überlesen und würde mich über einen Link freuen.

[derwunner]

Hab ich dort noch nicht gelesen, überlesen und würde mich über einen Link freuen.

Steht eigentlich hier schon: https://angular.io