javascript SproutCore 与卡布奇诺

SproutCore vs. Cappuccino

提问by Sheehan Alam

Aside from the language differences Javascript vs. Objective-J what benefits does Cappuccino provide over SproutCore and vice-versa in your experiences?

除了 Javascript 与 Objective-J 的语言差异之外，在您的体验中，Cappuccino 与 SproutCore 相比有什么好处，反之亦然？

In terms of a long-term forecast, is SproutCore more "supported" than Cappuccino because it is backed by Apple?

从长期预测来看，SproutCore 是否比 Cappuccino 更“受支持”，因为它得到了苹果的支持？

I am trying to choose between the two. I am both familiar with JavaScript and Objective-C.

我试图在两者之间做出选择。我熟悉 JavaScript 和 Objective-C。

回答by Michael Cohen

This is an interesting question, and one that has been popping up fairly frequently on various messages groups, twitter, and even IRC. There's a couple of ways to evaluate SproutCore versus Cappuccino, but, perhaps, some of the immediate caparisons that people look at are the following:

这是一个有趣的问题，并且在各种消息组、推特甚至 IRC 上经常出现。有几种方法可以评估 SproutCore 与卡布奇诺咖啡，但是，也许人们看到的一些直接caparisons 如下：

1) Their respective feature set
2) Ease of use
3) Community support and documentation

1) 各自的功能集
2) 易用性
3) 社区支持和文档

Let's look at the first point -- there respective feature set. By "feature set" there's a couple of ways to look at it. From the number of UI widgets they have; the foundational support to connect things together and communicate with some kind of back-end; the framework's general architectural approach, although not necessarily a "feature", but still important; and, yes, even the language you can use.

让我们看看第一点——有各自的功能集。通过“功能集”，有几种方法可以查看它。从他们拥有的 UI 小部件的数量来看；将事物连接在一起并与某种后端进行通信的基础支持；框架的一般架构方法，虽然不一定是“特性”，但仍然很重要；而且，是的，甚至是您可以使用的语言。

Regarding language, I think it's important that you do not dismiss what is being used (JS versus Obj-J). Why? Because of adoption and where you are coming from. SproutCore came from the perspective that JavaScript is indeed the language of the web, so it's what you use to program against the framework. Where JavaScript lacks in language OO completeness (proper object-object inheritance, etc) it makes up for in the framework (e.g. MyApp.Foo = SC.Object.extend({...})). Cappuccino comes in from a different angle. They use Obj-J as a primary language enhancement to JS in order to inject language features that JS is missing; this instead of injecting those language features directly into the framework (Cappuccino) itself. Of course, as the folks over at Cappuccino have noted before, you can still use JS to program against Cappuccino proper, but, then, you miss out on what Obj-J provides. Note to the Cappuccino community: Please correct me if I'm wrong :-). Finally, if you're someone who is already familiar with Obj-C then Obj-J may be more your cup of tea. Hey, even Sony is apparently now jumping on the whole Obj-C bandwagon to develop against their mobile platform :-P.

关于语言，我认为重要的是不要忽视正在使用的内容（JS 与 Obj-J）。为什么？因为收养和你来自哪里。SproutCore 的出发点是 JavaScript 确实是 Web 语言，因此您可以使用它来针对框架进行编程。JavaScript 缺乏语言 OO 完整性（正确的对象-对象继承等），它在框架中弥补（例如 MyApp.Foo = SC.Object.extend({...})）。卡布奇诺从不同的角度进来。他们使用 Obj-J 作为 JS 的主要语言增强，以注入 JS 缺少的语言特性；这而不是将这些语言功能直接注入框架 (Cappuccino) 本身。当然，正如 Cappuccino 的人之前所指出的，您仍然可以使用 JS 对 Cappuccino 进行适当的编程，但是，然后，您就会错过 Obj-J 提供的功能。卡布奇诺社区的注意事项：如果我错了，请纠正我:-)。最后，如果您已经熟悉 Obj-C，那么 Obj-J 可能更适合您。嘿，即使是索尼显然现在也加入了整个 Obj-C 的潮流，以针对他们的移动平台进行开发：-P。

