Before you dig into a new framework you ask yourself: "Why should I invest time in learning a new framework?". I will not answer this with "it depends" (of course it depends on your situation) but rather provide you with all the information so that you can decide.
First let's have a brief look at Rack, Sinatra, Padrino, Rails.
Rack provides a minimal interface between web servers that support Ruby and Ruby frameworks.
Rack is a minimal interface between web servers that supports Ruby and Ruby frameworks (like Sinatra, Rails, Padrino, Cuba, Hanami). A webserver like Passenger, Puma, or Unicorn has to be depend only on the Rack interface. As long as other frameworks also depends on Rack, they all can work with the web servers.
A bare bone Rack application
consists of an objects which responds to a call method, which returns an Array consisting of HTTP status code, a hash
of HTTP headers and the response body.
Here is an example app:
class HelloRack
def self.call(env)
['200', { 'Content-Type' => 'text/html' }, ['Hello rack']]
end
end
run HelloRackNow you can start the webserver with rackup config.ru. The rackup command comes with the rack gem, looks at the config.ru file and starts the rack app.
A app can also just be configured as either as Proc:
# config.ru
run Proc.new { |env| ['200', { 'Content-Type' => 'text/html' }, ['Hello rack']] }Lambda:
run lambda { |env| ['200', { 'Content-Type' => 'text/html' }, ['Hello rack']] }Rack helped the Ruby community to have such a large number of both web servers and frameworks.
You own your code and you decide when it should change.
It's a domain-specific-language (DSL) for building websites, web services and web applications in Ruby . It acts as a middleware between Ruby and a lot of libraries, apps, and big variety of other languages. Sinatra is offering only what is essential to handle HTTP requests and delivers responses to client request. It is small, flexible, does not follow the MVC pattern and is named after the musician Frank Sinatra.
The biggest benefit of Sinatra is its stability. You trade the convenience of a code generators for your own design decisions. Writing in Sinatra can give developers and businesses API stability because the framework rarely changes. Just consider that Sinatra is written in less then 2000 lines of code.
De-couple your application by splitting it up into lots of smaller applications mounted under one base. This is the secret to keeping things simple and clean.
Sinatra is a good foundation for a base platform and you can use other gems to provide the features in order to create the tools you need for your "own framework". In the essence, this is what Padrino does: It's a Ruby web framework built upon the Sinatra web library.
The generator for each new project creates a clean and compact directory structure keeping your code simple and well organized. Padrino can be used easily for classic web development for a project of any size as well as to a lightweight, api driven json web service or a full-stack web application, where the business logic is completly handled in JavaScript (Angular, React).
It is designed to make programming web applications easier by making assumptions about what every developer needs to get started.
Rails saves you the trouble to spend a lot of time researching over which technologies to follow or adopt.
It is said that Rails is "opinionated" - meaning that there is a "Rails way" for many problems that must be solved by a web application developer. Buy following the Rails conventions you'll have fewer decisions to make and you find that most things that you need are already built in. The benefits from this is faster development, better collaboration and easier maintenance.
"Convention over configuration" is an example of Rails as "opinionated software." It is an extension of the concept of a default, a setting or value automatically assigned without user intervention. If you create a model named "User" it will automatically saves dara to a database table named "users". You won't spend time setting up configuration files makes you more productive and easier to collaborate.
Rails provides three default environments: development, testing, and production. Each behaves slightly differently, making your entire software development cycle easier. For example, Rails creates a fresh copy of the Test database for each test run.
This question came from @moneyscarf.
Well Padrino is based on the excellent Sinatra micro-framework. Padrino inherits the simplicity and expressiveness of Sinatra but gives you the extra sugar when you want to build non-trivial applications.
It adds value on Sinatra with a clear MVC approach, generators (for applications, controller, models, mailer), tag helpers for reusing components in your views, offers localization, a basic project structure, several caching mechanisms, mailers, and speeds up your development cycle by automatically server reloads.
Besides you can easily scaffold new applications very easy with available components for testing, rendering, JavaScript, CSS so that you don't need to configure those for yourself (see http://padrinorb.com/#agnostic). If one component is missing, you can add the missing part on your own by writing a custom generator.
Sinatra and Padrino goes hand in hand:
- it uses Sinatra router, but the controllers and routes are combined in the same space and you can use nested routing (http://padrinorb.com/guides/controllers/routing/#nested-routes)
- it uses Sinatra rendering basic erb rendering, and Padrino makes it easy to use haml, slim, liquid instead).
So if you have a Sinatra applications and it gets bigger and bigger, then you may graduate to Padrino if you need it.
There's a lot of folks who insist that people who don't know better should just use Rails for the amount of effort that goes into security in Rails, versus having to know about XSS, CSRF, SQL Injection, etc. In Sinatra/Padrino you need to add Rack Middleware to have those protections.
The greatest strength of Rails is it's claim "convention over complexity". It assumes common basis for testing, debugging, and app structure to generate all of this for you so that you can work trouble-free as well as creative on your tasks. For the software you write in Rails, you can be sure that the same parts (like ActiveRecord) are always in use.
Downsides of Rails? It's opiniated. What is if Rails has no opinion? Until 2013 there was no "official" approach to queueing background jobs. Most parts that drives the development of the next Rails version is to remove the lack of "opinions" and offers a solution that is good for the maturity. So if you create a solution for a problems on your own, they may be not suitable for next releases.
The claim "convention over configuration" add obscurity. Without a configuration file, there is no code that shows that the data from a class with the name "Person" is saved to a table named "people". So you cannot always look where the source of the behavior lies.
Many people nowadays say that Rails is bad. But why? The most told problem with is that it is bloated and not easy to learn in the beginning. Bloated means in this context, that many things are loaded on the startup time of your application that can influence the performance of your application. There is a lot of magic behind the scene, which can be intimidating at first. For example to avoid repetitive code, Rails often will offer default behavior that looks like magic because the underlying implementation is hidden in the Rails code library. You can create a simple web application within a glimpse of time but you may wonder where all the behavior comes from. This can be frustrating when, as a beginner, you attempt to customize your application to do more than what’s shown in simple tutorials.
Padrino gives you in comparison to Rails more power of choice. The use of Modularity components results in low-lever design. But you have to be careful of the potential to have a more complex and flexible architecture which can be unstable if you decide to use the wrong components when designing your application.
Padrino is agnostic: You can use a variety of components for your database wrapper, javascript library, renderers, stylesheets. It also offers a drop-in admin for users and role management. The routing is in the controller where in Rails you have a separate routes files. You can make it behave exactly like Rails or break out of the mold if you want to.
- Contributers