第一章 了解LiveView

过去Web开发比较简单，交互就是“点击，请求，刷新，显示”。浏览器发起请求，服务端回应请求，返回网页数据，浏览器收到数据，重新刷新页面显示给用户。但用户需求慢慢提高了，需要更好的体验。举一些例子：

  • 页面不再是一页一页地加载内容，而是随着用户向下滚动而加载更多内容。
  • 用户想要的不是一个带有“刷新”按钮的电子邮件客户端收件箱，而是能实时接受新邮件，不需要刷新。
  • 搜索框根据数据库中的数据自动完成。

用户希望web能想本地应用一样反应迅速，无感刷新，网速虽然提升不少，但比起cpu, 它几乎是整个环节中最慢的一环。那怎么办？交给浏览器，交给JavaScript。重活累活在客户端（浏览器）完成，服务器只发送很少的数据–JSON数据。前端根据这些数据来实时更新页面，当然，只要实时，肯定有段代码在你的电脑上一直循环运行监听这些数据，这段代码一般都是JavaScript，更进一步，把JS代码模块化，赋予更多的功能，就是各种前端框架了，React, Vue, Stimulus等等。前后端分离就是这么来的，前端负责界面，后端负责API。这种模式目前很成熟，适合大公司，或者稍大一点的公司，前端一波人，后端一波人。在中国，最不缺的就是人，所以，它成了主流。

但对于个人全栈开发者，它实在是有点重，一个人负责前端后端，在两种开发模式中来回切换，有点分裂。有没有体验好，又不是前后端分离的解决方案呢？有的，Ruby on Rails 7 的 hotwire 技术是个较完美的答案，还是服务端渲染，只是JSON换成HTML 片段，其实数据量也没大多少，速度、体验能保证，逻辑基本都是在Server端，client端还是负责GUI显示，经典的MVC结构。ruby 的生态也足够强大，不用自己造轮子。确实是比较好的技术栈，一个人单枪匹马就能做出一个小团队的活。

但它还是有不足的地方，不够快也不够省。我一个穷人打工仔，服务器都买最便宜的，当然希望 server 越快越好，处理能力越快越好。而且，我不喜欢OOP，面向对象是对现实世界的模拟，在这个基础上衍生出一系列的语言，框架，技术，生态。但代码和现实有各鸡毛关系，硅基cpu又不是碳基人类，OOP 没有减少复杂度，它也不是银弹。我没有那么好的抽象能力，对别人抽象出来的东西也看不懂，云里雾里的。我喜欢白刀子进，红刀子出。C 永远都是最强的，但太原始了，现在这个时代相当于刀刻硬盘，手写二进制了。Rust 似乎不错，翻了一下，太TM复杂了，C++在它面前都自愧不如，一堆概念，何必呢？

不喜欢OOP，要简单，要高级，要生产力，要速度，要稳定（它爹Erlang毕竟5个9），要生态，低能开发嵌入式，高能开发Web，再搭个AI的快车就完美了。目前，elixir 似乎是不错的选择，嵌入式有Nerves, Web有Phoenix 和 Ash, AI有nx。而且这个语言国内基本没人学，学了也找不到工作，只能自己用，简直是古希腊掌管全栈的神，全栈全栈，什么都是自己干。

完美！