评论
.jpg "ES2015 与 ES5 #2"){kind=avatar}
|
问题是“大多数浏览器都开始支持”几乎马上 是的，你是对的，它在技术上更好，但我向你保证它 像这样的项目真的 “普通”JS 有效。如果你真的想要类，请使用它的“普通”JS Laserweb 在不到一年的时间里已经被重写了 3 次，它 2016 年 8 月 30 日星期二晚上 11:39，João Matos notifications@github.com
Courage et bonne humeur。 |
.png "ES2015 与 ES5 #2"){kind=avatar}
|
@arthurwolf最新发布的 Chrome、Firefox 和 IE 版本已经支持 >90% 的 ES6，就像我说的，有一些方法可以在旧浏览器中支持 ES2015 代码。这就是 JS 世界多年来所做的事情（旧浏览器的 polyfills），人们一直很好地处理这个模型。在我发布的分支中，它已经生成了适用于旧版浏览器的 ES5，无需额外的努力。 我很难理解你的论点。您是否反对使用 ES2015 模块系统或类系统（或两者？）？如果它真的让事情变得更难理解，我会同意你的看法，但事实并非如此。这是一个更容易理解的模型，几乎所有其他编程语言都已经可以使用了。人们习惯于导入/导出模型，这就是 Node 的工作方式 ( 如果我建议的是一些激进的尖端功能，我会理解，但这是一些相对简单的模型，可以在不到一个小时的时间内学会。如果它确实会赶走贡献者，那么在我看来，就这样吧，一个项目不能仅仅基于某些人不想学习新东西这一事实来做出技术决策。此外，一旦设置好架构，大多数更改将不需要触及任何导入/导出模型，人们将能够编写常规的 JS。 我快速浏览了一下 Fabrica，它似乎使用了一种叫做 JS 是历史上导致编写“错误”代码的语言，因为它没有标准的代码结构方式（ES2015 解决了这一问题）。如果在这个新版本中做出可靠的工程选择（并且仔细审查代码，有时说起来容易做起来难，但我们可以尝试），那么 LaserWeb 没有理由需要重写这么多次。 |
|
再一次：你是绝对正确的，这是正确的技术选择，
最重要的是，关于“如果我们现在做出正确的选择，则不需要重写 laserweb”的评论基本上向我展示了您的目标
您不想要一个闪亮的完美系统，它可以使用最新标准永远工作。你想要一些能让用户 你想要做的改变是一个渐进的改变。要有耐心。 在 2016 年 8 月 31 日星期三上午 12:33，João Matos notifications@github.com
Courage et bonne humeur。 |
|
@arthurwolf我明白你从哪里来。事实上，在决定尝试使用新的 JS 功能时，我已经考虑了贡献因素。如果我自己做某事，我什至不会考虑 JavaScript（如果我想在浏览器上运行，我会使用像 TypeScript 这样的静态类型）。但我更愿意与社区合作，并确保每个人都可以做出贡献。 你是对的，以“技术上正确”的方式做事需要更多的努力和时间，但也会导致更可靠的产品。例如，我一直在关注 Smoothie 的开发，它似乎非常遵循这种模式。我见过很多拉取请求被拒绝或要求用户返工，因为它不遵循指南或技术上的最佳解决方案。事实上，这就是我使用和关注该项目的原因，而不是其他没有强大技术领导力并以意大利面条代码结尾的社区固件。 你也是对的，我们不能指望代码随着时间的推移由于贡献者而保持超级干净（好吧，在实践中你可以拥有强大的技术领导力，但需要大量的努力并且你可能会激怒一些人），但是使用导致更好的代码或使重构更容易的语言结构是使保持这种状态更容易的良好开端。 我发现有很大帮助的是设置一个 CI 系统以确保拉取请求至少可以编译，并拥有一个广泛的测试套件。我在使用 JS 的大中型项目中没有太多经验，但我想某种 linting 系统也会有所帮助。我还通过个人经验发现，如果你花时间指导贡献者，他们大部分时间都会听从你的建议，并学会编写更好的代码。 我为此付出努力的原因是我计划将 LaserWeb 的代码用于某些自动化目的，因此我个人有兴趣尽我所能提供帮助，并确保我们最终得到可靠的东西。 我认为实现这一目标的方法是将 UI 代码/逻辑与后端分开，以便可以在不影响另一个的情况下修改其中一个。然后人们可以在后端（控制器通信、CAM 模块、成本估算）上构建，而无需提取整个 UI 代码。 相同的逻辑可以单独应用于每个组件。例如，应该可以使用“可视化器 UI 组件”在独立网页的网格上可视化呈现的 SVG，而无需引入整个停靠代码。 无论如何只是一些想法，希望是有道理的，在这里迟到了? |
.png "ES2015 与 ES5 #2"){kind=avatar}
|
我喜欢为 LW4 改用 ES2015 的想法。我查看了 LW3 的贡献者列表，只有 11 名贡献者，其中 249/322 次提交来自@openhardwarecoza和@lautr3k。在我看来，LW3 代码库受到旧 JS 结构的影响比它从大量贡献者那里得到的好处更多。我认为如果主要开发人员想在 ES2015 中工作，那将比其他任何东西都对项目产生更多的发展。 因为不太了解，所以查了一下ES2015。事实证明，ECMAscript 委员会将采用年度模型，因此无论如何都会更频繁地对语言进行更改。 我发现此页面按功能列出了 ES2015 的浏览器兼容性： http://kangax.github.io/compat-table/es6/ 大型浏览器和 Node 6 具有 92%+ 的功能集兼容性。这对我来说很好看。 |
.jpg "ES2015 与 ES5 #2"){kind=avatar}
|
有趣的对话 从反馈中我得到大多数认真的开发人员实际上对我的业余代码感到震惊 So a switch to something better is fine with me. |
抱歉，我上周一直处于离线状态
我打开这个问题是为了继续LaserWeb/deprecated-LaserWeb3#97的讨论。
由于我们正在启动 LaserWeb 的新版本，我觉得我们讨论一些选项很重要，这样我们就不会在将来再次重写部分代码。
因此，在某些情况下，ES2015 是已发布的新版本 JS，并开始支持我的主要浏览器。它与以前的 JS 相比带来了一些重大变化，我发现对于编写复杂应用程序更重要的是模块和类。我认为 LaserWeb 代码库将从使用新的模块系统中受益匪浅。它基本上允许每个文件声明并显式导入其依赖项，这使得代码更容易推理。
我建议我们采用这个标准。它已经 1 岁了，所以它不像刚刚发布的那样。虽然它现在不是最受支持的标准，但一旦人们开始升级到更新的浏览器版本，它将在几个月后得到支持。在这种情况发生之前，我们可以使用像 Babel 这样的 ES6 到 ES5 JS 编译器。它生成适用于所有浏览器的代码。
@arthurwolf提出了它将赶走贡献者的观点。由于更简洁的架构和语法，除了前端 JS 之外，习惯于几乎所有其他编程语言的人都会有宾至如归的感觉，而且由于代码更容易推理，人们会更快地理解代码并做出更多贡献。此外，大多数 JS 开发人员已经习惯了 Node.js 的导出/导入模式。
除了模块，类也会有所帮助。@lautr3k 提议的模型无论如何都在后台使用类继承，但它没有在代码中明确指定，而是使用 jQuery 辅助方法。这不是最容易理解的模型，我不得不多次查阅 jQuery 文档以了解它的真正作用。
我已经将转换的第一个版本推送到 es6 分支：https ://github.com/openhardwarecoza/LaserWeb4/tree/es6
@lautr3k 我必须对你的架构做的唯一真正的改变是摆脱对
lw.get_module来自码头代码的依赖，并将其替换为发布/订阅模式。这样，停靠代码就不会直接依赖于其父级，而是相反。让我知道你们的想法。如果你仍然觉得 ES5 是可行的方法，那么我将去掉这个分支，但如果你同意这是面向未来的 LaserWeb 代码的最佳方法，那么我们可以决定从 ES6 生成 ES5 的最佳方法，使它是对开发影响最小的方式。
顺便说一下，我已经很多年没有编写 JS 代码了，所以我可能搞砸了一些东西。