Hacker News Reader

Comment by grandalf | Hacker News Reader

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.

View on HN

> - 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>.

> 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.

AOLServer did that many years before Rails happened, but many developers weren't paying attention.

Scripted in Tcl. Would be happy if we had this instead of JS today.

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.

> 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.

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.

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.

And that was pretty much it. Neither 3 -> 4 nor 4 -> were nearly as painful.

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 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).

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 :)

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 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.

[1] https://news.ycombinator.com/item?id=12763681

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.

> 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?

> 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.

> 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

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.

Their Benchmarks section comparing Kemal to Sinatra is quite huge.

Oh right, I didn't see that on the homepage: http://kemalcr.com/

So 44x faster (100238 / 2274). Not quite 100x, but still very impressive.

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.

Great points.

> 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.

>> 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/

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

> 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.

> - 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".

Phoenix is definitely inspired by Rails.

> 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.

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.

> 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.

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.

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.

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-...

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

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.

Sinatra came before Node.js even existed.

Reply on news.ycombinator.com