Welcome to Maurits Lamers and Mitch Oliver

Dec 12

Hot on the heels of last week’s introduction of five new team members, I’m pleased to announce that Maurits Lamers and Mitch Oliver have also signed on as SproutCore Committers. As with the people from my previous post, these names should be of no surprise to anyone who has been with SproutCore for some time.

For those that aren’t sure of the difference between Committers and Reviewers, Committers are actually required to work in their own branches in the repo and submit every change as a pull request to be accepted by a Reviewer. The Reviewers are allowed to make direct fixes, but will most likely submit anything at all substantial as a pull request too in order to get another Reviewer’s feedback and acceptance. Both roles also include the responsibility to try to move the outstanding issues and pull requests towards a resolution.

As you can tell from the above description, both roles are a lot of work and it takes people with a real dedication to the project to accept what can be a thankless and demanding task, so please take a moment to catch all of these people on #sproutcore and sproutcore@googlegroups.com and show them your support.

Welcome to SproutCore’s newest Committers and Reviewer

written by Tyler Keating

Dec 9

Changes to SproutCore

written by Charles Jolley

Dec 7

19 Comments

Today I am writing to announce three important changes to the SproutCore project to better accomodate the community who are using it.

Change 1: SproutCore 2.0 Is Now Amber

SproutCore 2.0 started out as a rebuild of SproutCore around a more modular and modern design. Since then, the project has evolved in a different direction that means it will never be a complete replacement for SproutCore 1.x.

Therefore, we have decided to rename SproutCore 2.0 and manage it as a separate project. The new project will take on the original code name – Amber. It will be run by Yehuda Katz, Tom Dale, and Peter Wagenet.

The Amber guys are working on a new website and complete update for the new project. When they are ready we will post a link to the blog here so you can find out more about it. In the meantime, work on this project is continuing in the sproutcore20 repository on Github.

Change 2: New Contributor Process

With the Amber change, SproutCore will now once again be the sole domain of those wanting to create fast, native style applications on the web based on the SproutCore 1.x code base.

There is a very active community of developers who have invested heavily in this area. But, due to the structure of our governance system (via a Core Team), we haven’t done a very good job at making it easy for members of the community to get actively involved.

As of today we are adopting a new contributor process that will change all of this. The new process is based on the Reviewer/Committer model used by WebKit and several other big projects. It is fully documented on the SproutCore wiki, but here are the highlights:

All SproutCore projects will have reviewers and committers. Reviewers have the authority to approve changes to the code, committers can commit code when it is approved by a reviewer.
Anyone can become a committer once they have had a few patches accepted and a reviewer is willing to sponsor them. Anyone can become a reviewer once they have experience as a committer and the majority of other reviewers votes to approve them.
There is no longer a “Core Team”. Instead, we expect reviewers and committers to agree as a group on directional changes to the project. All discussions will be held on the sproutcore-dev mailing list or in IRC. We will avoid private mailing lists.

The goal is to make it possible for anyone who is willing to put in the time and effort to contribute to SproutCore to become a leader in the community. You don’t need a secret handshake to get in – just contribute.

To get this process started, we have identified a group of people – both former Core Team members and others – who qualify as either Committers or Reviewers and reached out to them. You can see the list of those who have already accepted on the wiki. If you aren’t on the list and you want to be, please email Tyler Keating and he will help you out.

Change 3: New Leadership

Finally, I want to talk a bit about my own role in SproutCore. Over the last year, my job has evolved to include a lot less coding and more other activities. While I am still very passionate about seeing SproutCore grow, I am not able to provide the kind of detailed attention that the project needs on a day-to-day level.

Part of the solution to this is to move towards the community driven contributor process above so that no one person can be a bottleneck anymore. We also need someone who has shown dedication to the community to help lead the process.

Tyler Keating is an independent developer who has been contributing to SproutCore for the last four years. He has shown dedication to the project and a desire to get others involved that is just what SproutCore needs.

Therefore, Tyler has agreed to become the new administrator for SproutCore. He is the main guy you should now contact with questions about managing the project day to day. I am going to remain as an honorary project owner so I can chime in on directional things. In general though, I hope SproutCore can become more community directed than it has been in the past. Tyler is here to help facilitate that.

