Il n’existe pas encore de prise en charge officielle des flux RSS, mais une solution est en préparation

 (developer.chrome.com)
1 points par GN⁺ 2023-12-12 | 2 commentaires | Partager sur WhatsApp
  • La page Feeds de Chrome for Developers indique comment recevoir automatiquement les nouveaux articles des domaines qui vous intéressent dans un lecteur RSS
  • À l’heure actuelle, l’abonnement disponible et vérifié est le flux Blog, auquel on peut ajouter le flux RSS via un lien distinct Subscribe to Blog
  • Parmi les exemples d’articles du blog figurent un site web prêt pour les agents, des outils de développement tiers pour Chrome DevTools for agents et les changements de WebGPU
  • Chaque article affiche son titre, une brève description et des tags de sujets associés, ce qui permet de comprendre l’étendue des contenus publiés avant de s’abonner
  • Pour suivre les mises à jour de Chrome for Developers sans visiter le site séparément, la méthode la plus directe consiste à enregistrer le flux Blog dans un lecteur RSS

Mises à jour disponibles en RSS sur Chrome for Developers

  • La page Feeds explique comment recevoir automatiquement dans un lecteur RSS les mises à jour des sections de Chrome for Developers qui vous intéressent
  • Le corps de la page précise qu’il est possible d’ajouter à un lecteur de flux le flux RSS correspondant à la section du site qui vous intéresse

Flux Blog actuellement proposé

  • La section de flux affichée dans le contenu est Blog
  • Le flux Blog est proposé via le lien Subscribe to Blog

Exemples d’articles affichés dans le flux Blog

Informations vérifiables avant l’abonnement

  • En s’abonnant au flux Blog, il est possible de suivre dans un lecteur RSS les nouveaux articles du blog Chrome for Developers
  • Chaque entrée fournit le titre, le résumé et les domaines techniques associés, ce qui permet de voir facilement l’étendue des contenus inclus dans l’abonnement

À lire aussi

2 commentaires

 
ndrgrd 2023-12-14

Vu le buzz, le problème a été réglé en un rien de temps. J’imagine que c’est pareil partout ^^
 
