Derzeit gibt es noch keine offizielle RSS-Feed-Unterstützung, aber es wird an einer Lösung gearbeitet

 (developer.chrome.com)
1 Punkte von GN⁺ 2023-12-12 | 2 Kommentare | Auf WhatsApp teilen
  • Die Feeds-Seite von Chrome for Developers zeigt, wie sich neue Beiträge aus interessanten Bereichen automatisch in einem RSS-Reader empfangen lassen
  • Aktuell ist als abonnierbares Ziel der Blog-Feed erkennbar; über den separaten Link Subscribe to Blog lässt sich der RSS-Feed hinzufügen
  • Beispielbeiträge im Blog umfassen eine agententaugliche Website, Drittanbieter-Entwicklertools für Chrome DevTools for agents und WebGPU-Änderungen
  • Jeder Beitrag zeigt Titel, kurze Beschreibung und thematisch passende Tags, sodass sich der Umfang der Inhalte vor dem Abonnieren einschätzen lässt
  • Wer Updates von Chrome for Developers verfolgen möchte, ohne die Seite separat zu besuchen, fährt am direktesten damit, den Blog-Feed im RSS-Reader zu registrieren

Updates von Chrome for Developers per RSS erhalten

  • Die Feeds-Seite erklärt, wie sich Updates aus interessanten Bereichen der Chrome-for-Developers-Website automatisch mit einem RSS-Reader empfangen lassen
  • Im Seitentext wird erläutert, dass sich der RSS-Feed des jeweils interessierenden Bereichs der Website zu einem Feed-Reader hinzufügen lässt

Der derzeit verfügbare Blog-Feed

  • Der im Text angezeigte Feed-Bereich ist Blog
  • Der Blog-Feed wird über den Link Subscribe to Blog bereitgestellt

Beispielbeiträge im Blog-Feed

Informationen, die sich vor dem Abonnieren prüfen lassen

  • Mit dem Abonnement des Blog-Feeds lassen sich neue Beiträge aus dem Chrome-for-Developers-Blog in einem RSS-Reader verfolgen
  • Jeder Eintrag enthält Titel, Kurzfassung und zugehörige Technikbereiche, wodurch sich der thematische Umfang der abonnierbaren Inhalte leicht prüfen lässt

Verwandte Beiträge

2 Kommentare

 
ndrgrd 2023-12-14

Sobald es zum Thema wurde, war das Problem im Handumdrehen gelöst. Ist wohl überall dasselbe ^^
 
