@CharmanderS5 #28 Bear 目前依赖 iCloud，所以强关联了苹果平台。Web 版提了多年，一直还没有明确的开发进度公布出来，不知道阻碍在哪里。如果有 Web 版并且具备全部基本功能的话，安卓版也应该不远了。

说起来，单论 Markdown 编辑体验，Bear 是最舒服的。可惜支持的功能少了点（尤其是不支持表格）。

@liximomo #48 这点确实是一个问题。可能我中文搜索需求确实不多，笔记本和 Table/List Block 系统已经可以满足我的定位需要了。

我很想知道，Firefox 的开发者工具相比于 Chrome 强在哪儿？每次我尝试用 Firefox Developer Edition 调试前端应用，但总是被劝退。

RBAC 只是一个权限管理模型，或者说方法论，通过角色关联业务实现权限分割。至于业务是什么，RBAC 本身是不管的，需要你根据实际业务情况做具体设计和实现。

以文章编辑为例，角色关联的可以是文章编辑功能（编辑按钮），也可以是文章的某个属性（比如分类、标签等）。关联的东西不一样，权限分割的效果也不同。

如果你说的是某个 RBAC 模型的框架实现，那就得看那个框架的说明书了。

@CEBBCAT 大概是因为表达有歧义，为避免引发无谓的口水战，所以处理了

403 了。

不过能猜到你说的是什么。嗯，有点猛。

确实各种广告。感觉被污染了。

CSS 太难，不如用现成的 UI 框架。

@sfqtsh #2 我知道。我想表达的意思是，纯键盘场景下 OneNote 用起来太奇怪了，只有用上手写笔时 OneNote 才能体现明显优势。

emmm，忘了敲空格导致 @ 失败。请见上一条回复。 @Livid

想点个踩，但似乎没有效果，Ajax 返回 200，返回数据始终是 {changed: 0}。业务设计如此？@Livid

目前在用 Notion。

Notion 给我的使用体验是最稳定的。这个稳定不是说软件不崩溃、性能够平滑，而是它不会给我预期之外的操作结果。当然这里有个前提，就是你的预期符合它的设计意图。有个性的应用就是这样，顺着它的思路使用就会很舒服，否则就很纠结，所以往往变得「小众」。但好在 Notion 的设计意图大多都符合直觉，接受起来门槛不高。我理解的 Notion 的产品思路是：用户需要明确要记录的内容是什么类型、对应哪种 Block，然后 Notion 会把那种类型的内容以最好的方式呈现出来。

Evernote （或印象笔记）给我的使用体验是最简单的。Evernote 就像一个内容仓库，给你各种方式去记录内容，也给你强大的工具（尤其是标签）去整理内容。Evernote 在「存储」这件事情上做到了极致——但之后的事情，Evernote 就有些力不从心了。如果你对内容呈现的质量有要求，Evernote 往往会让你困扰：要么文字样式不一致，要么难以实现你理想的格式。当遇到非文本内容或非段落结构时，Evernote 的体验就更痛苦了。印象笔记中国版发布 Markdown 模式后我就没有再使用了，所以后来出的新功能我不了解，也许体验变好了一些——但结合之前表格工具的更新来看，优化程度多半是有限的。

OneNote 很少用。我始终怀疑，OneNote 是微软专门用来宣传 Surface Pen 的。

Image 是类，Container 是实例。你修改一个实例的属性不会影响其他实例。

如果 jQuery 本身就能满足业务需要，那大可不必立刻上 Node 工具链（ Vue CLI 也不用），把 Vue 当 jQuery 用就好，从个别模块开始逐步替换到整个业务应用。Vuex 和 Vue Router 也可以在这个过程中按需引入（就跟引入一个 jQuery 插件一样）。只要没有业务需求，全程不用碰 Node。

如果 Node 工具链是刚需，或者你就是想正儿八经学习现代前端开发的话，在学习 Vue 本身的使用之余，了解一下 Webpack 是个什么东西（但不用上手学习其使用），然后了解 Vue CLI 的基本使用，再把手头一个没有用到 Node 工具链的项目（规模可大可小）转写成 Vue SFC （单文件组件）并成功跑起来，你就算入门了。

JSBox ？

我觉得应该让孩子早些培养社交能力，增强社会安全感。各种幼儿园事件虽然让人愤怒，但不应当是放弃这个目的的理由。

不过不需要太早，也不需要期望孩子在幼儿园能学到什么「知识」。

@sodatea #36 （文章真长！）我觉得他想要的是这种模式。

@duanzs #38 找到了一个翻译版： https://hijiangtao.github.io/2018/04/20/Designing-Very-Large-JavaScript-Applications/

@duanzs #37 这个要分情况了。

如果子项目本身就可以独立运作并发挥业务价值（有自己的业务环境、root 实例、入口页、整体布局等），只是在特定情况下需要「嵌入」到一个更大的应用中，但内外并没有太多交互，那么你可以考虑 <iframe>——这种情况，你只是希望两个应用显示在一个页面中。（这种情况讲道理不能算「插件」。）

而，如果你不想用 <iframe>，你可以考虑 Vue-in-Vue （我瞎编的术语）。子项目的也是一个完整的 Vue 应用，其实只是需要一个 mountpoint 而已，那么主项目应用留出这么一个元素让子项目去 mount 即可。此时子项目的 install 方法就是一句 new Vue(...).$mount(...)。

如果子项目是一个业务模块，需要依赖外部环境才能发挥业务价值，那么子项目的 index.html 应该只是为了方便独立开发调试而存在，真正 build 出来的应该是一个库（也就是 dev 和 build 是两套打包流程）。剩下的就跟 element-ui、vue-router 等没什么本质不同了。

@duanzs #34 你是不是误解了什么。

function loadExternalModule (url) { document.createElement('script') /* ... */ }

有了这样一个函数，只要能有一个 url，是不是就可以在运行时加载一个外部 JS 模块了呢？至于模块信息……你（的业务）总得设计一个机制来生成或获得模块信息啊，不然插件系统做出来要怎么用？

function useExternalPlugin (plugin) { Vue.use(plugin) /* ... */ }

有了这样一个函数，只要能有一个插件对象（通过 loadExternalModule( ) 获得），是不是就可以在运行时注册一个外部 Vue 插件呢？完全不需要重新编译主项目。

我不明白你为什么要纠结于「是否预先知晓模块信息」这一点。

所有模块都可以转换成一个 JS 文件。我们约定这个 JS 文件会以某种方式输出一个 Plain JS Object，并且包含一个 install 方法，这样就可以通过 Vue 插件机制 ( https://cn.vuejs.org/v2/guide/plugins.html) 动态注册到 Vue 应用中。接下来你只需要解决「获取这个 JS 文件」的问题即可。解决起来也不难，理论上任何异步加载 JS 资源的方案都可以。在整个这个过程中你的主业务应用不需要做任何变化（当然主业务应用本身要实现插件系统的底层支持）。

至于从哪里加载，当然会有一个后端服务提供模块清单（就好比 VS Code 的插件搜索），但这个事情是业务的事情，并且与主业务应用无关了（除非搜索功能本身是主业务应用提供的）。确定待加载模块列表（不论是自动生成的还是用户手动选择的），转换为各模块的 URL，依次加载对应的 JS 文件并调用其中的 install 方法（通过 Vue.use( )），一个「插」系统就实现了。

这里唯一需要额外实现的是「拔」，因为并没有一个 Vue.unuse( )，Vue 也不识别 uninstall 方法。但既然模块本身已经在本地了，手动调用 uninstall 方法并没有什么障碍，实现相应的卸载逻辑即可。