Jose Valim heard about people avoiding Rails thanks to it not having a Sinatra-like routing syntax, and he just decided to code one up:
Why critics of Rails have it all wrong (and Ruby's bright multicore future)
91–100 of 127 posts
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#92Earlier quoted context omitted.
I thought most of the security in Rails is provided by the rack-security middleware? Or am I forgetting something which Rails provides here?
Escaping everything by default to avoid XSS attacks. that's a nice feature to have.
This can be done in Sinatra: http://www.sinatrarb.com/faq.html#auto_escape_html
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#93Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#94Earlier quoted context omitted.
heh. running specs requires to boot rails, starting the console, switching branchs, reviewing code, etc... rails boots fast if you have few files but when the project is big it is a pain, it takes a lot of time to boot and it's not fun. That's why the article says rails is "a day job". I just hope the rails team don't think like you.
You don't need to restart the rails app when running specs if you use spork. Also ruby 1.9.3 vastly improved rails application boot times over 1.9.2, just in case your slow experience was with 1.9.1.x - 1.9.2.x.
Spork's a fine notion, but it's no panacea. Pretty regularly we would be running down some weird bug only to discover that we had to restart. It doesn't take a lot of 10-minute debugging excursions to eat up all the time that Spork saves on starting tests.
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#95Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#96I love Ruby, but I have no love for Rails. Want to write a nice JSON API using something light and nice? Use Sinatra, pick your favorite ORM (even ActiveRecord) and go to town. Why mess with all the other Rails junk when you can have a simple app.rb for your sinatra app and just write simple little controller actions and you're good to go? You don't need all the ceremony and structure of Rails and MVC to write a JSON…
"Rails" is a collection of libraries and conventions, just as "Sinatra + ActiveRecord" is. There's nothing inherent in it that makes it "worse" than Sinatra (which I love, by the way) for JSON APIs. Use Rack, pick your favorite gems, and go to town. Why mess with all the other Sinatra junk when you can have a simple config.ru for your app and just write a simple call method and you're good to go? You don't need all t…
Whole-heartedly disagree. You can't even parse a json-encoded POST body with plain-vanilla Rack without a middleware from rack-contrib HEAD (the "stable" version is about a year behind the last time I checked). Rack is a standard and abstraction for build ruby app servers and frameworks. To say it's sufficient for building production quality API's is just absurd.
One of the main benefits of using frameworks like Sinatra and Rails is that you often don't need to re-write and re-implement all the same boilerplate code (like parsing JSON post bodies) over and over again.
And the difference with rails and sinatra vs most other open source projects is the size and activity community, and as a result, the overall stability of those projects.
So, in theory, do you need all that "ceremony and structure"? No, but I can't think of a good reason why you'd go implement all that stuff yourself.
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#97Earlier quoted context omitted.
Last I checked out Django they had just added a bunch of features from Rails 1.2. (Edit: sorry, Rails 2.1) Python suffers from their web framework community being too fragmented, so none of the projects are as mature as Rails.
I use Django for my projects and I don't share this opinion on the maturity aspect. Can you explain your statement a bit more? What aspects of Django are immature?
The release notes for Django 1.4, for example, list support for both Time Zones and Selenium.
Time Zones were added to Rails 2.1 in 2008. selenium-on-rails also debuted in 2008.
Does it not seem strange to you that it took 4 years after Rails for Django to get these features?
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#98Earlier quoted context omitted.
You should check out Zeus ( https://github.com/burke/zeus ). "Boot any rails app in under a second". It'll use more memory, unless you want to GC-patch your ruby (instructions in the repo).
yeah already saw it, but why are these hacks needed in first place? I am pretty sure there's a good way to fix rails to load faster in a reasonable amount of time (again, I am talking about big projects).
Extensive work has already gone into improving Rails startup time. If you want to further improve it, try removing railties you aren't using.
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#99Earlier quoted context omitted.
but I shouldn't get cocky, eh? :)
In case it wasn't clear, that aphorism is supposed to be telling you to get into the habit of reading the source code of the libraries you use. It is often the fastest way to solve your problems, and you'll learn a lot about the lib and about the language in the process. Without the ability to do this one can only be a plumber fitting other peoples' appliances.
Han Solo says, "Don't get cocky, kid," to Luke.
Re: Why critics of Rails have it all wrong (and Ruby's bright multicore future)
#100Earlier quoted context omitted.
I really liked using Sinatra until I used it with a team. The lack of ceremony and structure (as you put it) killed us. The app started out as just a simple service, so why not use Sinatra right? Then things changed and we were more focused on the web side, but stuck with Sinatra because everyone had heard the FUD about rails. Each person has a preference on where they thought something should be. Days were spent arg…
My experience is similar. Sinatra is great for one-man-shows or really simple REST apis. For the rest, forget about it... However, Rails is just too f ng complex. It's true what they're saying, Rails-only programmers aren't necessarily Ruby programmers. For a good reason, even the simplest tasks are performed with Rails metaprogramming magic behind the scenes. Idiomatic Rails programming actually means not doing impe…
Do you think that a "legacy" Node(or Sinatra for that matter) app will be easier to understand than a "legacy" Rails app?
Legacy is where conventions actually shine!