Wow, wirklich ein großartiges Programm. Der Entwickler scheint Norweger zu sein. So ein hochwertiges Programm nur aus Spaß zu entwickeln und dann auch noch zu veröffentlichen – das ist sogar bewundernswert. Es wird mir wieder einmal bewusst, wie groß die Welt ist und wie viele Genies es gibt. Auch koreanische Entwickler sollten sich anstrengen und versuchen, einmal so etwas Großartiges zu entwickeln und zu veröffentlichen.
Das Konzept selbst kannte ich zwar gelegentlich schon, aber ich war überrascht, wie gut die Webseite aufgebaut ist, sodass man sie auf einen Blick verstehen und die Funktionen direkt ausprobieren kann.
Es war eine unterhaltsame Erfahrung, die mich in einem schläfrigen Moment sofort wieder hellwach gemacht hat.
Ursprünglich hätte ich in Situationen, in denen man ein SPA allein wegen der „Flüssigkeit“ in Betracht zieht, lieber einfach auf diese Flüssigkeit verzichtet und es als MPA umgesetzt, daher kann ich mich damit nicht wirklich identifizieren ...
Ehrlich gesagt gab es schon ein paar Leute, die eigentlich nichts zu tun hatten und trotzdem gezwungen versucht haben, mit mehreren Instanzen das Maximum rauszuholen...
Von den von Ihnen angeführten Beispielen gibt es praktisch nur bei Echtzeit-Kollaborationstools etwas, das sich nicht durch SPA mit Dingen wie View Transitions ersetzen ließe — aber die große Mehrheit der Websites sind keine Echtzeit-Kollaborationstools. Marketingseiten, Dashboards und Commerce-Apps lassen sich alle auch ohne SPA-Frameworks umsetzen, wenn man die Bedingungen Server-Rendering, echte Seiten, CSS-basierte Animationen, bewusstes Preloading und den Einsatz eines Minimums an JS einhält. In der Rails-Welt gibt es dafür auch Hotwire, und dafür existieren mit Basecamp und Hey zudem Produktionsbeispiele. State Management? Solange es nicht um so etwas wie Echtzeit-Kollaborationstools geht, reichen serverseitige Methoden wie URL-Parameter oder Server-Sessions oder auch Local Storage völlig aus. Es gibt eindeutig Fälle, in denen allein wegen der Seitenübergänge SPA eingeführt wird (wie etwa die offizielle Website von AGF, wo Astro eigentlich völlig ausgereicht hätte, aber trotzdem React eingeführt wurde), und man kann nicht bestreiten, dass Seitenübergänge häufig als einer der zentralen Vorteile von SPA genannt werden.
Es gibt sicherlich Fälle, in denen ein SPA-Framework allein wegen einer einzigen flüssigen Interaktion eingeführt wird. Bei einem erheblichen Teil der Websites, auf denen SPAs eingesetzt werden, sind komplexe Interaktionen gar nicht nötig.
Nicht alles ist ein Endofunktor. Bei Result<T, E> zum Beispiel, wo es mehrere Typparameter gibt, ist es nicht 𝒞 → 𝒞, sondern Result : 𝒞 × 𝒞 → 𝒞, daher ist so etwas ein Bifunktor.
Das ist ein sehr treffender Hinweis!
Es scheint, als sei beim Übertragen von Inhalten, die in anderen Sprachen verfasst wurden, auf Rust-Basis ein Missverständnis entstanden.
Da das Typsystem von Rust eine einzelne Kategorie bildet, scheint die Unterscheidung zwischen Endofunktor und allgemeinem Funktor bedeutungslos zu sein.
Schade, dass der Blog keine Kommentarfunktion hat; ich werde wohl nachfragen müssen, ob eine Korrekturanfrage möglich ist.
Da sind wirklich all die Funktionen drin, bei denen man sich denkt, es wäre schön, wenn es sie gäbe. Das Ding übernimmt ganz allein praktisch die Rolle eines NAS.
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.
Interessant.
Wow, wirklich ein großartiges Programm. Der Entwickler scheint Norweger zu sein. So ein hochwertiges Programm nur aus Spaß zu entwickeln und dann auch noch zu veröffentlichen – das ist sogar bewundernswert. Es wird mir wieder einmal bewusst, wie groß die Welt ist und wie viele Genies es gibt. Auch koreanische Entwickler sollten sich anstrengen und versuchen, einmal so etwas Großartiges zu entwickeln und zu veröffentlichen.
Dort drüben sind es auch nur viele Köpfe, aber was sie tun, ist hier wie dort dasselbe, haha.
Fängt mit K an und endet mit rea – wirkt wie der gewohnte Alltag eines uns nur zu vertrauten Landes.
Das Konzept selbst kannte ich zwar gelegentlich schon, aber ich war überrascht, wie gut die Webseite aufgebaut ist, sodass man sie auf einen Blick verstehen und die Funktionen direkt ausprobieren kann.
Es war eine unterhaltsame Erfahrung, die mich in einem schläfrigen Moment sofort wieder hellwach gemacht hat.
Ursprünglich hätte ich in Situationen, in denen man ein SPA allein wegen der „Flüssigkeit“ in Betracht zieht, lieber einfach auf diese Flüssigkeit verzichtet und es als MPA umgesetzt, daher kann ich mich damit nicht wirklich identifizieren ...
Ehrlich gesagt gab es schon ein paar Leute, die eigentlich nichts zu tun hatten und trotzdem gezwungen versucht haben, mit mehreren Instanzen das Maximum rauszuholen...
Von den von Ihnen angeführten Beispielen gibt es praktisch nur bei Echtzeit-Kollaborationstools etwas, das sich nicht durch SPA mit Dingen wie View Transitions ersetzen ließe — aber die große Mehrheit der Websites sind keine Echtzeit-Kollaborationstools. Marketingseiten, Dashboards und Commerce-Apps lassen sich alle auch ohne SPA-Frameworks umsetzen, wenn man die Bedingungen Server-Rendering, echte Seiten, CSS-basierte Animationen, bewusstes Preloading und den Einsatz eines Minimums an JS einhält. In der Rails-Welt gibt es dafür auch Hotwire, und dafür existieren mit Basecamp und Hey zudem Produktionsbeispiele. State Management? Solange es nicht um so etwas wie Echtzeit-Kollaborationstools geht, reichen serverseitige Methoden wie URL-Parameter oder Server-Sessions oder auch Local Storage völlig aus. Es gibt eindeutig Fälle, in denen allein wegen der Seitenübergänge SPA eingeführt wird (wie etwa die offizielle Website von AGF, wo Astro eigentlich völlig ausgereicht hätte, aber trotzdem React eingeführt wurde), und man kann nicht bestreiten, dass Seitenübergänge häufig als einer der zentralen Vorteile von SPA genannt werden.
Es gibt sicherlich Fälle, in denen ein SPA-Framework allein wegen einer einzigen flüssigen Interaktion eingeführt wird. Bei einem erheblichen Teil der Websites, auf denen SPAs eingesetzt werden, sind komplexe Interaktionen gar nicht nötig.
Nicht alles ist ein Endofunktor. Bei
Result<T, E>zum Beispiel, wo es mehrere Typparameter gibt, ist es nicht 𝒞 → 𝒞, sondernResult : 𝒞 × 𝒞 → 𝒞, daher ist so etwas ein Bifunktor.Das ist ein sehr treffender Hinweis!
Es scheint, als sei beim Übertragen von Inhalten, die in anderen Sprachen verfasst wurden, auf Rust-Basis ein Missverständnis entstanden.
Da das Typsystem von Rust eine einzelne Kategorie bildet, scheint die Unterscheidung zwischen Endofunktor und allgemeinem Funktor bedeutungslos zu sein.
Schade, dass der Blog keine Kommentarfunktion hat; ich werde wohl nachfragen müssen, ob eine Korrekturanfrage möglich ist.
Guter Artikel! Allerdings enthält die Erklärung zum Endofunktor einen Fehler, daher wäre es gut, wenn das korrigiert würde: https://x.com/simnalamburt/status/1950074970647761168?s=46
king - man + woman = queen
Da sind wirklich all die Funktionen drin, bei denen man sich denkt, es wäre schön, wenn es sie gäbe. Das Ding übernimmt ganz allein praktisch die Rolle eines NAS.
Schon die Demo-Seite ist äußerst beeindruckend. Es ist erstaunlich, wie viele verschiedene Funktionen mit wirklich kurzem Code unterstützt werden.
Von Komoot erwischt
NamuWiki ...
Ich verstehe nicht so recht, wie Altersverifikation und Datenschutz zusammen funktionieren sollen..
In dem Moment, in dem man sich verifiziert, hinterlässt man dort doch mindestens einmal so etwas wie seine Unterschrift, oder nicht?
Wenn man Datenschutz wirklich ernst meint, müsste man es anonym nutzen können.
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.