7 ms·

The relevant timeline for Sinatra is as follows: - Rails 1.0 is released, popularizing Ruby - Rails 2.0 is released, deprecating patterns that were best pract

The relevant timeline for Sinatra is as follows: - Rails 1.0 is released, popularizing Ruby - Rails 2.0 is released, deprecating patterns that were best practices in 1.0 and advocating REST patterns. - Sinatra is born, distilling the ideas behind REST into an extremely simple and performant microframework. - Sinatra has been copied/emulated in nearly every programming language, and its clones have also been widely successful. - Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. - Meanwhile, Sinatra has remained very stable and its design has continued to inspire new clones. See Floor, Scotty, Opium, Express, Flask, etc. Bravo to the Sinatra team for building and maintaining a useful product.

pvinis 9y ago
Wow, I had no idea Sinatra came before Express! TIL
- BukhariH 9y ago
  Not only did it come before Express but Express was directly inspired by it. IIRC back when Express first came out it actually said "Sinatra inspired web framework" as its description.
- tlrobinson 9y ago
  Sinatra came before Node.js even existed.
matt4077 9y ago
> - Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. That's simply wrong. I've maintained a moderately-sized Rails app since 3.x, and updating never took more than an hour or so, even for the major version changes. It's also deeply unfair to the Rails team. Your timeline should include, as the first entry: - Rails 1.0 is released, showing the web development community how to structure a project, delivering us from XML, and banishing config.backup.inc.php3 from our nightmares. Rails came about in a world of SQL embedded in html, or (almost worse) the idiotic idea of "templating languages" that were poorly designed re-implementations of php ("but this time it's just for templates!"). Testing meant clicking through your application, and javascript was exclusively used for replacing the deprecated <marquee>.
- grandalf 9y ago
  > moderately-sized Rails app How many models? How many gems that hook into the framework? > Rails came about in a world of SQL embedded in html Great point. Rails deserves tremendous credit for showing people the light in many ways.
  - pjmlp 9y ago
    AOLServer did that many years before Rails happened, but many developers weren't paying attention.
    - _pmf_ 9y ago
      Scripted in Tcl. Would be happy if we had this instead of JS today.
  - FanaHOVA 9y ago
    We updated from Rails 3 to 4 ~1 month and a half ago. Our Gemfile has 138 lines and we have ~70 models. We updated everything and did a full regression testing to fix all the new bugs within a sprint (2 weeks) while also working on a bunch of other tasks.
    - bigtunacan 9y ago
      This just means you had it easy. You don't feel the pain of teams that started on Rails earlier and have more complex apps. I've seen a Rails application that started on Rails 1 upgraded all the way to Rails 4, and soon will go to Rails 5. It has close to 400 models, 500K+ LOC (not including gems), almost 30 obsolete "plugins" that must be internally maintained and kept working with new versions of Rails. The upgrade from 2 to 3 took nearly a year on this project and that was with 2 people. The upgrade from 3 to 4 was roughly 6 months.
      - grandalf 9y ago
        > The upgrade from 2 to 3 took nearly a year on this project and that was with 2 people. The upgrade from 3 to 4 was roughly 6 months. That is typical in my experience for a non-trivial app.
100k 9y ago
I agree with the sibling comment that this is an unfair summary of Rails' evolution and impact. I gave a talk about this when Rails turned 10: http://www.recursion.org/looking-backward/ http://www.recursion.org/looking-backward/ It's hard to overstate how incredible Rails was compared to the what most people were writing in 2004. In both the frameworks that copied it, and those that reacted to it (like Sinatra) it has been widely influential. As to the particular point, yes, there has been a lot of framework churn; but it also does far more than Sinatra. But there's more than one Rails app that's been upgraded all the way from 0.5 or whatever all the way to 5.0.
- grandalf 9y ago
  My intent was to mention the timeline from Sinatra's perspective, not to diminish the contribution Rails made. Of course, Rails was revolutionary in many ways, and certainly, Sinatra was a riff off of Rails. Great points.
