非常棒～ 这两天正好有空学习一下

从比较高的层面去看，插件系统无非是要针对所在系统的特性与想要实现的需求，去设计一种数据结构，以及解释 /执行该数据结构的某种机制，让这个数据结构能够动态地进入到应用系统的生命周期中去，从而影响应用系统的某些功能。具体来看，你这个需求类似于基于 Web 的低代码，你可以参考这方面比较流行的一些开源项目的设计

SICP

这个帖子下的一些回复充分验证了垃圾后端只能看到与自己同水平的垃圾前端，从而觉得前端的技术一无是处，却完全意识不到这只是因为自己是井底之蛙而已。
话说回来，作为同样对业务不感兴趣，只想做一些比较纯粹的技术的人，给楼主一些我的看法与建议。
1. 前端某种程度上确实可以让你脱离具体的业务，大部分公司里负责将设计稿转成代码的前端并不怎么需要理解业务，只需要画页面调接口填数据即可。但这样的前端技术含量较低，重复劳动多，只是从业务搬砖变成了 UI 层面的搬砖，成长性还远不如业务搬砖，所以不建议。
2. 想要脱离业务，又想做有意思且成长性高的工作，后端可以往 infra 靠，做云原生，数据库等基础设施。前端可以做一些通用且复杂度高的基于 UI 的 SaaS ，如富文本编辑器，Workflow UI ，基于 Web 的设计工具等等。但这需要你能找到对口的公司。
3. 不要把自己限制在某一个端，而是从软件工程的角度思考问题。事实上很多软件领域的问题并不是被限定在某一个端的，而是需要从更底层的视角，如算法，数据结构，设计模式，编程范式，工程架构等等维度去找到解决方案，这部分属于属于程序员的自我修养了。与哪个端没关系，但如果你想脱离业务的话，这部分是必修课，也是你的竞争力。
4. 想要成为具备全栈能力的开发者，学习前端的技术栈相对后端更有优势一些。TS 弥补了 JS 在大型项目上的不足，Node 则填补了 JS/TS 技术栈的后端开发能力。一个项目的前后端代码可以达到相通甚至复用。
5. 如果不得不接触业务的话，试着从业务中抽象出通用的解决方案或者能力。

youtube 有个 JS 的版本，也很不错。链接是 https://www.youtube.com/watch?v=6oQLRhw5Ah0&list=PLP29wDx6QmW5yfO1LAgO8kU3aQEj8SIrU

太棒了👍🏻

可能现在环境不太好吧。从我个人经历上看，有几个我觉得很不错的工作机会（有去了的也有没去的）都是在酷工作找到的。

试下 docusaurus ？

@cctrv 你的观点只有一部分是对的，当我们遇到一些所谓「知道什么」的问题时，我们当然可以 Google 去获得这些我们不知道的知识。但问题是，在工作中遇到的问题往往并不直接是这种「知道什么」的问题，但「知道什么」却恰恰是解决问题的前提条件。正如在工作中很难直接遇到一个问进程与线程区别的问题，却常常会遇到，这里的代码是用多进程还是多线程比较好？如果不知道进程与线程的区别，你要怎么去 Google 呢？哪怕你 Google 了，你获取信息的效率有那些已经了解进程与线程区别的程序员快吗？

可以看下 TS 对 Assertion Function 的支持

@avastms 不太认同你的观点喔，首先“函数可以现场生成并在程序内部传来传去”这个与动态语言的思潮无关，这个是 first-class function 的特性，与语言的静态或者动态无关。其次，你说的内存问题是闭包这个机制实现上的细节，而闭包是一个语言设计上的问题，设计上的问题与实现无关。

@lcwylxx921 另外， 你应该是对 namespace 有什么误解，一般来说 namespace 是用来做模块化的划分的，在闭包这个语境下，更合适的词是 scope 。

正如上面所讨论的，JS 的闭包来源于函数式语言，在函数式语言中，函数作为 first-class 成员，需要具备一种能力使其可以方便地访问其定义范围之外的数据，并且这种访问在好的语言设计中应该是遵循 lexical scope 的。此外，关于你纠结的是否允许修改闭包数据的问题，这个首先在许多纯函数式语言（比如 SML ）中，所有数据都是 immutable 的，也就谈不上是否允许修改闭包了，但是，出于灵活性的考虑，部分语言放开了这个限制, 比如在 Scheme 中加入了 set ！关键字可以做一些 assignment 以及一些 mutable 的数据结构，但都还是有一定限制的，比如对 top-level scope 的修改，这种限制是非常合理的，可以避免在程序的各个地方做顶层的 assignment 然后对其他地方产生副作用。至于 JS 为什么毫无限制，只能说 JS 太灵活了吧。

自己写个 parser ？

赞～ 希望增加更多的可交互性