RSS消亡史：没有比这更令人扼腕叹息的了！
引言
大约七年前，谷歌决定关闭谷歌阅读器，这是一个世界闻名且深受喜爱的RSS阅读器，我觉得从那时起，没有其他服务像它一样受到如此真诚的哀悼。我还记得，当我打开HTC一款小巧的 Wildfire 阅读器时，那种温暖的感觉。
当然，我尝试了 Feedly 和 Inoreader 以及许多其他的替代品，甚至在我的服务器上安装了微型 RSS，但都没有什么感觉。多年以后，我也不再使用 RSS 了，而是从 Twitter、HN 或Reddit 上获取新闻。
真是有些令人悲观。
所以我想也许是时候做一个我自己的 RSS 阅读器了，一个比其他阅读器更适合我个人需求的阅读器，也许这会让我恢复阅读RSS的好习惯。
过去的辉煌
一切都开始于几年前。
很明显，web将成为主导技术，因此我开始使用 jQuery、添加 CSS 并创建了一个很小的 HTML 静态页面，该页面通过 AJAX 下载 RSS 内容，对其进行解析，并将标题显示在屏幕上。
我当时对极简主义很感兴趣，那个页面只显示了简短的新闻标题和漂亮清晰的排版。甚至为了添加另一个博客，我不得不编辑 HTML 源代码本身。
好的方面是 RSS 阅读器页面从来没有收集过任何个人信息，需要任何登录，并且非常容易使用。
完成 RSS 和 Atom 提要解析的简短函数，真是令人兴奋，因为真是简单！
一时间，越来越多的博客对我的读者来说变得遥不可及。原因是 CORS（跨域）。
从另一个来源的客户端 javascript 获取 RSS/Atom xml 已经不可行。所以我编辑了 HTML 新闻页面来使用一些公共的 CORS 代理。
当这些语言开始消亡时，我自己用 Go 语言做了功能实现：
个人 CORS 代理和用于推送新闻的 HTML 文件的组合工作得很好，但是后来我慢慢地也放弃了这些努力。
当前现状
这些天来，看着老式的 jQuery 总感觉怪怪的，所以我使用 React 迅速地完成了一个单页面应用（SPA）。
我决定加一些功能，允许用户添加/删除提要，而不是强制他们编辑 HTML代码；我还添加了一些动画，异步获取新闻，这样用户就不需要重新加载页面了。
我在笔记本电脑和手机上做了多轮测试，深深觉得，更简单，更直观的方式才是正确的。于是我做了一些努力：
- 抛弃使用 JSX，直接在HTML中创建基础布局。
- 使用 <template> 节点来定义动态添加元素的布局，比如新闻标题或提要列表中的条目。
- 仅留下了一个屏幕，减少动画数量。
我在想，如果我在十年前写，没有这么多花里胡哨的现代技术，这将如何实现。
你知道吗，即使没有框架，ES6 也牛的一匹。
即使没有预处理器，CSS 也牛的一匹。
有时，更简单的工具会产生更好的结果。
展望一下
由于每个人都在谈论进步的Web应用程序，我决定将项目改成 PWA 模式。我并不强硬，有 Lighthouse 和大量的文件。现在，即使在断网状态下，我也可以阅读最后一条缓存的新闻。
然而，如果该应用程序有一段时间没有使用，Webkit 和 Apple 会默认清空本地的存储数据。那么用户不仅会丢失缓存的新闻，还会丢失宝贵的提要列表。
这当然很不爽，我找到了一个快捷的办法——提要列表序列化为 URL 。因此，如果你为标题页添加了书签，就能够使用获取到关联的提要。
此外，你可以在桌面上创建订阅源，将URL转换成二维码，在移动设备上打开它，这样无需任何后端技术，就可以轻松同步数据。
另一个想要处理的问题是，如何减少标题提要中的帖子数量。我打算尝试自然语言处理方法，根据用户兴趣过滤新闻。
我尝试了能搜索到的方法，从TD-IDF、“Bag of Words”到 word2vec。最后尝试了通用的 word2vec 模型，并根据 HN 和 Reddit 标题训练了自己的模型，使其应用于特定的领域。
想象一下 Apple，Swift，Go，Sketch 的相关词汇，都高度依赖于上下文，而上下文几乎不可能从十个单词的标题中提取出来。我仍然不放弃有一天能够实现的希望，但现在我已经放弃了。
另辟蹊径，我倒是实现了文字关键字过滤。用户可以列出要突出显示的单词和正则表达式，就可以突出显示匹配的标题。
简单、快速、可预测。所以我又回到了每天使用 RSS 的状态。
写在最后
这算是一次愉快的经历吗？算，也不算。
在我看来，RSS 看起来更像是死不了的，它不会消失。
对于那些记得 RSS 过去辉煌的人来说，它还永远活着。
技术不会消亡，RSS 也绝对不会消亡。
Happy coding :-)