11–20 of 79 posts
What does the number of lines of code have to do with whether it's appropriate for beginners?
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.
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.
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.
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.
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.
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.
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.
So yeah, I'm not so sure I agree with this.
What does the number of lines of code have to do with whether it's appropriate for beginners?
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.
However, the question is: Is it harder to understand the subset of rails that does what sinatra does, than it is to understand sinatra as a result?
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 ye…
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.