33 karma · joined January 12, 2011
There is already an iOS serial cable though, which I would think would be a better option for many projects:
This is the problem with Padrino- it isn't different enough. We don't need a smaller MVC Ruby framework, as there isn't much space between what Sinatra is great for and what Rails is great for.
There is also an assumption that scaling Sinatra up is a good idea. I'd propose that it's likely not.
You can even write a Sinatra clone in very little code on top of Rails: http://yehudakatz.com/2009/08/26/how-to-build-sinatra-on-rai...
If you already know Rails, there is very little reason to build a substantial app in anything "smaller". The reality is that for any moderately-sized app, you will end up using many of the parts of Rails that you think are unnecessary in the beginning. Especially as your app grows.
I tried using Padrino for an app a year ago, and while the framework has probably matured since then, I moved back to Rails fairly quickly due do a lack of polish/documentation/community/benefit other than being different.
There is a common tendency to find a part of a framework that doesn't work exactly the way you want, and in turn throw the entire framework out and seek out or write something new. I still prefer the way Merb and Sinatra handle responses, where the controller action return value is the response sent to the client. But the benefits that Rails provides so outweigh many of these kind of preferences that it's usually best to just embrace the way the framework works and move on to actually building an app that does something.
It's also short sighted to discount how valuable the wealth of existing documentation and extentions exist for an established framework such as Rails.
The presentation makes it sounds as though by using Rails you have to use SASS and Coffeescript. This is not true, you can easily use plain JavaScript and CSS if you want.
The majority of developers will be more productive in Rails.
You will probably still have to look at the API docs (and read some source) from time to time, but the core team is taking documentation a lot more seriously now.
SC 2.0 seeks to change this, by making the framework much more modular (think Rails 3) and trying to do less. KVC/KVO really pay off on larger apps by allowing the data to drive the app instead of you having to write a lot of boilerplate code to push data and UI elements around as changes are made to the data. Statecharts are really useful for giving structure to a complex client-side codebase- I highly recommend using them.
I have only looked at Backbone briefly, so I can't comment on how it compares on a real app. But my gut is that it boils down to this: with Backbone you will be writing more framework-level and boilerplate code, which may seem more explicit, but will also be harder to maintain. With SproutCore, you will be relying on the framework to do more, but you will have to understand the framework in order to take advantage of what it offers you. And since SC 2 is still under heavy development, you should be OK with adapting to change as the framework matures.
At the Chicago SproutCore Meetup, Tom Dale mentioned that they are working on a new UI toolkit to take the place of the one in SproutCore 1.x. There has been no word when that will be released, but I would expect a widget demo of some kind when it is.
Separating the results into exclusive types (testing framework, browser integration framework, assertion macros, etc) would make a lot more sense. Or asking what tool is being used for a particular task (unit testing, integration testing, mocking/stubbing, assertion macros, etc).