Re:Where Ruby/Sinatra falls short
by faitswulff on Monday October 15, 2018 @12:56PM
(#18221408)
These complaints aren't even consistent. The author complains about being given too many options for accessing parameters but also complains about not having enough options for templating, internationalization, various devops things, ORM...
Sinatra is a minimalist framework. It even describes itself as being a domain specific language, not a framework. IMO author should have just gone with Rails if they wanted an easily extendable, batteries-included framework with a massive community.
It's supposed to be more than that. Sinatra is described as "a DSL for quickly creating web applications in Ruby with minimal effort".
Entire web applications, with minimal effort. I have not found this to be the case with Sinatra.
The application is not the server.
Of course, I agree. But though in practice Sinatra may be just a library for routing HTTP requests to a Ruby application, it is marketed as a relatively complete environment for building web applications, making a bunch of these criticisms valid.
None of the complaints here are the fault of Ruby or Sinatra. One exception could be the trailing slashes complaint. The issue exists in really any web framework, though. Flask, for example, will give you the same hiccup.
I tend to defeat it in Flask with `app.url_map.strict_slashes = False`
> There are too many ways to access parameters
This is a bad thing? The framework gives you flexibility to build your program the way you want, and the way your specific problems might require.
> You will need much more than included
Well... yeah. This is not a batteries included tool for building websites end-to-end ... it's a simple way to map an HTTP request to Ruby.
> Rewriting www.yourpage.com to yourpage.com, or the other way around
> Serving your site over https
> Redirecting all http:// pages to https://
> Running tasks in the background
> Saving data in a database, and reading from it
These are definitely not responsibilities for an HTTP -> Ruby library and the first 3 are certainly responsibilities for your public-facing HTTP server (Nginx, etc...)