Sproutcore 1.5 released(blog.sproutcore.com)
blog.sproutcore.com
Sproutcore 1.5 released
http://blog.sproutcore.com/post/4788153769/sproutcore-1-5-released
5 comments
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.
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 :).
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?
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:
(if had been python I could have hacked it myself. i dont know ruby)
gem install sproutcore
(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!
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?
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.
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.
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.
...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)
http://amber-todos.strobeapp.com/ (demo)
https://github.com/wycats/experimental-amber-todos (source)
[deleted]
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
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.
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.
Leaving out screenshots or a demo of the new theme was definitely an oversight on our part. Sorry!
I've put up a build of our sample controls app that demonstrates the new controls:
http://samplecontrols.strobeapp.com/
I've put up a build of our sample controls app that demonstrates the new controls:
http://samplecontrols.strobeapp.com/
I browsed the buttons demo for a while, then went to "Panels" demo. The combo box worked fine at first, but after I opened an alert box and closed it, the combo box does not work properly any more. The combo box popup does not appear in the place it should be.
Screenshot: http://i.imgur.com/EgRNJ.png am on chrome 10, linux.
Screenshot: http://i.imgur.com/EgRNJ.png am on chrome 10, linux.
Scrolling the scroll views in this demo is unusably slow on my macbook pro (Safari 5, OS X 10.6).
We (matygo) use SC for our client side app, and once we got over the learning curve we came to really enjoy it. The reason I posted this was there is a lot of great stuff they put into 1.5 that should lower the barrier to entry for a lot of people :)
We're seriously considering sproutcore for our next web project. Personally I'm a little uneasy about investing so completely. I mean it's nothing like jQuery or other libraries where you just sprinkle it here and there, it's an entire development methodology. It'll be interesting to see how it goes.
Would be really great to see some feedback from other users.
Would be really great to see some feedback from other users.
With the release of Amber you'll be able to sprinkle in only the view layer, or only the core if you see fit. So it'll be less of an investment.
However personally I think the other stuff that is in there is pretty slick as well. The data bindings are pretty handy.
However personally I think the other stuff that is in there is pretty slick as well. The data bindings are pretty handy.
Yeah, my boss is really sold on it. I think I'll come round to it once I start playing with it. Interesting to hear about amber though, thanks!
I'd be interested in the templating stuff as a jQuery plug-in. As it is, knockout.js is a lot less violent for someone working with an existing application.
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.