Das ist viel zu beängstigend.
Dass böswillig festgehaltene Aufzeichnungen
Erinnerungen und Erfahrungen verdrängen, zu Beweisen werden
und uns bedrohen können.
Es gibt doch gar nicht so viele Browser, die die Leute verwenden, aber warum gibt es dann so viele Frameworks? Wäre es nicht am besten, wenn die Unternehmen, die die Browser betreiben, ein optimales Framework entwickeln und es gemeinsam mitverwalten würden? Wie lange soll dieser Teufelskreis noch weitergehen?
Dem beschriebenen Phänomen stimme ich zu, der Schlussfolgerung aber nicht.
Die vordergründige Ursache des Phänomens ist, wie auch im Artikel erwähnt, die gestiegene Nachfrage nach einem „app-ähnlichen Web“.
Sowohl damals als auch heute war das Web eigentlich nicht besonders geeignet, um „etwas App-Ähnliches“ zu bauen, aber mit genug Verrenkungen ist es in einem Zustand, in dem man „etwas Ähnliches bauen kann“.
Tatsächlich wurde das Web seinem Ursprung nach als Plattform geschaffen, um eine Art „Dokumente“ wie wissenschaftliche Arbeiten zu teilen.
Das erkennt man schon an den grundlegenden Bausteinen von HTML.
Dann kamen Technologien auf, mit denen sich dynamische Inhalte erzeugen ließen, etwa CGI, und als auf Browser-Seite Skriptsprachen eingebaut wurden, konnte man den Ergebnissen Dynamik verleihen. Damit begann die Ablösung vom „Web als Dokument“.
Das Problem ist, dass das Fundament des Webs vom ersten Moment dieser Ablösung bis heute weiterhin ein auf „Dokumenten“ basierendes System ist.
Natürlich sind mit WebSocket, WebRTC, WASM und ähnlichem viele neue Technologien entstanden, die sich von der „Dokument“-Ausrichtung entfernen, aber bis heute werden die meisten Websites weiterhin auf Grundlage der bestehenden „dokumentbasierten“ Plattform entwickelt.
Noch immer müssen wir div-Tags aufeinanderstapeln, um Bildschirme zu zeichnen.
Bis hierhin wäre das die Analyse des Phänomens, und dann fragt man sich natürlich, was die Antwort darauf ist.
Wenn man die Realisierbarkeit völlig außer Acht lässt und sich die Funktionen einer idealen nächsten Plattform vorstellt, sähe das so aus:
(Nicht, dass alle Websites so sein müssten, sondern nur Seiten mit Anwendungscharakter.)
Der Browser würde zunächst eine Art App-Launcher werden.
Wenn man eine Anwendung einmal heruntergeladen hat, sollte sie auch offline ausführbar sein.
Und die Apps würden nicht mehr mit dem bisherigen HTML/CSS/JS umgesetzt, sondern in anderen Sprachen.
Dabei könnte der Browser, ähnlich wie Android, eine Art Framework bereitstellen.
Auch die Kommunikation mit dem Server könnte sich vom bisherigen Web-Request-Modell lösen und ein anderes Paradigma verwenden.
Für Kommunikation mit Echtzeit-Anforderungen könnte man weiterhin das bestehende TCP direkt nutzen,
oder man könnte eine neue, einfachere RPC-Kommunikation schaffen und verwenden, die nicht auf dem HTTP-Protokoll basiert.
Vor einem Monat habe ich mit CURSOR begonnen, um zu lernen, was AI Coding ist, und habe mich an die Entwicklung eines Entwicklungs-Frameworks gemacht.
Etwa drei Wochen lang wiederholte sich, dass Quellcode, der erfolgreich war und von einem AI Agent validiert worden war, wieder kaputtging. Ich versuchte mit allen möglichen Methoden, den AI Agent zu kontrollieren, aber ich scheiterte.
Dann wurde mir klar, dass es Vorrang hat, vor der Entwicklung des Entwicklungs-Frameworks zunächst den Quellcode zu entwickeln, der den AI Agent kontrolliert.
Schließlich habe ich genau einen Monat nach dem Start, bei dem ich zunächst verstehen wollte, was AI überhaupt ist, das Ergebnis erreicht, Software fertigzustellen, die zu 100 % durch AI implementiert und zu 100 % betrieben werden kann, wobei ich den AI Agent vollständig kontrolliere (genauer gesagt: ohne dass externe LLMs oder AI Agents nötig sind).
Derzeit bin ich am 14. Tag dabei, diese META AI für zusätzliche Weiterentwicklung weiter zu trainieren und dabei Betriebsregeln zu erstellen und durchsetzen zu lassen. Gleichzeitig migriere, verbessere und standardisiere ich drei MES-Systeme, die zuvor von Menschen unvollständig erstellt worden waren, und befinde mich dabei in der Abschlussphase.
Und jetzt bereite ich bereits die nächste Evolution vor.
Die Kernvision der MCP-B-Technologie lässt sich wohl wie folgt zusammenfassen.
„Über das vertrauenswürdige Vermittlungsmedium einer Chrome-Erweiterung (Extension) sollen die Nutzerdaten, die der Browser bereits sicher verwaltet (Cookies, Sessions, Authentifizierung usw.), genutzt werden, um die vom Entwickler vorab auf der Webseite definierten ‚Tools‘ per natürlichem Sprachbefehl aus dem AI-Chatfenster aufzurufen und zu steuern.“
Ich habe jedoch das Gefühl, dass „kaum Potenzial zur Verbreitung besteht“, und ich denke, die Gründe dafür sind die folgenden.
Widerstand der Nutzer: Das ist die größte Hürde. Nutzer haben eine instinktive Abneigung und Sicherheitsbedenken gegenüber der Installation von Erweiterungen, die auf ihre Browserdaten zugreifen. Wenn der Komfort, den diese Technologie bietet, diese Sorgen nicht deutlich überwiegt, werden Nutzer mit der Installation zögern.
Belastung für Webentwickler: Entwickler von Websites müssen zusätzlich zur Erstellung bestehender APIs einen zusätzlichen Aufwand betreiben, indem sie eigens ‚Tools‘ für MCP-B definieren und verwalten. Wenn der Nutzen durch eine breite Einführung dieser Technologie nicht groß ist, werden Entwickler kaum bereit sein, diesen doppelten Aufwand auf sich zu nehmen.
Unklare Verantwortlichkeit bei Sicherheitsproblemen: Falls durch diese Technologie ein Sicherheitsvorfall entsteht, könnte unklar werden, ob die Verantwortung beim Website-Entwickler, beim Entwickler der Erweiterung oder beim Anbieter des AI-Modells liegt. Diese Komplexität führt dazu, dass Unternehmen die Einführung der Technologie scheuen.
Fehlen einer zentralisierten Plattform: Derzeit gibt es kein standardisiertes Verzeichnis oder keine Plattform, die angibt, „welche Website welche Tools bereitstellt“. Nutzer können daher vor dem Besuch einer Website nur schwer erkennen, welche AI-Funktionen verfügbar sind.
Zusammenfassend lässt sich sagen:
Die Idee von MCP-B selbst ist technologisch sehr interessant und innovativ, doch sie scheint weder Nutzern noch Entwicklern eine klare Antwort auf die grundlegende Frage zu geben: „Warum sollte man ausgerechnet diesen Ansatz verwenden?“ Gegenüber dem bestehenden API-Ansatz sind die Vorteile unklar, während die Nachteile in Form von Sicherheitsbedenken und Entwicklungsaufwand deutlich zutage treten.
Daher scheint diese Technologie derzeit zwar experimentell von einigen Enthusiasten oder Entwicklern mit speziellen Zielen genutzt werden zu können, doch für eine Ausweitung auf das gesamte Web-Ökosystem gibt es offenbar viele Hürden.
Ich kann die grundlegende Problemwahrnehmung dieses Artikels nachvollziehen, aber an manchen Stellen bringt er mich doch etwas zum Stirnrunzeln.
Zum Beispiel bewahrt die Werbe-Website für einen bestimmten Dienst, den unser Unternehmen betreibt, genau die Art von Einfachheit, die dieser Artikel lobt. Glücklicherweise sind die meisten Elemente dieser Website hinreichend statisch. Der Frontend-Code wie HTML und CSS wurde von Menschen direkt von Hand geschrieben, ganz ohne Framework, und bei JS hängen nur jQuery und Google Analytics dran. Dinge wie Bekanntmachungen oder ein schwarzes Brett sind zwar per AJAX mit jQuery umgesetzt, aber ich halte das weder für unvernünftig noch für übermäßig komplex. Meiner Meinung nach ist das ungefähr auf dem Niveau, das ich umsetzen konnte, als ich vor langer Zeit mit grundlegender Webentwicklung anfing. Soweit ich weiß, wird diese Seite noch seit der Zeit des Internet Explorer betrieben, also habe ich sie nicht selbst gebaut, aber ich finde sie gar nicht schlecht.
Allerdings gibt es hier Git-Versionsverwaltung und eine CI/CD-Pipeline, und Staging-Server und Produktionsserver sind voneinander getrennt. Wenn ein Pull Request in den Main-Branch gemergt wird, deployt die Pipeline das vom Bundler erzeugte Artefakt automatisch auf den Staging-Server, und nachdem die zuständige Person den Staging-Server geprüft und die endgültige Freigabe erteilt hat, wird es anschließend auf den Produktionsserver ausgerollt. Früher wurden die Quelldateien einfach per FTP direkt auf dem Produktionsserver überschrieben, aber nachdem die entsprechende Arbeit an unser Team überging, haben wir das so geändert.
Ist das wirklich unvernünftige Komplexität? Früher war das Ändern des Title-Tags dieser Website eine Sache von: mit AcroEdit auf den Produktionsserver per FTP verbinden (ja, die Leute, die das HTML dieser Seite ursprünglich direkt geschrieben haben, benutzten das immer noch), eine Zeile in der HTML-Datei direkt ändern und speichern, und damit war alles erledigt. Daher könnten sie das wahrscheinlich tatsächlich so empfinden.
Ich denke jedoch, dass dieses Maß an zusätzlicher Komplexität absolut vertretbar war. Nicht jede Aufgabe ist schließlich so einfach wie das Ändern eines einzigen Title-Tags. Und dass alter, nur auskommentierter Code, der überall angeklebt war, jederzeit wiederhergestellt werden kann, erlaubt es einem, ihn ohne große Last vollständig zu löschen; außerdem sind transparente Nachverfolgung von Änderungen und Rollbacks möglich, und der Bundler kann bei Bedarf noch einige grundlegendere Optimierungen hinzufügen. Das sind meiner Ansicht nach klare Vorteile. Auch das Hinzufügen eines Staging-Servers, auf dem man vor dem Deployment in die reale Umgebung eine Vorschau sehen kann, könnte man als eine Form von Komplexität ansehen, aber ich halte das für notwendig.
Auch ich habe viele Beschwerden darüber, dass die internen Code-Strukturen verschiedenster Websites übermäßig komplex und schwerfällig geworden sind. Die Outlook-App unter Windows basiert heutzutage auf einer Web-App, und in letzter Zeit ist sie besonders noch schwerfälliger geworden. Es ist inzwischen so weit, dass es schon ruckelt, wenn man einfach nur den Mail-Text auf dem Bildschirm schreibt oder den gesamten Text markiert, und im Extremfall erscheint sogar "Seite reagiert nicht". Als ich mich fragte, warum das so ist, und in Web-Outlook die Entwicklertools öffnete, war ich ehrlich schockiert. Nachdem ich einmal den Cache geleert und die Seite neu geladen hatte, liefen selbst eine Minute später noch immer irgendwelche Requests weiter. Als ich im Browser nachsah, waren allein im Zusammenhang mit der MS-Office-Site mehrere Gigabyte an Daten gespeichert.
Dieser Artikel wirft jedoch vieles durcheinander; manchen Punkten stimme ich zu, manchen eher nicht. Was semantisches HTML oder Barrierefreiheit betrifft, war die Vergangenheit meinem Wissen nach sogar noch viel schlimmer. Und dass eine Verbesserung der Developer Experience die User Experience verschlechtere, kann ich überhaupt nicht nachvollziehen — vielleicht liegt das daran, dass ich kein Web-Frontend-Entwickler bin. Sogar die Behauptung, dass sich alle Macht und Kontrolle bei den Entwicklern konzentriert hätten, klingt für mich absurd. Liegt die Macht in Unternehmen nicht beim Management? Oder sind Unternehmensstrukturen im Westen vielleicht doch etwas anders als in Korea?
Wie immer stimme ich voll und ganz zu, dass Ausgewogenheit und Maß, Einfachheit und Pragmatismus wichtige Werte sind und bei Entscheidungen priorisiert werden sollten. Aber dieser Artikel argumentiert so, als sei "alle Websites wie Softwareprodukte zu behandeln" vollständig die Verantwortung der Entwickler, und ich denke, genau das verwässert eher die grundlegende Problemwahrnehmung. Und die Stellen, die die "gute alte Zeit" verklären, in der es keine gewachsenen Prozesse gab, verdienen meiner Meinung nach eher Kritik.
Die angestrebten Entwicklungsphilosophien unterscheiden sich eben stark voneinander.........
Offenbar ist auch KI nicht fair.
Das ist viel zu beängstigend.
Dass böswillig festgehaltene Aufzeichnungen
Erinnerungen und Erfahrungen verdrängen, zu Beweisen werden
und uns bedrohen können.
Es gibt doch gar nicht so viele Browser, die die Leute verwenden, aber warum gibt es dann so viele Frameworks? Wäre es nicht am besten, wenn die Unternehmen, die die Browser betreiben, ein optimales Framework entwickeln und es gemeinsam mitverwalten würden? Wie lange soll dieser Teufelskreis noch weitergehen?
Ich frage mich, warum es gescheitert ist.
Die ultimative Form einer KI, die Nutzern schmeichelt, war also eine KI, die dem Chef schmeichelt ...
Dem beschriebenen Phänomen stimme ich zu, der Schlussfolgerung aber nicht.
Die vordergründige Ursache des Phänomens ist, wie auch im Artikel erwähnt, die gestiegene Nachfrage nach einem „app-ähnlichen Web“.
Sowohl damals als auch heute war das Web eigentlich nicht besonders geeignet, um „etwas App-Ähnliches“ zu bauen, aber mit genug Verrenkungen ist es in einem Zustand, in dem man „etwas Ähnliches bauen kann“.
Tatsächlich wurde das Web seinem Ursprung nach als Plattform geschaffen, um eine Art „Dokumente“ wie wissenschaftliche Arbeiten zu teilen.
Das erkennt man schon an den grundlegenden Bausteinen von HTML.
Dann kamen Technologien auf, mit denen sich dynamische Inhalte erzeugen ließen, etwa CGI, und als auf Browser-Seite Skriptsprachen eingebaut wurden, konnte man den Ergebnissen Dynamik verleihen. Damit begann die Ablösung vom „Web als Dokument“.
Das Problem ist, dass das Fundament des Webs vom ersten Moment dieser Ablösung bis heute weiterhin ein auf „Dokumenten“ basierendes System ist.
Natürlich sind mit WebSocket, WebRTC, WASM und ähnlichem viele neue Technologien entstanden, die sich von der „Dokument“-Ausrichtung entfernen, aber bis heute werden die meisten Websites weiterhin auf Grundlage der bestehenden „dokumentbasierten“ Plattform entwickelt.
Noch immer müssen wir
div-Tags aufeinanderstapeln, um Bildschirme zu zeichnen.Bis hierhin wäre das die Analyse des Phänomens, und dann fragt man sich natürlich, was die Antwort darauf ist.
Wenn man die Realisierbarkeit völlig außer Acht lässt und sich die Funktionen einer idealen nächsten Plattform vorstellt, sähe das so aus:
(Nicht, dass alle Websites so sein müssten, sondern nur Seiten mit Anwendungscharakter.)
Der Browser würde zunächst eine Art App-Launcher werden.
Wenn man eine Anwendung einmal heruntergeladen hat, sollte sie auch offline ausführbar sein.
Und die Apps würden nicht mehr mit dem bisherigen HTML/CSS/JS umgesetzt, sondern in anderen Sprachen.
Dabei könnte der Browser, ähnlich wie Android, eine Art Framework bereitstellen.
Auch die Kommunikation mit dem Server könnte sich vom bisherigen Web-Request-Modell lösen und ein anderes Paradigma verwenden.
Für Kommunikation mit Echtzeit-Anforderungen könnte man weiterhin das bestehende TCP direkt nutzen,
oder man könnte eine neue, einfachere RPC-Kommunikation schaffen und verwenden, die nicht auf dem HTTP-Protokoll basiert.
Oh, na ja, offenbar ist auch die Zukunft von Windsurf nicht nur rosig.
Vor einem Monat habe ich mit CURSOR begonnen, um zu lernen, was AI Coding ist, und habe mich an die Entwicklung eines Entwicklungs-Frameworks gemacht.
Etwa drei Wochen lang wiederholte sich, dass Quellcode, der erfolgreich war und von einem AI Agent validiert worden war, wieder kaputtging. Ich versuchte mit allen möglichen Methoden, den AI Agent zu kontrollieren, aber ich scheiterte.
Dann wurde mir klar, dass es Vorrang hat, vor der Entwicklung des Entwicklungs-Frameworks zunächst den Quellcode zu entwickeln, der den AI Agent kontrolliert.
Schließlich habe ich genau einen Monat nach dem Start, bei dem ich zunächst verstehen wollte, was AI überhaupt ist, das Ergebnis erreicht, Software fertigzustellen, die zu 100 % durch AI implementiert und zu 100 % betrieben werden kann, wobei ich den AI Agent vollständig kontrolliere (genauer gesagt: ohne dass externe LLMs oder AI Agents nötig sind).
Derzeit bin ich am 14. Tag dabei, diese META AI für zusätzliche Weiterentwicklung weiter zu trainieren und dabei Betriebsregeln zu erstellen und durchsetzen zu lassen. Gleichzeitig migriere, verbessere und standardisiere ich drei MES-Systeme, die zuvor von Menschen unvollständig erstellt worden waren, und befinde mich dabei in der Abschlussphase.
Und jetzt bereite ich bereits die nächste Evolution vor.
Die Kernvision der MCP-B-Technologie lässt sich wohl wie folgt zusammenfassen.
„Über das vertrauenswürdige Vermittlungsmedium einer Chrome-Erweiterung (Extension) sollen die Nutzerdaten, die der Browser bereits sicher verwaltet (Cookies, Sessions, Authentifizierung usw.), genutzt werden, um die vom Entwickler vorab auf der Webseite definierten ‚Tools‘ per natürlichem Sprachbefehl aus dem AI-Chatfenster aufzurufen und zu steuern.“
Ich habe jedoch das Gefühl, dass „kaum Potenzial zur Verbreitung besteht“, und ich denke, die Gründe dafür sind die folgenden.
Zusammenfassend lässt sich sagen:
Die Idee von MCP-B selbst ist technologisch sehr interessant und innovativ, doch sie scheint weder Nutzern noch Entwicklern eine klare Antwort auf die grundlegende Frage zu geben: „Warum sollte man ausgerechnet diesen Ansatz verwenden?“ Gegenüber dem bestehenden API-Ansatz sind die Vorteile unklar, während die Nachteile in Form von Sicherheitsbedenken und Entwicklungsaufwand deutlich zutage treten.
Daher scheint diese Technologie derzeit zwar experimentell von einigen Enthusiasten oder Entwicklern mit speziellen Zielen genutzt werden zu können, doch für eine Ausweitung auf das gesamte Web-Ökosystem gibt es offenbar viele Hürden.
Ich kann die grundlegende Problemwahrnehmung dieses Artikels nachvollziehen, aber an manchen Stellen bringt er mich doch etwas zum Stirnrunzeln.
Zum Beispiel bewahrt die Werbe-Website für einen bestimmten Dienst, den unser Unternehmen betreibt, genau die Art von Einfachheit, die dieser Artikel lobt. Glücklicherweise sind die meisten Elemente dieser Website hinreichend statisch. Der Frontend-Code wie HTML und CSS wurde von Menschen direkt von Hand geschrieben, ganz ohne Framework, und bei JS hängen nur jQuery und Google Analytics dran. Dinge wie Bekanntmachungen oder ein schwarzes Brett sind zwar per AJAX mit jQuery umgesetzt, aber ich halte das weder für unvernünftig noch für übermäßig komplex. Meiner Meinung nach ist das ungefähr auf dem Niveau, das ich umsetzen konnte, als ich vor langer Zeit mit grundlegender Webentwicklung anfing. Soweit ich weiß, wird diese Seite noch seit der Zeit des Internet Explorer betrieben, also habe ich sie nicht selbst gebaut, aber ich finde sie gar nicht schlecht.
Allerdings gibt es hier Git-Versionsverwaltung und eine CI/CD-Pipeline, und Staging-Server und Produktionsserver sind voneinander getrennt. Wenn ein Pull Request in den Main-Branch gemergt wird, deployt die Pipeline das vom Bundler erzeugte Artefakt automatisch auf den Staging-Server, und nachdem die zuständige Person den Staging-Server geprüft und die endgültige Freigabe erteilt hat, wird es anschließend auf den Produktionsserver ausgerollt. Früher wurden die Quelldateien einfach per FTP direkt auf dem Produktionsserver überschrieben, aber nachdem die entsprechende Arbeit an unser Team überging, haben wir das so geändert.
Ist das wirklich unvernünftige Komplexität? Früher war das Ändern des Title-Tags dieser Website eine Sache von: mit AcroEdit auf den Produktionsserver per FTP verbinden (ja, die Leute, die das HTML dieser Seite ursprünglich direkt geschrieben haben, benutzten das immer noch), eine Zeile in der HTML-Datei direkt ändern und speichern, und damit war alles erledigt. Daher könnten sie das wahrscheinlich tatsächlich so empfinden.
Ich denke jedoch, dass dieses Maß an zusätzlicher Komplexität absolut vertretbar war. Nicht jede Aufgabe ist schließlich so einfach wie das Ändern eines einzigen Title-Tags. Und dass alter, nur auskommentierter Code, der überall angeklebt war, jederzeit wiederhergestellt werden kann, erlaubt es einem, ihn ohne große Last vollständig zu löschen; außerdem sind transparente Nachverfolgung von Änderungen und Rollbacks möglich, und der Bundler kann bei Bedarf noch einige grundlegendere Optimierungen hinzufügen. Das sind meiner Ansicht nach klare Vorteile. Auch das Hinzufügen eines Staging-Servers, auf dem man vor dem Deployment in die reale Umgebung eine Vorschau sehen kann, könnte man als eine Form von Komplexität ansehen, aber ich halte das für notwendig.
Auch ich habe viele Beschwerden darüber, dass die internen Code-Strukturen verschiedenster Websites übermäßig komplex und schwerfällig geworden sind. Die Outlook-App unter Windows basiert heutzutage auf einer Web-App, und in letzter Zeit ist sie besonders noch schwerfälliger geworden. Es ist inzwischen so weit, dass es schon ruckelt, wenn man einfach nur den Mail-Text auf dem Bildschirm schreibt oder den gesamten Text markiert, und im Extremfall erscheint sogar "Seite reagiert nicht". Als ich mich fragte, warum das so ist, und in Web-Outlook die Entwicklertools öffnete, war ich ehrlich schockiert. Nachdem ich einmal den Cache geleert und die Seite neu geladen hatte, liefen selbst eine Minute später noch immer irgendwelche Requests weiter. Als ich im Browser nachsah, waren allein im Zusammenhang mit der MS-Office-Site mehrere Gigabyte an Daten gespeichert.
Dieser Artikel wirft jedoch vieles durcheinander; manchen Punkten stimme ich zu, manchen eher nicht. Was semantisches HTML oder Barrierefreiheit betrifft, war die Vergangenheit meinem Wissen nach sogar noch viel schlimmer. Und dass eine Verbesserung der Developer Experience die User Experience verschlechtere, kann ich überhaupt nicht nachvollziehen — vielleicht liegt das daran, dass ich kein Web-Frontend-Entwickler bin. Sogar die Behauptung, dass sich alle Macht und Kontrolle bei den Entwicklern konzentriert hätten, klingt für mich absurd. Liegt die Macht in Unternehmen nicht beim Management? Oder sind Unternehmensstrukturen im Westen vielleicht doch etwas anders als in Korea?
Wie immer stimme ich voll und ganz zu, dass Ausgewogenheit und Maß, Einfachheit und Pragmatismus wichtige Werte sind und bei Entscheidungen priorisiert werden sollten. Aber dieser Artikel argumentiert so, als sei "alle Websites wie Softwareprodukte zu behandeln" vollständig die Verantwortung der Entwickler, und ich denke, genau das verwässert eher die grundlegende Problemwahrnehmung. Und die Stellen, die die "gute alte Zeit" verklären, in der es keine gewachsenen Prozesse gab, verdienen meiner Meinung nach eher Kritik.
Sooo langweilig …
In Korea ist am Ende doch alles Java-Land, deshalb wirkt das wohl ungewohnt, haha
Ich denke: Technologie aus anderen Ländern != Daten aus anderen Ländern
Ich glaube es erst, wenn es erstmal kostenlos verfügbar ist. Grok kostet sogar 30 Dollar, da habe ich Angst, ein Abo abzuschließen...
Hahahaha, der plötzlich aus dem Nichts getroffene Doktorand ist völlig verdattert ..
Nutzt Rails, seid glücklich
Den Versuch begrüße ich, aber ...
ich hoffe, sie machen nicht so etwas, dass sie eine neue Organization gründen und 1.0 einfach über Bord werfen.
(Koreanisch) Ist das das Arbeitsleben im Unternehmen? Haha
Ich würde mich freuen, wenn es auch als YCD erscheint~