Looking at the architecture of the two frameworks, they both looked at Apple's Cocoa framework for guidance/inspiration in one form or another. Cappuccino took Cocoa fully to heart and basically ported Cocoas API. Again, if you're coming from developing apps in Apple using Cocoa then you're probably going to feel right at home. SproutCore on the other hand took inspiration from Cocoa where it felt right. As for pure architecture, they both follow MVC, they both make use of Cocoa-style bindings, they both have a data store mechanism, and they both have their own respective style of rendering and composing UI widgets/views.

查看这两个框架的架构，他们都查看了 Apple 的 Cocoa 框架以某种形式的指导/灵感。Cappuccino 完全把 Cocoa 放在心上，基本上移植了 Cocoas API。再说一次，如果您是在 Apple 中使用 Cocoa 开发应用程序，那么您可能会感到宾至如归。另一方面，SproutCore 从 Cocoa 那里获得灵感，感觉不错。至于纯架构，他们都遵循MVC，他们都使用Cocoa风格的绑定，他们都有数据存储机制，他们都有自己的渲染和组成UI小部件/视图的风格。

The rendering of views is, to me, a particular area of importance. Both frameworks have some level abstraction in order to remove you from directly dealing with CSS and HTML even though at the end of the day they have to render to what the web browser ultimately understands.

对我来说，视图的呈现是一个特别重要的领域。这两个框架都有一定程度的抽象，以便让您无需直接处理 CSS 和 HTML，即使在一天结束时它们必须呈现 Web 浏览器最终能够理解的内容。

On the Cappuccino side, they completely abstract away CSS and HTML from you. Instead, you use the framework's various rendering primitives to "draw" your views. Because of this level of abstraction, Cappuccino can make use of the best rendering approach available instead of coupling you, to some degree, with CSS and HTML.

在 Cappuccino 方面，他们完全从你那里抽象出 CSS 和 HTML。相反，您可以使用框架的各种渲染原语来“绘制”您的视图。由于这种抽象级别，Cappuccino 可以利用可用的最佳渲染方法，而不是在某种程度上将您与 CSS 和 HTML 结合起来。

As for SproutCore, you are rendering closer to the "metal" so to speak. When doing a pure rendering of a view, you make use of a rendering context object that provides a certain degree of abstraction, but, ultimately, you are directly injecting HTML and adding class names to apply CSS. Even after your view has been rendered and you want to manipulate certain parts of the view based on an event, you can directly access to the DOM elements and manipulate their properties. Depending on where you are coming from this may seem good or bad. Good for those who are used to working with CSS and HTML and like the more direct control over how the views are rendered and styled. Bad if you want to generically render a view in order to make use of the best render approach based on what the browser allows (HTML/CSS, SVG, HTML5 canvas, etc). But, note, there are future plans to make SproutCore have a more abstract rendering approach but still allow you to directly work with HTML and CSS if you so choose. So you'll eventually get the best of both worlds.

至于 SproutCore，可以这么说，您渲染得更接近“金属”。在对视图进行纯渲染时，您会使用提供一定程度抽象的渲染上下文对象，但最终，您将直接注入 HTML 并添加类名以应用 CSS。即使在您的视图已呈现并且您想根据事件操作视图的某些部分后，您也可以直接访问 DOM 元素并操作它们的属性。取决于你来自哪里，这可能看起来好或坏。适合那些习惯于使用 CSS 和 HTML 并喜欢更直接地控制视图的呈现和样式的人。如果您想根据浏览器允许的内容（HTML/CSS、SVG、HTML5 画布等）使用最佳渲染方法来一般地渲染视图，那就不好了。但是，请注意，未来有计划使 SproutCore 具有更抽象的渲染方法，但如果您愿意，仍然允许您直接使用 HTML 和 CSS。所以你最终会得到两全其美的。

Now, as for the stock UI widgets/views the two frameworks come with -- they both have a lot right out of the box in order to get you going. Buttons, labels, lists, segmented views, radio buttons, scrollers, etc -- they're all there. Therefore, it's safe to say you're fine in both camps.

现在，至于两个框架附带的库存 UI 小部件/视图——它们都有很多开箱即用的功能，以便您继续前进。按钮、标签、列表、分段视图、单选按钮、滚动条等——它们都在那里。因此，可以肯定地说，您在两个阵营中都很好。