Open source is only as strong as the community around it. I have been proud to get to work with some of the best technical talent on the planet through SproutCore. Thank you everyone for your contributions over the last several years.

SproutCore exists to serve your needs. Get involved and make it your own!

PS. I am posting a similar version of this post to the SproutCore mailing list where we can discuss this in the open. Please feel free to join in there.

Why Handlebars?

written by Tom Dale

Oct 3

Handlebars

8 Comments

When people check out SproutCore 2.0 for the first time, one question that they frequently ask is: Do I have to use Handlebars?

Handlebars, if you’re not familiar with it, is a semantic templating language written entirely in JavaScript. It’s an expressive language with a tag syntax reminiscent of HTML, except expressions (oftentimes referred to as “mustaches”) are wrapped in double-curly braces. A simple template might look like this:

<div class="entry">
  <h1>{{title}}</h1>
  <div class="body">
    {{body}}
  </div>
</div>

Handlebars, unlike other templating solutions like Eco, doesn’t tempt you to embed domain logic in your HTML. Anything other than simple conditionals and loops must be contained in your application’s JavaScript, which enforces the separation of concerns and leads to better testability. The language is also extensible with custom helpers, which allows you to effectively write a template DSL for your particular application.

So, while the answer to the question is use whatever templating system you’d like, we think Handlebars is a great option. Perhaps most importantly, we’ve spent a lot of time deeply integrating SproutCore and Handlebars, such that you get a lot for free just by using bindings, computed properties, and the SproutCore object system. In fact, while we like the features and simple-yet-expressive syntax of Handlebars, the real reason we chose it when creating SproutCore 2.0 was because of its speed and architecture, allowing us the kind of integration that would be very difficult with other templating libraries.
Continue reading →

SproutCore 2 and AJAX

written by Peter Wagenet

Sep 22

Tutorial

16 Comments

A question we hear often about SproutCore 2 is “how do I connect to a server?” The answer to this question is actually easier than you might expect. Since SC2 is dependent on jQuery, we already have access to all the standard jQuery methods, including the AJAX ones. In this post, I’ll explain to you how to use AJAX in SC2 to communicate with your server.

In this example, I’ll assume a standard REST backend. To make things easier on you, I’ve made up a basic one in Rails. You can grab it with:

git clone git://github.com/sproutcore/todos-server.git --recursive

If you just want to grab the completed SC code you can run:

git clone git://github.com/sproutcore/todos.git -b server

Anyway, lets dive into the code. All of our work is based upon the original SC2 To-Dos app, and I’ll walk through how we get from there to our completed AJAXified app.

Fetching from the Server

The first step is to fetch a list of our to-dos from the server. Here’s the code to do that:

Todos = SC.Application.create({
  ready: function(){
    this._super();
    this.fetchTodos();
  },
 
  fetchTodos: function(){
    $.ajax('/todos.json', {
      success: function(data){
        Todos.todosController.beginPropertyChanges();
        data.forEach(function(item){
          item = item.todo;
          var todo = Todos.Todo.create({
            id: item.id,
            title: item.title,
            isDone: item.done
          });
          Todos.todosController.pushObject(todo);
        });
        Todos.todosController.endPropertyChanges();
      }
    });
  }
});

Continue reading →

Hubbub ❤ SproutCore – Socket.IO & Modular Loading

written by Tyler Keating

Sep 15

Tutorial

4 Comments

As promised in my last post, I’ll go into more detail on some of the technical aspects of Hubbub. And since there was only a single request to talk about Socket.IO integration with SproutCore, that’s the topic for today. In order to keep these posts down to a nice bite-sized length, today will strictly be about how Hubbub uses SproutCore’s modular loading to include Socket.IO.

Socket.IO! I Choose You.

There is actually some nice stuff that happens in Hubbub in real time if you have the app open. For example, if someone sends you a message, signs out an item to you, makes a new item available, or any number of other events occur, then the application updates instantly without requiring a page reload. Sure it’s not new, but with Socket.IO and SproutCore it’s also not a difficult-to-implement kludge.

So for those that haven’t yet tried it, Socket.IO is available here. There are really good instructions on using Socket.IO on their site, but it’s so simple I will include my entire setup here.

My Setup – Server Side

