30 December 2020
I really like Jetpack Compose. Between work and personal stuff I have three projects which are each built on top of it. It’s great!
So far my biggest problem is its name… but that requires some explaining. Welcome to one of the hills I’ll die on!
2020年12月30日
我真的很喜欢 Jetpack Compose。在工作和个人项目之间，我有三个项目是基于它构建的。它很棒！
到目前为止，我最大的问题是它的名字……但是这需要一些解释。欢迎来到我愿意为之奋斗的一个观点！
What is Jetpack Compose? If you’re already familiar with it, something should pop in your head when asked: What is Jetpack Compose?
A new UI toolkit for Android? Yep, that’s right. A declarative Android UI framework? Sure, that is correct. A multiplatform application UI? Thanks to JetBrains this is also true.
什么是 Jetpack Compose？ 如果你已经熟悉它，当被问到“什么是 Jetpack Compose？”时，你应该会想到一些东西：
一个新的 Android UI 工具包？是的，没错。一个声明式的 Android UI 框架？当然，这是正确的。一个多平台应用程序 UI？感谢 JetBrains，这也是正确的。
If you’re somewhat in tune to how the sausage is made you may also reference the fact that it’s a Kotlin compiler plugin and DSL to build Android UI or multiplatform UI. It’s those things, too.
None of these answers are wrong. However, they’re doing a bit of a disservice to the internals of Compose and its unrealized potential.
如果你对它的工作原理有所了解，你可能还会提到它是一个 Kotlin 编译器插件和 DSL，用于构建 Android UI 或多平台 UI。它也是这些东西。
这些答案都没有错。然而，它们对 Compose 的内部工作原理和未实现的潜力有些低估。
Pedigree
What we now know as Jetpack Compose started as two separate projects: The first was a solution for writing declarative Android UIs using the existing platform UI toolkit. Take the declarative components of React, wrap it in an ahead-of-time compiler like Svelte, and target Android’s UI toolkit with Kotlin. All existing View-based UI could suddenly level-up by changing their programming paradigm from imperative to declarative.
Separately, the toolkit team was about to ramp up on unbundling as many UI widgets as possible from the OS. This followed on the success of ViewPager, RecyclerView, and what was learned from the AppCompat and Design libraries. By removing a ton of OEM touchpoints and normalizing behavior across all versions of Android, the work required to build a good UI would be reduced.
Over time these efforts became inescapably linked.
背景
我们现在称之为 Jetpack Compose 最初是两个独立的项目：
第一个是使用现有平台 UI 工具包编写声明式 Android UI 的解决方案。将 React 的声明式组件包裹在一个类似 Svelte 的提前编译器中，并使用 Kotlin 作为目标 Android 的 UI 工具包。所有现有的基于视图的 UI 突然可以通过将编程范式从命令式改为声明式而升级。
与此同时，工具包团队正在准备将尽可能多的 UI 小部件从操作系统中解耦。这是基于 ViewPager、RecyclerView 的成功以及从 AppCompat 和 Design 库中学到的经验。通过减少大量的 OEM 接触点并在所有版本的 Android 上规范行为，构建一个好的 UI 所需的工作量会减少。
随着时间的推移，这些努力变得不可避免地联系在一起。
If you are building standalone versions of the platform UI widgets then why not take the opportunity to correct mistakes in their API and overcome limitations of the resource system? And if you’re changing their API, why not have the new declarative system target only these unbundled widgets? Each project only empowered the other as they spiraled closer together.
In hindsight, it seems inevitable they would become a single effort. Being a single effort does not necessarily mean tight coupling, however.
如果你正在构建平台 UI 小部件的独立版本，那么为什么不借此机会纠正它们的 API 中的错误并克服资源系统的限制呢？如果你正在更改它们的 API，为什么不让新的声明式系统仅针对这些解耦的小部件呢？每个项目都在彼此的螺旋中相互赋能。
事后看来，它们成为一个单一的努力似乎是不可避免的。然而，成为一个单一的努力并不一定意味着紧密耦合。
Layering
Each of my three projects built on Compose do not use the new Compose UI toolkit. That can be a confusing statement even to those who have done a lot of Compose work. Didn’t we just call them inescapably linked? Didn’t we define it earlier as a UI toolkit?
While Compose became a single effort started from two projects, a layering and responsibility split similar to those original projects still exists. In fact, that separation has only become more defined.
What this means is that Compose is, at its core, a general-purpose tool for managing a tree of nodes of any type. Well a “tree of nodes” describes just about anything, and as a result Compose can target just about anything.
分层
我基于 Compose 构建的三个项目中没有使用新的 Compose UI 工具包。即使对那些做了很多 Compose 工作的人来说，这也是一个令人困惑的声明。我们不是刚刚称它们为不可避免的联系吗？我们不是早先定义它为一个 UI 工具包吗？
尽管 Compose 从两个项目开始成为一个单一的努力，但类似于那些原始项目的分层和责任分配仍然存在。事实上，这种分离变得更加明确。
这意味着 Compose 在其核心是一个用于管理任何类型节点树的通用工具。嗯，“节点树”几乎描述了任何东西，因此 Compose 可以几乎针对任何东西。
Those tree nodes could be the new Compose UI toolkit internals. But it could just as easily be the old View nodes inside a ViewGroup tree, it could be a RemoteView and the various remote views within its tree, or a notification and the content inside it.
The nodes don’t have to be UI related at all. The tree could exist at the presenter layer as view state objects, at the data layer as model objects, or simply be a value tree of pure data.
Compose doesn’t care! This is the part I really like. This is the part that’s great.
这些节点树可以是新的 Compose UI 工具包的内部。但它也可以很容易地是旧的视图节点在 ViewGroup 树内，它可以是 RemoteView 及其树内的各种远程视图，或者是通知及其内部的内容。
这些节点不必与 UI 相关。树可以存在于表示层作为视图状态对象，在数据层作为模型对象，或者仅仅是一个纯数据的值树。
Compose 并不关心！这是我真正喜欢的部分。这是很棒的部分。
Separately, however, Compose is also a new UI toolkit and DSL which renders applications on Android and Desktop. This part of Compose is built on top of the aforementioned core as a tree of nodes which happen to be able to render themselves to a canvas.
The two parts are called the Compose compiler/runtime and Compose UI, respectively.
This separation of concerns is very welcome. Conflating both under the name of Compose, in my opinion, is not welcome.
然而，Compose 也是一个新的 UI 工具包和 DSL，它在 Android 和桌面上渲染应用程序。Compose 的这部分是基于前述核心之上的一个树节点，它们恰好可以将自己渲染到画布上。
这两部分分别称为 Compose 编译器/运行时和 Compose UI。
这种关注点的分离是非常受欢迎的。在我看来，将这两者都称为 Compose 是不受欢迎的。
Naming
Adjusting the naming here would address two problems: specificity and pigeonholing.
Placing a general-purpose compiler and runtime with a specific UI toolkit implementation under an umbrella name means discussions about them are imprecise by nature. This post started by saying that I’m working on three projects built on Compose… did you think I meant Compose UI? You almost certainly did.
命名
在这里调整命名可以解决两个问题：特异性和限制性。
将一个通用编译器和运行时与一个特定的 UI 工具包实现放在一个伞式名称下，意味着关于它们的讨论本质上是不精确的。这篇文章一开始就说我在做三个基于 Compose 的项目……你是不是以为我是指 Compose UI？你几乎肯定是这样认为的。
The Compose name is more akin to Jetpack than it is AppCompat. We don’t treat it like that, and there are no signs of Google correcting our perception. So now I must endlessly clarify that I’m working on three projects built on the Compose compiler/runtime which do not use the Compose UI toolkit and oh, by the way, yes, those are separate things.
Maybe you don’t think this is a good enough reason to have two names. After all, how many people are going to build something on just the compiler and runtime?
Yet that is all the more reason to rename it! You’ve just pigeonholed the project to not be anything more than what it already is–a cool technology on which Compose UI is built. The possible applications of the general-purpose Compose compiler/runtime are widespread and should be encouraged. Right now it feels like Google buried the lede.
Compose 的名称更类似于 Jetpack，而不是 AppCompat。我们并没有这样对待它，也没有任何迹象表明 Google 会纠正我们的看法。所以现在我必须不断澄清我正在做的三个项目是基于 Compose 编译器/运行时的，而不是使用 Compose UI 工具包，哦，顺便说一下，是的，它们是分开的东西。
也许你认为这还不足以有两个名字。毕竟，有多少人会只构建在编译器和运行时之上呢？
然而，这正是更应该重命名的原因！你刚刚将这个项目限制在它已经是的东西上——一个很酷的技术，Compose UI 就是基于它构建的。Compose 编译器/运行时的可能应用范围广泛，应该受到鼓励。现在感觉 Google 掩盖了重点。
A separate name is an easy way to draw attention to the great work which is the compiler and runtime of Compose. There’s been the rare tweet about it, the casual mention in a talk, and the occasional blog post showcasing a different use, but aside from that there’s not much breathing room. The excitement around Compose UI (which is also much deserved) drowns it out.
Compose compiler/runtime supports more platforms and targets than Compose UI. In addition to Android I’ve run Compose-based projects on the JVM (in a server, not on desktop) and limped one along in a non-browser JS engine. These are places where Compose UI is impossible, but Compose is not!
I’m excited for these three projects of mine to make their way into open source to showcase what the Compose compiler and runtime can do on their own. I am not excited about having to continually clarify that the Compose compiler/runtime duo are not related to Compose UI or to Android.
一个单独的名字是引起注意的简单方法，引起注意的是 Compose 的编译器和运行时的出色工作。有少量的推文提到它，在演讲中偶尔提到，在博客文章中展示了不同的用法，但除此之外没有太多的喘息空间。对 Compose UI 的兴奋（也是非常应得的）淹没了它。
Compose compiler/runtime 支持比 Compose UI 更多的平台和目标。除了 Android，我还在 JVM 上运行过基于 Compose 的项目（在服务器上，而不是在桌面上），并在非浏览器的 JS 引擎中勉强运行过。这些地方 Compose UI 是不可能的，但 Compose 是可能的！
我很兴奋能将我的这三个项目开源，展示 Compose 编译器和运行时本身能做什么。我不兴奋的是必须不断澄清 Compose 编译器/运行时与 Compose UI 或 Android 无关。
Crane
The internal codename for the new UI toolkit was “crane”. Before it was public I voiced support of retaining that name. After Compose was public I voiced support of using two names and using “crane” for Compose UI. But messages in chat rooms are easy to ignore–even if some agreed.
Unfortunately, much time has passed, and the tea leaves are showing that Compose is about to enter beta. It’s too late to make this naming change for Compose UI. No one even calls it Compose UI. It’s always been just Compose.
So this blog post is a hail-mary plea to Google: please rename the compiler and runtime to something else!
Crane
新的 UI 工具包的内部代号是“crane”。在它公开之前，我支持保留这个名字。在 Compose 公开之后，我支持使用两个名字，并使用“crane”作为 Compose UI 的名字。但聊天室里的消息很容易被忽略——即使有些人同意。
不幸的是，时间已经过去了很多，迹象表明 Compose 即将进入测试版。为 Compose UI 进行这种命名更改已经太晚了。没有人甚至称它为 Compose UI。它一直只是 Compose。
所以这篇博文是对 Google 的最后一搏：请将编译器和运行时重命名为其他名字！
Compose is such a bland name anyway. Name it Evergreen (like the trees). Name it Juliet (who wrote the blog title). Hell, name it Crane (for maximum internal confusion). Give it the different name that it deserves so it can stand on its own.
But please, don’t relegate this amazing, general-purpose, multiplatform compiler and runtime to live behind the blanket nomenclature that is just Compose!
Compose 这个名字太平淡了。把它命名为 Evergreen（像树一样）。把它命名为 Juliet（写这篇博文标题的人）。天呐，把它命名为 Crane（最大程度的内部混乱）。给它一个应得的不同名字，让它可以独立存在。
但请不要将这个惊人的、通用的、多平台编译器和运行时局限于一个叫 Compose 的笼统名称之下！
作者 | Jake Wharton 原文地址 | jakewharton.com/a-jetpack-c…
