From Standard Pixel:

Indeed we are becoming more and more aware that there are two different categories of web project, Web Apps and Web Sites. Web Apps are a lot like a desktop client. Users expect to have a single interface and be able to get to everything they need in few clicks. Web Sites, on the other hand are more like a news paper and people expect to enter through a front page of some kind and explore in to get more detailed information on a subject. For me, I have settled on creating one Web App project with a Ruby on Rails back-end mixed with a client written in SproutCore. Another project however, is a simple information site which will use PHP, along with a little interface help from YUI. - SproutCore is a chainsaw and YUI is a paring knife.

Could not agree more.  We decided a long time ago that there is a big difference between building a thick-client JavaScript app vs a web site with some JavaScript enhancements.  Thick-clients require a whole new level of complexity that web sites don’t have.  Use the right tool for the job.

Tags: Opinion by charles
2 Comments »

Onitunes has been hard at work the last few weeks writing an excellent tutorial on the model portion of SproutCore Model-View-Controller architecture.  It’s a great explanation of how to use models in your own applications.

Check out SproutCores Modern Models.

Tags: Announcements, Uncategorized by charles
No Comments »

What kind of backend server technologies does SproutCore work with?  Anything.  And to prove it, cpomer just posted an excellent tutorial on building a SproutCore app and paired backend service in ASP.net.

Way to go!

(BTW, take a look at that wiki while you are there.  It’s hard to believe its only been up a week.  The community around this project is amazing!)

Tags: Uncategorized by charles
6 Comments »

Calling all developers - It’s time for a contest!

That’s right, a contest.  In order to really show off what SproutCore can do, and to help foster the growth of great SproutCore developers, we are looking for you to create the best demo app possible.  Rules?  Simple.  To enter:

