1244943563

@honkew 你是对的，我忘记加 2 倍清晰度了，感谢感谢，我在官网接入的问题

@leokun 感谢认可，确实是有点垄断，没啥好用的开源替代，很多人从 0 开始做这种编辑器真没啥头绪，第一步先把框架开源再说

@dassh 已修复，特别抱歉，没及时看到

@nzbin 关注过 ag 的 signal ，不过我感觉不是因为使用 signal 就不重了，例如 react 的 class Component VS Function Component ，Class Compoennt 就重，Ag 的重体现在它的架构层设计与工程上，不在 signal ，这个没必要争，这是它的灵魂，就是不要求灵活性而要求代码一致性，我写过几周 ag 19, 它的写法让我很像回归函数式编程。16 以后核心是轻了，但是它重的何止是大而全，哎 难以言说...

@pursuer 哈哈哈 因为这个我一直没有使用过，solid 有比较代表性的 signal ，svelte 我深度使用过，国外现在确实也很火爆，所以它们俩支持上是很有必要的，其实我感觉就 react vue svelte 三个是 AI 应用中最轻量主流的，所有框架支持还真的精力不够（就算加上 ai 帮忙），里面的 core 跟 theme 包其实已经够三方来为自己喜欢的框架定制一套适配器了，现在自己的体量还太小没几个人知道更没几个人真的用，真有人用的话后续再考虑扩展更加广泛的市场😂

@orluna 感谢体验

@beginor
@nzbin

OKK 那我先计划着，后续加，因为它其实有点重，不是特别轻量，目前策略先把轻量的主流框架抓住，感觉更优先的是基于它打造个 chat ui 直接提供一整套服务算了，太难挤进别人家的生态了

@codehz 目前是解析层测性能提升，benchmark 脚本已公开，clone 仓库，按文档，将你要测试的 markdown 文件全都丢进 test-data 中，短文档 increamrk 不占优势，长文档优势巨大

原因：incremark 默认使用极速模式，也就是使用 marked 作为引擎，streamdown 与 x-markdown 也都是 marked 作为引擎，incremark 每次只解析一个块，其他的每次都全量解析，单纯从相同的 marked 角度出发，你认为 o(n) 快还是 o(n²) 快。increamrk 短内容下，因为各种边界检测 + 内置的一些插件，会比默认 marked 慢的，这个文档中有描述。

测试方法文档： http://incremark.com/zh/advanced/benchmark.html

@TossPig
@beginor

真的要？那我要规划了，做好通知你们