Going all the way back, let's now discuss the ease of use. To me, ease of use is based on you own personal experience working with JavaScript, HTML, Obj-C, Cocoa, other MVC frameworks, documentation, and community support. If you've never worked with Cocoa, or never built a decktop- or iPad-like app, then it's fair to say you're going to have a bit of a learning curve no matter what framework you choose. That being said, what you don't know and want to learn can be acquired through each framework's respective community and docs. Both have active communities in one for or another, so you won't be left out in the cold if you get stuck somewhere. As for docs, Cappuccino, admittedly, has the upper hand. The docs for SproutCore are lacking, but the code base is at least fully commented. The SproutCore community is fully aware of the docs needing to be updated, and it is currently something that is being dealt with, so keep checking.

回过头来，现在让我们讨论一下易用性。对我来说，易用性是基于你个人使用 JavaScript、HTML、Obj-C、Cocoa、其他 MVC 框架、文档和社区支持的经验。如果您从未使用过 Cocoa，或者从未构建过类似桌面或 iPad 的应用程序，那么可以公平地说，无论您选择哪种框架，您都会有一些学习曲线。话虽如此，您不知道和想学习的内容可以通过每个框架各自的社区和文档获得。两者都有活跃的社区，所以如果你被困在某个地方，你不会被冷落。至于文档，无可否认，卡布奇诺占了上风。缺少 SproutCore 的文档，但代码库至少有完整的注释。

Finally, you mentioned the long-term forecast for the two frameworks. It's public knowledge that Motorola bought the Cappuccino framework, so you certainly have a big company backing its growth and longevity, or at least it seems like that way for now. As for Apple and SproutCore, I personally can't speak for them, but Apple does not own the framework. There are many companies and various individuals that all use and contribute back to the framework in some way. That might give some people and companies pause or discomfort for those who are looking at SproutCore due to the more organic nature of the framework's development, but I don't see that as a problem. My feeling is that both frameworks will be around for a long time, especially now that more are looking at developing next generation desktop and iPad apps using open source frameworks. And, hey, competition between the frameworks is good -- keeps everyone on their respective toes :-).

最后，您提到了两个框架的长期预测。众所周知，摩托罗拉购买了 Cappuccino 框架，因此您肯定有一家大公司支持其增长和长寿，或者至少目前看起来是这样。至于Apple和SproutCore，我个人不能代表他们，但Apple不拥有该框架。有许多公司和各种个人都以某种方式使用该框架并对其做出贡献。由于框架开发的更有机的性质，这可能会让一些人和公司对那些关注 SproutCore 的人感到犹豫或不适，但我不认为这是一个问题。我的感觉是这两个框架都会存在很长时间，特别是现在越来越多的人正在考虑使用开源框架开发下一代桌面和 iPad 应用程序。而且，嘿，框架之间的竞争很好——让每个人都保持警觉:-)。

Hope this information helps you out with your decision!

希望这些信息可以帮助您做出决定！

Cheers,

干杯，

Mike

麦克风

回答by Me1000

I'd like to touch on the comments made about objective-j Michael.

我想谈谈关于objective-j Michael 的评论。

You're not going to lose anything if you drop down to JavaScript instead of objective-j. In all actuality the distinction is kind of difficult to make, especially in cases where we have toll-free bridged classes (more on that in a bit).

如果你选择 JavaScript 而不是 Objective-j，你不会失去任何东西。实际上，这种区别有点难以区分，尤其是在我们有免费桥接课程的情况下（稍后会详细介绍）。

Objective-j is really just a thin wrapper over js. It provides classical inheritance something that has traditionally been implemented as a language feature, which sproutcore implements as a framework feature, it also provides code importing, accessor generation, static scoping, and support for messaging nil.

Objective-j 实际上只是对 js 的一个薄包装。它提供了传统上作为语言特性实现的经典继承，sproutcore 作为框架特性实现，它还提供代码导入、访问器生成、静态范围和对消息 nil 的支持。

Objective-j instance variables are accessible via the traditional dot syntax if you want... I like to think of it like this: once you start writing a method, you're mostly writing JavaScript. That is, loops, variables, functions, closures, etc are all just javascript. You're not losing anything by dropping down, that's exactly how the language is designed.