1. Must be built using SproutCore (of course)
2. Must feel like a desktop app (you’ll find that easy to do when you follow rule #1)
3. Just create a cool demo doing anything you like and host it somewhere online.
4. Must be submitted to the wiki - (http://github.com/sproutit/sproutcore/wikis/sproutcore-demo-awards-1)
5. Send an email to sproutcore@sproutitmail.com with your email address and the name of your entry
6. OH, and must be completed by midnight on July 21.

Only 3 weeks!? That’s right.  3 weeks.  But, I think you will be surprised how fast you can put something together using SproutCore.  But, to win, your app must have that “wow” factor.  We will choose the top 4 apps and winners will be announced at the first SproutCore Founder’s Meetup on July 23.

So, what’s in it for me?  Glad you asked.

• link from the SproutCore demos page to your app
• a special badge to place on your website (hey, even chuck norris wore a badge)
• free t-shirt …. you know you want it
• chance to present your award winning app at the Founder’s Meetup
• never ending glory and bragging rights!

Time to get to it.  We look forward to some great apps!

Tags: Announcements by chris
5 Comments »

Everyone always asks: “What is the difference between SproutCore and GWT?”.  If you don’t know, GWT is the Ajax library developed by Google.  You write Java code, which is translated into JavaScript for you to run in the browser.  

I could go into lots of details about the specific strengths or weaknesses of this or that feature, but the big difference between GWT and SproutCore can be summed up with this quote from their from page:

Google Web Toolkit (GWT) makes it easier to write high-performance AJAX applications. You write your front end in the Java programming language and GWT compiles your source into highly optimized JavaScript. Writing web apps today is a tedious and error-prone process. You spend 90% of your time working around browser quirks, and JavaScript’s lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile. It doesn’t have to be that way.

In other words: we don’t like JavaScript.  It’s not Java and it’s hard.  Use GWT instead and avoid learning that language altogether!

SproutCore’s approach, as you probably know by now, is quite the opposite.  Embrace JavaScript.  It’s a good language once you get to know it.  The tedious and error-prone part of it is not the fault of JavaScript, its the natural state of the web browsers and their relatively primitive APIs.  But that’s what a framework is for.

Here’s the problem with using something like GWT or any other framework or tool that lets you write in <insert favorite language here> and then converts it to JavaScript:  they can’t always get it right.  

Every framework, even SproutCore, makes some assumptions about the kinds of problems you will need to solve or how your code will need to perform.  When you run up against these limits (and you always will) in a platform that tries to isolate you from JavaScript what do you do?  Well you have to write the JavaScript yourself.  Only now the problem is twice as hard because you have to figure out how to interface with that super-optimized, totally unreadable code generated by your tool as well.

With SproutCore, if you want to do something not anticipated by the framework, well, write a little more JavaScript.  It will be easy to interface with the rest of your app because that is what SproutCore does. Better yet, use one of the many libraries already out there to help you.  It feels totally natural and normal to do this because you get to stay in the same platform where you belong.

The point is, any framework that tries to help you avoid learning JavaScript, be it GWT, ruby helpers, or anything else, is fine when you have some relatively simple things to do.  But if you want to build apps that really shine in the browser, you need to go native.  Use the technologies that the browser is made of and you’ll be far happier in the long run.

And that’s the difference between SproutCore and GWT.

Update: I have great respect for the GWT team and what they have built.  It’s an amazing feat of technology and very useful for any Java engineer who needs to add a little Ajax love without learning JavaScript.  But for the kinds of apps SproutCore is designed for, we differ on the approach.  The purpose of this post is to explain that difference.

Tags: Opinion by charles
23 Comments »

Andrew Tetlaw, a Technical Editor at Sitepoint, decides to look at SporutCore to see just what it can do.

As a JavaScript fan I’m impressed; the interface performance is excellent. SproutCore raises the bar for what JavaScript can do in the browser.  Read More…

Tags: Announcements by chris
No Comments »

By far the most requested addition for the SproutCore site over the last few days has been a tutorial describing how to interface with the server.  There is a lot to cover in this area, but you can already start to see some great material developing thanks to the hard work of several people including onitunes, stefanfoulis, methote and others.  Check these out to get some more info on how the backend works:

• SproutCore’s Modern Model Layer - The developing tutorial on building a ToDo application integrated with a backend.
• Using the built-in REST API - A description of the built-in classes that help you interface with a REST-ful API.  More is coming, but this is a great start!

Check out these great tutorials, and chip in by improving them or adding more detail.  Just check out the Wiki Editing Guidelines to get started.  It’s very easy.

Tags: Announcements by charles
1 Comment »

Just a week after releasing the 0.9.10 release, we have a new gem for you called 0.9.11 or “This one goes to 11″.  This release includes a number of important bug fixes that have kept some of you from using SproutCore as well a few useful new features for integrating with a backend.  The bug fixes include:

• Windows Support.  0.9.10 supported building SC apps for production on Windows machines but you couldn’t use it in dev mode.  Images and other static resources would be missing because the sc-server tool depended on a Unix-only symlink.  This is now fixed in 0.9.11 so no symlink is required.  0.9.11 should allow you to work completely in Windows now.  Please let us know if you run into more trouble.
• Spaces in Volume Names.  If your install path (including the Volume Name) included spaces, this would break the build tools, especially the documentation engine.  Paths are now properly escaped so you can put the spaces back in your paths.  

Those are the fixes, now for the features.  

Introducing Proxy, by SproutCore

One of the most challenging parts of working with SproutCore in the past has been interacting with your backend server.  SproutCore apps are loaded using sc-server in dev mode an then communicate with your backend server using Ajax.  This architecture is one of the best things about SproutCore because you can use it with any backend technology.  However because of the same origin policy of web browsers, testing has always been a bit difficult because you had to setup a reverse proxy on your dev machine to proxy both SproutCore and backend traffic to the same domain.  If that sounds complicated, it is.

Now with 0.9.11 you can avoid all this because reverse proxy support is handled directly by sc-server.  Just add one line to your sc-config and you’re good to go.  Let’s say for example, you were working on a SproutCore application with a Rails backend.  You load your SproutCore app by visiting http://localhost:4020/myapp, but your Rails server is running on port 3000.  How does your application talk to the Rails server?

Simple, just add the following line to your sc-config.rb file and restart sc-server:

proxy '/rails', :to => 'localhost:3000'

Now any request your SproutCore app makes via XHR to /rails will be proxied by sc-server to your Rails app so you can talk to the backend.

This new feature is important because it makes the process of hooking your dev servers together into a format that resembles your production environment a one step process instead of dozens of steps involving apache like it did before.  

To put a cap on this new feature, we’ve added the beginnings of a new demo app to the samples project.  It’s a twitter client that right now will fetch the public feed of any user.  How does the client talk to twitter?  Well, if you look at the sc-config.rb file for the samples, you will see this line:

proxy '/', :to => 'twitter.com'

Done.

The forthcoming tutorials we are writing for tying a SproutCore app to a backend will explain how to use this feature in more detail but until then, for an example of tying your app to a backend, please see the Twitter client under development. 

Other Features/Fixes

There are some other great feature improvements in 0.9.11 including:

• sc-server is now much faster thanks to some config changes to Merb.
• The sc-server is now much more sane about how it handles sc-config.  You can now simply drop the latest sproutcore or prototype into your frameworks directory without having to edit the sc-config file and sc-server will pick up the latest version after you restart it.
• Improved documentation for various classes.
• Improved CSS appearance in FireFox 3 thanks to mde
• Removed debugger statements that could cause problems on some platforms thanks to August.

Below is the full set of release notes for this new release, but it is recommended that everyone upgrade.  To upgrade your sproutcore just do:

sudo gem update sproutcore

In your shell.

Thanks to everyone who contributed tickets and patches for this release.  You make a growing community of developers’ lives a little easier.

SproutCore 0.9.11 Release Notes

Framework

• [FIX] innerFrame tests were failing.  Now working.
• Progress bar now shows 100% fill when set to indeterminate.  This should make it easier to style an indeterminate appearance.
• Changed all references for window.location= to window.location.href=.  Improves IE compatibility.
• Cleaned JSLint warnings from animator.js
• Removed stray debugger statements (thanks august!)
• Fixed CSS issues with SC-theme that made buttons appear offset.  Now appears correctly in FF3 & Safari (thanks mde!)
• Added detect-browser script which can be included at the top of your page to detect the current browser and platform.  Also includes an  SC.setupBodyClassNames method that you can call after the body tag has been declared that will add class names for the current browser and platform. 
• Added documentation for Function.property(), SC.Error, and SC.SegmentedView

Build Tools

• Build tools are now much smarter about how the they process configs.  Before if you imported a framework (such as sproutcore) into your project you would need to import any dependent frameworks as well AND create configs for all of them.  Now you do not need to do that.  The build tools will load the most recent base environment (defined in config :all), along with the most recent bundle-specific config (defined in config :bundle_name) and the bundle-location details from whatever library holds the bundle.  This will avoid a whole class of head-scratching config probs that people encountered when trying to setup their system.
• Removed unused controllers array from core.js template in client generator
• sc-server now supports the new proxy option in sc-config.  You can use this to proxy your backend services through to your front-end SproutCore clients without having to setup a separate service.
• Changed some launch options for sc-server that will improve performance.
• JSDoc can now handle paths spaces in them.
• Build tools no longer rely on symlink in dev mode.  This should improve compatibility with Windows systems.

Tags: Announcements by charles
2 Comments »

Techcrunch launched a new blog yesterday discussing the technologies that drive the enterprise tech space.   SproutCore is honored to be one of the of the lead stories they will be following this year.

Check out the interview giving the some history and future plans of SC!

http://www.techcrunchit.com/

Tags: Announcements by peter
1 Comment »

This guy gets it:

This is why projects like Sproutcore have me excited. Never mind the whole “Cocoa on the web angle” that a lot of people are talking up when describing it. It’s exciting because it is promoting a “back-end neutral” philosophy and emphasizing that people who ignore Javascript are turning their backs on a lot of good functionality. - New Trends in Front Ends

Tags: Opinion by charles
1 Comment »