Native Apps就像CD-ROM,只是发展过渡?

标签: 前沿与评论 mobile web apps mozilia | 发表时间:2012-05-19 11:43 | 作者:dina_wh
出处:http://www.webapptrend.com

Jay Sullivan是Mozilla的产品副总裁,也是Open Web的代言人,他现在红的发紫。

“如果你想拥有各种各样的Apps,将需要大笔的费用……因为有太多应用可以去构建”。Jay Sullivan在最近的VentureBeat采访中说。

Sullivan强烈反对native App,并且赞成将移动互联网作为取代其它所有平台的新平台。

现在,事态的发展使他的话显得格外合乎时宜。Yahoo刚刚发布了Yahoo Cocktails工具,该工具可以让Web Apps更像native Apps。Mozilla正在致力于开发一套工具,可以将web Apps卖给移动设备用户,帮助web Apps开发商像iTunes App Store和Android Market上的开发人员一样获得利润。

甚至Adobe取消了移动手机上的Flash功能,将希望寄托于移动互联网平台的HTML 5。“除了少数情况,基本上现在大多数移动设备都支持HTML 5,”兼任Adobe 副总裁和交互式开发总经理的Danny Winokur写道。

“这使得HTML 5成为了在移动平台上创建和部署内容的最好方法。”

似乎移动Apps正朝着多媒体CD-ROM十年前的方向在前进。可悲的mobile apps,正在步CD-ROM的后尘。

也有人反对这种看法,认为现在为apps鸣哀还为时过早。App的拥护者说即使移动互联网热衷者正沉溺于那些不切实际的想法,但是其他的人仍然在使用现在成熟的技术。尽管他们承认使用HTML5构建mobile web apps最终会更便宜、更快和更容易,但是这至少在近几年实现不了。

在Mozilla Foundation的新办公室楼可以俯瞰旧金山湾跨海大桥,Sullivan——这个HTML5拥护者——坐在会议室快速解读了关于“想要在移动手机上发布软件,不得不首先建立一个native App”的设想。

他没有依靠那些陈旧的意识形态,说一些将企业从技术依赖中解放出来的陈词滥调,这种依赖性在Mozilla的广告活动中得到充分体现。相反,他完全从实际出发。

首先,Sullivan解释:显然每一个移动生态圈都需要有自己的成熟技术,自己的操作系统和开发语言。这就意味着每一个生态圈都要求各自不同的技能和独立开发过程。

总而言之,相比于native apps需要两个、三个或者四个构建技术,只需一种构建技术的Web App将更具有经济价值。“使用HTML 5会更加便宜。”Sullivan说。“相对于使用七种不同的语言开发,HTML5是值得拥有的,虽然总有一些边缘的东西不能很好的运作”。

对于开发者来说,打造一个mobile web app比开发半打或者甚至只是两个native apps从技术层面上都要容易的多。而且,鉴于移动互联网标准,很快地最终用户将区别不了mobile web apps和native apps。Sullivan 认为,剩下来需要做的事就是为mobile web apps建立一种商业模式。

“当开发者可以更容易进入商业圈,mobile web 将变得更有吸引力。”

一套更好的措施

在与Mozilla和Yahoo这些组织交谈中,了解到基本没有移动开发商对于

推进一个单独的移动操作系统如Android或Ios有明显的兴趣——因此,如下的趋势变得格外明显:

  • Apps已经奄奄一息了。
  • Apps像CD一样,正日益成为一套不必要的过时的数字信息包。
  • 正如CD一样,我们正等待一种更好的解决方法来替代它。

这是从技术层面和文化层面发起的挑战。为此,Mobile Web Apps首先必须满足用户高品质高性能的需求,其次,如前面所提到的,开发者需要有销售Apps的市场。

Yahoo正对第一个挑战发起进攻(致力于开发高品质高性能的应用)。Bruno Fernandez-Ruiz是Yahoo平台副总裁,他将他所做的工作描述为“采用一系列措施让web apps体验可媲美native app”。

