恰恰相反，业界已经几乎没有纯 fp 或纯 oop ，大多数情况下，最佳实践都是某种比例的糅杂。

@nicoljiang 服务端抓取是这样的，但是需要无头浏览器，还有就是抓不了要登录的页面... (archive-box 啥的可以配 token 和 cookie ，就是比较麻烦）。
所以这俩（服务端抓取和客户端抓取）其实是不同思路的东西。他这个页面太夸张了，80M 😂

@caomingjun 第一次知道，我等会试试

@zxq9 移动端适配是网站做了移动端适配。不是说可以装插件啦…
不过我最近在考虑这个… 但是安卓只有 chrome ，ios 只有 Safari 可以装插件，还必须得上架，太麻烦了

想太多了，他妈的烂命一条，就是干，就是梭。
服务宕了就重启，数据丢了就恢复。
上来就搞容器部署？开什么玩笑，pm2 start 就是干。

你费老大劲大概率也没人用，还不如自己开心梭哈，想怎么来就怎么来。

@loveqianool 因为初衷是我们俩自己用的工具顺便开源，如果社区希望实现的话，提交 pr 或者 fork 一份都是可以的（只要遵守 GPL v3 协议）

@sublimevsatom 不支持，因为我们俩都不用 firefox ，移植难度应该不大，不过没有动力

@SenLief 实际上用了 singlefile （ https://chromewebstore.google.com/detail/singlefile/mpiodijhokgodhhofbcjdecpffjipkle ） 的核心 lib 。把图片和一些其他资源 base64 内联了。
直接下载对现代很多 csr 网页是没用的。

@jqtmviyu Mac 卡也是真的，windows 卡也是真的。
毕竟光是优化方案的帖子都不知道多少了... 一视同仁的卡。只是 webkit 有一些特有问题吧

有个问题，canvas 背景把下面的 footer 遮住了，点不了。
后生可畏。

看了一下你的代码，不是 WYSIWYG （所见即所得），只是用开源的 markdown-it 实现了一下 markdown 渲染，用的也是 Electron.... 你为啥会觉得自己写完之后性能会比 typora 好。
如果 typora 是 80 ，你进度这才 0.05 呢。
typora 以前巨卡是因为没做虚拟渲染，后来好了一点，现在引入 GPU 加速，已经是 web 实现里中等水平了。
不 hack 的话 web 编辑器的性能都差不多，什么 editor.js 、milkdown ，内容一多最后都是一坨。
有个日本人叫 takuya ，他用 web 写的编辑器性能不错，主要思路是做 render cache ，就是把 100 行的内容拆成 5 份，渲染成 html 块，如果你编辑第四块，就只有第四块的内容会重新渲染，其他的就是展示之前渲染好的 html 。
而且这个 cache 和一部分 render 还是在 worker 里做的，就这你想一想是什么级别的复杂度吧。

高质量和流量是不可兼得的。
cha.fan 已经似了就可以说明这一点。

这玩意大概率还不是 GPT 写的，是通义灵码写的。
阿里那个语料库里全是简中技术糟粕。

textmate

@Mianmiss 英文问答的话比通义好用，中文不如

自己部署
https://ray-d-song.com/zh-cn/blog/continue-free-ai-code-assistant/

https://imgur.com/gallery/llama3-wKjlZmB

说实话，我感觉比 gpt3.5 聪明

2s ，你这个网站已经几乎是不可用的状态了。首次进入触发瀑布请求，直接等个七八秒是吧。
至于排查方式：前端用 sentry 做个埋点，对比一下请求时间和返回时间。

背景好歹找个高清图。
还有哥们，visitor 都拼错了。