Ehy thank you @kachurun. Riot.js is feature complete and with v10 will smoothen some issues in few edge cases. I plan to improve the power of the spread operator as well.
All the things above require small effort and will be released with v10 but the maintenance of the official website, examples, templates and so on are quite a lot of work and will keep me busy for a while

Regarding the future development, being feature complete I can imagine that we could improve the memory management and its performance without touching the API.

Other important topics are pinned here in the discussions page https://github.com/riot/riot/discussions

Sorry for the late response.
A couple of things on my mind:
First of all, I hate the way packages are spread out; development never feels comfortable to me in this format. I think we need to put everything in one main monorepo and use Turborepo + Changesets for releases, at least for core, compiler, and dom bindings packages.
Secondly, TypeScript in the code itself—the code is not typed in any way right now, and I see this as a big problem.
And most importantly, infrastructure. If we're not ready to change the core API, we can at least extend the functionality through separate modules. At the very least, we can add reactive stores/signals, functionality like provide/inject or createProvider, etc. This doesn't have to be part of the core, but it can be available as separate packages for those who need it. I'm pretty sure it will require some changes in the core code, but not in the public API at least.
I believe this will greatly benefit many developers who may want to use Riot but struggle due to their existing mindset and lack of understanding of how to build a frontend differently. We definitely don't have the power to change people's thinking, but we might have the power to make using Riot more convenient without changing the API.
What do you think about this?

First of all, I hate the way packages are spread out; development never feels comfortable to me in this format. I think we need to put everything in one main monorepo and use Turborepo + Changesets for releases, at least for core, compiler, and dom bindings packages.

The repos are separated since I like to work in clean scopes with clear separation of concerns. In this way I can set up CI, unit test + coverage, issues management, release notes and git workflows in a granular way without overlapping.
If someone is going to take over the maintenance and think that a monorepo setup works better for him/her I am fine with that.
In the meantime that's not a priority

Secondly, TypeScript in the code itself—the code is not typed in any way right now, and I see this as a big problem...

That should be feasible since the type interfaces are available almost for every module and the code uses JSDoc. Probably a couple of rounds of LLM agents should be able to do it easily without touching the unit tests.
This is also not my prio since I am working to prepare the v10.

Thank you for your ideas, whoever is going to work on the project in future could get inspired by this post 🙏

Just realized my last message might’ve sounded rude - not what I meant, sorry about that 🤦‍♂️

Bro, I’m fully on board with separating concerns in code, but modern monorepo setups don’t contradict that at all. You can still split everything into scoped packages (even private ones, which is perfect for shared internals).

And the benefits are pretty clear:

• Easier local development

• More consistent and atomic package releases

• Shared tooling (TS, lint, test, build)

• Fewer repos to track and maintain

• Easier for contributors to understand the full system

• Simpler infrastructure and CI setup

The only real tradeoff is centralizing issues, but let’s be honest, unless the repos are maintained by separate teams, that rarely matters in practice. People usually open issues in the main repo anyway, and you can organize them with labels or scopes.

You mentioned it's hard to maintain multiple repos and this is actually a partial solution to that.
I'm not suggesting pulling everything (like router, observer, etc.) into one place, but at least having core, compiler, and dom-bindings in a single repo would massively improve DX.

Honestly, I think this would save you a hell of a lot of time in the long run — way less repo overhead.
Really worth considering. Anyway, thank you for taking the time to discuss this 🙏

Thank you for your feedback, I work daily on several projects managed in monorepo setups and my experience with it is unfortunately not so smooth as yours.

In the end it's about preferences, I prefer at moment to work on several repos. Managing them in this way has pros and contras but it's the way I like to work on them in my free time.

I might consider the migration to typescript in future though ✌️