“我们不想模仿native app,web Apps有它独有的模式。我们想为Web Apps创建新的用户体验,使其可以跨越电话、电视和平板电脑——互联网是可以跨平台的典范。”

虽然,Mozilla或者Yahoo会很想看到移动互联网应用赶超本地应用,但是实际上此时此刻他们仍然必须处理本地和栈的问题。

“我完全相信移动网络会继续快速增长”,Jeff Haynie说,Jeff Haynie与人共同创办的Appcelerator,是一家专门从事培养Web开发人员和运行移动操作系统平台的公司。

同时Haynie认为,现在低估移动App所带来的机会还为时过早。

“这是全球开发者的机遇,”谈论到mobile web Apps,他继续说道,“但是在多种平台上构建和native apps一样的Web Apps所带来的机遇是短暂的。消费者已经对用户体验有了相当高的标准,如Filpboards和Instagrams这些native app的体验在Web app上是无法实现的。

谈到Mozilla等公司,Haynie说道,“这些公司有大量的Web开发者——他们的基础都是web。怎么基于Web进行开发,是他们梦寐以求的。”

“但真正的问题是,怎么样让web开发者基于Web开发具有native apps体验的应用程序?”

毫无疑问,web apps拥护者的答案是:可以通过新的技术和新的市场从web app中获取利润。

移动互联网新技术:Javescripe和Node

JavaScript和Node.js是使native apps向Web apps转型的两项关键技术。

“JaveScript是伪LISP,它比任何函数编程语言功能都强大。”Yahoo的 Fernandez-Ruiz说。

对于基于JavaScript的Node.js,他说,“说不定这就是下一个Ruby on Rails。”(Ruby on Rails是一个近几年广受欢迎的Web应用开发平台,开发人员可以在上面快速的创建网站和应用程序。)

JaveScript和Node是Yahoo Cocktails工具的核心组件,这套新工具帮助开发人员构建的mobile Web apps在外观和感觉无异与于高品质的native apps。Fernandez-Ruiz提到,对于前期的试用版,移动开发者对这套工具反映出了极大的兴趣与热情,每个人都希望能使用到它。

事实上,使内容兼容所有移动设备平台,是一项艰巨的任务。目前,许多公司正在设法采用将一种操作系统语言翻译成另一个操作系统的语言的方式来解决这个难题,例如将开发iPhone应用的Objective C语言翻译成进行Android开发Java。

但是,通过这种方式翻译出来的代码往往是混乱不堪的,而且试图采用这种方法去解决兼容性问题也不是长久之计。

相反,Fernandez-Ruiz说,“我们准备要解决未来3年内的可能出现的问题,而不是仅仅是现在存在的一些问题。”

理想的情况下,雅虎试图不再使用多语言进行开发,因为多语言使开发工作变的复杂无比。这也是Cocktail的目标所在。Cocktail其中一个称作Mojito的工具,就使用JavaScript和Node让同一套代码可以同时在客户端和服务器端运行。

“我们没有将前端和后端进行区分,”Fernandez-Ruiz说,“对于我们来说,前后端采用的是完全相同的代码。”

另一种Cocktail工具Manhattan是Mojito的Node.js托管环境。应用程序可以在本地的shell中进行打包,然后送到iTunes App Store或Android Market上发布,或是浏览器上运行。Manhattan作用在于加快网络速度不稳定的用户的访问速度,并且让那些不完全支持HTML5/CSS3的平台正常运行各种应用。

虽然Node已被证实有许多疯狂的性能优势,Fernandez-Ruiz说道,“我们并没有使用这些功能,因为它的事件驱动、低延时功能。而我们使用Node的原因在于它是在服务器端运行JaveScript”

JavaScript是逐步发展的,他说,“下一代的JavaScript将是一种引人注目的、令人兴奋的高性能的Web编程语言。这将使Web apps拥有跨平台的、连续的、流畅的全新用户体验。”

