Sinatra v3.0.0

[namusyaka]

I'm planning to list the major tasks for Sinatra v3.0.0.

Improve performance by especially focusing on our routing algorithm.

I'd love to improve the performance.
As a PoC, I have implemented pendragon and its radix tree implementation.
In fact, we need to implement original pure Ruby radix tree and its searching method in Sinatra. But there is a possibility of reducing the cost. In addition, roda also has an interesting way for improving routing performance.

Refactor our code base (especially sinatra/base.rb)

I have often seen developers whose base.rb code is awkward and gives up contributions.
The actual Sinatra's logic is not very complicated, but it seems that the code base integrated into one current file has the effect of making it feel more difficult than the actual difficulty.
Regarding this, I want to simplify the implementation by dividing the file properly and correcting the inappropriate specification.

Other topics, and opinions regarding the above topics are welcome.

[jkowens]

I absolutely think you're right about the need to refactor the code base. If new developers are going to be moved to help contribute to Sinatra and move it forward, the code needs to be better organized.

If performance can be improved, that will go a long ways toward keeping Sinatra relevant as well. Besides the routing tree that Roda has implemented, I like their philosophy of avoiding "pollution". They have been very careful to limit the instance variables, methods, and constants available in the route block scope. I think that could be improved in Sinatra, so naming collisions are less likely.

[304]

I fully support the idea of splitting base.rb into separate files. It can definitely be confusing for new contributors when they see almost 2k lines of code in a single file.

I would also like to share an idea and see if it makes sense to implement that. The suggestion is to introduce Rubocop to maintain the consistent code style across the project. It can be added as an another Travis CI check and I believe it would help developers to fix code style issues before opening a new PR. What do you think?

[namusyaka]

@304 First off, thanks so much for proposing the idea and working on that.
Overall seems good to me. To be honest, I don't think Rubocop is always good because I'm remembering ruby-grape/grape#1548 in Grape. As above link, I think Rubocop sometimes raises a new problem, however Rubocop is very useful for providing consistency on our development for new comers on the other hand.
In the end, we need to carefully review the code changes, but I believe Rubocop is able to reduce the cost of reviewing.

This is not a negative opinion on your proposal. I will carefully review your changes, which will probably be merged.
Finally, thank you again for your effort.

[halan]

I did the very first step of splitting base.rb into files. I can help refactoring small pieces too after that.

[namusyaka]

I know your contributions and other incoming PRs exist, but I have been ultra busy now.
I'll try to review those by next month. Sorry for the inconvenience.

[adbatista]

I would like to help with this, but probably should wait for #1543 first right?

[adbatista]

Hi, @namusyaka I think you still are pretty busy but if you need some help please let me know :D
I'm looking forward to getting Sinatra 3.0 ready for use :D

[namusyaka]

@adbatista Great, thanks for your kindness comment.

To everyone: I'm thinking how we make v3.0.0 more great for a lot of rubyists.
This is a new idea:

• How about Sinatra to be a cloud native Rack application?
  • This purpose doesn't mean our code changes, but growth of our eco-system by creating related code example, library and gems.
  • e.g. a recipe for sinatra on kubernetes, sinatra on aws/azure/gcp..

[nileshtrivedi]

Ruby 3 has been released with Ractor-based concurrency as an experimental module: https://www.ruby-lang.org/en/news/2020/12/25/ruby-3-0-0-released/

Here is an article on building a Ractor-based webserver: https://kirshatrov.com/2020/12/27/ractor-web-server-part-two/

I don't know the timeline for Sinatra v3.0.0 but it would be great to see some support for concurrency as it can bring multi-factor performance improvements for most users.

[epergo]

For following iterations of Sinatra (either 3.0 or minor revisions) maybe is a bit unusual but I would try to support fewer things, following your idea of making the project - and its ecosystem - easier to maintain.

Template languages

For example, IMO we support too many template languages, a couple of them haven't been updated for quite some time, like Builder (2013) and others I don't think are used much like WLang.

I think Sinatra should support mainstream templating systems, the rest could be removed, maybe we could add a section in the README to explain how to support a new template language so developers know how to implement it in their projects and/or create gems.

Ruby flavors

I already opened a PR for this. Basically, we supported a couple of Ruby flavors that are all deprecated and their development has been stopped so I think we shouldn't even mention them.

Clean up communication channels

As of now, in the README we can see that there are 4 ways of engaging with the community

• A slack channel which I tried to join and received a Channel not found "sinatrarb"
• An IRC channel, don't know if this has any activity or not
• The issue tracker here in Github
• A mailing list

Right now Sinatra doesn't have much activity, I think we could guide users to either use the mailing list or open issues here, so IMO slack and IRC could be dropped.

Documentation sites

Developers have multiple ways of learning about Sinatra, there is the README.md which has a lot of information, the Sinatra book which adds extra information but hasn't been updated since 2017 and the Sinatra Recipes but it doesn't work.

I think all of this could be merged (if possible) into the main Sinatra's web page so users can easily navigate all the available information about the project.

Also, we could clean up deprecated stuff or talks/blog posts too old.

---

As for code itself, both the WIP Rubocop integration and splitting base.rb are fantastic things to do, as they would ease the development of the project.

Speeding up the routing algorithm sounds great too, but I think Sinatra is sadly in a stale state so IMO we should push for tackling issues that clean up the project.

Same for the cloud-native recipes, it sounds great but it would mean more things to maintain, and unless Sinatra goes mainstream again I'm afraid those repositories and gems would stale too. That doesn't mean I'm against it!

