Sinatra 2.0 released
github.com
github.com
- 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.
IIRC back when Express first came out it actually said "Sinatra inspired web framework" as its description.
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>.
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.
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.
That is typical in my experience for a non-trivial app.
I would say those are likely not very complex applications they are upgrading.
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.
But sure, upgrading apps from 3.x up through current is pretty trivial.
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.
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.
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.
Great points.
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.
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.
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
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.
So 44x faster (100238 / 2274). Not quite 100x, but still very impressive.
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.
This is no surprise, I think the OP was stating that it is performant compared to RoR.
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.
It is at best an inappropriate comparison.
The comparison with Wicket was purely on performance. As that is something that Ruby will most likely never fully catch up with.
Nancy[0] is the .NET clone that was x-plat using Mono long before .NET core came out.
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.
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".
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?!?
[1] - http://www.padrinorb.com
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.
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.
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.
https://github.com/sinatra/sinatra/blob/v2.0.0/CHANGELOG.md#...
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.
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.
Sinatra is one of my all-time favorite libraries. To me, it is the ideal microframework for rapidly prototyping websites and APIs
Edit: some of the security based refactoring and ENV settings might be breaking?
https://github.com/sinatra/sinatra/commits/master/lib/sinatr...
"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."
That said, it doesn't use Sinatra there either. It uses WEBrick which is in the Ruby standard library.
https://github.com/jekyll/jekyll/blob/master/Gemfile
https://github.com/jekyll/jekyll/blob/master/lib/jekyll/comm...