@shintendo #113 不要扯这些乱七八糟的，我说这个两套 JS/TS 文档只是想顺着逻辑讽刺”它的文档和学习资源几乎全部是面向 TS 的“

@shintendo #113

你的逻辑从一开始就不成立，Angular 本身就没有要求你会 TS，文档里也说了 latest JavaScript(指 ES6)
还有一个概念的错误 ES 才是标准 JS 和 TS 都是 ES 的实现

https://angular.io/docs
”These docs assume that you are already familiar with HTML, CSS, JavaScript, and some of the tools from the latest standards, such as classes and modules. The code samples are written using TypeScript. Most Angular code can be written with just the latest JavaScript, using types for dependency injection, and using decorators for metadata.“

所以你的意思是 Angular 的文档说了只能用 TS 了？ 只是要求你会 ES6 而已。那么为什么 Vue 文档里对比就要这么阴阳怪气来一句 "Angular 事实上必须用 TypeScript 来开发，因为它的文档和学习资源几乎全部是面向 TS 的。"?

@shintendo #105 "Angular 事实上必须用 TypeScript 来开发，因为它的文档和学习资源几乎全部是面向 TS 的。"
我的理解是 Angular 没有面向 JS 的文档，所以不能 JS 开发，没错吧？
那么假设 Vue 3 没有面向 TS 的文档，用同样的逻辑来思考，Vue 3 不能 TS 开发，没错吧？

@shintendo #100
如果他只出了一份那我也可以阴阳怪气的来一句 “事实上 Vue 3 必须用 TS/JS 来开发，因为它的文档和学习资源几乎全部是面向 TS/JS 的。"

@shintendo #100 就看 Vue 3 到时候会不会同时提供面向 TS 和 JS 两份文档了咯，让我们看看 TS 和 JS 之间到底有多少差异？

@shintendo #92 Angular 也没必须写 TS 啊。但你看 Vue 的文档怎么说的？

@LokiSharp #88 现在文档里还没改掉，期待 v3 文档里面怎么说
https://cn.vuejs.org/v2/guide/comparison.html#TypeScript

Angular 事实上必须用 TypeScript 来开发，因为它的文档和学习资源几乎全部是面向 TS 的。TS 有很多好处——静态类型检查在大规模的应用中非常有用，同时对于 Java 和 C# 背景的开发者也是非常提升开发效率的。

然而，并不是所有人都想用 TS——在中小型规模的项目中，引入 TS 可能并不会带来太多明显的优势。在这些情况下，用 Vue 会是更好的选择，因为在不用 TS 的情况下使用 Angular 会很有挑战性。

最后，虽然 Vue 和 TS 的整合可能不如 Angular 那么深入，我们也提供了官方的类型声明和组件装饰器，并且知道有大量用户在生产环境中使用 Vue + TS 的组合。我们也和微软的 TS / VSCode 团队进行着积极的合作，目标是为 Vue + TS 用户提供更好的类型检查和 IDE 开发体验。

@faceRollingKB #85 跟进了不是打自己脸么，当年 Vue 社区说 Angular 2 学习曲线陡峭最主要的一点就是 Angular 2 是 ts 写的，现在的情况一模一样。

@ChanKc #79 我觉得 这个 i18n 这么干是可能因为部分 vue 用户（大多为新手）都不用 vue-cli 建工程化的项目,而是用官方文档首选的 <script src="..."></script>
我碰到过很多用 vue 的人，他们就和楼主一样认为就用个模板功能就足够，对他们来说 Vue 比起 React 、Angular 最大的优势就是直接 script 引入到 HTML 就行。
不过我看了这个作者最新的 repo https:// github.com/kazupon/vue-i18n-locale-message 他去年开始在做这个提取文本为 json 的工具，可能会好一点。


我现在不喜欢 Vue 的一点就是 Vue 的各种轮子太多了，也没人总结个最佳实践。除了 Vue 核心之外其余组件的文档大部分也写得不怎么样，拿到手什么东西东西得自己考虑，考虑到最后结果会发现用他们现成的还不如自己造个轮子。你说的 GitLab FOSS 这种应该就是这个情况。

@marcong95 #69
qt 之类的成熟的框架用 gettext 之类提取的文本注释带有源码位置信息的，可以是体现上下文的。
Artifex Mundi 翻译质量问题不是流程的锅，他们的作品本来就是小品级的节约成本不花钱做校对很正常。

@TsubasaHanekaw #45 是的，主要是少了这样一个工具。当然这个自己写一个也不难，但是我用“框架”不就是为了避免多写业务以外的东西么

@agdhole #49 Crowdin 是翻译平台，源文件要自己处理的。刚才看文档发现现在居然支持直接上传 js 文件了，我去看看怎么用= =

@slyang5 抱歉了这个我不太清楚，我 C 的时候好像还没有 LeetCode，现在的工作也不需要我折腾算法，我也没求职需求

@murmur 就用个模版，还没有专门的前端，也不需要 SPA 级别的复杂交互。还跟风前后端分离用 Vue 干啥，按传统后端的直接渲染 HTML 不就好了？别和我说你还是 Serverless(笑

@TypeError 是的，当时看到这作者还是 Vue Core Team 的人，我就开始怀疑 Vue 的水平了。

真当 CTO 不上 V 站系列，坐等 CTO 登场

不要吹那些有的没的的类似语法糖的特性，到头来都是一场空。Vue 所谓的学习曲线平缓只是因为他本体是渐进式（指没有实现完整的功能）框架（自称）而已，功能少的东西自然学起来简单。
想要达到满足工程化的功能的话。

发送请求你得学个 axios 吧？
路由管理的 Vue Router 总得学吧
状态管理得学个 Vuex 或者 RxJS 吧?
单元测试 Jest 和 Mocha 选一个？
是用官方文档放在首位的 script 引入还是官方 Vue CLI 或者手动配 webpack ？
为了深入理解最新的 Vue 3 尤雨溪最近真香了的 TS 是不是也得学一下呢？

你正文里的四个问题让我感觉你是在黑 Vue，非专业前端、开发小程序、非 SPA 、不需要维护满足这 4 点要求的简单页面，按照你说的啥都别学的场景直接用 JQ 和原生 JS 不就好了，Vue 有啥优势？

@murmur #24 我觉得吧，主要问题还是 Vue 的用户使用场景单一导致工程化的缺失。
刚刚我看了看这个作者的 Github https://github.com/kazupon/vue-i18n-locale-message
去年年底已经开始写新的工具了，文档上粗看应该是分析 vue 文件并提取待翻译的字符串，用 json 保存。
说明 Vue 团队还是有人思考这些实际问题的，而不像某些进取的用户。

@murmur #19
vc6 时代的汉化玩法？？？请你告诉我这个时代该怎么玩，硬编码到代码上每个语言编译一份二进制文件？
字符串该不该翻译和语言有什么关系需要翻译的字符串都是有专门的占位符标注的。

你这两句话暴露了可能是一小部分 Vue 用户普遍的情况，只参与过前端项目开发。