[译]Mantra核心概念—对通用应用说不

第一次翻译,如有不妥之处,请斧正。

原文链接 Say No to Universal Apps
原作者:Arunoda Susiripala
译:Godi13

If you build modern apps (especially in Meteor), you’ve probably heard of universal apps. In this article, I suggest that you **stop **building universal apps. Don’t panic. Read to the end. You will see why!

如果你正在开发最新的APP(尤其是使用Meteor),你很可能已经听说了通用应用。 但在这边文章中,我建议你停止开发通用应用。 不要慌,读到最后,你就知道为什么了!

Edit: Earlier, I titled this post as “Say No to Isomorphic Apps”. But with the comments I got, it seems like Universal is a better word instead of Isomorphic in this context. So, I renamed it.

编辑:先前,我将此贴命名为『对同构应用说不』。但看到评论我意识到,用『通用』替代『同构』看上去更合适。所以,我重命名了。

What’s an universal app?

什么是通用应用?

In theory, an universal app is an app that you write once and it can be used everywhere, including the web and on iOS and Android devices.
With Meteor, this became trivial.

理论上,通用应用是那种你写一次就可以用到所有地方的应用,包括web、iOS、Android三端。随着Meteor出现,这变得没那么重要了。


Before we dive into our main topic, let’s see what will happen in the web and mobile ecosystem in the future.

在我们进入正题前,让我们看看web和移动设备生态圈在未来会发生什么。

  • The web will become super charged and it’ll get a lot of new features. Mobile web performance will increase a lot.
  • Mobile user penetration will rise as usual.
  • Web usage won’t die, but usage will be reduced.
  • iOS and Android will get more native features and apps will utilize them (for example, iOS Force Touch).
  • web会变得非常强大并且获得许多新的特性。移动web性能会大幅提升。
  • 移动用户普及率会像往常一样增加。
  • web不会消失但使用量会减少。
  • iOS和Android端将得到更多的原生特性并且apps会应用它们(例如,iOS的Force Touch)。

Okay, now let’s talk about why it’s a bad to have isomorphic apps.
好的,现在让我们开始谈论为什么说使用同构应用是不好的。(这里的同构应用应该指的是通用应用,译者注)

It’s all about the user experience

全都是关于用户体验

When building an app, you need to create a great user experience, which is hard. We always need to use platform-specific functionalities and we must consider the user expectations for each type of platform.

在开发一个应用时,你需要创建良好的用户体验,这很难。我们总是需要用到特定于平台的功能,并且我们必须考虑基于不同类型的平台的用户体验。

For example, iOS does not have a built-in back button but Android does. So, we need to design our apps taking that into account. This is just a single example, and there are many cases like this.

例如,iOS系统没有内置的后退按钮,但是安卓的有。所以,我们需要考虑到这种情况并设计到我们的应用中去。这只是一个例子,有其他很多类似的情况。

Although the web is getting better and better every day, it won’t be able to beat native mobile apps in performance and user experience. So, an isomorphic app **does not **add a considerable amount of value to your product.

虽然web端每天都在变好,但是在性能和用户体验两个方面它还不能够与原生移动应用相抗衡。所以,一个同构应用不能为你的产品增加相当可观的价值。(这里的同构应用应该指的是通用应用,译者注)

For example, you can wrap a mobile web app as a Cordova app and publish it to a store. It’ll work for sure. But you will never be able to achieve an experience like that of a native app, no matter how hard you try.

例如,你可以将移动web app包装成Cordova app并发布到应用商店。确实可以这么做。但是你永远不能获得原生应用的体验,不管你付出多大的努力。

And in doing so, the user experience will be bad and users won’t use it often. They may even write bad reviews.

这么做的话,用户体验会变差并导致他们不会经常使用。他们甚至会写差评

"Okay, I get your point. But our team doesn’t have the resources to build native mobile apps."
『好吧,我知道你说的什么。但是我们的团队没有足够的资源去开发原生移动应用』

This is a valid point.
这是一个合理的问题。

The answer is: don’t build mobile apps. Instead, improve your app’s mobile web experience. You can do this by applying some style changes and thinking about where to put things.

答案就是:不要开发移动应用。你可以通过应用样式的改变和思考在哪里放东西,来提高你的应用的移动web体验。

Once you do so correctly, mobile users will use it. The point is, now they know they are using a web app, but not an app. So, they don’t look for an app-like experience. Instead they look it as a mobile web app.

一旦你做的正确,移动用户就会使用它。关键在于,现在他们知道他们在使用一个web app,而不是一个原生应用。所以,他们不会去寻求使用原生应用的体验,取而代之的是他们会把它看做是一个移动web app。

Because of this, you’ll have a lot of satisfied users, who will say things like:

正因为如此,你将获得大量满意的用户,他们将这样说:

Wow, this app works pretty awesomely in mobile. I love it.
哇,这个应用在手机里运行的真好。我喜欢。

One code base for all is a really bad idea

一份基本代码适配全部平台真是个坏主意

For isomorphic apps, we use a single code base targeting all these types of app.

