Differences between Sproutcore and Ember
Asked Answered
Y

2

45

I had selected sproutcore as a framework right before Ember forked from sproutcore. I am left uncertain of which way to go and a bit frustrated in the apparent dilution of efforts caused by the fragmentation - as rarely does that lead to better things. The efforts of Sproutcore 2.0 (now Ember) seemed to be going in the right direction of modularization and reuse of other javasript components (jQuery), however it is really unclear from an outside view why the two efforts had to split... couldn't we have modular code, and a widget library module too?

The main questions are:

  1. What are the effective differences between the two efforts?
  2. What is history of the split?
  3. What is sproutcore future, where is it going now?
  4. Is Ember going develop to be a complete replacement for sproutcore?
Yearlong answered 24/2, 2012 at 4:16 Comment(1)
I have those questions myself. Everyone is saying, if you are building a desktop-like app go with Sproutcore 1.x, for a web app go with Ember (previously Sproutcore 2). I think such a division doesn't make sense, aren't they both intended for client-side RIA? The only real difference for me is that while Ember is easier to work with, it is still in development and misses a lot of features.Cereus
V
82

As someone who has both a Sproutcore app and an Ember app close to a production launch, I'll take a stab at your questions (re-ordered for clarity). All of the below is what I've observed with no inside knowledge. A bit of it is speculation, so I've enabled wiki mode on this answer, so that more informed people can correct details.

What is history of the split?

Here is what I've pieced together:

SproutCore was created by Charles Jolley's company Sproutit as the basis of their Mailroom product in 2007. Jolley later joined Apple and Sproutcore was used to build the original web apps for Mobile Me. The mandate was to recreate the experience of Mac apps like Mail and iCal, and that effort continues on Sproutcore today with iCloud.

Jolley left Apple and formed a company called Strobe in San Francisco with a vision in part to leverage Sproutcore. The team at Strobe decided that Sproutcore didn't fit many Web 2.0 use cases well enough, and was too much of an all-or-nothing proposition for developers, so they initiated an effort toward Sproutcore 2. The goals of Sproutcore 2 were modularity, and a more HTML-aware approach that would be more accessible to web developers everywhere. Backbone's early traction was part of this analysis.

After struggling to move the Sproutcore codebase toward this vision, the Strobe team decided to start fresh with Sproutcore 2 (internal codename Amber). Charles wrote the core Run Loop and key-value observer code. Yehuda Katz and Tom Dale were the lead Strobe developers on the project. The vision at the time was that Strobe and the community would eventually port over most features and functionality from Sproutcore 1.x to Sproutcore 2.

Strobe business efforts were not yielding hoped-for results, and the company weighed its options, eventually deciding on a acquisition of Strobe talent by Facebook. Before this happened, a number of Strobe employees, including Katz and Dale, split off to form a new company called Tilde.

Tilde decided to continue to develop Sproutcore 2, but change the name (to Amber.js and then Ember.js) and goals of the project. They dropped long-term goals of backward compatibility with Sproutcore. They dropped support for any kind of view widget library and focused on the HTML/CSS use case with tight integration of data binding with the Handlebars templating language.

Since the dissolution of Strobe, stewardship of Sproutcore 1.x has passed from Jolley to Tyler Keating, and the community has re-focused on cleaning up Sproutcore 1.x, which was in an uncomfortable place for a while when the idea of Sproutcore 2 was looming.

What are the effective differences between the two efforts?

The similarities in the projects are that they feature very similar object models. They have similar property, observer and binding systems, too.

Sproutcore includes a library of view widgets like toolbars, list views, grid views, buttons, and theming system, and a focus on defining the view layer via Javascript and absolute positioning managed by the library. It is very powerful for creating desktop-style apps on the web.

Ember has a smaller footprint. It features tight integration with Handlebars. It is an alternative to Backbone for many projects. It aims to provide a standard application architecture for client-side apps and eliminate boilerplate code.

Those differences will likely lead to the frameworks diverging, although there has been some consideration of adopting the same core. In that scenario, Sproutcore would use Ember's "metal" library and perhaps other core libs).

What is Sproutcore's future, where is it going now?

This thread has minutes from the a recent contributor's meetup.

https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#

