关于将现有的类封装为vue组件的尝试 about noname HOT 2 OPEN

不建议这样做吧。
使用某项技术是为了解决特定问题，而不应该为了使用技术而使用技术。
当前工程结构虽然看似原始了点，但我觉得蛮好的，启动也方便，没必要使用vue吧。

我认为引入vue是有如下缺点的：

1. 引入vue runtime无端增加运行的代码体积，工程复杂化，视情况需要引入打包器
2. 可能引起性能的劣化，这类框架实际上相对原生代码实现界面性能是更差的，相当于是用一部分性能换取更清晰的工程组织方式、以及一些编写更简洁的语法糖
3. 大量的重构工作量

如果使用vue编写部分组件带来的好处能超过上述缺点那我也支持使用，但如果没有好处的话，我建议不要这样做，另建一个分支或者自己试试可以，还是不要合入主干吧

from noname.

不建议这样做吧。
使用某项技术是为了解决特定问题，而不应该为了使用技术而使用技术。
当前工程结构虽然看似原始了点，但我觉得蛮好的，启动也方便，没必要使用vue吧。

我认为引入vue是有如下缺点的：

1. 引入vue runtime无端增加运行的代码体积，工程复杂化，视情况需要引入打包器
2. 可能引起性能的劣化，这类框架实际上相对原生代码实现界面性能是更差的，相当于是用一部分性能换取更清晰的工程组织方式、以及一些编写更简洁的语法糖
3. 大量的重构工作量

如果使用vue编写部分组件带来的好处能超过上述缺点那我也支持使用，但如果没有好处的话，我建议不要这样做，另建一个分支或者自己试试可以，还是不要合入主干吧

主分支代码中直接使用vue文件确实会这样导致性能问题和重构问题。但是就目前来说，vue的引入我是更想让其应用于扩展文件(extension)。

目前如果你使用的是我提供的客户端或者使用noname-server.exe(一些特性还在测试中。不久后会更新官方的客户端来让所有人使用新特性)，你可以直接import一个css，ts，json，vue文件，就像是在一个vue工程中那样。

但由于项目的更新方式(离线更新)，这些新特性并不是主分支将来所急着去用的，反而是可以让扩展(extension)能更标准，便捷的编写。

以ui扩展为例子，目前的ui扩展，十周年ui等，其写法和主分支的某个特定版本过分藕合绑定。我打算写一套逻辑特定但ui可以自由切换为其他样式(目前的ui扩展大多都不互相兼容)的扩展用作此类美化扩展的标杆。

至于性能方面:
主分支加入了vue的runtime文件但是目前没有加载，所以在没有扩展主动加载的情况是不会有大的性能问题的。
目前确实加入了编译vue(sfc)和typeScript的代码，但是其运行在service worker，也不需要过于担心性能问题，虽然旧的客户端无法加载service worker

from noname.