关于反馈的邮件_关于反馈

关于反馈的邮件

重点 (Top highlight)

Angular is an onion with the following layers:

Angular是具有以下几层的洋葱：

1. The core capabilities of the framework (e.g., renderer, compiler)
   框架的核心功能(例如，渲染器，编译器)
2. Core APIs (e.g., ng-if, ng-for, decorators, animations)
   核心API(例如ng-if，ng-for，装饰器，动画)
3. APIs for building applications (e.g., router, forms, state management)
   用于构建应用程序的API(例如，路由器，表单，状态管理)
4. Basic CLI capabilities
   基本的CLI功能
5. CLI Plugins (karma, protractor, webpack, tslint)
   CLI插件(业力，量角器，Webpack，tslint)

Layer 1 is the most technically challenging, but, at the same time, you only need one good implementation of this stuff, and it will work reasonably well for most applications. This layer is also really well-defined. You can even benchmark your implementation to see how good it is. Someone who understands browser internals and compilers is the best person to work on this.

第1层在技术上是最具挑战性的，但是与此同时，您只需要对这些内容进行一个良好的实现，它将对大多数应用程序相当有效。 此层也确实定义明确。 您甚至可以对您的实现进行基准测试，以查看其效果如何。 了解浏览器内部和编译器的人是从事此工作的最佳人选。

Layer 2 is somewhat similar. The API is narrow, which means that one well-written ng-if is good enough for everyone, and getting feedback from just a couple of teams is sufficient to design it well.

第2层有些相似。 API狭窄，这意味着一个编写良好的ng-if对每个人都足够了，仅从几个团队获得反馈就可以很好地进行设计。

Layer 3 is where things change. Routers, forms, and state management libraries have much broader APIs. As a result, there will always be multiple incompatible implementations (e.g., Apollo and NgRx). Technically, this layer isn’t as challenging as Layers 1 and 2, but it’s harder here to get the API and the dev experience right. You need a lot of feedback. Feedback from developers working at different organizations, building different apps. The more the better.

第三层是变化的地方。 路由器，表单和状态管理库具有更广泛的API。 结果，将始终存在多个不兼容的实现(例如，Apollo和NgRx)。 从技术上讲，该层并不像第1层和第2层那样具有挑战性，但是在这里很难获得正确的API和开发经验。 您需要很多反馈。 来自不同组织，构建不同应用程序的开发人员的反馈。 越多越好。

…

…

关于反馈 (On Feedback)

While on the Angular team, I found working on Layers 1 and 2 straightforward. I knew what needed to be done, and I could rely on the feedback from other teams at Google. If something didn’t work, they would let me know. If something was slow, I’d hear about it.

在Angular团队中，我发现第1层和第2层的工作很简单。 我知道需要做什么，我可以依靠Google其他团队的反馈。 如果某事不起作用，他们会让我知道。 如果事情很慢，我会听说的。

Layer 3 is a different story. Many, but of course not all, Google engineers have little or no experience outside of Google. They are also very intelligent. The problem with intelligent people with little experience is that they can make anything work, no matter how convoluted that thing is. This is bad feedback because it’s hard to gauge how well the API solves real problems.

第三层则不同。 许多(当然不是全部)Google工程师在Google之外几乎没有经验。 他们也很聪明。 缺乏经验的聪明人的问题在于，无论事情多么复杂，他们都可以使任何事情起作用。 这是不好的反馈，因为很难评估API解决实际问题的程度。

It was even tougher for the Angular CLI team. Given that it is not used at Google, it’s almost surprising how great it ended up being. And, in my opinion, it’s due to a very strong eng team consisting of Googlers (in particular Hans Larsen) and external contributors. But there are no miracles. Once you start using the CLI on large projects, you see right away that some use cases don’t work well (e.g., large projects cannot update from one version of Angular to another in a single go. Using peer dependencies for deciding what needs to be updated doesn’t work well, etc..)