The short-term roadmap is to focus on solidifying the marketing materials, demos, and codebase. The team recently released the Sproutcore Showcase. There is general consensus about replacing abbot, the Ruby build tools for Sproutcore, with a Javascript(node.js)-based solution, which is now under active development. There is also a desire for fewer "large" merges of code from companies like Apple and more frequent releases. Sproutcore 1.8 was recently released.

Is Ember going develop to be a complete replacement for sproutcore?

Not likely. The Ember core team has been clear that they have no intention of personally developing those missing features. It is possible that community members may develop those as separate projects -- flame.js is the most ambitious attempt so far. Ember's design choices make it easier to integrate with projects like jQuery UI, so a full replacement may or may not be necessary.

Vibraculum answered 24/2, 2012 at 4:16 Comment(5)
Actually SproutCore was created at Charles' company Sproutit as the basis of their Mailroom product back in 2007 before Charles joined Apple. Other than that small detail, +1 fine sir. Nicely written.Merozoite
Thanks, for that correction Roy. I've update the answer accordingly.Vibraculum
Thanks for the detailed explanation. When going out on a limb choosing a framework, one likes to know it is stable and has long term community support - jQuery is a good example. These events certainly are unfortunate, and place doubt in the future of both Sproutcore and Ember in a field of more duluted efforts. Of course what most people want is both a small modular code base and easy to use UI widget and theming (with the option of customization or pulling it out all together).Yearlong
@TroyHarvey the teams working on both projects are quite talented, and my personal opinion is that the split and fork was a good thing for the future of both projects. It brought clarity to the goals of the projects, and I'm especially impressed with the community around Ember that has sprung up since the split. I don't think I'd agree with your "Of course what most people want..." statement. What people want, or even I personally want, varies a lot across projects.Vibraculum
@Luke. I didn't mean to sound grandious with my "most people" statement. Rather it seems that these are not mutually exclusive goals. You can cleanly rearchitect it to be built out of optional components and have one of those components providing the UI layer that sproutcore currently provides. Then, to each their own, chose which compoenets you want in your project. But it appears the more I read that funding and reasources is perhaps the real reason for the split, not software ideals.Yearlong
P
13

1) The official line is Sproutcore is intended for RIAs and Ember.js is intended for "web-styled" applications. So when you look at iCloud think Sproutcore and when you look at Twitter think Ember.js.

From the technical standpoint, Ember.js is focused on more modularized code and so called "semantic-templates" for views. Sproutcore is more monolithic.

2) I'm not sure anyone really knows. If you look at the timeline, Charles Jolley left Apple to form a company called Strobe, which developed a full-stack platform for application development. Strobe hired Yehuda Katz and others, who began working on slimming down SC so it would run better on mobile devices. After about a year, Yehuda left to form the company Tilde, and a month after that Facebook bought Strobe in what is widely regarded as a talent acquisition.

So interpret that as you will.

3) This is an excellent question. Recently there was a meetup and several things were discussed. Key points discussed were:

  • SC is still alive and kicking
  • Improve documentation (we have been hearing that for a while).
  • Keep the good parts the code that was introduced post 1.4.5 in development of SC2 and get rid of or move to optional modules other stuff (like Templates)
  • new javascript-based build tools
  • completely new canvas based view layer, called Blossom.
  • Some sort of foundation/corporate backing for SC

There are probably others that I missed

4) Definitely not a replacement, although you can use any framework to build any app (it's all javascript, after all).

Parenteau answered 24/2, 2012 at 15:24 Comment(3)
Just to add a quick point, there is a documentation/website "sprint" this weekend for SC to fix some of the things that are broken and to help new developers get up-and-running quickly with the right tools. You can read a bit more about the sprint here: blog.sproutcore.com/sprint-towards-1-8-releasePolard
So I spent a Bit of time reading the meetup nodes and looking at Blossom... Blossom looks like the right direction however I am concerned about the note that Blossom will drop mobile/touch capability, which is alarming the anyone would consider dropping mobile support in 2012. Any thoughts on what is going on here and if touch/mobile is truly being supported in future of sproutcore?Yearlong
Tools are currently being built that will compile blossom apps to run natively on any platform. Obviously, each platform will need to be implemented individually, but I think you can expect the support for the major platforms pretty quickly. From what I've seen in the #blossom IRC, these tools will be avaiable on April 1. The caveat is that runtime support will require licensing. I suggest you drop by #blossom on freenode and start asking questions. Or hit the sproutcore google groupParenteau

© 2022 - 2024 — McMap. All rights reserved.