I also avoid using Rocket for exactly the same reason!
I think, as a crate author, every authors want their crate works on Rust stable. But if Rocket changes to compile on stable, it will not Rocket any more. I means, it's not only more difficult to develop Rocket itself, but also more difficult to use on users side.
About Simi. At first, I try to use macro_rules! (which works on stable) but it is impossible to implement some of my ideas for the application!/component! macros. I spent a lot of time, go in different directions (try and error) to find a working solution, but I always have to choose which way: support this or that, not able to support both. It's a difficult choice. Several times in the process, I give looks into procedural macro, and finally give it a try. Later, I have a more than relief feeling to find out that there is another crate (maud) also decided to go from macro_rules! to procedural macro (they did it before me).
About the chance to stabilize Simi
wasm-bindgen (on which Simi depends) now compiles on beta.
Simi requires 2 nightly features:
#![feature(proc_macro_non_items)]: this is strictly required. Simi will still on nightly until this go stable.
#![feature(proc_macro_diagnostic)]: this only helps to report better error messages to Simi users.
If proc_macro_non_items is stable first, then we can turn proc_macro_diagnostic off for the production build. Only turns it on during development to have better error messages.
Yeah, it is simple thanks to procedural macro. If I only use macro_rules!, Simi is unable to reach that level of simplicity. Another reason is that it (counter) is the simplest example.
Hmm..., If I use github, I believe the number of stars for Simi must be many more than it has now, and also it may has a number of forks. And if I post an announcement on reddit.com/r/rust (I don't have a reddit account) it may receives more attention than it has now too.
But I believe that the succeed or failure of a project is not because it is on github or gitlab. The primary reasons must be the project itself. I think it may be:
Is it simple to use?
Is it good enough?
Is it flexible enough?
Simi was born from my own need. Next, I will use it in my own project, I hope I can improve it more!