对于Angular CLI团队而言，这更加艰难。 鉴于它没有在Google上使用，因此其出色的表现令人惊讶。 在我看来，这归功于由Google员工(尤其是汉斯·拉尔森)和外部贡献者组成的强大的英语团队。 但是没有奇迹。 在大型项目上开始使用CLI后，您会立即发现某些用例无法正常工作(例如，大型项目无法一次将Angular的一个版本更新为另一个版本。使用对等依赖项来决定需要做什么不能很好地进行更新等。)

What about GitHub issues? GitHub issues are useful for bug reports, but not for assessing dev experience. To know how something feels, you actually need to use it, and use it a lot.

GitHub问题呢？ GitHub问题对于错误报告很有用，但对于评估开发人员经验却无济于事。 要知道某种感觉，您实际上需要使用它，并经常使用它。

Same story for CLI plugins. As a plugin author, you cannot assess, say, testing tools unless you are using them on real projects with a lot of different teams at different companies.

CLI插件的情况与此相同。 作为插件作者，除非您在具有不同公司的许多不同团队的真实项目中使用测试工具，否则您无法评估测试工具。

This situation isn’t unique to Angular or Google. In all large companies I know infrastructure/tooling teams don’t spend much time building applications. And for Layers 1 and 2 this is actually the best arrangement. Let me explain why.

这种情况并非Angular或Google独有。 我知道在所有大型公司中，基础架构/工具团队都不会花费很多时间来构建应用程序。 对于第1层和第2层，这实际上是最好的安排。 让我解释一下原因。

角度很重要 (Angular is Many Things)

Angular is many things, and some of them are easier for the team at Google to get right. The team is very good at Layers 1 and 2 because the team gets sufficient feedback, and the team has a lot of expertise in this stuff. No one else can do it but them.

Angular有很多事情，其中​​一些事情对于Google团队来说更容易解决。 该团队非常擅长第1层和第2层，因为该团队获得了足够的反馈，并且该团队在这方面有很多专业知识。 除了他们，没有其他人可以做到。

To get APIs for building applications (Layer 3) right you actually need to spend most of your time building applications. There is no other way. This isn’t a question of staffing or getting the best people etc. Unless you are in the trenches, you won’t get enough feedback, you won’t feel the dev experience.

要正确获取用于构建应用程序的API(第3层)，您实际上需要花费大部分时间来构建应用程序。 没有别的办法了。 这不是人员配备或获得最佳人才等问题。除非您处于战the之中，否则您将无法获得足够的反馈，也不会感到开发经验。

That’s why Apollo and NgRx are so robust. They are built by people in the trenches. And that’s why you should look at the angular-routing library by Brandon Roberts, who is a fellow Nrwlian btw.

这就是为什么Apollo和NgRx如此强大。 他们是由人们在战es中建造的。 这就是为什么您应该看一下Nrwlian好友Brandon Roberts编写的角度路由库的原因。

This cannot be solved by writing more design docs or soliciting more feedback. The Angular community will always be better at this because the community consists of people building applications.

这不能通过编写更多的设计文档或寻求更多的反馈来解决。 Angular社区将永远在这方面做得更好，因为该社区由构建应用程序的人员组成。

Finally, the CLI and its plugins. Karma, Protractor, TSLint are widely used inside and outside of Google. They have to be supported. No questions about it. The decision to keep them in the CLI is probably the right decision. At the same time, TSLint is deprecated. Karma and Protractor feel antiquated. But I don’t think it’s fair for us to expect the Angular team to provide CLI plugins for all popular testing and linting tools. No other framework team does it.

最后，CLI及其插件。 业力，量角器和TSLint在Google内部和外部均得到广泛使用。 他们必须得到支持。 没问题。 将它们保留在CLI中的决定可能是正确的决定。 同时，不推荐使用TSLint。 业力和量角器过时了。 但是我认为让Angular团队为所有流行的测试和整理工具提供CLI插件对我们来说是不公平的。 没有其他框架团队会这样做。

多元化 (Pluralism)

