播客 AsyncTalk 会讲些什么

开始

播客 AsyncTalk 是我,sleaf, tinko 以及小鹿一起做的一档播客节目。它主要是聊一些 web 开发技术相关的东西。目前我们第一季快要结束了,然后也因为我很久没对外写过文章,趁着这个时间,我来谈一谈我对我们播客的定位和发展。这篇文字只是我个人的理解,并未交给团队审核,所以它并不能决定最终我们的方向。

这档播客诞生于去年年中,那个时候我刚参与完一次播客的线下活动,对它挺感兴趣,而且看起来并不会花费太多的精力去抠细节。 又受到 tea hour, weakself 很大的影响,觉得是可以做一些东西。

顺带提一下我对这两个节目的看法:

首先是我非常喜欢的 tea hour 这个节目,它是极少数那种我认为主持人和嘉宾水平都非常好,而且产出的内容质量也相当高的那种节目。可惜的是它是年更节目,更多的是在大后端或者更加底层的方面,并太不关心 web 的发展。

相比之下 weak self 不仅主持人水平相当高,更新也比较勤快,谈论的内容也更加上层一些。只是 iOS 的内容我听不太懂。

那么有没有主持人嘉宾水平还凑合,更新频率也有保障,谈论的内容更加偏向 web 又技术型的节目呢?

我希望由我们来承担。

于是事情就这么发展起来了,我们开始拉人,准备文稿,录音,剪辑,发布。

事情的发展大概如此。

方向

如果你无聊翻一翻我们 第 0 期 节目,你大概会发现我们的标题有点儿 装逼 —— 我们的目标是把前端带向下一个高度 。 其实这个标题在我们内部争议也挺大, sleaf 觉得我们能力上还达不到, tinko 觉得目标太大了,而小鹿只想躺平。

不管其他人怎么看,我觉得我有理由做这样的事情。说起来,我一身的编程能力其中九成都来自于开源社区,来自于开放而又耐心的一个个优秀工程师。现在,我成长了,我需要把我自身的能力,还有这样一个开放的精神再还回开源社区。也许我能力低微,也许我会失败,也许我会因此意志消沉。

但是,也许我的节目会给某个尚且年轻的同学带来方向,给某个被领导 PUA 要转去运营的同事带来坚定。给某个被所谓的后端鄙视链压得郁郁寡欢的朋友带来希望。给某个设计新方案的天才工程师带来一个想法。 我想,这是一件我应该做的事情。

所以很多时候我们愿意更欢快一些,也愿意去聊一些也许对工资并不能产生太大影响的东西,希望能让听众从编程中感到些许乐趣,感受到原来写代码可以并不是攀比,并不是摸鱼,并不是痛苦。比如在 前端工程化 的一期,我们希望能推动听众去做一些有趣的工具。 在 CSS 一期,我们更侧重于各种 CSS 稀奇古怪的设计思路,而不是说这个属性怎么用的话题。到了 低代码 一期,我更愿意聊怎么实现,用哪些方案,而不是用很多空泛地名词幻想有低代码的 PPT 应该是什么样子。

另一方面,时代在变化。

过去,我们认为和 OS 交互才是所谓 “真正” 的程序员,他们痴迷于各种内存间的魔法,钻研 monad 的奇妙。同时也鄙视各种各样的工具,嘲笑着客户端在孱弱的手机上折腾,挖苦前端程序员不会写逻辑。

今天我们可以明显地看到 Java 系的衰落:冗长的代码,繁重的 IDE,自诩 “企业级” 却漏洞不断。 而 iOS/Android 的辉煌不再,它们的 UI 至今仍然难以组件化,大多数程序员依旧沉醉于 MV* 的幻想中不愿接受变化。

另一侧,自 Angular 1.x 面世以来,web 前端开始逐渐有能力承接大型项目。在推出 Flux 概念后,前端领域已经开始尝试获得 GUI 编程的主导地位。在 React Hooks 面世后,毫无疑问,接下来的几年,所有其他平台都要去努力追随 Web 的脚步。