GN⁺ 2023-12-12
Hacker-News-Kommentare

  • Dass ein Ingenieur aus dem Chrome-DevRel-Team, statt auf offizielles RSS zu warten, selbst einen inoffiziellen RSS-Generator gebaut und veröffentlicht hat, ist wirklich eine Absurdität, wie sie zu einem Großunternehmen passt.
    Der Feed für dieses Blog liegt unter https://chrome-for-developers-rss.bramus.workers.dev/blog, und „ich habe beim DevSite-Team ein internes Issue eröffnet“ bedeutet nicht, dass das irgendwann Priorität bekommt.
    Beim früheren Google wäre es vermutlich für irgendwen intern einfacher gewesen, das direkt zu beheben.
    Referenzen: https://front-end.social/@bramus/111448166340277056, https://github.com/bramus/web-dev-rss, https://github.com/bramus/chrome-for-developers-rss, https://issuetracker.google.com/issues/314910854#comment2

    • Ich weiß nicht, wie lange dieses „frühere Google“ her sein soll. In der Contacts-Webapp gab es einen Bug, bei dem die Liste der Bundesstaaten nach zweistelligen State-IDs sortiert war, aber mit Namen angezeigt wurde; Nutzer aus New York konnten also nicht per Tab dorthin springen, den Namen des Bundesstaats eingeben und ihn auswählen.
      Das war selbst intern bei Google ein registrierter Bug, den man beheben wollte, wurde aber erst dieses Jahr nach fast zehn Jahren behoben.
    • Ich frage mich, wann man ungefähr den Wendepunkt des „früheren Google“ ansetzen sollte.

  • Ich leite das Team, das diese Site betreibt. Wir haben die Site auf eine andere Infrastruktur umgezogen, und diese Infrastruktur unterstützt die automatische Erzeugung von RSS-Feeds nicht.
    Uns ist schmerzlich bewusst, dass die aktuelle Lösung nicht optimal ist. Wir mussten eine Deadline einhalten, um alle Inhalte in das neue System zu migrieren, und danach die fehlenden Funktionen angehen.
    Wir arbeiten daran, das so schnell wie möglich umzusetzen — Paul

    • Daher ist https://developer.chrome.com/feeds also plötzlich gestorben. Aber warum „musste eine Deadline eingehalten werden“?
    • Die Antworten „wir arbeiten an einer Lösung“ und „wir arbeiten daran, dass es umgesetzt wird“ klingen nach typischem Business-Sprech.
      Es wirkt wie: „Wir werden es nicht hinzufügen, aber wahrscheinlich eine Alternative liefern, die die bisherigen Anforderungen nicht erfüllt.“
      Ich will diesmal wohlwollend sein, aber ich verstehe nicht, warum man so um den heißen Brei herumredet. Kann man nicht sagen: „Wir fügen RSS hinzu“ oder „unser Ziel ist es, RSS-Support wiederherzustellen“?
    • Die Reaktionen hier zeigen gut, wie unrealistisch absolutistisch Techniker sein können.
      Business und Arbeit sind am Ende immer Trade-offs, aber viele Leute auf HN betrachten es absolutistisch. Die Deadline einzuhalten und sich persönlich zu melden, um es zu erklären, war richtig; mehr Hacker sollten solche Entscheidungen tatsächlich einmal selbst treffen, dann würden sie die Realität verstehen.
    • Dieser Satz im HN-Profil ist charmant: „RSS is alive https://paul.kinlan.me/index.xml“
    • Ein halbwegs kompetenter Programmierer kann innerhalb von einer Stunde einen funktionierenden RSS-Feed bauen. Was zur Hölle passiert da bei Google?

  • Als Chrome begann, Marktanteile zu gewinnen, hatten die anderen großen Browser, vermutlich sogar der Internet Explorer, standardmäßig Unterstützung zum Lesen von RSS.
    Sie zeigten etwa in der Adressleiste ein RSS-Icon an und machten damit auch sichtbar, dass diese Site RSS anbietet. Chrome hingegen warf einem beim Öffnen eines RSS-Links nur rohes XML hin und zeigte auch nicht an, ob RSS vorhanden war.
    Ich sehe das als Hauptgrund für den Niedergang von RSS.

    • Es gibt noch drei weitere Gründe. Google Reader wurde oft als bester RSS-Reader bezeichnet, aber nach seiner Einstellung ging die Nutzerzahl zurück; viele Publisher wollten, dass Leute auf ihre Site kommen, und boten deshalb statt vollständiger Feeds nur Überschriften an oder schränkten sie auf verschiedene Weise ein.
      Außerdem begannen die Leute, Twitter und Facebook als News-Aggregatoren zu nutzen, und erwarteten, dass ihr Social Graph „relevante“ Nachrichten bereits für sie vorsortiert.
      Hinzu kommt: Bei Nachrichtensites stößt eine reine Liste von Einträgen an Grenzen. In RSS wirken alle Artikel gleichwertig, aber bei Nachrichten möchten viele die wichtigsten Meldungen hervorgehoben sehen, ähnlich wie auf einer Nachrichtenseite.
      An Tagen wie dem Wahltag, wenn zugleich ein Haupt-Zusammenfassungsartikel und detaillierte Artikel nach Regionen und Parteien erscheinen, wird im Feed alles gleich gewichtet angezeigt, sodass der Hauptartikel schwer zu finden ist; außerdem ist der erste Ergebnisartikel schnell veraltet.
    • RSS steht den Interessen von Link-Aggregationsdiensten wie Google diametral entgegen. Ich glaube nicht, dass die mangelhafte Unterstützung ein Zufall war.
    • Danach haben auch andere Browser die standardmäßige Unterstützung für RSS/Atom-Feeds entfernt.
      Firefox und Safari haben es früher beide unterstützt, inzwischen ist es entfernt; wenn man in Safari einen RSS-Feed öffnet, erscheint eine 404-ähnliche Seite, die sagt, dass Feeds nicht mehr unterstützt werden.
    • Vielleicht haben normale Nutzer RSS einfach nicht gut verstanden, und deshalb hat es sich nicht im Mainstream durchgesetzt. Apple ging sogar so weit, ein Browser-Release Safari RSS zu nennen: https://www.anandtech.com/show/1671/9
      Aber obwohl Apple es so gepusht hat, habe ich kaum gehört, dass Leute in meinem Umfeld damit angefangen hätten. Wer bereits RSS nutzte, hatte bessere Reader, und wer es nicht nutzte, sah in dieser Implementierung wohl keinen Wert.
    • Vivaldi hat diese Funktion eingebaut, und auch der RSS-Reader ist gut. Das ist immer noch sehr nützlich.

  • Paradoxerweise scheint das Web immer weniger maschinen- und automatisierungsfreundlich zu werden.
    Kürzlich musste ich mehr als 150 Google-Workspace-Konten ändern; in einer Unix-Umgebung vor 20 Jahren hätte man das mit einem sehr einfachen Shell-Skript erledigt.
    Stattdessen musste ich mich wie ein Affe durch jede Seite klicken, kopieren, einfügen und wieder klicken – 20 Mal pro Seite. Es gibt sicher eine API, aber das hätte vermutlich 100-mal länger gedauert als ein einfaches Kommandozeilen-Skript.
    Auf dem Weg zu mehr Aufmerksamkeit von Menschen verliert das Web immer mehr seine Maschinenfreundlichkeit.

    • Für verteilte, demokratisierte Maschinen und Automatisierung ist es weniger freundlich geworden, aber für riesige Such-Scraper mit enormen Rechenressourcen, Geld, IP-Blöcken und KI ist es weiterhin automatisierungsfreundlich.
      Weil ich das ändern wollte, habe ich BrowserBox ursprünglich als Plattform gebaut, die „Tools zum Erstellen von Web-Scraping“ bereitstellt. Solche Tools werden üblicherweise als Erweiterungen oder herunterladbare Electron-Apps angeboten, aber es braucht einen Ansatz, der einfacher zu verteilen, leistungsfähiger und leichtgewichtiger ist und weniger an die Freigabe geschlossener Ökosysteme gebunden ist.
      BrowserBox benötigt keinen separaten Client und läuft auch mobil in einem normalen Webbrowser. Das Ziel war, Scraping-Skripte sogar im Bus auf einem Mobilgerät erstellen zu können.
      Momentan sind wir etwas in die Richtung abgebogen, dass der „einbettbare Browser“ selbst ein nützliches Produkt ist, aber das ursprüngliche Ziel will ich ebenfalls wieder erreichen. Der Kern ist, auf dem Chrome-DevTools-Protokoll und den BrowserBox-Funktionen eine API zu bauen, die ähnlich wie Erweiterungen ist, aber besser.
      Es ist Open Source; wer Interesse hat, kann gern vorbeischauen: https://github.com/BrowserBox/BrowserBox
    • https://github.com/GAM-team/GAM
      GAM ist ein Kommandozeilen-Tool, mit dem Google-Workspace-Administratoren Domain- und Nutzereinstellungen schnell und einfach verwalten können. Man braucht es vielleicht einmal im Jahr, aber dann ist es wirklich Gold wert.
    • Die grobe Richtung stimmt, aber für Google Workspace gibt es eine ziemlich gute Drittanbieter-Lösung: https://github.com/GAM-team/GAM
    • Eine API gibt es zwar, aber seltsamerweise ist es keine Workspace-API, sondern eine GCP-API, weshalb die Einstiegshürden für die Nutzung recht hoch sind.
    • In der DevTools-Kommandozeile kann man mit den Standard-DOM-APIs viele dieser Aufgaben automatisieren.
      Das ist nicht ideal, aber man kann damit die meisten Dinge erledigen, die man sonst manuell macht – klicken, Text lesen, Eingabefelder ausfüllen – und es ist leicht zu lernen.

  • Ich bin nur ein einzelner Webentwickler, mit wenig Geld und ohne überragende Intelligenz, aber in alle Blogs oder blogähnlichen Dinge, die ich gebaut habe, habe ich erfolgreich eine RSS-Implementierung eingebaut.
    Vielleicht sollte ich mich bei Google bewerben und ihnen meine erstaunliche Lösung beibringen.

    • RSS-Anfragen tragen vermutlich nicht zu irgendeiner Engagement-Metrik eines Programmmanagers für die Entwicklerdoku-Website bei, also braucht man sie wohl nicht mehr!

  • Wenn es heißt: „Derzeit gibt es keine offizielle Unterstützung für RSS-Feeds, aber wir arbeiten aktiv an einer Lösung“, bedeutet das doch, dass es künftig RSS-Feeds geben wird, oder?

    • Erst etwas Vorhandenes entfernen und dann sagen „Ups, machen wir“ ist schon ziemlich armselig.
      Wenn man etwas abschaffen will, soll man es einfach abschaffen; ich verstehe nicht, warum man dazu noch so offensichtlich lügen muss. Was soll das überhaupt bringen?
    • Nein, es bedeutet, dass sie an einer „Lösung“ arbeiten. Vermutlich bauen sie ein verriegeltes, geschlossenes Push-System wie Google Updates™ und hängen noch eine Premium-Stufe dran.

  • RSS könnte genau diese Lösung sein!

    • Diese Formulierung fand ich auch seltsam. Es gab die Funktion, sie wurde entfernt, und jetzt arbeitet man an einer Lösung … einer Lösung wofür?
      Hat Google eine neue interne Blogging-Plattform gebaut und es noch nicht geschafft, RSS-Unterstützung einzubauen?
    • „Wir arbeiten aktiv an einer Lösung“ – das klingt wirklich nach ziemlichem Unsinn.

  • Dasselbe habe ich auch bei Googles https://web.dev/ gesehen.
    Der letzte Beitrag im Feed war vor ein paar Monaten „Changes to the web.dev infrastructure“: https://web.dev/blog/webdev-migration
    Den Feed gibt es noch, aber er wird nicht aktualisiert: https://web.dev/feed.xml
    Auf der Website erscheinen neue Beiträge. Es ist schade, dass bei der Modernisierung der Site-Infrastruktur der RSS-Feed aus der Funktionsliste gefallen ist – zumindest im Moment.

  • Der Google-Ingenieur Bramus hat einen inoffiziellen Workaround gebaut: https://mastodon.social/@bramus@front-end.social/111448166953123004

  • Viele Leute scheinen nicht zu wissen, wie nützlich RSS ist.
    Ich bin immer noch sauer, dass Google Reader eingestellt hat. Es war die beste Art, Inhalte im Web zu konsumieren.

    • Ohne Werbung, ohne Suche und ohne Google dafür zu bezahlen, News-Schlagzeilen auf Android-Geräte zu pushen.
      RSS ist eine Bedrohung für Googles Profitabilität!
    • Ich habe Reader nie benutzt und frage mich ernsthaft: Was hat es an diesem Dienst so schwer gemacht, ihn zu replizieren?
    • Im Apple-Ökosystem ist NetNewsWire in Kombination mit iOS + macOS + iCloud-Synchronisierung die beste Lösung.
    • Wo wir gerade über Reader-Alternativen sprechen: Ich nutze Miniflux als Sync-Backend und Web-Reader für NetNewsWire.
      TheOldReader.com ist ebenfalls sehr gut, und die UI ist stark von Google Reader inspiriert.
    • Deshalb hat Google es wahrscheinlich eingestellt. Es gab Endnutzern zu viel Kontrolle darüber, welche Inhalte sie konsumieren und wie sie das tun.
      Und natürlich konnte Google dadurch auch nicht wirklich wissen, was man wann gelesen hat.