@nightire 非常感谢 细心的回答。其实由于之前是个人工具，其实我也清楚与 livereload 去做功能对比也不科学，其实从 reload 的功能角度上 puer 就直接缺乏两个基本需求

1. 没有抽象去向：即文件变化后只引起浏览器刷新一种结果，比如 livereload 提供了预编译的选择。这个其实很好解决
2. 没有抽象来源：即来只有文件变化一种，比如可能希望是一种操作引起你的刷新，而不仅仅是文件变化。

这两点也是我马上会考虑的问题，问题是一旦引入预处理等机制，就必然需要考虑使用带来的复杂性，参数太多说不定还需要配置文件 (或脚本)，甚至后续还会有 GUI，趁现在还算简单我还有时间去考虑这些问题，特别是已经有 gulp、grunt 这类构建时。

puer 现在能引起一些关注的主要原因估计就是简单，puer 做了很多无需插件介入的注入工作。一个还有些功能的工具可以在命令行下使用而不显繁琐 (当然 puer 也提供了 API，可以与 gulp 之类的集成) 可能是它的简单价值。

夹缝之下，寻求生存，确实也是一门学问。

关于专业性，其实除了 inspect 可以去掉，puer 功能不算东拼西凑，mock 和 proxy 其实都依赖启动的服务器

#1 楼 @luikore 跟 guard 其实关系并不大，如果是 live-reload 我在这里回答了一次 https://gitter.im/leeluolee/puer 可以参考下

#12 楼 @darkbaby123 YES！基本原理是一类的，不过它不是 改写 是 Template -> handlrbar AST -> 改写 htmlbar AST -> Living Dom . 而 Regularjs 没有中间改写过程 http://www.html-js.com/article/Regularjs-Chinese-guidelines-for-a-comprehensive-summary-of-the-front-template-technology 之前发过一篇文章，包括下面评论很有些质量 推荐你有空可以了解下

#7 楼 @xiongxin8802 nej 是框架，这个组件库 不冲突了。

#8 楼 @Numbcoder 好久不见。。。pemolo 三雄 只剩一个了 哈哈哈

#5 楼 @billy 谢谢鼓励 :) 已经在公司新启动的大项目中开始使用，希望项目完成后能让这个库更贴合实际应用场景

#3 楼 @billy 我是作者，谢谢反馈，不知道你心目中有没有比较确切的对于新意的见解，我会作为意见可以放到后续 todolist 里，现在强烈的需要反馈。

这里引用的贴 完整的应该是在 CNode 中我发的帖子，你可以参考下理解下我的实际观点。

其实很简单，就是 String-based Parser 来带语法上的灵活性的同时让输出保持动态性，首页的第一个例子虽然不能再简单，但其实恰恰是其它 MVVM 库不容易实现的。

目前虽然市面上只有 ractive 和 regularjs 是这种解决思路，但是我觉得确实会是未来的趋势，因为内建的 Parser 保证了可以与未来的 Custom Element 共存