What's new in Sinatra 1.4? | Hacker News Reader

What's new in Sinatra 1.4?

rkh.im

61 pointsEzGraphs29 comments

came from python (and tornado) to ruby, if it wasnt for sinatra, i'd have stayed with python and tornado. great work, keep up the clean syntax and lightweightness.

python has flask & bottle, so.. you may consider going back?..

can't go back, at least not now, at work we've standardized on ruby. for personal projects, i've also decided to stick with ruby as well, the main reason being mostly the gem package manager and community support, not saying that python doesn't have a good community with great libraries (egg, setup tools, etc), but ruby's just cleaner for me with regards to web app development.

I'm glad there is Sinatra because it inspired Scalatra, which seems way more lightweight than Play :-). Keep up being lightweight!

I don't blame the authors for discontinuing old branches (1.2.x), but it makes me hesitant using Sinatra for a production website that's meant to be there for >= 2 years (though is an eon in IT).

The upgrade process is pretty smooth, the latest Sinatra release still runs all the first example apps published in 2007.

Also, the Sinatra code base is pretty small, so just because it's no longer officially maintained doesn't mean you can't run Sinatra 1.2.0. All security issues we have seen so far have all been in Sinatra dependencies (namely Rack) and never in Sinatra itself.

If you are stuck on an unmaintained Ruby version that's a way bigger issue than being stuck on an unmaintained Sinatra version. You should not run Ruby 1.8.6 in production for security reasons.

Many projects out there follow the two maintained feature versions approach, like Rails. How many versions of Sinatra should see regular releases? What about 1.1.x? Or 0.9.x?

It has also been announced with the 1.3.0 release that 1.2.x will be continued until the 1.4.0 release.

Being stuck on 1.2.x is pretty bad, as it still ships without rack-protection.

I agree: doesn't make sense to support versions that run on unmaintained Ruby versions. I didn't see that when I posted.

Similarly, I'm a fan of Mojolicious, and Mojolicious::Lite looks to have been heavily inspired by Sinatra. I'm not sure exactly how far that inspiration goes though, as I see Sinatra explained as best used when you want something light, and Mojolicious looks to scale quite well to larger apps.

That is a typical explanation but there is nothing stopping you from using Sinatra for building large apps. In fact I find myself just as productive with Sinatra as I was with Rails for building very feature full apps.

1.2.x was last released in 2011, is just for ruby 1.8.6 compatibility (with 1.8.7 reaching end of life in june)

It's just the logical step to get rid of old deprecated stuff.

What do you mean by "lightweight"?

I'm curious, too. Also how does it compare to Spray? https://github.com/spray/spray

Does one thing or a few and does it well.

I haven't checked, but for starters you possibly could look at the download size.

lightweight as in activerecord and all the other things aren't bundled in by default. you bundle what you need. sinatra doesnt assume that you need an orm or template language. think of sinatra as a domain specific language for creating websites, but you could tack on orm or templates as you see fit.

It's not just in Scala that Sinatra inspired, such as express(Node.js), Slim(PHP).

> By default, Sinatra will now only serve localhost in development mode. You should not be running your production system in development mode.

This "opinionated default" makes it very hard to test when you're running your development environment from a virtual machine, like Vagrant.

More and more people are doing this (gotta use those extra cores + memory for something, right?), so please consider us before adding a "listen 127.0.0.1". :)

Simply run with -o 0.0.0.0, I think the number of people running without firewall or having an annoying firewall warning every time they start a Sinatra process is larger than the number of people developing on a VM. Also note that this has no effect if you use some different way to run your Sinatra app, like rackup.

For static sites I use rack, for dynamic sites I use rails.

When do I use Sinatra?

For starters, I would use Sinatra where you use Rack.

It takes care of a lot of unknowns for a lot of people. For instance, it makes sure you do proper redirects. Did you know that IE9 implements 302 like 307 but only for redirects from Ajax? But you can't simply use 303 as some HTTP clients don't properly implement it? Rack does not care about such things.

It also comes with built-in security, which Rack does not.

If you are comfortable with Rails and it suits your needs (that is, a monolithic model driven application), stick with it, there is nothing wrong with Rails.

you can use sinatra in place of rails for dynamic sites, but you'd need to pick template language (erb, haml), object relational model (activerecord, sequel, datamapper), and other things that come bundled in rails. that's what makes sinatra lightweight, you add as you need as opposed to everything there for you out of the gate. you can think of sinatra as being a simple domain specific language for creating sites or apis (i use it for both).

http://github.com/cloudfoundry/defekts

I think you described Padrino (http://www.padrinorb.com/).

Sinatra is good for APIs but it's easy to find yourself reinventing Rails/Padrino when you have a view layer.

also, sinatra uses rack and adds a domain specific language on top.

With Sinatra you add in and with Rails you taketh away.

You can use Sinatra for the same things that you use Rails for, but typical use cases are API's, since there's a lot of stuff in Rails that you don't want to use if your main output isn't html.

When you want to keep it lightweight

Sinatra is my default. Rails is overkill for most CRUD apps.

Why not serve static sites from Apache/nginx or a CDN?

For light sites.

And for REST endpoints.

Travis CI uses Sinatra and it's all but light.

"all but light" is all too generic. Explain.

The light part means: it doesn't drag a huge framework and code and complexity you don't need with it. It uses less resources than it would if it was doing that.

I would actually say that Travis CI is a Rails app, Rails is just not taking care of HTTP, but we use large parts of the Rails stack in many of our applications (Travis CI is a fully distributed app).

Our API app used to be a Rails application, but we ended up writing our own object serializers etc, so that the controllers were actually more or less just calling out to one method.

When we reworked our API, authentication, etc, we switched over to Sinatra.

Reply on news.ycombinator.com