The Angular team is very good at building frameworks (Layers 1 and 2). We, the Angular community, are good at building applications. So when it comes to APIs for building applications or CLI plugins, we are actually better positioned to get things right. We have the right expertise, and we should use it.

Angular团队非常擅长构建框架(第1层和第2层)。 我们，Angular社区，擅长构建应用程序。 因此，当涉及到用于构建应用程序或CLI插件的API时，实际上我们可以更好地解决问题。 我们拥有正确的专业知识，应该使用它。

When we need to change the compiler, we have no choice but to wait for the team at Google to do it. But when it comes to changing, say, the forms, we could just do it ourselves. It’s OK to have a different take on forms. And if at one point, some ideas from the new implementation make their way into the Angular repo, that’s even better.

当我们需要更改编译器时，我们别无选择，只能等待Google团队来做。 但是，当涉及到更改形式时，我们可以自己完成。 可以采用其他形式的表单。 而且，如果有一次，新实现中的一些想法进入了Angular仓库，那就更好了。

Pluralism is good.

多元化是好的。

Remember, everything in the Angular repo has to basically work for everyone, and the changes have to made in the backwards-compatible way. These are the tough constraints the Angular team works within. (For instance, the Forms API is a bit clunky because it had to work with and without Observables, and be familiar for AngularJS users.)

请记住，Angular存储库中的所有内容都必须对所有人都适用，并且更改必须以向后兼容的方式进行。 这些是Angular团队所处的严峻约束。 (例如，Forms API有点笨拙，因为它必须使用和不使用Observables，并且必须对AngularJS用户熟悉。)

A community project doesn’t have to work for everyone, it doesn’t to be backwards compatible. It’s a much better place for experimentation.

社区项目不必为每个人工作，也不必向后兼容。 这是一个更好的实验场所。

对CLI的不同理解 (Different Take on CLI)

We at Nrwl have been doing this for three years — we have our own take on the CLI. If you want to use modern testing and linting tools, run: npx create-nx-workspace --preset=angular to get an Angular CLI-powered Nx workspace with:

我们在Nrwl从事这项工作已经三年了-我们对CLI有自己的看法。 如果要使用现代的测试和整理工具，请运行： npx create-nx-workspace --preset=angular以使用以下命令由Angular CLI驱动的Nx工作区：

• Jest instead of Karma
  开玩笑而不是业力
• Cypress instead of Protractor
  赛普拉斯代替量角器
• ESLint instead of TSLint
  ESLint代替TSLint
• “Fixed” ng update
  “固定”更新
• Built-in support for NgRx
  对NgRx的内置支持
• And many other cool things
  还有很多其他很棒的东西

It’s still Angular, just with a different, perhaps more modern set of tools around it.

它仍然是Angular，只是周围有一套不同的，也许是更现代的工具。

呼吁采取行动 (Call to Action)

In the Angular community we expect the Angular team to provide us with pretty much everything we need to build applications. This is too much of an ask. This isn’t even a question of the team’s resources or skill (the Angular team is very capable) — I don’t think this is desirable. Successful software ecosystems rely on the community to do most of the heavy lifting.

在Angular社区中，我们希望Angular团队能够为我们提供构建应用程序所需的几乎所有东西。 这是一个太多的问题。 这甚至不是团队资源或技能的问题(Angular团队非常有能力)—我认为这不是可取的。 成功的软件生态系统依靠社区来完成大部分繁重的工作。

The Angular team is giving us stable and expressive primitives. We can use those to build amazing things like Nx, Scully, NgRx, etc… Let’s fill in the gaps we see, let’s innovate, and by doing so we will help the Angular community and the Angular team.

Angular团队正在为我们提供稳定且富有表现力的图元。 我们可以使用它们来构建Nx，Scully，NgRx等令人惊奇的东西……让我们填补我们所看到的空白，让我们进行创新，从而为Angular社区和Angular团队提供帮助。

翻译自: https://blog.nrwl.io/angular-is-an-onion-63f4cd1ece6

关于反馈的邮件