Who is using sproutcore

You'll see issues like this since it's inception. Also a few weeks ago someone asked the group how to create a hyperlink using Sproutcore. I mean, LOL, it takes hours to create a simple hyperlink apparently.

It is claimed not by sproutcore itself afaik that Apple uses it, but if you look closely you'll see that Apple has it's own codebase. I personally found sproutcore to be riddled with bugs, the lack of a simple tableview annoying, incomplete or non-working examples, and the absence of documentation and even the absence of complete TESTS is just not a good base to build upon.

First I developed using version 0. But since SproutCore is Javascript close to javascript we were able to solve them for our application. For me actually, SproutCore taught me proper way of javascript coding. I was learning Javascript and SproutCore same time.

Somewhere around July they released SproutCore 1. API was changed significantly so converting our application to newer version was a project in itself.

And documentation was zero at that time. Now things are changed, There is documentation and very nice wiki. New tutorials and documentation added each day. And each day SproutCore amaze me with capability and power it contains. Still there is lots of rough edges, which reduces everyday.

Recent addition for data store API which is very important part. It is something I think other JS frameworks lack. Their binding framework makes updating views a snap. Their examples are enough to get you started, but advanced things will stump most users.

The data access layer is too complicated. Its a huge mystery. They need to really shore up documentation or provide more examples to pave the way so people can use it properly. On the other hand, it seems to be a really powerful almost ORM framework.

Lack of a grid is a real drag. Many if not most apps need grids. A lot of the code seemed overly complex. Anytime a method gets to be longer than lines it should really be broken up to increase readability. Perhaps the biggest consideration is this: if you are working a project and considering SC, you are going to have real trouble finding competent developers to work on it.

So it might be good for a small personal project, but you are taking a risk with a large project that will need maintenance. I am using SproutCore and it is simply great.

We switched from jQuery to SproutCore , since jQuery offers a small set of utilities and SproutCore offers a nice high-level architecture. Of course there are more toolkits, but these are the ones we evaluated. As a conclusion I can highly recommend SproutCore to anyone who is building a desktop class applications using Javascript. If you just need some simple Javascript, like date pickers etc. Just one more tip. At the time of writing this answer the SproutCore 1. Unfortunately it is quite old and we are using the latest version that can be found from the SproutCore's Github page.

I can highly recommend that. If you are trying to get into SproutCore I recommend that you dig into the SproutTweets sample application. Many of the more powerful constructs states, dynamically loaded frameworks, a useful example of a datasource are in there. Even if you have no intention of using SproutCore in a production application you owe it to yourself to explore it further to see a powerful approach to javascript application programming -- especially the KVO and mixins aspects stuff.

Lots of great architecture to ponder and learn from. Last point -- the IRC channel can be far more helpful than other sources of information, second only to some deep diving in the google group discussions. I have used SproutCore in the past. In my experience, in order to develop web software that truly rivals the native software, you need more than just a collection of parts, and you need a cohesive set of tools with strong fundamentals.

I've actually toyed with calling SproutCore something more akin to a platform, rather than a framework, because it is really more than just the framework code, it's also the tools, the ideas, and the experience that come with it.

On the other side of the argument, there is the idea of picking small pieces and cobbling them together to form an application. While this is a seductive idea and makes great demos, this approach quickly runs out of steam when attempting to go beyond a simple project.

The problem isn't the technology, it's the realities of software development: customization is the enemy of maintainability and growth. Without a native software like structure to build on, the developers must provide more and more glue code to keep it all together and writing architecturally sound code is extremely hard.

Unfortunately, under deadlines this results in difficult to maintain codebases that don't scale. In the end, the ability to execute and the ability to iterate are more important than the ability to start.

Fortunately, almost all of what you need in an application is common to all applications and so there is no need to reinvent the foundations in each project. It just needs to work and work exceptionally well so that we can free up time and resources to focus on attaining the next level in the user experience. This is the SproutCore approach. SproutCore does not just include all the components you need to create a real application.

It also includes thousands of hours of real world tested professional engineering experience on how to develop and deploy genre-changing web applications that are used by millions of people. This experience is baked into the heart of SproutCore and it's completely free to use, which I hope you find as exciting a prospect as I do! As you may have noticed, I use the word "software" occasionally and I will continue to do so, because I don't want to make any false pretenses about what it is we are doing.

SproutCore is about writing software for the web. If the term software feels too heavy or too involved to describe your project, then SproutCore may not be the best platform for you. A good measure of whether SproutCore is a good candidate for your project or not, is to describe the goals of your project in normal language.

For example, if we were to describe a typical SproutCore application, we would use terms such as:. If these terms match several of the goals for your own project, then we are definitely on the right path. Let me talk about the other important factor to consider, possibly the most important factor to consider when deciding as a business on which technology to use: developer performance.

It does not matter at all what features a framework has if the time it takes or the skill required to build real applications with it becomes unmanageable.

I can tell you first hand that custom code written by a star developer quickly becomes useless in the hands of the next person and all software eventually ends up in someone else's hands. This provides a simple entry point for a lot of current web developers to start from. But more importantly, SproutCore was built around the software concepts that native desktop and mobile developers have used for years, but that have barely existed in the web.

These concepts include:. While there is also a full UI library and many conveniences, the application of software development principles onto web technology is what makes SproutCore so great. When your web app becomes successful and grows exponentially, and I hope it does, then you will be thankful to have SproutCore at its root.

Now that we've gone through some of the theory behind SproutCore, let's jump right in to see it in action.

Don't be concerned if some of this first application seems like magic, we'll go into much more detail in the later chapters. For now it's good enough to get SproutCore installed and to gain a feel for SproutCore web app development.