如果你愿意，Objective-j 实例变量可以通过传统的点语法访问......我喜欢这样想：一旦你开始编写一个方法，你主要是在编写 JavaScript。也就是说，循环、变量、函数、闭包等都只是 javascript。你不会因为下拉而失去任何东西，这正是语言的设计方式。

We take it a step further by "toll-free bridging" some of our classes CPDate, CPArray, CPException, CPString and perhaps more that I can't recall. Toll free bridging just means a CPArray IS a native js array, and a native js array is a CPArray, so you can use methods and functions of both world interchangeably.

我们更进一步，通过“免费桥接”我们的一些类 CPDate、CPArray、CPException、CPString 以及我不记得的更多类。免费桥接只是意味着 CPArray 是原生 js 数组，而原生 js 数组是 CPArray，因此您可以互换使用这两个世界的方法和函数。

So for example would could do:

因此，例如可以这样做：

var foo = [];
[foo addObject:"bar"];
foo.push("2nd push");
var value = foo[0];
var value2 = [foo objectAtIndex:0];

alert(value === value2); //true

As you can see I'm using objective-j syntax and js syntax together... You can imagine the power if this.

正如你所看到的，我同时使用了 Objective-j 语法和 js 语法......你可以想象它的威力。

The final thing I want to put out ther, just to make sure there is no confusion: objective-j gets parsed in the browser. It doesn't need to be compiled before hand (although we provide compilation tools for when you're ready to deploy your app).

我想提出的最后一件事，只是为了确保没有混淆：objective-j 在浏览器中被解析。它不需要事先编译（尽管我们为您准备好部署应用程序提供了编译工具）。

I think some people are needlessly put off by objective-j as if it's some monstrous beast that will take time to learn, and while objective-j adds a lot of great features to js, to actually learn them won't really take you the better part of a day if you're already familiar with object oriented programming, and obviously if you're coming from cocoa you'll be able to jump right in.

我认为有些人不必要地被 Objective-j 拖延，就好像它是一种需要时间学习的怪物一样，虽然 Objective-j 为 js 添加了许多很棒的功能，但实际学习它们并不会真正带你如果您已经熟悉面向对象的编程，那么一天中的大部分时间，显然如果您来自可可，您将能够直接进入。

回答by Elias

I wrote a blog article exactly about "cappuccino vs. sproutcore". It is not a technical comparison but compares other interesting data.

我写了一篇关于“卡布奇诺 vs. sproutcore”的博客文章。这不是技术比较，而是比较其他有趣的数据。

http://elii.info/2010/11/cappuccino-vs-sproutcore/

http://elii.info/2010/11/cappuccino-vs-sproutcore/

回答by hvgotcodes

From the Cappuccino website:

从卡布奇诺网站：

"On the other end of the existing frameworks are technologies like SproutCore. While SproutCore set out with similar goals to Cappuccino, it takes a distincly different approach. It still relies on HTML, CSS, JavaScript, Prototype, and an entirely new and unique set of APIs. It also requires special development software and a cumbersome compilation step. We think this is the wrong approach.

“在现有框架的另一端是像 SproutCore 这样的技术。虽然 SproutCore 与 Cappuccino 有着相似的目标，但它采用了截然不同的方法。它仍然依赖于 HTML、CSS、JavaScript、Prototype，以及一个全新且独特的集合的API，还需要专门的开发软件和繁琐的编译步骤，我们认为这是错误的做法。

With Cappuccino, you don't need to know HTML. You'll never write a line of CSS. You don't ever have interact with DOM. We only ask developers to learn one technology, Objective-J, and one set of APIs. Plus, these technologies are implementations of well known and well understood existing ones. Developers can leverage decades of collective experience to really accelerate the pace of building rich web applications."

使用 Cappuccino，您无需了解 HTML。你永远不会写一行 CSS。您永远不会与 DOM 进行交互。我们只要求开发者学习一种技术，Objective-J 和一套 API。此外，这些技术是众所周知且易于理解的现有技术的实现。开发人员可以利用数十年的集体经验来真正加快构建丰富的 Web 应用程序的步伐。”

