If you optimize a framework for beginners, you're optimizing for learnability. That's great for the first few days or even weeks of learning. But once you're past that, it's not so great. What you care more about is the usability of the thing once you know it. There are plenty of cases where learnability and usability are in conflict. Letting learnability win is a short-term relief.
If you on the other hand optimize for usability, for making things simple and easy to use for someone who understands the basics, you'll often end up with something that has great learnability as well. Maybe not as much as could be achieved as if that was your only goal, but plenty still.
The other aspect is whether you as a framework designer are designing something for yourself and your peers or if you're trying to dumb things down on behalf of beginners. In other words, designing for what you think beginners might find easy in their learning phase. That's really hard to do. Most technology I've seen designed in such a master/apprentice fashion sucks.
Finally, when you're comparing complexity, it's generally more helpful to look at the complexity involved with completing an entire task. Comparing complexity of "hello world" tells you little about what the complexity is going to be like developing a complete, modern web application from database migrations to XSS/CRSF protection.
That's where learnability and usability are again in conflict. Yes, it's harder to learn a framework that has answers for things like "how do I migrate a database once I have data I care about", or whatever feature you want to focus on, but once you hit that problem, you'll be glad that it's there and find the solution less complex than stringing something together from tons of separate parts yourself.
All that being said, I think Sinatra is wonderful. So what if it's not a fit for building a whole Basecamp or Github? It's great for teaching someone the basics of how HTTP works and it's great for smaller surface apps or for smaller, isolated parts of bigger apps.
I apologize if you've addressed this elsewhere, but do you have any specific suggestions beyond http://guides.rubyonrails.org/ for a beginner (who knows basic HTML/CSS but not much else) trying to learn Rails?
I've been using RailsTutorial, and while it's packed with info, I feel like I would benefit from a more solid understanding of many of the basics.
>All that being said, I think Sinatra is wonderful. So what if it's not a fit for building a whole Basecamp or Github? It's great for teaching someone the basics of how HTTP works and it's great for smaller surface apps or for smaller, isolated parts of bigger apps.
Sinatra is actually a great foundation for big things, although it doesn't give you the whole stack, but only the way how to build your stack.
I've been developing on Padrino (which builds on Sinatra) for 2 years now and I am still surprised by how easy adding features/plugins to Sinatra (and by that, Padrino) is, especially as the most useful Rails plugins now also come with a "pure rack" variant.
On the other side, I often ran into problems with the huge stack that Rails has, so that I had to tackle issues far before I actually needed a feature.
I personally went from PHP > RUBY > Ruby(cgi) > Sinatra > Rails, And i think the journey was great because sometimes we need to learn and work in really bad technologies to appreciate something as good as rails.
We should strive to make the learning curve more enjoyable rather than making it beginner friendly, The only way i know of doing that is to show evolution of technologies, there merits and de-merits and why or how we have reached where we have reached and why we took the technological decisions that we took. How we reached to rails from PHP or cgi. How treacherous the journey was.
Rails just has too much magic and higher level of abstraction built in that it easier for beginners, But when you want to do something really great you need to look under the hood. That is RUBY, Rack and HTTP.
I think learning something as basic as sinatra is much better than learning rails , so that you have some idea of the underlying stuff and then when you move to rails you can learn more of rails by just looking at its code.
Personally i learnt a great deal from looking at rails source than looking at a tutorial. But surely it would be a daunting task for a noob. Also learning Rack comes naturally with sinatra. and as you look at Rack, sooner or later you would figure out how to write a cgi adapter for your rack app.
Then Comes rails which saves you from all the mundane task you were doing developing in sinatra and much more.
This way you would have a better understanding and appreciation for rails and all the stuff that you don't have to do or write in rails.
At the same time you will have a better understanding of how a particular feature is working in rails. This improves your debugging skills because you know where to look for when something goes wrong.
Finally Ruby is the elephant in the room so you need to be better at ruby to become excellent at rails, Which often is shadowed by the magic that rails provides, so learning RUBY first is more important than rails, sinatra or anything.
I beg to disagree. Learnability and usability can get along together. Good examples are Jquery and Cakephp. Both have executed this very well from producing well written and well maintained documentation then add a good amount of plugins that is contributed by the community.
For example, in cakephp we have this cook book http://book.cakephp.org which the quality of the content surpasses every cakephp book on amazon.
So, like apps "simple & feature rich" can get along together like "learnability & usability" can get along too. It just needs more work.
> But the CoffeeScript/Backbone.js route is harder for
> beginners but in the long run it's a much better choice.
What you say makes no sense. Ok it makes sense, but does not make sense in context of jQuery. jQuery was never intended to be a framework or tool to organize your code. It is just a DOM/events/Ajax library, that's it. Its purpose is completely orthogonal to what Backbone does and even more so to what Coffeescript does. You don't manipulate DOM with Coffeescript or Backbone, but you may use Coffeescript to write your DOM manipulation code and you may use Backbone to organize your code.
The problem with cakephp is that every book written on this subject surpasses the quality of the framework itself.
cakephp is easy to learn, but for me it's unusable in the long run. Easy stuff get's even easier, hard stuff get's harder.
That's exactly what David meant. If you trade everything for learnability, it's not usable.
That sums up my experience with cakePHP too. I don't know what's happened with this framework in the last couple of years, but when I was first learning Rails and enjoying it, I used cakePHP for a big project because I knew PHP well, and didn't yet feel comfortable with committing to using Rails for it.
That was a decision I regretted many times. The hoops I had to jump through to deal with complex database queries were ridiculous. The difference in quality and robustness between ActiveRecord and cakePHP's ORM (at that time, anyway) were pronounced, with AR coming out way, way ahead.
There's no doubt, in my mind, that if you are going to take on a large, ambitious web application project, you'll be better served by Rails.
Yes, CakePHP's "ORM" isn't a real ORM - it was built when Objects were awesomely broken in PHP4 - but I've actually found it much more usable than the current state of Ruby's ActiveRecord/Datamapper. Manipulating arrays to get just the SQL you want is sometimes annoying, but for the queries that you honestly can't get out of the ORM in CakePHP, it's also likely you wouldn't be able to do the same in any other ORM.
You'll also have to note that both frameworks have progressed significantly in the last few years - CakePHP actually just released a new major version, as did Rails a few months ago - so your experience a few years ago - was this in the 1.1 era - would just be indicative of the framework's beginnings, not where it currently is.
Feel free to message me with your thoughts if they still conflict; I'd love to hear the other side of the story since improving CakePHP as a framework helps not just my ego, but other developers who are using CakePHP to make a living :)
- In my very humble opinion, only one - English! I can't comment on the international community - book has been any good (That by Mariano Iglesias) and they all tend to either have outdated information or just bad code samples. So no, they do not surpass the quality of the framework.
- Hard stuff is always hard, regardless of the framework. At a certain point, you start butting heads with limitations in the language, at which point no framework will help. I've also found "hard stuff" to be fairly easy in CakePHP due to the large plugin base I can reach into - only Django and Ruby Gems really solve this sort of problem - so no, the hard stuff doesn't get harder.
Regardless, I'd be more than happy to get your feedback on this though. Send me a message :)
Can't comment on CakePHP, but I think jQuery is actually an example that favors DHH's view: It really simple to get started with, and there's tons of cools stuff you can accomplish. But try building a full web app along the lines of GMail or Google Docs with it and you'll quickly see that there's only so much you can do well with $(). In a simple website, jQuery can take care of all your JS needs. In a full fledged web application, it's mostly magic in the View.
One of my favorite Alan Kay quotes: "Make simple things simple, and complex things possible." And the Albert Einstein quote everyone mangles: "A scientific theorem should be as simple as possible, but not simpler." It's a matter of finding the sweet spot where the system is easy enough to learn to be accessible, and sophisticated enough to be powerful. In terms of usability, I've generally been happy with where Rails falls on that spectrum. The real challenge with Rails is learning the codebase well enough to make effective contributions to the framework.
I don't think you need to go from Sinatra to Rails - I actually started with Rails and like dhh said - before I knew it I was building real apps. Rails provided a great framework to get something up and running. It provides MVC and interacts with a database. After familiarising myself with Rails I started using Sinatra (which doesn't offer any MVC or support you get from Rails) and then ultimately started coding just in Ruby. I don't think there's any issue with the learning curve for Rails because it provides the support where you need it. I speak to new developers all the time who use Rails and get it almost instantly - releasing apps a week or two later.