lucaspiller 9y ago
> Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. As someone else said this isn't really correct. Since version 3 (released in 2010) the external API has been pretty much the same, bar a few minor breaking changes and new features. The internal APIs however have changed a lot. The issue I've had with upgrading since then hasn't been Rails, but third party libraries (gems) I also used. As it's not possible to make a method truly private in Ruby, they often hook into whatever they needed to work. They are then abandoned and aren't updated, and so if you are stuck relying on a certain library, you will have a hard time upgrading Rails. I also had a few cases of incompatibilities with Ruby versions (before 2.0 it didn't use semver), but thankfully that seems to be over now.
JohnBooty 9y ago
> Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. We recently upgraded our huge monolithic Rails 3.2x application to Rails 4.0 About ~300 kloc, and several hundred models. Lots of libs, tons of gem dependencies, lots of assorted bits like Resque tasks, etc. It's big. The upgrade was pretty painless, and it was handled by our least experienced internal team. No major rewrites involved. Most of the pain was just the grunt work of adopting Rails 4's strong parameters. We could have continued using attr_accessible, but felt that switching to strong parameters would give us an easier path in the future. There was also some random pain involved by the need to update various "3rd-party" (i.e., not core Rails) gems, some of which introduced incompatibilities or other issues. But, this was relatively minor. We did not encounter a need for this "near rewrite" you speak of. Nothing was rewritten, and none of the changes were large. From what I've seen of Rails 5.x, it shouldn't pose a major problem either. Now, I've heard that Rails 1.x to 2.x or 2.x to 3.x did involve a lot of breakage. I think that's what you're thinking of, maybe?
- grandalf 9y ago
  > Rails 1.x to 2.x or 2.x to 3.x Yep. I stopped choosing Rails for new projects after 2.0 but inherited a few codebases with newer Rails subsequently. The problem is not necessarily just with Rails, it's that gem authors don't necessarily have the bandwidth to support high quality versions of a gem for both versions. So if a gem is coupled to Rails' inner workings (as many are -- some unnecessarily) there is added downside to not upgrading even if the older version is working fine. It does look like the APIs are finally stabilizing. I'd like to see Rails gravitate more toward a series of conventions defined by contracts, not abstracted away into implicit behaviors.
JohnBooty 9y ago
> Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. We recently upgraded our huge monolithic Rails 3.2x application to Rails 4.0 About ~300 kloc, and several hundred models. Lots of libs, tons of gem dependencies, lots of assorted bits like Resque tasks, etc. It's big. The upgrade was pretty painless, and it was handled by our least experienced internal team. No major rewrites involved. Most of the pain was just the grunt work of adopting Rails 4's strong parameters. We could have continued using attr_accessible, but felt that switching to strong parameters would give us an easier path in the future. There was also some random pain involved by the need to update various "3rd-party" (i.e., not core Rails) gems, some of which introduced incompatibilities or other issues. But, this was relatively minor. We did not encounter a need for this "near rewrite" you speak of. Nothing was rewritten, and none of the changes were large.
nathan_f77 9y ago
> Sinatra has been copied/emulated in nearly every programming language, and its clones have also been widely successful. I was just thinking about a Sinatra clone that works in Crystal, and it turns out that there is one: https://github.com/kemalcr/kemal https://github.com/kemalcr/kemal I love the idea that you can write almost the same code, and get a small web service that runs 100x (?) faster than the Ruby version.
- smaili 9y ago
  Their Benchmarks section comparing Kemal to Sinatra is quite huge.
  - nathan_f77 9y ago
    Oh right, I didn't see that on the homepage: http://kemalcr.com/ http://kemalcr.com/ So 44x faster (100238 / 2274). Not quite 100x, but still very impressive.
    - cutler 9y ago
      That's until you have a significant amount string parsing with regexen in your app. Then Crystal is actually slower than MRI Ruby. Hard to believe for a compiled language but true.
