@Belinda
2015-05-04T07:19:04.000000Z
字数 11432
阅读 1442
英文翻译
好吧，看别人的东西消化真的很慢，如果希望能有所收获，还是自己去有所输出。
原文来自 facebook
作者： Tom Occhino
If you're new to React, you can read more about it on the React website. You can also get started with React Native for iOS, which was released at F8 2015 on the React Native website.
如果你是react的初学者，你可以在react的官网上去学习更多的内容。你也可以从react native开始入手，学习开发ios，react native在将在2015年的3月8号在官网上发布。
We introduced React to the world two years ago, and since then it's seen impressive growth, both inside and outside of Facebook。
两年前，我们已经向世界介绍过 react了。从那以后，react 以迅雷不及掩耳之势茁壮成长起来。无论是在 facebook 团队还是其他的地方。
Today, even though no one is forced to use it, new web projects at Facebook are commonly built using React in one form or another, and it's being broadly adopted across the industry.
在今天，即使没有人被迫去使用react，使用react 技术的新的 web 项目，如雨后春笋般，一个接一个的出现在facebook中的。react 在行业中也被广泛的采用。
Engineers are choosing to use React every day because it enables them to spend more time focusing on their products and less time fighting with their framework.
很多开发人员之所以选择 react ，是因为 react 能能让他们花最少在开发框架上，从集中精力去做他们的产品。
It wasn't until we'd been building with React for a while, though, that we started to understand what makes it so powerful.
还没等我们把 react 建立完善，我们开始去思考到底是什么让 react 有这么大的影响力。
React forces us to break our applications down into discrete components, each representing a single view
React 迫使我们去把应用拆分成一些独立的组件，每个组件代表一个视图。
These components make it easier to iterate on our products, since we don't need to keep the entire system in our head in order to make changes to one part of it.
这些组件，让我们的产品迭代变得更加容易。因为，我们不需要为了更改系统的某一块内容，而把整个系统记在我们的脑袋瓜里。
More important, though, React wraps the DOM's mutative, imperative API with a declarative one, which raises the level of abstraction and simplifies the programming model.
更重要的是，虽然 React 包含了 DOM 结点的变化，为了提升编程模型的抽象和简化程度,声明一个统一的 API 是很有必要的。
What we've found is that when we build with React, our code is a lot more predictable.
我们发现，使用 React 会使我们的代码更加具有可预测性。
This predictability makes it so we can iterate more quickly with confidence, and our applications are a lot more reliable as a result. Additionally, it's not only easier to scale our applications when they're built with React, but we've found it's also easier to scale the size of our teams themselves.
正式这些可预测性，我们能够更加快速更加自信的迭代我们的产品，也使得我们的产品更加可靠。另外，这些可预测性不仅让我们更容易的去调整我们的应用的规模，同时也使我们控制开发团队规模变得容易。
Together with the rapid iteration cycle of the web, we've been able to build some awesome products with React, including many components of Facebook.com.
加上 web 的快速迭代周期，我们已经能够用 React 去建立一些酷炫的产品，包括在 facebook 上很多漂亮的组件。
Additionally, we've built amazing frameworks in JavaScript on top of React, like Relay, which allows us to greatly simplify our data fetching at scale.
此外，我们用 javascript 和 React来构建亚马逊框架，并把javascript用在 React 上面。就像 Relay 一样，这样可以让我们最大的程度地简化我们的数据，并取得极大的规模。
Of course, web is only part of the story. Facebook also has widely used Android and iOS apps, which are built on top of disjointed, proprietary technology stacks.
当然，web 仅仅是我们的一部分。facebook 也广泛的应用于安卓好 ios 的app，这些app是建立在脱节的专有的技术堆栈的基础上的。
Having to build our apps on top of multiple platforms has bifurcated our engineering organization, but that's only one of the things that makes native mobile application development hard.
只有一件事让 native app 那就是开发变得困难。那就是应用需要兼容多平台，这可难坏了我们的开发团队。
Why native is difficult
There are many reasons the native mobile environment is more difficult to work with than the web. For one thing, it's harder to lay things out on the screen, and we often have to manually compute the size and position of all our views.
本地移动环境比 web 难有很多的原因，期中之一，就是难以把元素布局到屏幕上，通常需要我们手工去计算我们视图的尺寸和定位。
We also don't have access to React or Relay, which have made it easier to scale the process of developing websites and growing our engineering organization.
我们不需要十分深入 React 或则 Relay ，就能使得控制网站 开发的进程和发展我们的开发团队的规模变得更加简单。
One of the most painful things about our transition to mobile, though, is how much it's slowed down our development velocity.When building on the web, we can simply save our files and reload the browser to see the result of our changes.
最痛苦的事情之一就是我们向移动端的过渡。虽然他会很大程度上降低我们的开发速度。当我们在 web 上建立应用时，我们很简单的保存我们的文件，再重新登录浏览器去查看结果的变化。
On native, however, we need to recompile after every change, even if we just want to shift text a few pixels over on the screen.
然而，在本地，在每一次改变后，我们都需要重新编译。即使是我们仅仅想移动屏幕上的文本的一点点像素。
As a result, engineers end up working a lot more slowly, especially in a large codebase where compilation is especially burdensome. Building on native also makes testing new functionality more difficult. At Facebook, we deliver a new version of the website twice a day, so we can get the results of an experiment back almost immediately. On mobile, we often need to wait weeks or months in order to get the results of an experiment or A/B test back, because new versions of our app are released far less often. “Move fast” is in Facebook's DNA, but we can't move as fast on mobile as we can on the web. So why make the switch away from web in the first place?
The reason we build native apps on these proprietary platforms is that right now, we can create better-feeling experiences that are more consistent with the rest of the platform than we can on the web.
Why native is necessary
Even though developing native mobile apps takes longer, there are many reasons why we can produce better experiences on the mobile platforms than we can on the web. For one thing, we have access to platform-specific UI components, like maps, date pickers, switches, and navigation stacks. It's possible to reimplement these components on the web, but our reimplementations never feel exactly like their native counterparts, and they also don't get updated automatically with changes to the platform. We also don't have anything as sophisticated as the native mobile gesture recognizers on the web, and we don't yet have the proper tooling or the developer discipline needed to build a system that gets this right.
On the web, we also don't have a sophisticated threading model, so we can't parallelize work onto multiple threads. We can try to make use of web workers to execute some of our application logic in the background, but we can't yet perform highly numeric computation like image decoding or text measurement efficiently off the main thread in the browser. This is probably one of the biggest challenges of building high-performance and responsive web apps.
Best of both worlds?
What we really want is the user experience of the native mobile platforms, combined with the developer experience we have when building with React on the web. There are a few ways we can probably achieve this:
Using WebViews
One possibility is to use WebViews inside simple native wrapper applications. We tried this a few years back, and we actually think it's a great idea. While our implementation didn't give us the performance and scaling we wanted, this approach is remarkably flexible and comes with all the positives associated with the developer experience of the web, like the ability to take full advantage of React and the web's rapid iteration cycle. Unfortunately, because all the rendering is done using web tech, we can't produce a truly native user experience.
Porting React to native
Porting React to native code is also a great idea, and in fact, we built this for iOS! This project is called ComponentKit, and we just open sourced it yesterday at F8. With ComponentKit, we get all the benefits of React, especially declarative, predictable UIs, but we can also take advantage of the power of the native environment, with platform-specific components and sophisticated gesture handling, as well as asynchronous image decoding, text measurement, and rendering. Additionally, since ComponentKit uses flexbox for layout, you don't need to manually position and size the views in your application, so your code ends up being more concise and easier to maintain.
There are a couple of minor downsides to this approach, though. First, it's iOS-only, so if we want to take advantage of it on Android, we'd have to build a separate implementation, and teach engineers how to use it. Additionally, we don't have access to any of the stuff we've built for the web on top of React, like Relay, which helps us solve real problems we've faced scaling our data fetching. Most important, though, is that we haven't fundamentally improved our developer velocity challenge — we still need to recompile after every change.
Scripting native
If we use JavaScript to call into native APIs, we should have access to all the power of the native environment but should also be able to iterate quickly and take advantage of some of our existing JavaScript infrastructure. Additionally, since it's just JavaScript, we could probably make this stack work across platforms. It sounds like everything we want, and it's no surprise that there are tons of frameworks out there doing this. But it's actually not quite so straightforward.
Scripting native is tricky
If we just synchronously call back and forth between the native environment and an interpreted environment, our UI thread could end up being blocked on JavaScript execution. To make this efficient, we know we want to execute our JavaScript off the main thread, but doing so is hard. The first reason it's hard is resource contention. If our JavaScript code accesses something that might represent a resource on another thread — the dimensions of a rendered view, for example — the system has to lock, which can cause stalls in the UI. The second reason this is tough is that there's some fixed amount of overhead associated with every round trip between the native environment and the JavaScript virtual machine. If we need to cross the thread boundary often, we'll have to incur this overhead over and over again.
So if we don't do this correctly, our app could end up feeling worse than if it were written entirely in either native code or in JavaScript. We can't just reimplement synchronous, imperative user interface APIs in JavaScript and expect to get a responsive, native-feeling experience. We need to fundamentally change the programming model and ensure that our system always passes messages across the thread boundary asynchronously and that we can batch up as many of these messages per frame as possible, minimizing cross-thread communication overhead.
Luckily, React gives us the perfect programming model to do this correctly.
Introducing React Native
Since React components are just pure, side-effect-free functions that return what our views look like at any point in time, we never need to read from our underlying rendered view implementation in order to write to it. In the browser environment, React is non-blocking with respect to the DOM, but the beauty of React is that it is abstract and not tightly coupled to the DOM. React can wrap any imperative view system, like UIKit on iOS, for example.
So this means with a bit of work, we can make it so the exact same React that's on GitHub can power truly native mobile applications. The only difference in the mobile environment is that instead of running React in the browser and rendering to divs and spans, we run it in an embedded instance of JavaScriptCore inside our apps and render to higher-level platform-specific components.
One of the best parts about this approach is that we can adopt it incrementally, building new products on top of it or converting old products to use it whenever and wherever it makes sense. Just as we didn't need to rewrite all of Facebook.com in order to start using React in some places, we don't need to rebuild our entire mobile Facebook applications in order to start realizing the benefits of React Native.
This is working
We've been using React Native in production at Facebook for some time now, and while there's still a ton of work to do, it's been working really well for us. It's worth noting that we're not chasing “write once, run anywhere.” Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach “learn once, write anywhere.”
If you have an iPhone, you can test out a few apps using React Native that are available from the App Store. Facebook Groups is a hybrid application, consisting of views built both with native code and React Native JavaScript, and Facebook Ads Manager is built entirely using React Native.
Open source
At Facebook, our mission is to make the world more open and connected, and we want to actively contribute to that mission via open source. React Native is no exception. We realize that the problems we face as an engineering organization are not unique to us, and accordingly, we want to develop in the open as much as possible, collaborating with others who are facing the same challenges.
Today, we're excited to open-source React Native for iOS and make it available on GitHub. Android support is coming soon, and we're also continuing full steam ahead on React for the web, but we wanted to get this initial iOS support out as early as possible so we can get input from others who are also excited about this approach. Keep in mind that there are probably many things that are either broken or not implemented yet. We welcome your feedback and contributions, and we can't wait to see what you'll build!