1. 写成 Haskell 风格函数签名：(A -> B) -> [A] -> [B]

2. 丢进 hoogle 你就知道这玩意叫做 map：<https://hoogle.haskell.org/?hoogle=%28A+-%3E+B%29+-%3E+%5BA%5D+-%3E+%5BB%5D&scope=set%3Astackage>

3. 然后去查 Java 里 map 怎么用

@AngryMagikarp jQuery 当然能做好单页巨型应用，并且在恰当的调教下能做得比 Vue 好。模块化、数据驱动、双向绑定，都可以依赖一些插件，但每个都能做到最好。而且对于 Progressive Enhancement 支持更好，比那些一旦自定义元素就直接废了的强。这点上我认为 Svelte （因为标榜自己是编译器所以）本可以做到更好…… 结果没能符合期待。
我还指望编译完成就符合表单交互（为什么会这么指望）

具体到底谁去写，还是 “组织结构决定软件结构”。

我更倾向用技术过滤愚蠢的人…… RESTful 我没能十分钟理解，就说明里面有问题。
最后是这一句让我（感到）完全理解了：“模拟 Unix 文件操作”。那么其优劣就很明显了。Unix 哲学完全看写的人，不然分分钟变 X11，说了等于没说…… 直接做成 HTTP 的 RFC，那就是真的 “什么都没说”
有（明白设计中间层规范的也是经常犯蠢的凡人）这基础，看 GraphQL 的时候就明白很多了。问题也很清晰：比如，多联级容易引入太多重复的数据。Pocket 的接口算是让我直接见识了。因为不信任不同级数据间能保持一致性的关系，我就一直在纠结到底用哪个这一数据。最后还是第二天重构成 dataclass 用 dacite 读取的时候才放弃思考这个问题。

我认为这方面 “工程化规范化的做事方式” 根本不存在。也可能我曾在和现在的组织本来就比较松散有关。
但基本上我觉得这种，要么是架构先拍板，要么就是先随便写，看情况再改。前者在快，后者在可变。
说到底是前后端语言不同的问题，最好是直接传有类型的。为什么要传 timestamp ？直接传 datetime 类型多好？

@AngryMagikarp 所以说问题的根源在于笼统地将所有的 “用户端” 称为 “前端”。
仔细检查就可以发现，twitter.com 是基于 Web 技术的 C/S 模式，我认为叫做 WC/S 模式也并无不可。
这和之前 Viaweb 那时候的真· B/S 模式是显著不同的。
更类似边缘计算了。

你什么时候产生了 GraphQL 只能 CRUD 的错觉？

@orzorzorzorz 你说的这个，不就是自己造了个 GraphQL ？

还有一个就是 RESTful 要让 Web 端计算的话做好打不开的准备。
一堆小请求直接阻塞，反正浏览器限制同域名同时 6 请求。

按标准的 “前端” “后端” 叫法分，就是后端提供数据，前端提供显示。

请其他分法不要叫前后端：
1、把 B/S 写成类 C/S 的，包括 SPA 请求生数据客户端计算的 —— 请叫 WC/S （ Web Client/Server ）；
2、用 WebSocket、高频轮询 等实现前后端同步的，请叫 WebUI ；
3、强行把接口设计不良的服务器套层 Web 变成用户友好的，请叫 Wrapper ；
4、欢迎补充……

当然具体用哪种可以自由选择，组织结构决定软件结构。

@springz 给你们公司推荐一下 GraphQL，你可以失业了

@Cytion 配合头像食用更佳

我觉得需要请 @geelaw 讲解一下
我目前看到的也就他讲得像是这么回事……
但我完全记不住……