SproutCore is made of two parts: the JavaScript framework and the build tools. The JavaScript framework runs in the browser and powers your application, while the build tools provide a development environment and the ability to build your application so that it may be most efficiently deployed.

The build tools are written in Ruby , but you do not need to know Ruby in order to use SproutCore. It is simply the language that the command-line tools were written in and how the framework is distributed. It does mean that you will need to have the Ruby interpreter installed. Although SproutCore's build tools should technically work on Ruby 1.

If you already have Ruby 1. To verify your Ruby installation, simply run the following from the command line as shown in the following screenshot:. I prefer using Ruby 1. It doesn't seem to affect anything, but the warnings are annoying. Once you've got Ruby installed, it's time to get SproutCore.

The SproutCore gem includes the command-line build tools as well as the JavaScript framework. At the time of this writing, the latest version of SproutCore was 1. To install it, simply run the following from the command line:.

To learn of more options available to use with the sproutcore command, use:. Every SproutCore application belongs to a SproutCore project. This allows you to create multiple apps as part of a single project and share resources among them more on this later. A SproutCore project is simply a directory that contains the related apps, frameworks and themes as well as a Buildfile for the entire project. To generate an empty project directory that we can use for experimentation, we can use the sproutcore gen command.

For a project, we will use the project generator and so we will simply run sproutcore gen project from the command line. If you have a directory used for development projects, you may want to cd to it first. To create the project, open a terminal window and type the following as shown in the following screenshot:. Feel free to rename it, remove it or replace it with whatever you like. The Buildfile is important however and must be included. This file is used to instruct the build tools as to how to build the apps within your project.

By default it simply requires the complete SproutCore framework for all the apps in the project. This is illustrated in the following screenshot:. We will look at more sophisticated Buildfile settings in Chapter 6 , Testing, Building and Deploying , but for now we can leave it as it is. Now that we have SproutCore installed and a project directory to work with, it's time to create our first app. Let's start with a simple address book app, that we'll call Contacts.

Our address book will contain individual contacts and we'll be able to view and group the contacts. You'll also be able to add, remove, and modify the contacts and the groups. To generate a skeleton for Contacts , we'll turn once more to the sproutcore gen command. Go back to the terminal and run the following as shown:. Now let's launch the app and see what we have. To serve the web app locally for debugging purposes, we use the SproutCore development server. To start it, open up another terminal window and type the following:.

SproutCore apps are just static files, but these static files still need to be served to a browser in order to load correctly. The server also proxies requests to remote servers as indicated by your Buildfile. This allows you to avoid the Same Origin Policy rule that would otherwise prevent your locally running app in the localhost domain from connecting with APIs on your production domain.

We will see more on this in Chapter 6 , Testing, Building and Deploying. Now just as when we generated a project, sproutcore gen app also created some basic folders and files for us to use.

Here is a brief description of each file and directory:. Buildfile : This is similar to the project's Buildfile, but contains instructions specific to the Contacts app.

Application instance and is the first file loaded from the application code. It also contains page files, which house the preconfigured UI panes and views. Page container that holds all the panes and views that will make up the main page of your app. Theme instance for the app. By default it extends the SC.

AceTheme instance. In user-focused development, it's often good to build the interface pieces first and enable them behind the scenes later one component at a time. As a side benefit, this gives us something to get into people's hands early on in order to get valuable feedback.

To create an interface with SproutCore we use a declarative approach in JavaScript, which may seem normal if you're coming from native software development, but new if you're accustomed to working directly with HTML. Although SproutCore has toyed with using templates in the past, these attempts have always turned out to perform worse from both an execution performance and a developer performance point of view.

For now, I ask you to trust that the style we'll use ends up both faster to write and faster to run. When starting to lay out a page, the best approach is to start from the outside and work our way in. From the previous figure, it appears that we have four major containing boxes: the toolbar, the groups list, the contacts list, and the contact detail.

The preceding code gives us our four containing views: toolbarView , groupsPanel , contactsPanel , and detailPanel. You will have noticed that the child views are defined by name in the parent view's childViews array. We also used a couple pre-defined SproutCore views, SC. ToolbarView and SC. The SC. ToolbarView just adds some nice default styling while the SC. SplitView will allow the user to resize the width of each panel. In order to make the split view work properly, we mix the SC.

SplitChild mixin to each of these child views and define a few settings for how each child should behave. A mixin is a collection of properties and methods that can be added to an object or class. Mixins and the use of design , extend , and create will be covered in detail in Chapter 2 , The Runtime Environment. Let's add all the remaining components of our page.

First we'll add the title to the toolbar and give it the value of "Contacts". Notice that we declare the layout of the titleView at the same time.

By default all instances of SC. View which includes SC. LabelView in this case will be positioned absolutely according to the layout property. Absolute positioning allows the browser to avoid any reflow when the DOM is updated and is therefore much faster to use.

It's actually a very flexible approach when used with single page apps. You'll also notice that we use the controlSize property. Several SproutCore controls, such as SC.

LabelView , use the controlSize property to affect the style applied. In this case, we use SC. We can override this in CSS later if we wish. Next we'll add both of the lists with their respective control bars as shown in the following code:. Since we know that we want our lists to scroll, we've placed each SC. ListView within an SC.

We also gave our lists some placeholder content to use while we're still designing the page. Let's add the buttons to the next view. Insert the following into both the controlBar views as shown in the following code:. You can find instructions here. Once you've got SproutCore installed, checkout the Getting Started tutorial. Resources for SproutCore developers include the docs for API documentation, and the Guides for a series of topical walk-throughs.

For additional SproutCore user support, join the mailing list , or stop by the sproutcore IRC channel. For those interested in contributing to the framework itself, please join sproutcore-dev googlegroups.

Skip to content. Star 2. View license.