Hubbub’s app server is written with Node and Express. So after installing Socket.IO, there’s nothing more to getting it working server-side than:

app = require('express').createServer({key: …, cert: …, ca: …});
io = require('socket.io').listen(app);
app.listen(3443);

Note: I use port 3443 locally with TLS/SSL encryption, which is not strictly necessary. Continue reading →

Dispatch From The Edge: Blacklists and Whitelists

written by Greg Moeck

Sep 13

Dispatch

2 Comments

The “true edge” of SproutCore nowadays is primarily the 2.0 branch, where the new and fresh is continually appearing. However that doesn’t mean that the 1.x branch has been forsaken, or forgotten. The 1.7 beta release has some pretty cool features that allow you to improve the performance of your application. What I want to focus on today is how to use a blacklist or whitelist with the 1.x build tools.

One of the biggest knocks against SproutCore 1.x is that it is a “big, monolithic framework”. You end up pulling in more than you’re ever going to use or need. This is a problem, particularly in a JavaScript context, because it increases the size of the file that needs to be sent down from your server, and then parsed by the browser. Particularly in a mobile context, this can be a serious performance drain.

Enter the SproutCore whitelist/blacklist. If there is a section of SproutCore 1.x that you’re not using inside of your application, you can use either a whitelist or a blacklist to tell the build tools not to include that code in the final packaged version of your application’s JavaScript. So for example, if my application is not using collection view, I could create a file called Blacklist inside of the root of my file directory, and put the following into it to exclude collection view:

{ "/sproutcore/desktop": "views/collection.js" }

“/sproutcore/desktop” is the “target” for the build tools, which you can think of as basically the framework to target. Then, “views/collection.js” which is the “rule” for the build tools. If the list is a whitelist, then the rule would mean to include the file in the final build, whereas if the list is a blacklist, then the rule would exclude that file. So in this case, “/sproutcore/desktop”: “views/collection.js” tells the build tools to exclude the file “views/collection.js” from the desktop framework.

So if you have a 1.x app and you’re looking to improve the initial load time of your app, I would create a blacklist for your application, and go file by file seeing what you can exclude from the framework. Happy optimizing.

Localization in SproutCore 1.6

written by Peter Bergstrom

Sep 1

Localization

3 Comments

Why Should I Care About Localization and Internationalization?

When developing applications, localization and internationalization are things that are easily overlooked and forgotten until the very end. In the case of smaller applications, they are targeted to only one language, and not having to account for localization or internationalization might work out in the end.

However, especially for larger applications or applications that are targeted to several international markets, planning and implementing an application with localization and internationalization is extremely important. Without proper planning, you can get into a lot of trouble that could have been alleviated with very little upfront effort. The type of planning you’ll need to do is what we’ll go over in this in this post.

Factor in localization early in your development cycle!

As a developer, you should plan for localization and internationalization early in your development cycle, when it is easy to deal with. Once an application grows too large, it is very difficult to add localizable strings.

If you develop without taking into account localization, often text winds up hard coded and, as with any application, these strings are found in a million different places. Having to track down all the non-localized strings after the fact is time consuming and unnecessary if accounted for earlier in the project.

Localizing Your Apps with SproutCore

SproutCore makes it easy to localize your application. Using a strings table for each language, developers can enter key-value pairs. These keys are generic and are referenced throughout the application.

When the application runs, instead of using the actual string in the view, SproutCore looks up the correct localized value from the strings table. This makes it easy not only to localize the application, but also to manage all of the strings in your application because they are all located in one place. If you need to finalize the strings, you can send that off to be finalized without having the stakeholders know any JavaScript.
Continue reading →

SproutCore 1.7 Beta Released

written by Peter Wagenet

Aug 30

Release

2 Comments

I’m pleased to announce that SproutCore 1.7 beta is now available. This release is largely a bug fix release and the addition of some minor features so if you’re using 1.6 and like the cutting edge you should check it out. Installers are available for Mac and Windows. If you’re using RubyGems, just run gem install sproutcore --pre. A word of warning, however: if you’re using the installers the beta will overwrite any previously installed versions of SproutCore. As always, share any issues you encounter on Github Issues.

Read on for more information on the changes. Continue reading →

Video from the August South Bay Meetup

written by Madeleine Douglas

Aug 26