我希望能通过做节目,让更多的朋友认识到这一变化,更快地接受。进而,去创造。去创造下一个能够推动 web 发展的东西,去创造下一个能够推动工程发展的项目,去创造下一个能够推动社会发展的产品。

那么,具体内容是什么

接下来,我个人想尝试聊一些更新的东西,比如 web container 的出现,比如 remix 如何改变 SSR,比如前端的 concurrent 是怎么一回事。

这些都是我很想很想聊,但是在第一季里忍住没有谈的话题。这些是我相信有机会把 Web 开发带入到下一个高度的底气。

我还想聊一些工程化方面的东西。比如前端的服务治理要怎么做,Headless CMS 有什么改变,GraphQL 是一个多么伟大的革新。

这些话题是来源于我短暂的职业经历,我意识到多数同事对于工程的认识还有很大提升空间,同时也缺少敢于尝试和变革的勇气。我期望能够通过这些主题,和大家一起寻找工程的下一步,去挑战更宏伟的项目。

之后,或许还能谈谈工具。比如 bat,比如 Vim,比如 HHKB。谈谈工程师的个人体验优化。

最后,也许会聊一聊关于产品一些的东西。比如为什么大多数产品不愿意支持 dark mode 我真的非常难以理解。

那么,我们不聊什么?

其实我个人还算是爱好广泛,有时候也愿意讲一讲。但我知道在其他方面,我的专业水平是不如专业人士的。就像是人人都可以谈论政治,却几乎没人看过《宪法》。

我们几个主播凑在一起,因为专业水平过低的关系,我感觉是难以迸发出有趣的内容的。

所以,我个人想的是,我们大概不会聊商业,不会谈政治,不说男女关系,不聊怪力乱神。

关于错误

错误,做节目难免会犯。我们过去的一季节目,目前我个人收到的反馈中,错误也是有一些的。

其他主播们对错误尤其看重,他们担心会传播错误,让听众记下错误的知识点。

但是我很乐观。我很害怕错误,但是当它到来的时候,我觉得我是很坦然地面对它。

一方面只要我在前期工作做得问心无愧,所有内容都有理论依据我相信听众们都能接受,即使它错了,也错得有逻辑,有道理。

我们在做节目中,时间最长的是剪辑,其次就是把节目中各种引用都记录下来。其实很多时候我觉得底下的 shownotes 才是节目的精华。

我想给听众们展示的是,主播讲出的观点或者方案,背后都是有各种各样的依据的。我们并非信口开河,而如果我们的某种方案和听众的认知相左,那么听众完全可以通过我们给出的各种 reference 来进一步了解这些话语背后的意义,找出漏洞。

另一方面,我个人非常信奉 erlang 中关于 crash early, crash fast 的理念。我觉得在很多时候,如果我们勇敢地承认自己地错误,才能更好地改善,下一次不再犯错。

我时常想起上学的时候,我总是会有几个错题本,里面记录了我做错的一些题目。我相信应该有一部分成绩确实会来源于错题本。可惜的是,随着我工作越久,我发现周围的人或者同事普遍不再愿意接受错题,只愿意一条路走到黑,从而错失了可以补救的机会。

这个节目对我来说,我会在描述技术的过程中尽量表达自己完整的能力 —— 我很期待错误。

比如我在节目中提到 npm 的依赖类型过于繁杂,其他语言就不是。我后面越想越不对,又去查了一遍才发现自己理解有问题。

如果没有这段经历,面试的时候我就按照之前错误的理解来说,那么影响的肯定就不止我的颜面。

其实这就是皇帝的新衣吧。我们愿意承认自己的无知,愿意接受错误的事实。我相信,下一次我们肯定会做得更好。


非常感谢听众愿意每期花上一个小时听我们几个吹牛逼。

希望我们的节目能给各位带来一些奇妙的想法,或者,至少能带来一丝欢乐。

愿我们在下一季相遇,看到更好的彼此,更辉煌的 Web。

我们希望把 Web 开发带往下一个高度,但是具体真的执行,真的努力去创造的,是勇敢而又拼搏的各位。

加油!我们一定可以的!