cies 9y ago
> an extremely simple and performant [...] Simple, yes. The beauty of APIs in the Ruby world really opened my eyes. But performant is never really was. For instance: at the time of Sinatra's first release Wicket (Java) already existed and was much more performant.
- romanovcode 9y ago
  Java is faster then Ruby. In other news - sky is blue. This is no surprise, I think the OP was stating that it is performant compared to RoR.
  - cies 9y ago
    > Java is faster then Ruby. In other news - sky is blue. RoR is dog slow. In other news - sky is blue. This is no surprise. > I think the OP was stating that it is performant compared to RoR. I think Sinatra is "performant enough for most" at best.
- brunoc 9y ago
  You are comparing a beautifully minimal web library (Sinatra) to an abominable horror from the very depths of hell (Wicket). It is at best an inappropriate comparison.
  - cies 9y ago
    If you read again you see I praise the Ruby community for its beautiful APIs. The comparison with Wicket was purely on performance. As that is something that Ruby will most likely never fully catch up with.
    - cutler 9y ago
      Before you bet on that one check out the advances in JRuby, TruffleRuby/Graal and SubstrateVM: http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-vm.html http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-...
kitd 9y ago
I've worked with Java for about 17 years now. IMHO Java in 2017 owes a huge debt of gratitude to Ruby, especially Rails and Sinatra. Writing Java REST apps now is immeasurably simpler via things like Ratpack/Dropwizard/Vert.x, using ideas that came from the Ruby world. Even Spring, itself a breath of fresh air, has been forced to play catch-up on occasions.
Pharylon 9y ago
>> Sinatra has remained very stable and its design has >> continued to inspire new clones. See Floor, Scotty, >> Opium, Express, Flask, etc. Nancy[0] is the .NET clone that was x-plat using Mono long before .NET core came out. 0. http://nancyfx.org/ http://nancyfx.org/
steveklabnik 9y ago
You're missing out on Camping, which (IIRC) pre-dated Sinatra and was an inspiration for it.
- grandalf 9y ago
  > Camping True, I didn't forget Camping, but in my mind last night as I wrote the comment I was thinking that camping inspired the micro-framework idea but not the REST ideas. But I agree with you.
nailer 9y ago
> - Sinatra has been copied/emulated in nearly every programming language, and its clones have also been widely successful. This. I'm not a Rubyist and I've never used Sinatra, but nearly every time I find a nice web framework I like in a language I use - Python/Flask, node/Express, Elixir/Phoenix - it's "inspired by Sinatra".
- zvrk 9y ago
  Phoenix is definitely inspired by Rails.

pvinis 9y ago

Wow, I had no idea Sinatra came before Express! TIL

BukhariH 9y ago
Not only did it come before Express but Express was directly inspired by it. IIRC back when Express first came out it actually said "Sinatra inspired web framework" as its description.
tlrobinson 9y ago
Sinatra came before Node.js even existed.

matt4077 9y ago

> - Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. That's simply wrong. I've maintained a moderately-sized Rails app since 3.x, and updating never took more than an hour or so, even for the major version changes. It's also deeply unfair to the Rails team. Your timeline should include, as the first entry: - Rails 1.0 is released, showing the web development community how to structure a project, delivering us from XML, and banishing config.backup.inc.php3 from our nightmares. Rails came about in a world of SQL embedded in html, or (almost worse) the idiotic idea of "templating languages" that were poorly designed re-implementations of php ("but this time it's just for templates!"). Testing meant clicking through your application, and javascript was exclusively used for replacing the deprecated <marquee>.

grandalf 9y ago
> moderately-sized Rails app How many models? How many gems that hook into the framework? > Rails came about in a world of SQL embedded in html Great point. Rails deserves tremendous credit for showing people the light in many ways.
- pjmlp 9y ago
  AOLServer did that many years before Rails happened, but many developers weren't paying attention.
  - _pmf_ 9y ago
    Scripted in Tcl. Would be happy if we had this instead of JS today.
