Das Plädoyer von @stilkov für eine klassische Frontend-Architektur, ursprünglich im @OBJEKTspektrum erschienen, ist jetzt auch bei uns zu lesen: innoq.com/de/articles/2019/0… #roca

Wider die SPA-Fixierung

Die Vorteile einer klassischen Frontend-Architektur für Webanwendungen, bei der die Serverseite für das Erzeugen von HTML verantwortlich ist und JavaScript zwar erlaubt ist, aber nicht die komple...

innoq.com
6
29
3
38
Ich finde das Vorgehen nicht mehr ganz zeitgemäß. Wenn man z.B. React serverseitig rendert, dann funktioniert die Seite auch ohne JavaScript und man hat aber nur noch ein System zu pflegen.
1
2
Gibt’s denn in dem Ansatz, den ich beschreibe, zwei? Mir ist egal, womit man serverseitig rendert. Wenn React dafür super ist, nur zu.
1
Das heißt, ihr habt keinen separaten Prototypen, bzw. eine Trennung zwischen Frontend- und Backend-Entwicklung?
1
Weil die Frontend-Entwicklung heutzutage nicht mehr nur aus ein bisschen jQuery für Progressive Enhancement besteht. Es hat ja keiner von Silos gesprochen, aber eine Spezialisierung macht auf jeden Fall Sinn.
2
Ich halte es für einen weit verbreiteten Irrglauben, dass eine gute UX bzw. ein schickes, modernes, ergonomisches UI auf der einen Seite und Progressive Enhancement, SSR sowie der reduzierte Einsatz von JS auf der anderen Seite und damit irgendwie im Konflikt stehen.
1
Was ist denn gegen eine serverseitig gerenderte SPA zu sagen? Damit erschlägt man doch direkt beide Fliegen..
1
Replying to @bit_working @youngbrioche
Meiner Meinung nach müsste man eher rechtfertigen, warum man ein SPA-Framework braucht und nicht, warum man es nicht tut. Mehr bewegliche Teile, mehr Komplexität, mehr Abhängigkeiten … aber ich glaube, wir kommen in dieser Diskussion nicht mehr zusammen.

Apr 18, 2019 · 9:36 AM UTC

1
Replying to @stilkov @youngbrioche
Das stimmt schon, nur ist genau dadurch die Frontend Programmierung erwachsen geworden. Es wird jetzt auch mit typisierten Sprachen gearbeitet, inklusive Linting und Testing.