So it seems that Cappuccino does not have/need any build tools, and completely abstracts the browser away from the developer. Whereas in Sproutcore you get build tools (a development server, for example) and the developer should be somewhat aware of what DOM is.

因此，Cappuccino 似乎没有/不需要任何构建工具，并且完全将浏览器从开发人员中抽象出来。而在 Sproutcore 中，您可以获得构建工具（例如开发服务器），开发人员应该有点了解 DOM 是什么。

回答by Dimitris Stefanidis

Michael Cohens answer pretty much covered everything since it was extremely detailed.

迈克尔科恩斯的回答几乎涵盖了所有内容，因为它非常详细。

I have been struggling with a decision for the past 3 weeks. I have read everything there is out on the web about both frameworks and I have written a lot of source samples with both and still cannot make a decision. The following issues have me jumping from one framework to the other and keep making my decision tougher.

在过去的 3 周里，我一直在为一个决定而苦苦挣扎。我已经阅读了网上关于这两个框架的所有内容，并且我已经用这两个框架编写了很多源示例，但仍然无法做出决定。以下问题让我从一个框架跳到另一个框架，并让我的决定变得更加艰难。

1. Sproutcore has a better data store api than the one cappuccino has.

2. Sproutcore makes use of bindings better than cappuccino currently does. Cappuccino does also have kvc/kvo support but bindings are not totally there yet. For example in sproutcore you can implement incremental loading with bindings and ArrayController very easily where on the other hand in cappuccino its not as straightforward. Of course cappuccino offers the CPTableView DataStore api which is pretty clean and can achieve similar results just not with bindings. Its what cocoa did before core data. Bindings are constantly being worked on in cappuccino though.

3. Cappuccino has a better view api according to my personal taste. Although I am used to developing html and the DOM I much prefer the idea of abstracting the DOM completely away and getting rid of css.

4. One issue that is really important to me is the lack of a good TableView in sproutcore. Currently SC.TableView is in alpha and it is not performant at all. I dont know of a timeline for the tableview in sproutcore. I tried asking on the irc sproutcore channel but got no satisfying answer. Cappuccino on the other hand has a great and very optimized table view.

5. I have found more real world applications written on cappuccino than on sproutcore. There is also a pretty nice full blown application that is provided by cappuccino as a source sample and is very helpful. Check out http://githubissues.heroku.com/.

1. Sproutcore 拥有比卡布奇诺更好的数据存储 API。

2. Sproutcore 比目前的卡布奇诺更好地利用绑定。Cappuccino 也有 kvc/kvo 支持，但目前还没有完全绑定。例如，在 sproutcore 中，您可以非常轻松地使用绑定和 ArrayController 实现增量加载，而另一方面，在卡布奇诺咖啡中则没有那么简单。当然，cappuccino 提供了 CPTableView DataStore api，它非常干净，可以实现类似的结果，只是不使用绑定。它是可可在核心数据之前所做的。不过，卡布奇诺咖啡一直在研究绑定。

3. 根据我个人的口味，卡布奇诺有更好的view api。尽管我习惯于开发 html 和 DOM，但我更喜欢完全抽象 DOM 并摆脱 css 的想法。

4. 对我来说非常重要的一个问题是 sproutcore 中缺少一个好的 TableView。目前 SC.TableView 处于 alpha 阶段，它根本没有性能。我不知道 sproutcore 中 tableview 的时间表。我尝试在 irc sproutcore 频道上提问，但没有得到满意的答案。另一方面，卡布奇诺具有出色且非常优化的表格视图。

5. 我发现用卡布奇诺写的真实世界应用程序比用 sproutcore 写的多。还有一个非常不错的完整应用程序，由卡布奇诺提供作为源示例，非常有帮助。查看http://githubissues.heroku.com/。

Despite the fact that I have no experience in objective-c and I much prefer the pure js syntax I will probably go with cappuccino on my current project and hope sproutcore comes out with a better table view in the future.

尽管我没有使用 Objective-c 的经验，而且我更喜欢纯 js 语法，但我可能会在我当前的项目中使用卡布奇诺，并希望 sproutcore 将来能提供更好的表格视图。