作为终端用户,Fernandez-Ruiz says提到,从TV的使用界面跳转到平板电脑或是智能手机或是PC上的另外一种界面是非常郁闷的事情。“但是,HTML5,CSS3和JavaScript,可以让应用在所有平台上都拥有同样的外观和使用感受。”

以下是我们在查看最新的LinkedIn mobile web apps时的所见,这些应用由Node驱动和使网络负荷重。虽然iOS和Android的native apps由于其大量的网页功能和网页,而使移动网络负荷非常重,但是移动互联网版本在外观和功能上和native版本完全一样。

谈及Yahoo的最终目标,Fernandez-Ruiz继续下去,“为了在服务器端执行代码,Node.js只是解决了难题的一部分。不管怎样,所有问题的先决条件是相同的:不是在本地,而是在Web上解决问题”。

在不久的将来,雅虎还会引入其他的Cocktails工具,如Windjammer和Screwdriver等。

但是Haynie认为需要慎重的对待web-app-in-a-native-wrapper模型。

“现在几乎没有人使用这样的混合应用。web-app-in-a-native-wrapper模型只是一个桥梁,让native apps展示网页内容,但如果你查看LinkedIn的新应用,会发觉这些应用几乎与native apps无异。”Haynie说道。

Dmitry Dragile在Zurb工作,该公司刚刚发布了设计应用程序的基础框架,按照这个框架设计的web apps可以同时在移动设备和桌面电脑上运行。这个框架让人觉得有点不可思议。随着窗口、设备屏幕分辨率的变化,链接可以变成按钮,图像会自动改变尺寸大小,布局也自动进行调整。

既然是Web技术,就没必要基于设备进行定制。“这个框架会搞定一切”Dragilev说,“人们再不必担心不同分辨率这些问题了”。

该技术的目的是可以使用在任何一种设备上,不管是移动设备或者其它设备,Dragilev说,“这是至关重要的,因为现在移动互联网的使用率已开始赶超桌面电脑。”

Mobile Web Apps市场

Mozilla团队正致力于研究使mobile apps运作模式转变的工具,向第二个挑战发起进攻:如何在大众市场里出售mobile web apps?

对于消费者而言,Mozilla的计划包括您可以在所有设备上使用您购买过的每一个应用。也就是说,所有的应用程序可以在所有的设备上运行。如果您在智能手机上购买过一个应用,那么您不必为您新买的平板电脑重新购买相同的应用程序。

“我们的想法是,任何人只要一个电子邮件地址就可以开始使用免费或付费的应用程序,该应用程序是为你所有,”Sullivan解释说,“在电脑上购买了一款游戏,你同样可以在手机上使用。因为这款游戏已经属于你了,而不是属于你的设备。”

在这种模式下,消费者可以在大量的虚拟商店中购买信誉良好的应用程序,这些虚拟商店构成了空中购物中心。或者,通过其他途径与开发者直接联系。

或许你,我亲爱的读者,觉得这只是乐观派想法的,Sullivan却认为,Mozilla带来了一种具有操作性的方法。

“我们在运营浏览器时采用了这种模式”他说,“我们将为WebApps开设一个市场。几年来,我们通过市场分销Firefox附加组件。我们已经为市场的管理、策略方针制定以及合法运作建立了一套系统——并且通过严厉的考验来验证它,我们得到了一个相当不错的结果”。

谷歌和苹果这些公司在市场以外的应用周围制造了一种FUD(恐惧,不确定和怀疑)气氛。作为消费者,我们被告知在非公司授权的应用商店上销售的应用程序,在安全和质量上都没有保证。

不过,Sullivan说FUD确实存在,特别是涉及到隐私和应用使用权时。Sullivan认为,事实上web apps要求更加透明的个人使用权,同时使用web“sandbox”模式更好的阻止恶意程序的发布。

Johnathan Nightingale是Mozilla公司Firefox项目的负责人,他也在房间里。当我们开始谈论的FUD时,他就精神起来了。

“如果你回到90年代末,美国在线曾经说过同样的话:‘如果你把它发布在网上,谁也不知道你会得到什么?’”

