Erlang/Elixir 对 Ruby China 的拙劣模仿，展示 LiveView 功能的 Elixir China 诞生了！
LiveView 展示
大家好，最近我使用 Phoenix 框架并完全基于 LiveView 构建了一个展示性质的网站，我模仿了 Ruby China 并称它做 Elixir China。
之所以说它是展示性质的，因为它没有接入真实的数据源。不过对于前端而言和接入真实数据源也没有什么差别。
完整的后端功能过于复杂，我创建这个网站的首要目的是想感受一下 LiveView，所以会不会让它具有真实功能看我后续还有无兴趣和精力。当然，如果有人想参与，它应该可以成为真正的 Elixir China。
LiveView 简单介绍
基于 LiveView 构建的 SPA 网站，感受上会觉得和 React/Vue 这类纯前端框架做出来的效果类似，但技术细节上却截然不同。
React/Vue 构建的前端，所有的页面（也就是各个组件）都在 JS 中定义好了，通过纯前端的路由切换显示不同的组件。但是 LiveView 的网站前端没有任何对 UI 的定义，所有的组件由后端提供。
LiveView 把状态和 View 层（概念上类似 React 组件的 render 方法）放在后端管理，后端根据状态的变化 diff 出需要更新的动态部分，以固定的数据结构响应给前端。前端有一个 LiveView 提供的库会自动帮你做页面更新。后端响应页面并不表示需要通过常规的 HTTP 访问来进行路由，因为 LiveView 提供的 URL 路由以触发隐式的 Websocket 通信的方式通知后端更新页面。类似的，页面的事件、表单等都可以触发这些已经封装好的基于隐式通信的异步更新。
也就是说你几乎不需要一行业务 JS 代码就能实现类似 React/Vue 的效果，并且因为 Websocket 的优势，它更加适合高事实性的网站。
毕竟最近海外服务器普遍网络不稳定。
感谢分享，不知道 liveview 是不是排他性质的？比如是否用了 liveview 就不能用其他 js 生态的东西了等等，能不能很好的混合使用？
u1411001432
回复
在前端绑定数据生成界面的框架都没用了，例如 React/Vue 生态。例如 moment.js 这种库的常见用法是在数据绑定前对时间数据进行格式化，这对于 LiveVIew 而言应该放在后端来做，但也可以通过一些不太便捷的方式在前端做到。还有一些前端 UI 框架自带 JS 库自己处理事件，也不行了。所以我选择了一个纯 CSS 的框架 Bluma 它不会对 LiveView 有丝毫影响。
Hentioe
回复
大概明白你的意思了，我隐约觉得不能很好的支持 js 生态会是推广开来的一大障碍，当年 js 社区有个 meteor.js 的框架，主打特性之一就是实时同步，只是早期不能很好的集成 js 生态 ( 不是不支持，只是不方便集成，有点别扭），直到现在都很小众。
另外不知道 liveview 在实际开发时候体验好吗，包括效率，开发体验等等。
zlfera
回复
我不清楚没什么限制是什么意思。但是这东西文档我扫了一眼，他们用的 GCP 和 AWS 的服务器。我个人在 AWS 的服务器遍布几乎所有节点（这个 elixircn.blueriain.io 部署在 aws 东京），无论是性能和速度都远超你说的这个东西。
u1411001432
回复
实际开发体验就是你能明显感觉到和传统的 Phoenix 的开发模式非常类似（毕竟 LiveView 建立在 Phoenix 之上），相比前后端分离的 SPA 网站省事太多了。后端渲染的传统网站过渡到基于 LiveView 的 SPA 将非常容易。
这个论坛怎么没有继续呢？Liveview 是很好的，很有趣，应该会有很多的应用。 可以写 SPA 单页，不用写 js，极大地简化了，一个语言 Elixir。