对于同构应用,我们用单一的基本代码适配全部种类的应用。(这里的同构应用应该指的是通用应用,译者注)

This leads to a lot of hacks and a very hard to manage code base.

这将导致需要大量的hack技巧并难以管理基础代码。

For example, let’s say you need to use some native functionality that is available on only one type of platform. Since it’s not available on the other platforms, you shouldn’t use it. If you do decide to implement it just for that platform, you will need to do some hacks to enable it just for that platform.

例如,让我们假设你需要一些仅在一种平台有效的原生功能。既然它不在其他的平台上有效,你就不应该用它。如果你决定就要为那个平台使用它的话,你将需要使用一些hack技巧,确保它只为那个平台所使用。

This all leads to a monolithic code base that will be very hard to manage in the long run. The solution is to build multiple apps for different platforms like web, iOS and Android.

随着开发的进行,这都将导致一个巨大的难以管理的基础代码。解决方法就是为不同的平台开发多个应用,就像是web端,iOS和Android。

"Okay, this seems like a valid point too. But then, I need to duplicate the functionalities in all those apps."
『好吧,这看起来也是一个合理的问题。但是,我要去复制这些功能到所有那些apps中去』

Alright! This is where we are going to talk about isomorphic modules and concepts.

没问题!接下来我们正式要谈论同构模块和概念

You can use React Native to build apps for both iOS and Android, following some isomorphic concepts.You learn how to do so with React Native once, and then you build different apps for different platforms.

你可以使用React Native分别为iOS和Android开发,按照一些同构的概念进行。你学一次如何使用React Native,然后你为不同的平台开发不同的应用。

On the other hand, you can wrap up your app’s client-side validation into an NPM module. Then you can use it on each of these platforms.

另一方面,你可以打包你的应用的客户端验证到NPM模块中。然后你可以在每一个这些平台中使用它。

You can do the same for a lot of the things in your app and that’s how you can reduce the need to write the same code everywhere.

你可以做许多同样的事情在你的应用中,这就是你如何减少需要在所有地方写相同代码的方法。


Here I mentioned two core ideas on why you should not build universal apps. That means we now need to build multiple apps for web, iOS and Android. Now I think you’ve got a question like this:

到这我提到过两个为什么你不应该开发通用应用的核心理念。那意味着我们现在需要为web,iOS和Android开发多个应用。现在我认为你已经想到这样一个问题:

"So, what about the server side?"
『那服务端怎么办?』

Now we have multiple clients. But all of them need to talk to a single server. We can use a common API that can be invoked from all of our apps. That’s exactly something like GraphQL.

现在我们有了多个客户端。但是他们都要跟一个服务器联络。我们所有的应用可以调用一个公共的API。这正是很像GraphQL。

If you are using Meteor, you need to have clear separation between the client side and the server side. Do not mix server code and client code together. Always treat them separately.

如果你正在用Meteor,你需要明确的分离客户端和服务器端。不能将服务端代码和客户端代码混合在一起。一定要将他们分离。

This is the core concept behind Mantra

这是Mantra的核心概念

When we were designing Mantra, we always wanted to use isomorphic modules with a clear separation between the client and server.

当我们设计Mantra的时候,我们总是想去使用客户端和服务端明确分离的同构模块。

Let me talk a bit about client and server separation.

让我说一说客户端与服务端分离。

All the interaction with the server will be done via a mediator on the client side. We should be able to swap it out(if needed) without re-architecting our app. You’ll be able to use Meteor’s LiveQuery, GraphQL, typical REST endpoints or anything you like without re-architecting your app.

所以与服务端的交流都将会通过一个客户端的中介进行。我们不需要重构应用就可以交换它(如果需要)。你可以使用Meteor的LiveQuery,GraphQL,typical REST endpoints或任何其他你喜欢且不需重构你的应用。

Mantra modules will help you to distribute code via NPM. So in the future, we can easily move into different platforms. That’s why I said Mantra will support React Native even if we haven’t thought about how to do so yet.

Mantre模块可以帮你通过NPM分发代码。所以将来,我们可以简单的迁移到不同的平台。这就是为什么我说Mantra将支持React Native,即使我们还没想到该如何去做。


For some apps, this may be a hard decision. But, try to stop building universal apps. You’ll see the benefit in the future.

对于一些应用,这或许是一个艰难的决定。但是,试着不要在开发通用应用。你将在未来受益。

If you are building a prototype, you can always ignore these suggestions. But keep in mind, it’s a prototype and not your final product (app).

如果你在开发一个原型,你可以忽略这些建议。但是请记住,这是一个原型而不是你最终的产品。

In a nutshell, whether you use Mantra or not, stop building universal apps. Instead, use isomorphic modules and build multiple apps. This will lead to better products and a better user experience in the long run. That’s all we want to achieve at the end of the day.

简而言之,无论你是否使用Mantra,停止开发通用应用。相反,使用同构模块并开发多个应用。从长远看这将引领更好的产品和更好的体验。这就是我们想要做的。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249

推荐阅读更多精彩内容