- FanaHOVA 9y ago
  We updated from Rails 3 to 4 ~1 month and a half ago. Our Gemfile has 138 lines and we have ~70 models. We updated everything and did a full regression testing to fix all the new bugs within a sprint (2 weeks) while also working on a bunch of other tasks.
  - bigtunacan 9y ago
    This just means you had it easy. You don't feel the pain of teams that started on Rails earlier and have more complex apps. I've seen a Rails application that started on Rails 1 upgraded all the way to Rails 4, and soon will go to Rails 5. It has close to 400 models, 500K+ LOC (not including gems), almost 30 obsolete "plugins" that must be internally maintained and kept working with new versions of Rails. The upgrade from 2 to 3 took nearly a year on this project and that was with 2 people. The upgrade from 3 to 4 was roughly 6 months.
    - grandalf 9y ago
      > The upgrade from 2 to 3 took nearly a year on this project and that was with 2 people. The upgrade from 3 to 4 was roughly 6 months. That is typical in my experience for a non-trivial app.

100k 9y ago

I agree with the sibling comment that this is an unfair summary of Rails' evolution and impact. I gave a talk about this when Rails turned 10: http://www.recursion.org/looking-backward/ http://www.recursion.org/looking-backward/ It's hard to overstate how incredible Rails was compared to the what most people were writing in 2004. In both the frameworks that copied it, and those that reacted to it (like Sinatra) it has been widely influential. As to the particular point, yes, there has been a lot of framework churn; but it also does far more than Sinatra. But there's more than one Rails app that's been upgraded all the way from 0.5 or whatever all the way to 5.0.

grandalf 9y ago
My intent was to mention the timeline from Sinatra's perspective, not to diminish the contribution Rails made. Of course, Rails was revolutionary in many ways, and certainly, Sinatra was a riff off of Rails. Great points.

lucaspiller 9y ago

> Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. As someone else said this isn't really correct. Since version 3 (released in 2010) the external API has been pretty much the same, bar a few minor breaking changes and new features. The internal APIs however have changed a lot. The issue I've had with upgrading since then hasn't been Rails, but third party libraries (gems) I also used. As it's not possible to make a method truly private in Ruby, they often hook into whatever they needed to work. They are then abandoned and aren't updated, and so if you are stuck relying on a certain library, you will have a hard time upgrading Rails. I also had a few cases of incompatibilities with Ruby versions (before 2.0 it didn't use semver), but thankfully that seems to be over now.

JohnBooty 9y ago

> Rails went on to release subsequent versions, each of which advocated doing a near rewrite of working code and obsoleted/broke many of the libraries in the ecosystem. We recently upgraded our huge monolithic Rails 3.2x application to Rails 4.0 About ~300 kloc, and several hundred models. Lots of libs, tons of gem dependencies, lots of assorted bits like Resque tasks, etc. It's big. The upgrade was pretty painless, and it was handled by our least experienced internal team. No major rewrites involved. Most of the pain was just the grunt work of adopting Rails 4's strong parameters. We could have continued using attr_accessible, but felt that switching to strong parameters would give us an easier path in the future. There was also some random pain involved by the need to update various "3rd-party" (i.e., not core Rails) gems, some of which introduced incompatibilities or other issues. But, this was relatively minor. We did not encounter a need for this "near rewrite" you speak of. Nothing was rewritten, and none of the changes were large. From what I've seen of Rails 5.x, it shouldn't pose a major problem either. Now, I've heard that Rails 1.x to 2.x or 2.x to 3.x did involve a lot of breakage. I think that's what you're thinking of, maybe?

