moonrailgun

@ALLROBOT 插件或者脚本无法实现浏览内容按需加载与回收，以及更高的控制权。
另外没有说要满足所有用户的需求，只是满足特定用户的需求即可。过于通用的功能往往也意味着平庸。

另外有个好处是可以对环境进行隔离。我需要一个容器能够帮我把常用的，和临时的分割开。（就如我需要 chrome 的多用户来管理不同上下文下的网页内容）

@TrembleBeforeMe 对，我平时用 chrome ，也用过类似的插件( https://chrome.google.com/webstore/detail/ahmkjjgdligadogjedmnogbpbcpofeeo)，实际体验并不佳(当我同时管理 50+个标签页时虽然只是最基本的内容，但是依旧会卡上 10s 以上)

@kylebing 以前我也是这样的，直到要做的事情越来越多，工作用的标签页常驻 10 个以上以及待办事项越来越多以后，这种操作方式就不兼容我的情况了，比较以前都是 app ，现在都是网页（可能只有我才会有这个困扰？这种感觉就好像单机和分布式虽然只是多几个实例了，但是操作的逻辑会完全发生变化这样？）

@947 树的结构真的真的很重要，多了一层维度带来的变化是翻天覆地的。就比如我也用过很多文档，但是 notion 的树结构让我感觉真的很好用(wiki 也有类似的设计，但是给我的感触不深可能是因为是团队的而不是个人的)

@xiaoxiaoming01 就是为了解决标签页多的问题。可以按照树的结构来管理你的标签页，经过我自己使用(我自己使用了很久)，实际效果是大量减少了不必要的标签页(常用的重复标签可能会打开很多个，因为标签页很多反而导致复用率不够)

@TrembleBeforeMe 这个插件本质还是标签页，我的设计是期望能够把收藏夹和常用标签页的概念组合起来。将常用的网页和临时打开的网页在工作区中直接区分，同时回收不需要的页面内存占用(标签页会一直占用内存，而 webbox 可以达到收藏夹的效果)

@Guidoo 感谢支持，如果遇到问题欢迎随时反馈

@947 垂直标签页和分组是一维的结构，和树的结构是有本质区别的，而且并不仅仅只有叶子节点可以打开网页。而且标签页是活动的(实际加载了一个页面)如果想要回收就得关闭标签页，但同时也丢失了入口，而 webbox 可以达到类似收藏夹的效果，不打开的时候是不会加载页面的，(也可以主动回收)
另外套壳浏览器确实，然而其实浏览器不也就是基本的 webview(脚本解释器+排版引擎)加上一堆功能吗？实际解决问题才是真正的价值所在，我自己使用了两周以后确实是解决了我的问题让我用的很开心

我写的开源项目 [tailchat]( https://github.com/msgbyte/tailchat) 就看 star 来说的 ROI 的话其实非常低，但是我很高兴有一些人的认可以及帮助一些用户解决了他们的问题。
开源项目不一定要非常功利，通过开源项目可以学习到很多工作中难以触及的东西。
如果硬是说要找工作的话，开源项目本身并没有什么优势，但是你与面试官的沟通中通过解决开源项目遇到的问题，这种解决问题的思维我想才是真正的加分项

@weiguo161 g6 辣鸡


@chuck1in 开发依赖也是依赖 [狗头]


@lrhtony 大佬方便提个 issue share 一下么？不方便就算了。

@jfv 自己写的开源即时通讯应用，node_modules 1.6G

[]( https://imgloc.com/i/2uHi3)

打个 alpine 的镜像结果最后还是被 node_modules 撑到 1 个多 g

https://github.com/msgbyte/tailchat

@kongkongye 这就是树形依赖的优势与劣势。其他的如 go/java 等都是扁平依赖

@ttyhtg 小规模使用没有人管你的，大规模要商业化就会开始查资质了。

如果目的是躲避监管的话确实不适合放在国内。服务丢香港 /新加坡到国内的网络也不差的。

@nomagick 6.涨知识了。但是说真的 node 生态属实是屁大点功能也要封装个包


@devswork 欢迎提 issue ，康康 lock 文件我修下