I'm sorry that you were turned off by the Ruby build tools.
Many people see the build tools and assume that you need to know Ruby to use SproutCore. This isn't true. SproutCore apps are written 100% in JavaScript, and Ruby just happens to be the language we used to create the tooling needed to build serious web applications.
For example, the build tools will automatically concatenate your JavaScript and CSS files, minify them, ensure that dependencies are loaded in the correct order, provide a proxy so you can work around the single-origin policy during development, generate unit tests, and much more. We think that the trade-off is worth it, especially since all Linux and Mac OS X distributions come with Ruby and RubyGems.
One of the guiding principles behind SproutCore is that it allows you to build well-architected JavaScript applications where the separation of concerns is clear. Being able to organize your JavaScript files is an important part of that. I think you'll find that when you start building web apps of any serious scale, you'll end up assembling a collection of command-line tools that do all of these things. We just put them all in one place for you.
Thanks for the response. I wasn't annoyed by any means. It's just really confusing and I think sending mixed signals (hence, "what the hell?").
Most need to be sold on what's possible before I can be sold on organization and architecture. If that's not your target audience then I don't think this is a big deal. But if you want to get your hard work out to the masses then show them what's possible and worry about the organization and architecture later :).
I had a similar reaction when I saw the mention of Ruby. I think it's a subconscious thing. It would help if you put this explanation up on the site in a prominent place as well.
...the problem is that there is no reason that a demo for a web framework should require an install in the first place--I mean you're already on a web page to look at it aren't you?...sure it's easy enough to install (i did it)...but it seems lazy especially if the intent is to promote usage of the framework.
We're working on new demos, and a new website. Demos feature much more heavily in the new design, and you definitely don't (and won't) need to install the build tools to run them!
I would encourage you to make that a priority. Every time I see something about SproutCore, I'm interested but end up not doing anything with it. I keep hearing about the demos being out of date.
Things like this: "we have a great new default theme called Ace 2.0"
Sounds great, how about a screenshot or two, if not a demo?
And this: "looks at home on ... mobile operating systems"
More info please? I'm interested but I see no examples, screenshots or other info about doing mobile dev. Device, browser and OS support?
Fair points all around; I agree wholeheartedly. Here's what the problem has been thus far: do we focus on making the framework better, or do we focus on selling it? Personally, I'm much more comfortable with making sure we deliver the goods before we try to sell it. That's what SproutCore 1.5 is about. This is the first smoke signal of where we want to head with the framework, and people can take that for what it is. The core of the framework is amazing and fun to work with, but a lot of our demos are old and ugly. In many cases, our documentation has been or is still lacking and we're working on that too.
This obviously makes it a tougher sell. However, when people actually start building apps, their responses are overwhelmingly positive and they're very happy with their decision. I would much rather this problem than vise versa. We're going to work on the outward facing stuff, I promise.
Good to hear. The way I (and most people) decide which frontend libraries to use are by seeing them in action. Then I can decide after evaluating it technically if it's something I want to use or not.
Couldn't agree more Colin, let us (the community of people building apps with it) continue to do the evangelizing, your team has been doing a great job and we appreciate it a lot.
agree with the above...went through some eval on SC a few months back. We didn't go with SC, not for the lack of the demo link (swear the demo link wasn't there then :)), but I recall being a bit off put about it as well
...seems there has been a lot of development since though, some updated demos would really be nice.
We've also created a build of SproutCore that fits into a single, <50k gzipped file. It's definitely experimental, but you can find an example application running it here (built using HTML5 Boilerplate):
for a bunch of hackers on hacker news, there's an awful lot of prissy "ew, might get my hands dirty" feedback going on here
sorry, but it's been a long day and I'm sick to the back teeth of people bitching about other people's hard work because it's not exactly to their liking
You're right. I didn't intend on coming off bitchy but can see how my choice of words made it seem so.
Anyways, my point is just that the team ought to work on their message to potential users of their library. It's a small price to pay to reap the rewards of their hard work.
Comments
I'm sure it's got its merits but the Sproutcore site does a horrible job explaining what it excels at.
For example, on the Demos and Sample Code page it has me install a ruby gem.
http://www.sproutcore.com/demos/
What the hell? You lost my interest at ruby and the command line.
I'm sorry that you were turned off by the Ruby build tools.
Many people see the build tools and assume that you need to know Ruby to use SproutCore. This isn't true. SproutCore apps are written 100% in JavaScript, and Ruby just happens to be the language we used to create the tooling needed to build serious web applications.
For example, the build tools will automatically concatenate your JavaScript and CSS files, minify them, ensure that dependencies are loaded in the correct order, provide a proxy so you can work around the single-origin policy during development, generate unit tests, and much more. We think that the trade-off is worth it, especially since all Linux and Mac OS X distributions come with Ruby and RubyGems.
One of the guiding principles behind SproutCore is that it allows you to build well-architected JavaScript applications where the separation of concerns is clear. Being able to organize your JavaScript files is an important part of that. I think you'll find that when you start building web apps of any serious scale, you'll end up assembling a collection of command-line tools that do all of these things. We just put them all in one place for you.
Thanks for the response. I wasn't annoyed by any means. It's just really confusing and I think sending mixed signals (hence, "what the hell?").
Most need to be sold on what's possible before I can be sold on organization and architecture. If that's not your target audience then I don't think this is a big deal. But if you want to get your hard work out to the masses then show them what's possible and worry about the organization and architecture later :).
I had a similar reaction when I saw the mention of Ruby. I think it's a subconscious thing. It would help if you put this explanation up on the site in a prominent place as well.
> What the hell? You lost my interest at ruby and the command line.
I install all my dev stuff with the command line (npm, gem, easy_python etc). What's wrong with that?
...the problem is that there is no reason that a demo for a web framework should require an install in the first place--I mean you're already on a web page to look at it aren't you?...sure it's easy enough to install (i did it)...but it seems lazy especially if the intent is to promote usage of the framework.
I wanted to try the demo many months ago, and had to stop at the first line:
There's no way I'm polluting my desktop ruby install. Please document a way to set up a standalone folder.(if had been python I could have hacked it myself. i dont know ruby)
We have a link to our, albeit totally old and crappy, demos right on that page: http://demo.sproutcore.com/
We're working on new demos, and a new website. Demos feature much more heavily in the new design, and you definitely don't (and won't) need to install the build tools to run them!
I would encourage you to make that a priority. Every time I see something about SproutCore, I'm interested but end up not doing anything with it. I keep hearing about the demos being out of date.
Things like this: "we have a great new default theme called Ace 2.0"
Sounds great, how about a screenshot or two, if not a demo?
And this: "looks at home on ... mobile operating systems"
More info please? I'm interested but I see no examples, screenshots or other info about doing mobile dev. Device, browser and OS support?
Fair points all around; I agree wholeheartedly. Here's what the problem has been thus far: do we focus on making the framework better, or do we focus on selling it? Personally, I'm much more comfortable with making sure we deliver the goods before we try to sell it. That's what SproutCore 1.5 is about. This is the first smoke signal of where we want to head with the framework, and people can take that for what it is. The core of the framework is amazing and fun to work with, but a lot of our demos are old and ugly. In many cases, our documentation has been or is still lacking and we're working on that too.
This obviously makes it a tougher sell. However, when people actually start building apps, their responses are overwhelmingly positive and they're very happy with their decision. I would much rather this problem than vise versa. We're going to work on the outward facing stuff, I promise.
Good to hear. The way I (and most people) decide which frontend libraries to use are by seeing them in action. Then I can decide after evaluating it technically if it's something I want to use or not.
Looking forward to doing that with SproutCore.
Couldn't agree more Colin, let us (the community of people building apps with it) continue to do the evangelizing, your team has been doing a great job and we appreciate it a lot.
agree with the above...went through some eval on SC a few months back. We didn't go with SC, not for the lack of the demo link (swear the demo link wasn't there then :)), but I recall being a bit off put about it as well
...seems there has been a lot of development since though, some updated demos would really be nice.
This is a client side (100% JavaScript) library. I love the command line, but shouldn't invoke it to learn more about a JavaScript library.
Backbone.js (http://documentcloud.github.com/backbone/) is a great alternative to SproutCore if you're turned off by the gem install.
We've also created a build of SproutCore that fits into a single, <50k gzipped file. It's definitely experimental, but you can find an example application running it here (built using HTML5 Boilerplate):
http://amber-todos.strobeapp.com/ (demo)
https://github.com/wycats/experimental-amber-todos (source)
for a bunch of hackers on hacker news, there's an awful lot of prissy "ew, might get my hands dirty" feedback going on here
sorry, but it's been a long day and I'm sick to the back teeth of people bitching about other people's hard work because it's not exactly to their liking
You're right. I didn't intend on coming off bitchy but can see how my choice of words made it seem so.
Anyways, my point is just that the team ought to work on their message to potential users of their library. It's a small price to pay to reap the rewards of their hard work.