As much as I like Sinatra, there were some limitations I found frustrating and unnecessary when using it in the real-world. These were mainly issues of code management and scalability. You either had to put all your routes for your entire application in a single "controller", in which they shared helpers, filters, configuration, and so on, or otherwise try and break your application out into multiple mini Sinatra applications, and mount them under different mappings using Rack. Neither solution was elegant. I thought Padrino might address a few of those issues, but found it equally if not more frustrating.
Given that I had a pretty good idea of what I wanted and because it was simple enough (maybe not in hindsight), I decided to roll my own, knowing that I'd not only be scratching my itch, but the itches of many other developers who inadvertantly run into issues of practicaility when using Sinatra.
It's a play on the DRY acronym. Much of Scorched is designed to provide ample oppurtunity for developers to reduce repetition.
3) Sinatra is a very minimalist Ruby framework that already has a lot of traction. What makes your framework different from Sinatra?
Scorched is very similar to Sinatra from a DSL perspective, so at first glance people wonder why I seem to have just rewritten Sinatra. The main difference from Sinatra is the introduction of the controller concept. These controllers can be composed and nested in many creative ways, and allow you to scope helpers, filters, error handlers, conditions, configuration, etc, to related groups of routes.
Another difference is that Scorched attempts to be even simpler and more predictable than Sinatra, and if it's possible, be even less opinionated. There's a few things in Sinatra that can surprise you. Sinatra sometimes does a little more than you might expect. I'd like to think I've achieved these goals as a result of a more thoughtful design, resisting the temptation to add too many smarts, and by not providing functionality that overlaps with Rack. Sinatra like most frameworks, provides a lot of helpers that abstract away Rack. With Scorched I want to expose developers to Rack as much as reasonably possible. The idea being that knowledge of Rack is portable between frameworks, where as helpers and DSL's are not. If someone is already familiar with Rack, that experience can be leveraged to lower the learning curve for Scorched, and vice versa.
4) How come you didn't contribute the extra features that your framework offers to Sinatra, either as a patch or extension?
Because the main features of Scorched are architectural. Applying such changes to Sinatra would break backwards compatibility, though I like to imagine Scorched as being an appropriate starting point for Sinatra 2.0.
Firstly, it makes you appreciate the amount of work one must put into even relatively simple frameworks and libraries. I'm also now much more familiar with Rack and it's limitations. It's certainly sparked my interest in a potential Rack 2.0. I suppose my Ruby skills have also inadvertantly been refined. It doesn't really matter what project I'm working on, I always like to explore as many creative solutions as possible trying to find that perfect solution, bumping into the limitations of the language, of which there are so few in Ruby, hence why I love it.
There's no reason it can't reach the popularity of Sinatra, though it would need a significant amount of documentation tailored to those less experienced with Ruby and other Ruby web frameworks. I would find it hard to imagine someone could like Sinatra but not Scorched. At the moment Scorched is targeted at more experienced Ruby web developers; those already familiar with Rack and Sinatra.
As for future development. I hope to release a v1.0 soon. I still need to put the framework through it's paces in some real-world applications to ensure there are no obvious things I've missed. A contrib library is also on the cards, though probably not until a v1.0 release. I'll likely just bundle any contrib-esque extras into the core for the moment, such as my simplifed implementation of content_for for ERB templates which I had to create for a project I'm porting from Padrino to Scorched.
require 'scorched'
class App < Scorched::Controller
get '/:name' do
@message = greeting(captures[:name])
render :hello
end
def greeting(name)
"Howdy #{name}"
end
end<h1><%= @message %></h1>require 'scorched'
require 'sequel'
Sequel::Model.db = Sequel.sqlite("development.db")
class Tasks < Sequel::Model
db.create_table? :tasks do
primary_key :id
String :name
DateTime :completed_at
end
end
class App < Scorched::Controller
controller '/tasks' do
get '/' do
@tasks = Tasks.all
render :index
end
get '/:id' do
render :task, locals: {task: task}
end
post '/' do
id = Tasks.insert(:name => request.POST['name'])
redirect "/tasks/#{id}"
end
put '/:id' do
task.update(completed_at: (request.POST['completed'] ? Time.now : nil), name: request.POST['name'])
redirect "/tasks/#{captures[:id]}"
end
delete '/:id' do
task.delete
redirect "/tasks"
end
def task(id = captures[:id])
Tasks[id] || halt(404)
end
end
end<% if @tasks.empty? %>
<em>No records found.</em>
<% end %>
<% @tasks.each do |task| %>
<%= render :task, locals: {task: task} %>
<% end %><p><%= task[:id] %>. <%= task[:name] %></p>