grandalf 9y ago
> Rails 1.x to 2.x or 2.x to 3.x Yep. I stopped choosing Rails for new projects after 2.0 but inherited a few codebases with newer Rails subsequently. The problem is not necessarily just with Rails, it's that gem authors don't necessarily have the bandwidth to support high quality versions of a gem for both versions. So if a gem is coupled to Rails' inner workings (as many are -- some unnecessarily) there is added downside to not upgrading even if the older version is working fine. It does look like the APIs are finally stabilizing. I'd like to see Rails gravitate more toward a series of conventions defined by contracts, not abstracted away into implicit behaviors.

JohnBooty 9y ago

nathan_f77 9y ago

> Sinatra has been copied/emulated in nearly every programming language, and its clones have also been widely successful. I was just thinking about a Sinatra clone that works in Crystal, and it turns out that there is one: https://github.com/kemalcr/kemal https://github.com/kemalcr/kemal I love the idea that you can write almost the same code, and get a small web service that runs 100x (?) faster than the Ruby version.

smaili 9y ago
Their Benchmarks section comparing Kemal to Sinatra is quite huge.
- nathan_f77 9y ago
  Oh right, I didn't see that on the homepage: http://kemalcr.com/ http://kemalcr.com/ So 44x faster (100238 / 2274). Not quite 100x, but still very impressive.
  - cutler 9y ago
    That's until you have a significant amount string parsing with regexen in your app. Then Crystal is actually slower than MRI Ruby. Hard to believe for a compiled language but true.

cies 9y ago

> an extremely simple and performant [...] Simple, yes. The beauty of APIs in the Ruby world really opened my eyes. But performant is never really was. For instance: at the time of Sinatra's first release Wicket (Java) already existed and was much more performant.

romanovcode 9y ago
Java is faster then Ruby. In other news - sky is blue. This is no surprise, I think the OP was stating that it is performant compared to RoR.
- cies 9y ago
  > Java is faster then Ruby. In other news - sky is blue. RoR is dog slow. In other news - sky is blue. This is no surprise. > I think the OP was stating that it is performant compared to RoR. I think Sinatra is "performant enough for most" at best.
brunoc 9y ago
You are comparing a beautifully minimal web library (Sinatra) to an abominable horror from the very depths of hell (Wicket). It is at best an inappropriate comparison.
- cies 9y ago
  If you read again you see I praise the Ruby community for its beautiful APIs. The comparison with Wicket was purely on performance. As that is something that Ruby will most likely never fully catch up with.
  - cutler 9y ago
    Before you bet on that one check out the advances in JRuby, TruffleRuby/Graal and SubstrateVM: http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-vm.html http://nirvdrum.com/2017/02/15/truffleruby-on-the-substrate-...

kitd 9y ago

I've worked with Java for about 17 years now. IMHO Java in 2017 owes a huge debt of gratitude to Ruby, especially Rails and Sinatra. Writing Java REST apps now is immeasurably simpler via things like Ratpack/Dropwizard/Vert.x, using ideas that came from the Ruby world. Even Spring, itself a breath of fresh air, has been forced to play catch-up on occasions.

Pharylon 9y ago

>> Sinatra has remained very stable and its design has >> continued to inspire new clones. See Floor, Scotty, >> Opium, Express, Flask, etc. Nancy[0] is the .NET clone that was x-plat using Mono long before .NET core came out. 0. http://nancyfx.org/ http://nancyfx.org/

steveklabnik 9y ago

You're missing out on Camping, which (IIRC) pre-dated Sinatra and was an inspiration for it.

grandalf 9y ago
> Camping True, I didn't forget Camping, but in my mind last night as I wrote the comment I was thinking that camping inspired the micro-framework idea but not the REST ideas. But I agree with you.

nailer 9y ago

> - Sinatra has been copied/emulated in nearly every programming language, and its clones have also been widely successful. This. I'm not a Rubyist and I've never used Sinatra, but nearly every time I find a nice web framework I like in a language I use - Python/Flask, node/Express, Elixir/Phoenix - it's "inspired by Sinatra".

zvrk 9y ago
Phoenix is definitely inspired by Rails.