This ended up being too long, sorry about that!

WDYT?

[namusyaka]

@epergo thanks for writing down, I like your ideas.
Overall seems reasonable to me.
@jkowens Any thoughts?

[jkowens]

@epergo @namusyaka I fully agree 👍

[jkowens]

We have a number of pull requests that I would like to see merged and released that are waiting for a major version.

[zzak]

I like the idea of splitting out unmaintained templates as a separate gem.

Another idea I had recently was to pull in the best parts of Sinatra::Contrib and make them first-class citizens of Sinatra. One gem, all the things you need.

[zzak]

I've taken a stab at starting the unstable branch, which includes rewriting the SHAs to try and solve #1305. I'm fine not going down this route but I thought now would be a good time as any if we're going to start a MAJOR release.

I also think we should be very loud about communicating when (if) we decide to merge this into the default branch, possibly creating a "stable" branch for the 2.x line for those who prefer using git over the releases. (I think there are those folks out there.)

[dentarg]

I've taken a stab at starting the unstable branch, which includes rewriting the SHAs to try and solve #1305. I'm fine not going down this route but I thought now would be a good time as any if we're going to start a MAJOR release.

I also think we should be very loud about communicating when (if) we decide to merge this into the default branch

I'm hesitant if #1305 should be solved for the default branch. The issue hasn't received any comments since 2017, and rewriting the history sounds disturbing for more people than the workarounds. #1305 (comment) linked five other repos with the same problem, but as far as I can tell, none of them have addressed it. (For the unstable branch I think we can do whatever we want)

[zzak]

@dentarg Thanks for your feedback! Actually this was my initial thought too, but I wanted to gauge the impact.

I can see possibly having to change existing PRs, or links to commits breaking but could you explain more how this could disturb other folks? I guess I'm not entirely sure on the trade-offs.

Appreciate any others who have knowledge here as well, this seemed like a good idea at first but like I said -- I'm happy to change my mind :)

[dentarg]

I can see possibly having to change existing PRs, or links to commits breaking but could you explain more how this could disturb other folks?

I mean disturbing as in unexpected. It will be a change for everyone that has ever cloned the Sinatra repo. I thought rewriting the history of a public repo was a big no-no? The things you list sounds enough to me to not consider rewriting the history.

• The Git documentation advise against it: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/user-manual.html#problems-With-rewriting-history
• Here's someone asking what we are wondering: https://stackoverflow.com/questions/11149499/what-happens-when-you-rewrite-history-of-a-public-branch
• Another one: https://stackoverflow.com/questions/1491001/what-are-the-practical-consequences-of-rewriting-git-history

There are probably many Gemfile/Gemfile.lock in the wild with references to commits too. (I guess those wont stop working, unless we tell GitHub to remove dangling commits)

Also sounds like signed commits will no longer be signed after a rewrite.

[zzak]

@dentarg Thanks for digging those up, I will give them a look and think a bit on this

[zzak]

Ok, I've changed my mind and just created a new unstable branch off master.

[RichStone]

@adbatista Great, thanks for your kindness comment.

To everyone: I'm thinking how we make v3.0.0 more great for a lot of rubyists.
This is a new idea:

• How about Sinatra to be a cloud native Rack application?

  • This purpose doesn't mean our code changes, but growth of our eco-system by creating related code example, library and gems.
  • e.g. a recipe for sinatra on kubernetes, sinatra on aws/azure/gcp..

I've recently created a Sinatra - MongoDB - Heroku - Minitest template.

This was quite fun and I'd be up for more stuff that you mention here.

And having worked with Sinatra for the first time trying to navigate all the (partly deprecated) docs, I really love the idea of minimizing some parts.

Developer experience is what we are after if we want to make it great for a lot of rubyists and it begins with the docs (10x here would be to refurbish them and give it a new modern look too🔮).

[RichStone]

I've recently created a Sinatra - MongoDB - Heroku - Minitest template.

This is the thing: https://richstone.io/the-freedom-stack-ruby-api-app-sinatra-mongodb-heroku-minitest/

It was kind of a special project and got a bit lengthy. The final vision would be to create something that will make into something like https://awesomestacks.dev/...

Cloud-based tutorials would be more to the point.

[GildedHonour]

the current Sinatra version 2.1.0 doesn't support Ruby 3.x, does it?

[dentarg]

@GildedHonour You can use Sinatra 2.1.0 with Ruby 3.0 but there's some use-cases that doesn't work. The ones I know about are #1684 and #1701.

[dentarg]

I think the master branch (possibly renamed to main) should be our "unstable" branch. It is too confusing with both master and unstable, we get duplicated pull requests like: #1740

The argument that many users have specified to run against the Sinatra master branch in their Gemfile is not valid IMHO. If you do that, you are on your own. Also, bundler records the specific commit, so it wont change for users without them knowing.

With the scarce resources Sinatra contributing, I don't think we should take on the responsibility of having a "stable" master branch. It is too much work. IMHO we need to merge fixes and make releases (yeah, this is our current problem, the people who can do that is MIA). Caring about only one branch for that makes the process easier.

Links:

• https://github.com/sinatra/sinatra/compare/unstable
• https://github.com/sinatra/sinatra/commits/master

[jkowens]

@dentarg I agree, I'm thinking master should be tagged as 2.2.0 and the unstable branch should be merged into master. I guess that means all the versions should be bumped for sinatra and its subprojects first.