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.
On top of that, I actually talk to beginners all the time who are thrilled with the ease of learning Rails. They're building real apps they never thought they could complete on their own.
Naturally, there's some selection bias there (most people who give up are unlikely to write), but that doesn't change the joy for the people who did have a great and easy time.
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.
Going to have to disagree; railsforzombies is so thin on information, I don't really feel like it's worth the time. Then again, it takes only like 20-30 minutes. So go for it I guess.
>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.
Because sooner or later you will realize that a web app is nothing more than HTML/CSS/Javascript so you know the nuts and bolts of the underlying infrastructure the better.
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.
I don't agree about JQuery. The learnability is good and it's really easy to get things done very fast. But when the code base grows it becomes really hard to maintain the code if you don't know JavaScript very well and know how to structure the code.
That's why many people have started to use CoffeeScript and/or Backbone.js to write more maintainable JavaScript. But the CoffeeScript/Backbone.js route is harder for beginners but in the long run it's a much better choice.
> 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.
Read closer. Never does he say usability and learnability are opposed, just that there are opposing cases and that he doesn't agree with optimizing for learnability first.
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.
Like you said, I get people to use Sinatra for a while before getting in to Rails. It gets them in to MVC style apps while keeping things simple. Definitely recommend it as a stepping stone to Rails.
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.
The size of the code base has nothing to do with whether something is for beginners. Beginners don't read the code to find out what something does, they read the docs and the tutorials. It's mostly about tutorials to get them started, and quick iteration so they can see the fruits of their progress, combined with being a solution to a problem they have.
Excel is a great example of something that can get beginners involved in computing. Huge code base, but lots of tutorials, and solves problems people have.
If people's problems were along the lines of needing a website that can say "hello world" then Sinatra would be perfect, if their needs are more along the lines of CRUD app with web and iphone front ends then rails will likely serve them better.
I've been dealing recently with a guy who asked me for some tutorials on XCode, although he absolutely cannot code with Storyboards and Interface Builder he's fully mocked out apps that he wants developed. It's that kind of thing that gets people coding.
I teach Rails a lot. I've ranted and raved for the last year how Rails 3 is much harder for a beginner to grasp than previous versions, but the things that make it difficult for the beginners are not specifically Rails itself. Usually the difficulties come from a few specific things:
First, it's the absolutely fragmented ecosystem, made up of everyone who has opinions on the best way to do Rails development. "You need this gem, and this gem, and ZOMG you're using that library? So last week! Use this one!"
Sure, it's funny to exaggerate that, but if you joined a community, you'd probably look around. A person who does daily work in Rails is going to have a preferred development stack. They may write tests with Rspec, they may use Cucumber. They may even use CoffeeScript. And they'll tell a newbie that they should too.
But a wide-eyed developer who thinks Rails will solve all his or her problems will get freaked out at all of the options available.
When I teach beginners, I don't teach RSpec or Cucumber, and I try to even avoid talking about Bundler. I stick with the core components of Rails. I stay on the happy path.
Rails has all these hooks for experts that you can unravel after a few months (or years) of daily work. But a beginner can understand ActiveRecord, controllers, and views easily.
I love the Dreyfus Model. It basically says newbies don't need choices in the beginning. They need clear instruction, clear tutorials. Once they master those, they can move on to reading the docs, exploring the options, etc.
I've been pretty successful teaching Rails to folks who know how to program.
Where Rails falls flat on its face for the beginner is when the beginner doesn't know SQL or HTML. That's a whole different ballgame. Then something like Sinatra is a nice slow introduction.
There seems to be a silent disagreement on what the goal of a beginner is: Is it to become a better programmer or is it to get a working app with the minimal amount of work?
Sinatra seems to be better for the former, Rails is better for the latter.
I'm partial to thinking that the former goal is the more noble. But I'm also immensely proud to work in a field that allows anyone with little more than motivation and patience to apply the immense power of computing to whatever itch they need scratched.
One of my favourite consulting jobs of all times was when a friend of a friend asked me to come in: They knew just enough of a certain PHP CMS to build an online history textbook, which they'd then gone on to sell to, oh, well, every school in the country. The traffic was strangling them and only just knew enough that they knew they didn't have a clue what to do. A week and change later, upgraded hardware and the clumsy CMS search engine replace by Solr, they were flying.
If they'd started out with the equivalent of Sinatra (essentially plain PHP), I'm not sure they'd have launched at all.
Rails is definitely not for beginners and the code size is an indicator - there is a steep curve to understand everything that Rails 3.1 uses per default - especially the (initially) arcane handling of javascript runtimes to compile coffeescript...
But: Sinatra ain't beginner-friendly either, I also don't think thats the goal. Sinatra is basically a minimal base framework for matching HTTP requests, generating responses and building a Rack stack around the base class. But it doesn't give you a lot beyond that. As such, it requires deep knowledge of how to use HTTP and Rack to do more fancy stuff.
I also don't think that there are "beginner-friendly" frameworks beyond the most simple ones. The problem is that each feature that a framework encodes also requires the user to learn how it works. Most beginners don't even understand the benefits, drawbacks and best practices when it comes to HTTP - how would they understand all the things that Rails has amassed over the years?[1]
If any, I would recommend pure Rack: its a one page specification that can be read and understood in an hour.
As a shameless plug: if you consider Rails too feature-laden, consider Padrino - it is definitely worth a look. (Disclaimer: i have commit access to the Padrino repository and sometimes use it)
[1] I don't consider users coming from other frameworks (even in other languages) as "beginners" - usually, they already know the domain language - for example what CSRF is and what Rails does against it.
Although Rails code can be straightforward if you stick to the conventions, many real-world apps call for something more than that. So in practice, it's usually necessary to perform at least some level of metaprogramming, or at least some more exotic configuration.
Also, if you're using Rails library, you'll notice the hipster aspect of the Ruby/Rails community, which is to say many libraries are active for 1 or 2 years before the developer gets bored and someone else comes up with a hotter alternative. That's cool, it's quick evolution, but it also means real-world Rails developers have to spend a fair amount of time dealing with libraries that are either no longer maintained or are not yet mature.
I've built many real world applications. Very complicated ones and not just your average CRUD apps. I never had to do exotic configurations or metaprogramming craziness.
If a popular gem is replaced, I see many times, that the API of the gem, mimicks the old one, or detailed migration tutorials will be delivered. So a new gem is often similar to a major version bump.
I don't know if labeling rapid evolution as "hipster" is quite fair, but the underlying point is true. Have you gone back to a update a Rails project that is 3 years old or more? I have, and it's significantly more hassle in general than going back and updating a PHP project that is 10 years old.
Personally I think this is a small price to pay for a framework that stays up to date and still releases forward-thinking features on a regular basis (Rails modularization in 3.0 and the asset pipeline in 3.1 are amazing features that an emphasis on backwards compatibility could have made more difficult), but let's acknowledge that it is not an unmitigated win in all aspects.
I usually say this about the types of webframeworks they are:
Rails - > great for intermediate people who see benefits it brings. Great for pretty straight forward projects for beginners that can follow a book.
Sinatra -> Great for beginners to "just get something working". Not great if someone needs everything decided for them. Awesome for advanced people. Awesome for non-standard projects.
Padrino (Why don't we hear about this more?) -> kind of the sweet spot between the two. I honestly think that Padrino should rightfully start taking mindshare. I don't know why it hasn't.
I'd tout Rails as more beginner-friendly than Sinatra. Much more beginner friendly.
Once a beginner gets past the trivial usage of Sinatra, where does he go next? Rails already has everything set up for you. If you want to implement something, you can just google it or find a tutorial or Railscast that can scoot you along. Or a free online tutorial that shows you how to test and implement a nontrivial application from scratch including testing. Or just dive into the massive community.
This article rubs me the wrong way. Rails is good for beginners because it has more tutorials than probably any other web framework ever. That's the main metric that matters for a true beginner.
The fact that Rails has a ton more features that will take longer to understand than Sinatra is neither here nor there. If you don't need those features than Sinatra is the obvious choice, if you do need them then Rails is the obvious choice. This is orthogonal to the user's experience level.
By the way, "beginners" wanting to get started building Ruby-based web applications should have a look at Serve (get-serve.com). It's not a framework per se, but if you're coming from PHP, it will probably get you started with the Ruby ecosystem pretty fast (and well), since it allows you to just create an .erb file and add inline code.
(Which is what most PHP people seem to want initially - you know, before that magic thing happens where they realize that real applications need structure.)
Sinatra is cool. However, then I need to start thinking about how to integrate database connectivity (configure it, set up controllers, what not). I need to worry about XSS attacks, and a zillion other tiny details that go into a web app. So I often end up choosing Rails anyway, because they made a lot of choices for me already that I frankly don't care much about making myself.
Still, Sinatra is great for a lot of small web projects.
However, if you're going to spend all day writing web-app code, learning rails pays off HUGELY. It's the full package for modern web-app development, with massive productivity bonuses at the expense of a higher upfront.
Sinatra, Cuba[1] etc. can finely be used for larger apps as well. It may require some more discipline upfront, but the notion that those are only usable for small hacks is moot. In fact, I have found it easier to introduce new coworkers (without prior knowledge of either) to medium sized (5k LOC) Sinatra apps than Rails apps the same size.
Everytime when you try to build bigger app with sinatra, you will probably end up building half-rails. So it the end it doesn't make much sense just the time it was needed to put in to find and require additional libs
It occurred to me while interviewing the other day--web development is not really for beginners anymore. To do web development without endangering customer passwords, data security and credit card numbers now takes very substantial knowledge, and it is knowledge that some beginners won't realize they need.
If you don't understand how to prevent sql injection attacks, cross site scripting, why SSL by default for web apps is needed, and whole host of things, you should probably stay away from anything more serious than flat html.
It never was for beginners. All those problems have been around since the web has, and beginners have been making insecure crap ever since the first perl cgis.
Perhaps I'm dating myself a bit here, but there was a time when there was no such thing as an "e-commerce app" and no wi-fi to eavesdrop on. Black hat hacking has evolved also, so although some techniques have always been possible, new vectors have opened up over time as they are discovered and disseminated, and I would suggest the corresponding knowledge burden needed to enter the arms race for a developer is higher now. Also, the tools have evolved in such a way that the barrier to entry is lower and lower. For example, FireSheep.
Of course there was a time before ecommerce apps. That would probably explain why I was talking about the very first perl cgis. While there's a lower barrier to entry for people to exploit security holes, there's also far more targets. Automated tools to go around exploiting the latest holes in "insert shitty PHP app here" aren't an issue for web developers who are writing their own apps. The security issues that impact web developers are the same as they have always been for all kinds of developers, input filtering, escaping output, etc. Web developers have always needed to understand basic security issues, it is just that 99% of web developers historically have been completely incompetent. This does not appear to have changed recently.
I am a beginner. I am trying to learn Rails. I am finding it difficult because the tutorials tend to be walkthroughs of creating very specific types of web apps, with understanding of the concepts being offered a side effect. I often have questions about why and wherefore of certain decisions tutorial authors make. My only recourse is the documentation, which is too large for me to maintain my excitement for too long, especially with my busy schedule.
I do not get excited about the sudden ability to make things because I have been making things (not webapps) for some time.
I have had much more success learning Sinatra. While the tutorials are similarly designed, the reduced reliance of magic makes it easier for me understand the purpose of the commands given. There are no files that are generated for me in places that I have to go looking for that do something important that I don't have to think about (but I do have to understand.) In fact, Sinatra has helped me to understand Rails in hindsight.
I think the issue is that the tutorials I have looked at tend to be trying to sell Rails as an awesome tool to make things. This has emphasized ease of use over understanding of concepts. You can contrast these tutorials with books or tutorials for any programming language. Books on programming languages tend to be more abstract and while they limit one's power at first, they enhance one's awareness in the end. Tutorials on Rails do the opposite for me.
Maybe I should have just bought a book on Rails (like the tutorials said.)
I read the article, and while it is easy to see where he is coming from, I remembered the WTF the first time I encountered web programming more than a decade ago. The idea of GET vs POST didn't make any sense at all to a person who wanted to put something on the screen and capture its value.
Some of these higher level frameworks dispense with get and post. This means that to an old timer, there is suddenly nothing left to build on, and this is why the learning curve appears high again.
the fact that rails is not for beginners is true (and main developers say so), but suggesting for beginners a smaller framework that gives you less and hence requires you to do more, know more and make choices that rails has done for you is simply nonsense.
The number of lines of codes, in this case, speaks to the amount of features in the framework. Rails is harder to fully understand than Sinatra because there are many, many more features, and it's possible for a beginner to get lost in, or confused by, all those features.
That's why we chose to start with Sinatra with our interactive courses on http://www.trybloc.com. It's an easier transition to learn Sinatra which is conceptually much simpler.
FYI There's a bug in the REPL on your Ruby basics course: if you enter more than a handful of lines the cursor runs down the page while the actual input is at the bottom of the JQuery console...
I have a harder time using Sinatra because I never know where to put things.
Also, the biggest problem with learning Rails is the Ruby language. After you learn the language, switching from Sinatra to Rails and back is not problematic.
Yeah, Rails gives beginners a big advantage by generating a huge scaffolding. It clears up a lot of ambiguities about where things go, and as a beginner it lets you explore different things that you can do in Rails.
As a novice developer, I absolutely loathed scaffolding (IDE-generated header and source files) because I could never understand why all the code got there, how do those files relate and what does it do.
I tried to learn COM once but gave up essentially because I could not find any docs not falling back on IDE code generation (and that code was huge and absolutely opaque).
I always loved tools which let you to type in a small program from the scratch and run it. So, perhaps, sinatra is the way to go for beginners.
I didn't find the scaffolding that difficult to understand, because I've used CakePHP before, but what gets me in Rails is the magic helper keywords. For instance: ActiveRecord.find_by_columnname(value), {controller}_path, {controller}_url.
I'm fairly certain that's not all of them, but I don't even know what those things are called to look for them. Those 3 are covered in a lot of tutorials without really explaining the full list of stuff Rails does for you automatically.
I guess everyone is different since scaffolding always scared me when I was a beginner. It felt like entering an existing code base not knowing where things should go and what you are allowed to edit, except unlike a real code base none of the functionality is there making it even harder to figure out where to put things.
I have always preferred to start simple and localized and add complexity as the project goes. Especially when I am learning something new.
I've enjoyed using Rails for a long time now and still do. That being said, I've started steering towards Sinatra more given the minimal startup time and speed. The biggest gripe I have with Rails is the long startup time. It's a real drag on test driven development. Waiting close to 30 seconds per test run while the framework boots really sucks.
I've just getting started with Rails and what I miss the most is good documentation like CodeIgniter.
But other than that that's an impressive piece of software!
I think beginners can struggle through Rails. Learning Rails is much less difficult that learn best practices for programming in general, in my opinion.
I am the profile this article talks about, and I can assure you Rails is perfect for beginners. Sinatra confuses the hell out of me, admittedly and I think the key - less and less so every day.
I also taught, being a total noob myself, my best friend how to code Rails in 2 months. He doesn't even know HTML, or how to make/compile something. But he can code Ruby/Rails. And I mean Ruby, not just plug together a scaffolded app.
rails is indeed make things easy, and sinatra is indeed easy to learn. however, imho they are in different leagues, just like different code patterns you are going to make use of.
I'm actually starting to think there's something to be said for letting each generation of programmers grow up simultaneously with a hot new framework. It encourages learning through experimentation, lets them make the mistakes we all have to make, helps spread new ideas unbounded by the received wisdom (many of which will be stupid, some will have important influence for decades to come).
In the end, you get a bunch of developers that are both comfortable with a modern framework, have some understanding of the growing pains of new, complicated systems, and are ready to bring fresh ideas to more mature parts of the industry.
The contrasting mentality of sticking to what we already know is "good enough" leaves developers dull and uninspired, less equipped to think outside the "rules" inherited from previous generations that came from solving problems that look a lot different when you examine them 10 years later.
All of which is to say, Rails probably isn't for beginners anymore, and it shouldn't be, but I don't think trying to substitute a simple framework that explicitly avoids becoming complicated is necessarily what the doctor ordered...
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.