Genau so etwas wollte ich mir bauen, weil ich es unbedingt gebraucht habe – und jetzt hat es jemand umgesetzt ... Ich nutze Claude Code Max, und während ich mehrere Projekte gleichzeitig entwickle, war das wirklich eine Software, die ich gebraucht habe.
Ich hätte mir gewünscht, dass deutlich gezeigt wird, wie stark die Verbesserungen sind, wie gut das Modell ist und wie präzise es arbeitet – idealerweise anhand von Zahlen.
Dem Problem der Verschwendung von Speicherplatz kann ich ziemlich gut nachempfinden ...
Ich betreibe AKS, und jedes Mal, wenn ich eine Python-App mit einem Container-Image von über 1 GB sehe, bekomme ich Kopfschmerzen.
Im Moment nehme ich mir einfach das Dockerfile, reduziere die Größe selbst und lade es dann hoch; wenn ich es nicht unter 500 MB bekomme, gebe ich einfach auf, haha
Wow ...! Als ich es zum ersten Mal benutzt habe, war es ein Projekt, das ich wegen Python verwendet habe ...
Es ist eine lange Zeit vergangen!
Ich hoffe, ich kann wieder in einem Umfeld arbeiten, in dem ich es nutzen kann :) hehe
Vielleicht probiere ich es mal nebenbei aus ...
Bei mir kamen auch ständig Android-Push-Benachrichtigungen, dass kein Zugriff auf den DNS-Server möglich sei.
Ich bin vorübergehend auf Google DNS ausgewichen. https://developers.google.com/speed/public-dns/…
Mit einer verdammt starken Maschine zu einem verdammt guten Preis dürfte das wohl gehen? Eine verdammt große Kanzlei würde so etwas wahrscheinlich einfach kaufen. Aber dann liefe das Ding wie eine Fabrikmaschine 24 Stunden am Tag, lol.
Die Absicht des Originaltexts besteht nicht einfach darin, nur die komplexer gewordenen JS-Frameworks zu kritisieren.
Der Einfachheit halber zitiere ich aus dem oben verlinkten koreanischen Übersetzungstext.
Inzwischen braucht man allein zum Ändern einer einfachen Überschrift 4 Ingenieure, 3 Frameworks und eine CI/CD-Pipeline. Das Veröffentlichen einer Webseite ist auf absurde Weise kompliziert geworden.
So ist das Web schrittweise zu etwas geworden, das vor der Veröffentlichung kompiliert werden muss. Nicht, weil Nutzer es brauchen. Sondern weil Entwickler sich modern fühlen wollten.
Alles wurde für Entwickler optimiert und ist für alle anderen feindselig.
Wir ertragen Komplexität nicht mehr einfach nur, wir halten sie inzwischen für selbstverständlich. Wir gehen davon aus, dass jede Seite eine Build-Phase, einen Bundler, eine Hydration-Strategie, eine Routing-Schicht, eine API-Schicht, ein Design-System und clevere Cache-Invalidierungslogik braucht. Wir bauen mit Microservices, hosten in Edge-Netzwerken und deployen Pipelines, um einfache Inhalte auszuliefern.
Wir bauen die Funktionen von Plattformen wie WordPress neu nach, erzeugen dabei aber Ergebnisse, die zehnmal schwergewichtiger sind und sich deutlich schlechter benutzen lassen. Noch schlimmer ist, dass jede neue Schicht neue Bugs, neue Kompatibilitätsprobleme und neue kognitive Belastung einführt. Inzwischen warten wir Hydration-Logik, Cache-Strategien und Build-Pipelines, nur um eine einfache Homepage online zu bringen.
Marketingkampagnen verzögern sich, weil Komponentenbibliotheken nicht flexibel genug sind. A/B-Tests werden gestrichen, weil die Analytics-Schicht nicht mit der Hydration-Strategie kompatibel ist. Auf Content-Updates wartet man tagelang auf einen Build. Grundlegende SEO-Anpassungen verschwinden im Backlog.
Marketer können ohne Ticket weder Texte aktualisieren noch Experimente durchführen. Sie können Inhalte nicht in der Vorschau ansehen, keine Layouts testen und keine Seiten veröffentlichen. Jede Änderung muss durch Entwickler, Pipelines, Freigaben und Rebuilds.
Marketer, Content-Editoren, SEO-Verantwortliche und Designer — sie alle werden aus dem Prozess ausgeschlossen. Denn inzwischen erfordern selbst einfache Aufgaben technische Souveränität. Wenn man ein Title-Tag ändern will, heißt es, man solle mit einem Ingenieur sprechen; wenn man eine Kampagne veröffentlichen will, soll man ein Ticket erstellen und zwei Sprints warten.
Alles läuft durch das Entwicklerteam. Das bedeutet, dass das Entwicklerteam entscheidet, was wichtig ist, was ausgeliefert wird und was auf unbestimmte Zeit depriorisiert wird. Und je mehr Komplexität sie hinzufügen, desto unverzichtbarer werden sie.
Ich stimme dem im Originaltext angesprochenen Problem der „übermäßigen Komplexität des Webs“ zu. Aber ich halte es für schwierig, die Ursache allein auf Entwicklerkultur oder den Missbrauch von Frameworks zurückzuführen. Die Komplexität des heutigen Webs ist zu einem erheblichen Teil der Schatten unvermeidlicher Funktionen und Sicherheitsanforderungen, die das „Geschäftsmodell“ verlangt. Lässt man diesen Punkt weg, bleibt die Diagnose zwangsläufig unvollständig.
Das Web ist längst keine „kostenlose Ausstellungshalle“ mehr. Die meisten Web-Services von heute – mit Ausnahme öffentlicher Websites – haben das Ziel, Umsatz zu generieren. Deshalb sollte die zentrale Frage bei der Technologiewahl nicht lauten: „Ist dieser Code rein?“, sondern: „Hilft diese Technologie unserem Business, erfolgreich zu sein?“
Aus dieser Perspektive stößt das vom Originaltext idealisierte „leichte Content-Web“ an die Wand realer Business-Anforderungen. Ein Business, das etwa Inhalte verkauft, kann mit einfachen statischen Seiten nicht betrieben werden. Um bezahlte Abonnements und Zahlungen abzuwickeln, braucht es zustandsbasierte Logik wie Benutzerauthentifizierung, Prüfung des Abonnementstatus und Rechtemanagement; zum Schutz der Inhalte sind zudem Sicherheitsebenen wie die Echtzeit-Tokenvalidierung erforderlich, um unerlaubte Vervielfältigung oder unbefugten Zugriff zu verhindern. Darüber hinaus ist auch dynamische Datenverarbeitung nötig, um durch Personalisierung und A/B-Tests die User Experience und die Conversion Rate zu steigern.
All das gehört in den Bereich einer „ausgereiften Applikation“, und Frameworks sind dafür realistische Werkzeuge.
Natürlich lässt sich nicht jede Komplexität rechtfertigen. Wir sollten Komplexität in zwei Arten unterscheiden.
Unvermeidliche Komplexität: Komplexität mit klarem ROI, die bei der Umsetzung von Business-Funktionen entsteht, etwa Authentifizierung, Zahlung oder Personalisierung. Sie ist ein Kostenfaktor, den man in Kauf nehmen muss.
Zufällige Komplexität: unnötige Komplexität, die aus Entwicklerbequemlichkeit oder übermäßiger technischer Abstraktion entsteht. Sie ist technische Schuld und Verschwendung, die fortlaufend gemessen und beseitigt werden muss.
Erfolgreiche Services unterscheiden zwischen diesen beiden Arten und bauen darauf eine realistische Architektur auf. Das heißt: Die Frontlinie, in der Marketing und SEO wichtig sind, wird so leicht wie möglich gehalten, während interne Bereiche, in denen zentrale Transaktionen oder Personalisierungsfunktionen nötig sind, auf Framework-Basis abgesichert werden. Mit einer solchen Hybridstrategie lassen sich Geschwindigkeit und Funktionalität zugleich erreichen.
Der Originaltext konzentriert sich bei der Verschlechterung der User Experience allein auf die Framework-Kultur und blendet die „unvermeidlichen Anforderungen des Erlösmodells“ aus. Über Webentwicklung zu sprechen und diesen Punkt wegzulassen, ist letztlich so, als würde man nur darüber reden, den Gästen am Tisch „schnelle und leckere Gerichte“ zu servieren, während man so tut, als gäbe es die komplexe Küche und die Kasse, in der dafür bezahlt wird, gar nicht.
Nur weil das Web schwergewichtig geworden ist, kann man Frameworks nicht einfach pauschal verwerfen. Entscheidend sollte sein, wie effizient und mit welchen minimalen Kosten sich die vom Business geforderten Funktionen umsetzen lassen, um den Nutzern Mehrwert zu liefern.
Bei Diensten wie Chatbots, bei denen eine Streaming-Funktion bereitgestellt werden muss, scheint sich bei gleichzeitiger Verarbeitung die Prefill-Arbeit bis auf das Decoding auszuwirken. Deshalb wirkt es aus Sicht der Nutzer so, als würde die Leistung stark einbrechen, selbst wenn ausreichend VRAM vorhanden ist.
Ich habe Optionen im Zusammenhang mit Chunked Prefill sowie die in vLLM experimentell bereitgestellte Funktion „Disaggregated Prefilling“ ausprobiert. Trotzdem tritt weiterhin das Phänomen auf, dass bereits laufende Antworten ins Stocken geraten und immer wieder abbrechen, sobald neue Anfragen eingehen. Daher würde mich aus der Sicht eines Einsteiger-Entwicklers interessieren, ob es abgesehen davon, die Zahl der GPUs oder Nodes zu erhöhen, einen effizienteren Ansatz gibt.
Genau so etwas wollte ich mir bauen, weil ich es unbedingt gebraucht habe – und jetzt hat es jemand umgesetzt ... Ich nutze Claude Code Max, und während ich mehrere Projekte gleichzeitig entwickle, war das wirklich eine Software, die ich gebraucht habe.
Herzlichen Glückwunsch zum Geburtstag, Django!
Die koreanische Übersetzung finden Sie unten.
https://roy-jung.github.io/250701-history-of-js/
Ich hätte mir gewünscht, dass deutlich gezeigt wird, wie stark die Verbesserungen sind, wie gut das Modell ist und wie präzise es arbeitet – idealerweise anhand von Zahlen.
Ich frage mich, wie sich Korea davon unterscheidet.
Dem Problem der
Verschwendung von Speicherplatzkann ich ziemlich gut nachempfinden ...Ich betreibe AKS, und jedes Mal, wenn ich eine Python-App mit einem Container-Image von über 1 GB sehe, bekomme ich Kopfschmerzen.
Im Moment nehme ich mir einfach das Dockerfile, reduziere die Größe selbst und lade es dann hoch; wenn ich es nicht unter 500 MB bekomme, gebe ich einfach auf, haha
Wow ...! Als ich es zum ersten Mal benutzt habe, war es ein Projekt, das ich wegen Python verwendet habe ...
Es ist eine lange Zeit vergangen!
Ich hoffe, ich kann wieder in einem Umfeld arbeiten, in dem ich es nutzen kann :) hehe
Vielleicht probiere ich es mal nebenbei aus ...
Ist es nicht fast schon Betrug, Claude 3 mit Claude 4 zu vergleichen, wenn Claude 4 bereits erschienen ist...
Es war ab etwa 7:00 Uhr koreanischer Zeit ungefähr 50 Minuten lang ausgefallen, jetzt funktioniert es wieder gut.
CMD> nslookup news.hada.io 1.1.1.1
Bei mir kamen auch ständig Android-Push-Benachrichtigungen, dass kein Zugriff auf den DNS-Server möglich sei.
Ich bin vorübergehend auf Google DNS ausgewichen.
https://developers.google.com/speed/public-dns/…
wow...
Stimmt, je tiefer man ergründet, was das Ziel ist und warum man es tun sollte, desto klarer scheint die Lösung zu werden.
Danke, dass Sie den Artikel so positiv aufgenommen haben!
Vielen Dank für die netten Worte!
Mit einer verdammt starken Maschine zu einem verdammt guten Preis dürfte das wohl gehen? Eine verdammt große Kanzlei würde so etwas wahrscheinlich einfach kaufen. Aber dann liefe das Ding wie eine Fabrikmaschine 24 Stunden am Tag, lol.
Jemand, der nur an den Porsche-Preis denkt und Unterhaltskosten, Spritkosten, Versicherung usw. überhaupt nicht berücksichtigt.
Die Absicht des Originaltexts besteht nicht einfach darin, nur die komplexer gewordenen JS-Frameworks zu kritisieren.
Der Einfachheit halber zitiere ich aus dem oben verlinkten koreanischen Übersetzungstext.
Scheint auf koreanische Unternehmen nicht anwendbar zu sein.
Ich stimme dem im Originaltext angesprochenen Problem der „übermäßigen Komplexität des Webs“ zu. Aber ich halte es für schwierig, die Ursache allein auf Entwicklerkultur oder den Missbrauch von Frameworks zurückzuführen. Die Komplexität des heutigen Webs ist zu einem erheblichen Teil der Schatten unvermeidlicher Funktionen und Sicherheitsanforderungen, die das „Geschäftsmodell“ verlangt. Lässt man diesen Punkt weg, bleibt die Diagnose zwangsläufig unvollständig.
Das Web ist längst keine „kostenlose Ausstellungshalle“ mehr. Die meisten Web-Services von heute – mit Ausnahme öffentlicher Websites – haben das Ziel, Umsatz zu generieren. Deshalb sollte die zentrale Frage bei der Technologiewahl nicht lauten: „Ist dieser Code rein?“, sondern: „Hilft diese Technologie unserem Business, erfolgreich zu sein?“
Aus dieser Perspektive stößt das vom Originaltext idealisierte „leichte Content-Web“ an die Wand realer Business-Anforderungen. Ein Business, das etwa Inhalte verkauft, kann mit einfachen statischen Seiten nicht betrieben werden. Um bezahlte Abonnements und Zahlungen abzuwickeln, braucht es zustandsbasierte Logik wie Benutzerauthentifizierung, Prüfung des Abonnementstatus und Rechtemanagement; zum Schutz der Inhalte sind zudem Sicherheitsebenen wie die Echtzeit-Tokenvalidierung erforderlich, um unerlaubte Vervielfältigung oder unbefugten Zugriff zu verhindern. Darüber hinaus ist auch dynamische Datenverarbeitung nötig, um durch Personalisierung und A/B-Tests die User Experience und die Conversion Rate zu steigern.
All das gehört in den Bereich einer „ausgereiften Applikation“, und Frameworks sind dafür realistische Werkzeuge.
Natürlich lässt sich nicht jede Komplexität rechtfertigen. Wir sollten Komplexität in zwei Arten unterscheiden.
Unvermeidliche Komplexität: Komplexität mit klarem ROI, die bei der Umsetzung von Business-Funktionen entsteht, etwa Authentifizierung, Zahlung oder Personalisierung. Sie ist ein Kostenfaktor, den man in Kauf nehmen muss.
Zufällige Komplexität: unnötige Komplexität, die aus Entwicklerbequemlichkeit oder übermäßiger technischer Abstraktion entsteht. Sie ist technische Schuld und Verschwendung, die fortlaufend gemessen und beseitigt werden muss.
Erfolgreiche Services unterscheiden zwischen diesen beiden Arten und bauen darauf eine realistische Architektur auf. Das heißt: Die Frontlinie, in der Marketing und SEO wichtig sind, wird so leicht wie möglich gehalten, während interne Bereiche, in denen zentrale Transaktionen oder Personalisierungsfunktionen nötig sind, auf Framework-Basis abgesichert werden. Mit einer solchen Hybridstrategie lassen sich Geschwindigkeit und Funktionalität zugleich erreichen.
Der Originaltext konzentriert sich bei der Verschlechterung der User Experience allein auf die Framework-Kultur und blendet die „unvermeidlichen Anforderungen des Erlösmodells“ aus. Über Webentwicklung zu sprechen und diesen Punkt wegzulassen, ist letztlich so, als würde man nur darüber reden, den Gästen am Tisch „schnelle und leckere Gerichte“ zu servieren, während man so tut, als gäbe es die komplexe Küche und die Kasse, in der dafür bezahlt wird, gar nicht.
Nur weil das Web schwergewichtig geworden ist, kann man Frameworks nicht einfach pauschal verwerfen. Entscheidend sollte sein, wie effizient und mit welchen minimalen Kosten sich die vom Business geforderten Funktionen umsetzen lassen, um den Nutzern Mehrwert zu liefern.
Bei Diensten wie Chatbots, bei denen eine Streaming-Funktion bereitgestellt werden muss, scheint sich bei gleichzeitiger Verarbeitung die Prefill-Arbeit bis auf das Decoding auszuwirken. Deshalb wirkt es aus Sicht der Nutzer so, als würde die Leistung stark einbrechen, selbst wenn ausreichend VRAM vorhanden ist.
Ich habe Optionen im Zusammenhang mit Chunked Prefill sowie die in vLLM experimentell bereitgestellte Funktion „Disaggregated Prefilling“ ausprobiert. Trotzdem tritt weiterhin das Phänomen auf, dass bereits laufende Antworten ins Stocken geraten und immer wieder abbrechen, sobald neue Anfragen eingehen. Daher würde mich aus der Sicht eines Einsteiger-Entwicklers interessieren, ob es abgesehen davon, die Zahl der GPUs oder Nodes zu erhöhen, einen effizienteren Ansatz gibt.