最近做了个为播客打造的 web 播放器 Shikwasa，支持一些播客常用的播放控制。由于用网页听播客的人几乎不存在，它存在的意义也只是节目官网在发布新 episode 文章时能够挂出一个相对好看的播放器，比浏览器自带播放器少了一分简陋，较其他音乐播放器多了一分硬核。
如果有兴趣，可以看看下面的废话实现历程。
一切纯属偶然。播客的收听场景似乎和网页没有什么关系：
音频文件耗流量，在非 Wi-Fi 环境下收听很可能需要离线；
订阅属性决定了节目的追随者们会持续接收这个节目的更新；
这个世界已经充满了各种好用的泛用型播客客户端；
这个时候，诞生了一个竟敢自称「为播客而生」的 web 播放器，是有闲得蛋疼制造代码垃圾来了嘛！_ (:з」∠) _
——只因为 Typlog 需要呀。
最初接到的是 @lepture 一个模糊的需求「给播客重写一个自用的响应式播放器」，只要求不同的设备访问网页时，能有较好的展示效果即可。🤨
需求
虽然几乎从不在网页上听播客，但由于通勤时常使用 Overcast 收听，对使用播客可能产生的交互操作还算熟悉，因此原本的播放器弊端一目了然：
原本的播放器在创造时使用场景便定为音乐播放器，用户可控操作包括：开始/停止, 上/下一首切换，拖拽进度，音量调整，播放列表快速选择音频。
然而播客收听场景与音乐收听场景并不完全重叠。 导致这一区别的原因，主要在于播客的信息量较音乐大得多，而听众从播客中吸收信息的能力却不尽相同。由于每个播客传递的信息密集程度不同，听众单一时间内可接受信息量、语速也不同，有时会需要调整节目的播放速度。比如：使用播客来学习第二语言的用户可能会以低于一倍速的播放速度收听，而想要快速获取信息又节约时间的用户可能以高于 1.0x 的速度收听。《津津乐道》这档播客就曾公布自家听众中有 1/4 使用倍速收听，说明这样的需求并不少见。但这在音乐播放器中是不存在的，有多少人以倍速听歌，而不是欣赏原汁原味呢？
出于相似的目的，快进/快退也是收听播客时必不可少的控制。以自己为例，快进/快退可能是我使用频率最高的功能了。由于收听时不断地在接收信息，在听到重要信息需要思考、或是听不清楚时，都会使用 Overcast 配合耳机线控快退个15秒；而在播客进入广告或是想要快速跳过某些讨论时，快进便是最佳选择了。这也说明播客传递的信息有不连贯的可能性，但这种可能性对用户而言是未知的。播客用户在内容未知的情况下拖动音频进度条，结果也并不可预见。使用数秒快进/快退，将这种不可见的粒度进行细化、分割，可以使结果变得至少可控一些。而在收听音乐的场景下，由于音乐本身连贯，快进/快退和拖动进度条的差别并没有那么明显，存在也就可有可无了。
至于音量控制，由于电脑、手机本身有原生音量控制。况且，系统音量的控制一般都有快捷键，比如手机上的实体侧边按钮，或是笔记本键盘快捷键——比在方块大的屏幕上拖拽或者切换网页 tab 再点击要方便得多。如果不是播客本身音量有问题，在嘈杂/极其安静的环境下也不需要对音量进行额外的增减幅。
于是……虽然原来的需求里并没有这些要求，还是自己给自己加了需求，只求也有好心人给我加个鸡腿_(:з」∠)_：
- 增加倍速切换功能；
- 增加10秒快进/快退功能；
- 取消音量控制；
原型
题图就是最后输出效果图。
码字、打包、发布、后续维护
Bundler 是第一次自己配置，为什么人生不能只是好好享受写功能的过程，还要烦这些东西呢！
后续还是要继续维护的，现在还不支持 episodes 播放列表，以及做一个网页挂 N 个播放器时的状态管理。
最后
发布了还是挺激动的嗷嗷嗷！本身受众就小，github 上估计最后也没有什么星，什么叉，什么表，就不过分期待了。看都看到这里了，帮我按个🌟，顺便催催 Typlog 快把它用上呗 Typlog 已经用上了，撒花~ 链接在此！