GN⁺ 2023-12-12
Commentaires sur Hacker News

  • Le fait qu’un ingénieur de l’équipe Chrome DevRel ait, au lieu d’attendre un RSS officiel, créé et publié lui-même un générateur RSS non officiel, c’est vraiment une absurdité typique d’un grand groupe
    Le flux pour ce blog est disponible sur https://chrome-for-developers-rss.bramus.workers.dev/blog, et le fait de dire qu’« un ticket interne a été ouvert auprès de l’équipe DevSite » ne permet pas de savoir quand cela deviendra une priorité
    Dans l’ancien Google, il aurait sans doute été plus simple pour n’importe qui de le corriger directement en interne
    Références : 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

    • Je ne sais pas à quel point il faut remonter pour parler de « l’ancien Google ». Il y avait un bug dans l’app web Contacts où la liste des États était triée selon l’identifiant d’État à 2 lettres tout en étant affichée par nom, et les utilisateurs de New York ne pouvaient pas se déplacer avec Tab puis taper le nom de leur État pour le sélectionner
      C’était un bug connu que des gens chez Google voulaient corriger, mais il n’a été résolu que cette année, après presque 10 ans
    • Je me demande à peu près à quel moment on situerait le point de bascule de « l’ancien Google »

  • Je suis responsable de l’équipe qui gère ce site. Le site a été migré vers une autre infrastructure, et cette infrastructure ne prend pas en charge la génération automatique de flux RSS
    Je sais très bien que la solution actuelle est loin d’être idéale. Il fallait respecter l’échéance de migration de tout le contenu vers le nouveau système, puis traiter les fonctionnalités manquantes
    Nous travaillons à ce que ce soit rétabli aussi vite que possible — Paul

    • Voilà donc pourquoi https://developer.chrome.com/feeds est soudainement tombé. Mais pourquoi fallait-il « respecter l’échéance » ?
    • Répondre qu’on « travaille sur une solution » et qu’on « travaille à son déploiement » sonne comme du langage business très classique
      On dirait que cela veut dire : « nous ne l’ajouterons pas, mais nous proposerons probablement une alternative qui ne répondra pas vraiment aux besoins existants »
      Cette fois, j’essaie de partir du principe de bonne foi, mais je ne comprends pas pourquoi tourner autour du pot ainsi. Pourquoi ne pas dire simplement « nous ajoutons le RSS » ou « nous visons à rétablir la prise en charge du RSS » ?
    • Les réactions ici montrent bien à quel point les techniciens peuvent devenir des absolutistes déconnectés du réel
      Le business et le travail sont toujours des compromis, mais beaucoup de gens sur HN les voient de façon absolue. Avoir respecté l’échéance et être venu l’expliquer directement, c’était une bonne chose, et davantage de hackers devraient prendre eux-mêmes ce type de décisions pour mieux comprendre la réalité
    • Cette phrase dans le profil HN est bien trouvée : « RSS is alive https://paul.kinlan.me/index.xml »
    • N’importe quel programmeur un tant soit peu compétent peut créer un flux RSS fonctionnel en une heure. Que se passe-t-il donc chez Google ?

  • Quand Chrome a commencé à gagner des parts de marché, les autres grands navigateurs, y compris probablement Internet Explorer, avaient une prise en charge native de la lecture RSS
    Ils affichaient une icône RSS dans la barre d’adresse ou ailleurs, ce qui signalait aussi qu’un site proposait du RSS. Chrome, lui, quand on ouvrait un lien RSS, affichait juste le XML brut et n’indiquait même pas la présence d’un flux RSS
    À mon avis, c’est la principale raison du déclin du RSS

    • Il y a encore trois autres raisons. Google Reader était souvent considéré comme le meilleur lecteur RSS, mais sa fermeture a fait chuter le nombre d’utilisateurs, et beaucoup d’éditeurs voulaient que les gens viennent sur leur site, donc ils ne proposaient que les titres au lieu du flux complet, ou imposaient diverses limitations
      Ensuite, les gens ont commencé à utiliser Twitter et Facebook comme agrégateurs d’actualités, en s’attendant à ce que leur graphe social présélectionne les nouvelles « pertinentes »
      De plus, sur les sites d’actualité, une simple liste d’éléments atteint vite ses limites. Dans un flux RSS, tous les articles se valent visuellement, alors que pour l’actualité beaucoup de lecteurs veulent voir les sujets principaux mis en avant comme sur une page d’accueil
      Lors de journées comme une élection, quand arrivent en même temps un article de synthèse principal et des articles détaillés par région ou par parti, le flux leur donne à tous le même poids, ce qui rend l’article principal difficile à trouver, et les premiers résultats deviennent vite obsolètes
    • Le RSS va totalement à l’encontre des intérêts des services d’agrégation de liens comme Google. À mon avis, l’absence de vrai support n’avait rien d’un hasard
    • Par la suite, les autres navigateurs ont eux aussi supprimé la prise en charge native des flux RSS/Atom
      Firefox et Safari la proposaient autrefois, mais ce n’est plus le cas, et dans Safari, ouvrir un flux RSS affiche désormais une sorte de page 404 disant que les flux ne sont plus pris en charge
    • Je me demande si le RSS ne s’est pas surtout peu diffusé parce que les utilisateurs ordinaires le comprenaient mal. Apple avait même donné à une version du navigateur le nom de Safari RSS https://www.anandtech.com/show/1671/9
      Pourtant, même avec cette mise en avant par Apple, j’ai rarement entendu parler de gens autour de moi qui se soient mis à l’utiliser. Ceux qui utilisaient déjà le RSS avaient de meilleurs lecteurs, et ceux qui ne l’utilisaient pas n’ont sans doute pas vu l’intérêt de cette implémentation
    • Vivaldi intègre cette fonction et son lecteur RSS est très bon. C’est encore très utile aujourd’hui

  • Le web semble paradoxalement devenir de moins en moins compatible avec les machines et l’automatisation.
    J’ai récemment dû modifier plus de 150 comptes Google Workspace ; il y a 20 ans, dans un environnement Unix, cela se serait fait très simplement avec un script shell.
    À la place, il a fallu cliquer-copier-coller-cliquer 20 fois par page comme un singe. Il existe sûrement une API, mais cela aurait sans doute pris 100 fois plus de temps que d’écrire un simple script en ligne de commande.
    À force de chercher à capter davantage l’attention humaine, le web perd progressivement sa compatibilité avec les machines.

    • C’est devenu moins compatible avec les machines et l’automatisation distribuées et démocratisées, mais cela reste très compatible avec l’automatisation des énormes scrapers de recherche disposant de ressources de calcul massives, d’argent, de blocs d’IP et d’IA.
      C’est pour changer cela que j’ai créé au départ BrowserBox comme une plateforme fournissant des « outils de création de web scraping ». Ces outils sont généralement proposés sous forme d’extensions ou d’apps Electron téléchargeables, mais il fallait une approche plus facile à déployer, plus puissante, plus légère, et moins dépendante de l’approbation d’écosystèmes fermés.
      BrowserBox ne nécessite pas de client séparé et fonctionne dans un navigateur web ordinaire, y compris sur mobile. L’objectif était de pouvoir créer des scripts de scraping sur un appareil mobile, dans le bus.
      Pour l’instant, je me suis un peu écarté de cet objectif en constatant que le « navigateur embarquable » lui-même était un produit utile, mais je compte aussi revenir à l’objectif initial. L’idée centrale est de créer, au-dessus du protocole Chrome DevTools et des fonctionnalités de BrowserBox, une API qui ressemble à une extension mais en mieux.
      C’est open source, donc si ça vous intéresse, n’hésitez pas à jeter un œil : https://github.com/BrowserBox/BrowserBox
    • https://github.com/GAM-team/GAM
      GAM est un outil en ligne de commande qui permet aux administrateurs Google Workspace de gérer rapidement et facilement leur domaine et les paramètres utilisateurs. On n’en a besoin qu’environ une fois par an, mais à ce moment-là, c’est vraiment précieux.
    • L’idée générale est juste, mais il existe une solution tierce assez correcte pour Google Workspace : https://github.com/GAM-team/GAM
    • Il y a bien une API, mais bizarrement ce n’est pas l’API Workspace, c’est l’API GCP, ce qui rend son utilisation difficile à cause de la barrière à l’entrée.
    • On peut automatiser une bonne partie de ce travail en utilisant l’API DOM de base depuis la ligne de commande DevTools.
      Ce n’est pas idéal, mais cela permet de faire la plupart des choses qu’on faisait manuellement, comme cliquer, lire du texte ou écrire dans des champs de saisie, et c’est assez facile à apprendre.

  • Je suis un développeur web indépendant, avec peu d’argent et sans intelligence exceptionnelle, mais j’ai réussi à intégrer RSS dans tous les blogs ou pseudo-blogs que j’ai créés.
    Il faudrait peut-être que j’aille passer un entretien chez Google pour leur apprendre ma solution géniale.

    • Une demande de RSS ne contribue à aucun indicateur d’engagement d’un program manager quelconque sur un site de documentation développeur, donc ce n’est sans doute plus nécessaire !

  • Dire « il n’y a pas de prise en charge officielle du RSS pour le moment, mais nous travaillons activement à une solution » veut donc dire qu’il y aura un flux RSS à l’avenir, non ?

    • Supprimer quelque chose qui existait puis dire « oups, on va le faire », c’est vraiment minable.
      Il suffirait simplement de supprimer ce qu’ils veulent supprimer ; je ne vois pas pourquoi il faut en plus mentir aussi ouvertement. À quoi cela sert-il au juste ?
    • Non, cela veut dire qu’ils travaillent sur une « solution ». Ce sera probablement un système push verrouillé et fermé du genre Google Updates™, avec peut-être même un palier premium.

  • Le RSS pourrait justement être la solution !

    • Cette formulation m’a paru bizarre aussi. La fonctionnalité existait, ils l’ont supprimée, et maintenant ils travaillent à une solution… une solution à quoi ?
      Est-ce que Google a créé une nouvelle plateforme de blogging interne sans avoir encore eu le temps d’y ajouter la prise en charge du RSS ?
    • « Nous travaillons activement à une solution »… franchement, quelle absurdité.

  • J’ai vu la même chose sur le https://web.dev/ de Google.
    Le dernier article apparu dans le flux était « Changes to the web.dev infrastructure », publié il y a plusieurs mois : https://web.dev/blog/webdev-migration
    Le flux existe toujours, mais il n’est plus mis à jour : https://web.dev/feed.xml
    De nouveaux articles continuent d’être publiés sur le site. C’est regrettable que, lors de la modernisation de l’infrastructure du site, le flux RSS ait disparu de la liste des fonctionnalités, du moins pour l’instant.

  • L’ingénieur Google Bramus a créé un contournement non officiel : https://mastodon.social/@bramus@front-end.social/111448166953123004

  • Les gens semblent mal mesurer à quel point le RSS est utile.
    Je suis encore en colère contre Google pour avoir tué Reader. C’était la meilleure manière de consommer du contenu sur le web.

    • Sans publicité, sans utiliser la recherche, et sans payer Google pour qu’il pousse des titres d’actualité sur un appareil Android.
      Le RSS est une menace pour la rentabilité de Google !
    • Je n’ai jamais utilisé Reader, donc je suis sincèrement curieux : qu’est-ce qui rendait ce service difficile à reproduire ?
    • Dans l’écosystème Apple, la combinaison NetNewsWire avec synchro iOS+macOS+iCloud est la meilleure solution.
    • Puisqu’on parle d’alternatives à Reader, j’utilise NetNewsWire avec Miniflux comme backend de synchronisation et lecteur web.
      TheOldReader.com est aussi très bien, et son interface s’inspire fortement de Google Reader.
    • C’est probablement pour cela que Google l’a supprimé : cela donnait trop de contrôle à l’utilisateur final sur les contenus à consommer et sur la manière de les consommer.
      Sans parler du fait qu’ils ne pouvaient évidemment pas savoir exactement quoi les gens lisaient ni à quel moment.