他继续谈到Mozilla建立的mobile web商业组织。“这并不是说我们要脱离应用商店。如果你是一名开发人员,你会想要进入尽可能多的商店;但是如果你建立了一个成功的商店,你将获得更高的权限。但是我们并不会阻止用户安装他们所需要的东西。”

停止Native Apps的开发

因此,如果以上措施联合运作起来——更好的移动互联网开发工具,更好的mobile web apps市场——完全有理由相信mobile web apps将成为创建智能手机、平板电脑和其他设备上应用的主导模式。

“最终,Web的将是可以构建新应用的唯一地方。” Nightingale说。

“如果现在说到App 开发商,他们正试图雇用顶尖的HTML5编码人员。他们不想使用四种或者五种不同的技术来进行开发。”

由于硬件的特定功能和native apps访问硬件的能力,Nightingale说,开发商仍然可以进行native apps的开发。“但我们停止了”,他说,为了给Mozilla的mobile web开发工具计划做铺垫。

但是也存在一些质疑的声音,当前native模式背后的支持势力——原始设备制造商和操作系统厂商——当涉及到访问硬件时,是否会给移动互联网一个公平的机会呢。

“我们正在努力使这些使Web开发商同时拥有硬件功能”,Haynie说,“但你认为苹果会得到所有kumbaya产品,并且进入到硬件行业?不可能。网络公司当然会非常高兴,但我们传统互联网上没有实现这一点,怎么会在移动互联网上做到呢?”

事实上,Sullivan的预测过于保守。他回想在软盘或者CD-ROM的时代,他指出大约他使用过的程序80%是桌面软件和20%是Web程序。

“随着功能的增加,80/20规则被颠覆了。现在,几乎所有的东西都已转移到网上。”

“我没有看出native apps是领先了许多,在某种意义上看,它只是从未离开过PC。但我认为也将会有一个移动互联网的80/20法则。”

同样,Zurb的设计总监,Jonathan Smiley认为,最终,我们将完全地停止区分web和native apps。我问他,是否他认为两者会一样好;他说,“绝对正确,届时native和web apps之间的界线会变的模糊不清。随着设备通过硬件来激活和加快访问web apps功能,而native apps也使用越来越多的web服务,两者有可能融合为一体称为‘Apps’”。

“我们的目标始终是要设计优秀的UI”,Kiran Prasad说,他是LinkedIn移动项目总监。“优秀的UI意味着简单。简单就意味着快速,简便和可靠的用户体验。”

Prasad说,手机的Web apps“的确是未来的”,但他指出,机会仍然摆在我们面前。如今,技术人员需要“在正确的时候使用正确的技术……现在的问题不是native apps与web apps的分庭对抗。而是在显示和交互层面:是选择本地显示或是网页显示。我们始终专注于最佳的用户体验,而今天这就意味着利用mobile web apps以及native apps的用户体验优势。”

您可能也喜欢:

海豚浏览器CTO刘铁锋:Web App对企业移动开发的影响

LinkedIn和FT再次引发web app和native app之争

iOS 5.1Web存储方式的打破会影响到Web App吗?

Google Web App开发指南第一章:什么是Web Apps?
无觅

相关 [native apps cd] 推荐:

Native Apps就像CD-ROM,只是发展过渡?

- - Web App Trend
Jay Sullivan是Mozilla的产品副总裁,也是Open Web的代言人,他现在红的发紫. “如果你想拥有各种各样的Apps,将需要大笔的费用……因为有太多应用可以去构建”. Jay Sullivan在最近的VentureBeat采访中说. Sullivan强烈反对native App,并且赞成将移动互联网作为取代其它所有平台的新平台.

恶搞CD封面

- Weiye - 超现实创意网
当你热衷于某一项事物时,收藏也许会慢慢变成浮云,如何从中获取对生命的重新思考才是大势所趋. 著名的DJ兼作曲家Christian Marclay手上拥有无数张CD唱片,一颗不羁的心促使他发现了这些唱片封面之间的“因果联系”,于是我们久仰的迈克也能穿上热辣的透视裤,被山寨化的PS一番.

