Simi is inspired by Yew. But it build on top of wasm-bindgen instead of stdweb.
View, Simi only check for what can be changed. You can also specify what to be no update at compile time.Any feedback is very appreciated!
nice, will check it out
the wasm-and-rust tutorial is heavily based around npm packages, which seems overkill if you don't intend to use anything else from the npm ecosystem
Npm is where the largest web crowd is. So its understandable why they gear towards it!
Very cool. I notice it appears to require nightly. What particular features require nightly? Do you plan to try and get it to stable at some point?
It may be foolish, but I've avoided Rocket because of the nightly issue.
BTW, I love the examples. Clear demonstration of basic principles. Thanks for including those.
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.
I tried the counter example!
It is simple to use. Thanks 
(If the project uses github, it might be better accepted.)
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:
Simi was born from my own need. Next, I will use it in my own project, I hope I can improve it more!
It is not nice to talk about github vs gitlab, I shouldn't ~ sorry.
I will try more examples in Simi, hopefully provide some feedback to you