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.
>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.
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.
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 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.
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.
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.
[+] [-] dhh|14 years ago|reply
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.
[+] [-] dhh|14 years ago|reply
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.
[+] [-] Argorak|14 years ago|reply
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.
[+] [-] pankajdoharey|14 years ago|reply
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.
[+] [-] bodegajed|14 years ago|reply
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.
[+] [-] joshsusser|14 years ago|reply
[+] [-] hisea|14 years ago|reply
A MD is not for beginners either. Policing is not for beginners either. Even cooking is not for beginners.
I had my first son 9 month ago before I learned how to change a diaper. Being a Dad is definitely not for beginners.
Life is not easy, nothing is for beginners.
People just learn along the way if they think this is the skill they need to learn and they have a strong will.
The most important thing is to BEGIN.
[+] [-] bashar3a|14 years ago|reply
[+] [-] ghr|14 years ago|reply
[+] [-] fleitz|14 years ago|reply
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.
[+] [-] jamesgeck0|14 years ago|reply
Until the docs and tutorials fall short, or something unexpected happens, or they want to see why something behaves the way it does.
[+] [-] bphogan|14 years ago|reply
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.
[+] [-] mseebach|14 years ago|reply
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.
[+] [-] Argorak|14 years ago|reply
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.
[+] [-] mmahemoff|14 years ago|reply
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.
[+] [-] sebilasse|14 years ago|reply
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.
[+] [-] fingerprinter|14 years ago|reply
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.
[+] [-] rman666|14 years ago|reply
[+] [-] minikomi|14 years ago|reply
[+] [-] sofuture|14 years ago|reply
[+] [-] danneu|14 years ago|reply
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.
[+] [-] dasil003|14 years ago|reply
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.
[+] [-] hmans|14 years ago|reply
(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.)
[+] [-] Tichy|14 years ago|reply
Still, Sinatra is great for a lot of small web projects.
[+] [-] andrewvc|14 years ago|reply
Sinatra is great for small things and beginners.
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.
[+] [-] ichverstehe|14 years ago|reply
[1] https://github.com/soveran/cuba
[+] [-] ericb|14 years ago|reply
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.
[+] [-] SomeOtherGuy|14 years ago|reply
[+] [-] tmroyal|14 years ago|reply
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.)
[+] [-] teyc|14 years ago|reply
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.
[+] [-] pistacchio|14 years ago|reply
[+] [-] rhizome|14 years ago|reply
[+] [-] kingkilr|14 years ago|reply
[+] [-] gabyar|14 years ago|reply
[+] [-] choxi|14 years ago|reply
[+] [-] spacemanaki|14 years ago|reply
[+] [-] bad_user|14 years ago|reply
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.
[+] [-] mnutt|14 years ago|reply