Diese Person meint wohl die Kosten für das IDE-Abonnement. FLCC wird in der kostenlosen Version nicht angeboten.
Aber es ist auch nicht so, dass die Leute nur deswegen Geld bezahlen.
Der eigentliche Zweck von SPA wird zu stark verkürzt interpretiert
Die View Transitions API ist wirklich großartig, aber allein dadurch werden SPAs nicht überflüssig.
Alle Websites werden nach denselben Maßstäben betrachtet
Marketing-Website ≠ Dashboard ≠ Commerce-App ≠ Echtzeit-Kollaborationstool
Alle haben unterschiedliche strukturelle Anforderungen.
In der Praxis koexistieren SPA + SSR + MPA
Hybride Frameworks wie Next.js zeigen das sehr gut.
Für statische Assets ist SSG sinnvoll, für Dashboards nach dem Login CSR/SPA, für Suchmaschinenkompatibilität SSR – es braucht also eine flexible Kombination.
Ich denke, SPA ist nicht nur ein Ergebnis der Verbesserung der User Experience, sondern eher ein Produkt struktureller Verbesserungen.
Für Seiten, auf denen SPA nicht nötig ist, kann MPA + modernes CSS eine gute Wahl sein. Aber in Bezug auf Architektur, State, Skalierbarkeit und Wartbarkeit bleibt SPA weiterhin essenziell. Ich denke, modernes CSS kann SPA zwar "ergänzen", aber nicht "ersetzen".
Ehrlich gesagt wirkt das so, als würde man über Rust oder Haskell, die man nicht einmal angefasst hat, sagen: „Das braucht man nicht, heutzutage geht mit C++ sowieso alles.“
Es stimmt zwar, dass man bei aktuellen SPA-Frameworks und den darauf basierenden Frontend-Trends weiterhin vorsichtig gegenüber fehlender Standardisierung sein muss und dass sie leicht zu Overengineering und unnötigem Ressourcenverbrauch führen können, aber …
Auch das Konzept eines SPA wird hier zu eng betrachtet, doch noch mehr frage ich mich, ob man versteht, welchen Einfluss SPA-Frameworks auf die Entwicklung insgesamt haben.
Zu sagen, mit nur einer View-Transition-API und etwas CSS sei alles erledigt, heißt anders formuliert, dass alle davon unabhängigen Funktionen und auch die Paradigmen zu ihrer Umsetzung völlig bedeutungslos seien — das erscheint mir keine zu arrogante Sichtweise zu sein.
Das ist wiederum ein anderes Problem als das Overengineering, wenn man eine Website, die kaum mehr als eine Broschüre ersetzt, mit React baut.
Ich stimme zu, dass die meisten kleinen Projekte nicht unbedingt ein SPA-Framework brauchen. Aber bei Services, deren Anforderungen komplexe Interaktionen, eine kontinuierliche User Experience sowie die daraus folgende Wartung und laufende Verbesserung umfassen, sehe ich das trotz der Weiterentwicklung von CSS anders.
Soweit ich weiß, kann es bei der Verwendung in Kotlin zu Performance-Problemen kommen, weil Primitive in Wrapper verpackt werden und dann nicht auf dem Stack, sondern auf dem Heap gespeichert werden. Natürlich hat in den meisten Use Cases die Wartbarkeit Vorrang. Außerdem lassen sich Performance-Probleme mit value class minimieren.
LLMs haben zwar nicht nur Vorteile, aber ich finde es schwer, der Aussage zuzustimmen, dass alle AI-Services nicht profitabel seien. Ich denke, dass innerhalb der nächsten fünf Jahre fast alle heutigen Plattform-Services größtenteils durch AI-Agenten ersetzt werden.
> Soll ich diese Zusammenfassung auch noch separat im Format eines zusammenfassenden PDF-Berichts (Kurzüberblick–Einleitung–Hauptteil–Fazit) dokumentieren?
Da die Person sonst auch oft viele Beiträge schreibt, wirkt es so, als hätte sie das absichtlich eingebaut, haha.
War ein interessanter Artikel. Wahrscheinlich ist es besser, erst einmal selbst den Kopf anzustrengen und dann ein LLM zu nutzen.
Großartig. Ich mag diesen Ansatz sehr.
Eine erfreuliche Optimierungsmethodik ohne ML-Basis.
Diese Person meint wohl die Kosten für das IDE-Abonnement. FLCC wird in der kostenlosen Version nicht angeboten.
Aber es ist auch nicht so, dass die Leute nur deswegen Geld bezahlen.
Was dem Artikel fehlt
Der eigentliche Zweck von SPA wird zu stark verkürzt interpretiert
Die View Transitions API ist wirklich großartig, aber allein dadurch werden SPAs nicht überflüssig.
Alle Websites werden nach denselben Maßstäben betrachtet
Marketing-Website ≠ Dashboard ≠ Commerce-App ≠ Echtzeit-Kollaborationstool
Alle haben unterschiedliche strukturelle Anforderungen.
In der Praxis koexistieren SPA + SSR + MPA
Hybride Frameworks wie Next.js zeigen das sehr gut.
Für statische Assets ist SSG sinnvoll, für Dashboards nach dem Login CSR/SPA, für Suchmaschinenkompatibilität SSR – es braucht also eine flexible Kombination.
Ich denke, SPA ist nicht nur ein Ergebnis der Verbesserung der User Experience, sondern eher ein Produkt struktureller Verbesserungen.
Für Seiten, auf denen SPA nicht nötig ist, kann MPA + modernes CSS eine gute Wahl sein. Aber in Bezug auf Architektur, State, Skalierbarkeit und Wartbarkeit bleibt SPA weiterhin essenziell. Ich denke, modernes CSS kann SPA zwar "ergänzen", aber nicht "ersetzen".
Ehrlich gesagt wirkt das so, als würde man über Rust oder Haskell, die man nicht einmal angefasst hat, sagen: „Das braucht man nicht, heutzutage geht mit C++ sowieso alles.“
Es stimmt zwar, dass man bei aktuellen SPA-Frameworks und den darauf basierenden Frontend-Trends weiterhin vorsichtig gegenüber fehlender Standardisierung sein muss und dass sie leicht zu Overengineering und unnötigem Ressourcenverbrauch führen können, aber …
Auch das Konzept eines SPA wird hier zu eng betrachtet, doch noch mehr frage ich mich, ob man versteht, welchen Einfluss SPA-Frameworks auf die Entwicklung insgesamt haben.
Zu sagen, mit nur einer View-Transition-API und etwas CSS sei alles erledigt, heißt anders formuliert, dass alle davon unabhängigen Funktionen und auch die Paradigmen zu ihrer Umsetzung völlig bedeutungslos seien — das erscheint mir keine zu arrogante Sichtweise zu sein.
Das ist wiederum ein anderes Problem als das Overengineering, wenn man eine Website, die kaum mehr als eine Broschüre ersetzt, mit React baut.
Ich stimme zu, dass die meisten kleinen Projekte nicht unbedingt ein SPA-Framework brauchen. Aber bei Services, deren Anforderungen komplexe Interaktionen, eine kontinuierliche User Experience sowie die daraus folgende Wartung und laufende Verbesserung umfassen, sehe ich das trotz der Weiterentwicklung von CSS anders.
Es ist schön, dass es viele Überlegungen zum Thema Vektorsuche gibt.
Soweit ich weiß, kann es bei der Verwendung in Kotlin zu Performance-Problemen kommen, weil Primitive in Wrapper verpackt werden und dann nicht auf dem Stack, sondern auf dem Heap gespeichert werden. Natürlich hat in den meisten Use Cases die Wartbarkeit Vorrang. Außerdem lassen sich Performance-Probleme mit
value classminimieren.Übrigens, das Rust-Support-Ticket: https://github.com/android/ndk/issues/1742
So etwas wäre auch für C++ schön!
Hm, ich weiß nicht so recht. Dient der Einsatz von SPA-Frameworks nicht eher komplexen Interaktionen mit den Nutzern als weichen Übergängen?
Da es lokal ausgeführt wird, scheint keine Gebühr erforderlich zu sein.
Dafür monatlich 20 bis 200 US-Dollar auszugeben, ist schon eher …
Übrigens Pass:
Hm ... ^^;;; Ich habe einen Fehler gemacht ... Beim nächsten Mal prüfe ich es etwas genauer, bevor ich es poste ...
LLMs haben zwar nicht nur Vorteile, aber ich finde es schwer, der Aussage zuzustimmen, dass alle AI-Services nicht profitabel seien. Ich denke, dass innerhalb der nächsten fünf Jahre fast alle heutigen Plattform-Services größtenteils durch AI-Agenten ersetzt werden.
> Soll ich diese Zusammenfassung auch noch separat im Format eines zusammenfassenden PDF-Berichts (Kurzüberblick–Einleitung–Hauptteil–Fazit) dokumentieren?
Da die Person sonst auch oft viele Beiträge schreibt, wirkt es so, als hätte sie das absichtlich eingebaut, haha.
War ein interessanter Artikel. Wahrscheinlich ist es besser, erst einmal selbst den Kopf anzustrengen und dann ein LLM zu nutzen.
Es stimmt wohl, dass sowohl die Genauigkeit als auch das Gefühl der Eigenverantwortung geringer waren.
Sogar die Zusammenfassung ist ein LLM …
Verstanden, danke.