- 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.
> - 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>.
Rails was a massive innovation [1] because making a CRUD webapp in other contemporary mainstream environments, like Struts, ASP, PHP4, or fresh PHP5, was either unnecessarily repetitive, or filled with having to tinker with external config files that bootstrapped the frameworks and taught the stack how to map the incoming http requests to transactions in your database.
Sinatra was something else entirely; it was a REST router DSL. The two are not, and never were directly comparable, except in the sense that they came up as good answers when someone asked "How do I make a web-exposed application with Ruby?". It's unfortunate how often they're compared, when they were both revolutionary in their respective categories, and both went on to inspire many other frameworks in other languages that borrowed their ideas.
Before I heard about rails (pre 1.0) I had been doing some stuff in PHP that was quite similar to Rails simply as my preferred convention. So when I saw Rails the thing I was most impressed by was Ruby, a very nice (aesthetically) language.
It took me longer to realize that I would prefer not to use ActiveSupport or to allow any of the monkey patching and metaprogramming-because-i-can that became en vogue in the Rails community for a while.
I think that if DHH had known about REST sooner, Rails controller layer would have been identical to Sinatra.
The convention for building controller classes in Rails involves several more layers of indirection than Sinatra... the routes.rb file becomes a lookup table for classes whose names all fit a pattern that the programmer should not have to be aware of. The flexibility of the router is still nothing beyond what Sinatra accomplishes with its matching DSL.
This is a great comment, but I feel like you might have missed out on all of the fun of upgrading Rails 2 => 3, which was especially painful. Some large applications are still stuck on 2.x and pay third parties for support because the changes were so large. They were mostly for the better of course, but there's a good chance the parent comment experienced this pain, and this is what they're referencing.
Both of my Rails apps were on 2.3 for this reason for 5+ years, though the new owners might have migrated. When I specced it out for one it would have been 2+ weeks of solid work.
I had a Rails 0.9 app that I'd carefully upgraded to Rails 2.3 (and then done security backports for) running for just over 10 years. Decommissioned it last month. The Rails 3 upgrade was certainly one step too far for that app :)
I realized after 3.x came out that committing to a large framework and associated ecosystem comes with a significant cost/tax that is often not worth it (but sometimes is).
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.
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.
Yeah; I've upgraded multiple complex Rails applications so this is not something that surprises me in the least these days. It's just people in here saying they have "moderately complex" apps that they upgraded in 2 weeks.
I would say those are likely not very complex applications they are upgrading.
That's about what another developer and I took to move a similar app from 3.2 to 4.2. We should move it again to 5.1 as soon as the customer agrees to invest in it.
I think the biggest step was between versions 2 and 3, when Gemfile appeared. Then the asset pipeline (3.1?).
All considered, the time saved because of following reasonable conventions trumps the time spent upgrading. I'll be updating a Django app from 1.8 to 1.10 soon, I'll be able to compare it with upgrading Rails.
My first experience with Rails was inheriting a rails 2.3 application. It was never ported to 3.x, and limped along for a good 4 years in maintenance mode before being replaced by a Java app.
But sure, upgrading apps from 3.x up through current is pretty trivial.
> 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?
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.
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.
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/
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.
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.
> 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.
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.
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.
> - 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".
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.
When Ruby on Rails first hit the ground, I thought that I would try and learn it and get to grips with it. But even with 20+ years of programming background to my name at the time, I really couldn't feel comfortable using it, as much as I wanted to learn Ruby and a corresponding framework.
Then I tried playing with Sinatra, and completely fell in love with it. Made perfect sense to me, and seemed to fit my thinking and my concept of a web project a lot better. Now I exclusively build my web apps using it. Well, actually I use Pardrino [0], which is the framework built upon Sinatra. I wonder how soon they will have the Sinatra 2.0 core working with Padrino?!?
A couple that are still going strong are LogbookHQ (www.logbookhq.com) and our flagship product, HR Partner - http://www.hrpartner.io
HR Partner is over 30,000 lines of Ruby/HAML code now, and nearing 100 tables. All work to date has been carried out by a single programmer (myself).
We started out with Datamapper as our ORM, but since that is a dead project now, we've transitioned all our new projects to Sequel, which once again, I found far more intuitive and approachable than ActiveRecord.
We use a stack of existing gems, even rails specific one, however there are quite a few that are now framework agnostic, or designed specifically for Sinatra. For example, we use padrino-warden (a Warden gem tailored for padrino) for all user authentication etc.
Sinatra is what finally made me "get" web applications. A few years back I considered web programming a confusing, scary place, but figured it was my future. I had tried out rails but I was overwhelmed with it all. I had done PHP at university and sort of understood it, but didn't like it. But Sinatra was such a nice abstraction over HTTP, and it came naturally to me.
We need more libraries like this. Straightforward, to the point, based around an effective abstraction. It lets you implement the other bells and whistles how you want - or lets you not implement them at all.
Really can't say enough good things about this library, but it's numerous clones probably speak for themselves.
* Each page of your site could be a script written in a different language if you wanted.
* Environment variables (and optionally stdin) arrive to your script representing the request.
* Your script writes the response (HTTP headers and page content) to stdout then exits.
Security/perf pitfalls aside, I still think it's a nice model. It really emphasises the statelessness of HTTP since a pristine new process is booted up to handle each request.
My business is built on CGI scripts for processing automated webhooks. There's several non-trivial benefits:
1. Nothing running 24/7. No services to monitor, very light on memory.
2. Immune to memory leaks and bloat. Guaranteed fresh state on every request.
It's not ideal for user-facing functionality but has proven extremely reliable and maint-free. My goal was to use something that would require no recurring maintenance, unlike all modern web tech. All that is running 24/7 is Apache.
Right, but for an aspiring web programmer, it's a great learning exercise. By hiding all of the magic, it makes it much easier to understand what's actually going on and fully "get" web programming.
I never got much into Ruby but everytime I played with it Sinatra is my absolute favorite gem. Although now that I do Python I use CherryPy a lot, which is somewhat similar (though others would pick Flask as a similar framework for Python) glad to see it's still around. Of course this was also the inspiration for NancyFX for .NET which is another one for C# that tries to be similar as well. I'll always enjoy Sinatra as one of the few Ruby projects I've ever played with.
Sinatra is awesome, but it has some limits. I've written http://notationtraining.com using it and been running this application for 7 or so years.
It was great when it was just two screens with a few lines of javascript, but when you keep adding functionality the code gets messy very quickly and you basically start to build some kind of meta framework on top of that DSL.
7 years in development and about million uniq users later I still like it. It just do the job, there is very few things that could go wrong and it is fast.
> you basically start to build some kind of meta framework on top of that DSL.
Exactly. That's why I almost always start with Rails. There are very little projects with a tiny numer of urls. Furthermore I get some scaffolded code for free and the integration with an ORM, a test framework, templating, db migrations.
I started with Sinatra sometimes and switched to Rails after I realized that I was adding most of the components and structures of a Rails application. It was not worth doing it by hand instead of using a proven tool.
After using Sinatra for many years, i switched to Roda http://roda.jeremyevans.net/ as my goto web framework. Hello world in Roda doesn't look as neat as in Sinatra, but bigger apps come out cleaner and better structured with it.
The URL matching engine, mustermann, breaks a few things, and it's now a separate component. Also, it's now supporting rack 2, which required some changes.
"Jekyll is a simple, blog-aware, static site generator. It takes a template directory containing raw text files in various formats, runs it through a converter (like Markdown) and our Liquid renderer, and spits out a complete, ready-to-publish static website suitable for serving with your favorite web server."
- 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.