谈谈 React Native

- - 唐巧的技术博客
几天前,Facebook 在 React.js Conf 2015 大会上推出了 React Native( 视频链接). 我发了一条微博( 地址),结果引来了 100 多次转发. 为什么 React Native 会引来如此多的关注呢. 我在这里谈谈我对 React Native 的理解. 一个新框架的出现总是为了解决现有的一些问题,那么对于现在的移动开发者来说,到底有哪些问题 React Native 能涉及呢.

Web Apps来袭

- - HTML5研究小组
如同历史上任何一次互联网基础标准的变化都会在随后几年中带来应用创新的大爆发一样,当HTML5在2011年逐渐被主流厂商所接受之后,围绕Web Apps领域的创新风暴正山雨欲来. 2012年1月12日,老牌传媒集团《金融时报》(Financial Times,以下简称FT)宣布收购为其开发移动Web App的研发公司Assanka ,这样,FT将不再以外包的形式雇佣Assanka为其打造移动Web App,而可以直接让它在内部进行开发.

CD之父大贺典雄去世

- aviot - Solidot
前索尼公司CEO大贺典雄因多脏器功能衰竭于4月23日去世,终年81岁. 大贺典雄从1982年到1995年领导索尼,期间的重要决策包括耗资34亿美元收购哥伦比亚唱片公司;作为一位前歌唱家,他坚持CD的直径应设计为12厘米,能播放74分钟长的音乐——恰好能收录全首贝多芬第九交响曲.

废弃物之美,CD成海

- Y - 果壳网 guokr.com - 果壳网
在这个高速发展的数字时代,光盘已经不再是人们存储信息的首选. 你已经多久没有打开CD机,塞入一张CD,静静地放完整张专辑了. 现在许多人都能随意翻出一堆弃置许久的CD,它们的盘面都已刮花,不能再被机器读取. 可是,那些曾经挚爱的CD现在只能被尘封在记忆里了吗. 当然不是,两个法国人告诉我们,废旧CD也可以创造艺术美.

有赞零售移动 CI/CD 实践

- - IT瘾-dev
点击关注“有赞coder”. 随着有赞零售业务的蓬勃发展,为了尽早交付有价值的应用满足客户需求,我们采用了敏捷开发的模式,快速拥抱变化的同时保持竞争优势. 从 2019 年起,零售客户端的发版周期更改为每周一次,这对移动端的持续集成与交付提出更高的要求. 如何根据现有的团队规模,在有限的资源下,快速搭建稳定可靠的持续集成与交付系统,我们有了自己的实践与思考.

gitlab 的CI/CD 流水线初体验

- - xLog Latest
关于 CI/CD 的理念与解释这里就不说了,可以看 这篇文章. 为什么选择 gitlab 的流水线 #. 原因也很简单,公司的代码托管在 gitlab 上,且 gitlab 的 free 额度好像还挺高. 不选择 Jenkins的原因也很简单,UI 过时,功能虽多但占用也高. 如果是新手的话 Drone 可能也很好.

Chrome 14 beta启用Native Client

- tinda - Solidot
Google发布了Chrome 14 beta,默认启用Native Client(NaCl),它最早在上半年发布的Chrome 10 beta整合了NaCl,但并未激活. Google在2008年首次推出了试验项目NaCl,让开发者可以编译C/C++代码为不针对特定平台的二进制文件,在浏览器整合的运行时中执行,利用沙盒技术避开安全缺陷.

剑走偏锋的 Native Client

- - 谷奥——探寻谷歌的奥秘
感谢读者  liuyanghejerry 的投稿. 不知不觉,Google已经正式推出其Native Client (NaCl)过去约7个月之久. 而目前国内似乎还没有多少关于NaCl的资料,所以在这里面向Web开发者做一下简单的介绍,希望能够起到一个抛砖引玉的效果. 本文的所有代码均来自于 https://developers.google.com/native-client/devguide/tutorial,如果您对其中的任何技术细节存在疑问,请以原文为准.