Thank you but I'm satisfied with the current Proxy approach of the store implementation and for now I'm not planning changing it (the pattern is very similar to what people nowadays refer as "signal").

The only thing that still bothers me slightly (and it is yet to be tested how it will perform with deeply nested tags) is the global MutationObserver required for the lifecycle functions (onmount, onunmount) as I couldn't find a way how to do it properly (I didn't want to introduce a special component wrapper structure) but the approach will be evaluated during integration.

The way to get around the problems of global MutationObserver is to use shadowdom with each component having its own one.

I recommend that you look at ponys (not my project). It's a good base for vue-like and svelte-like components. There is nice simple code there with a lot of eyeballs on it. You can mount any element in the template for your Shablon approach, and style and script tags can be written as normal. Put the Shablon function as a render function, or something like that.

I'll have to step up the release of my framework so that it can at least be seen. How will people include their own themes for components that doesn't crash with other people's themes? Instead of all of that trouble they could just put it in a style tag. This approach allows components to be inlined or async downloaded. If you look at ponys you'll see that it's leveraging many evergreen browser technologies.

The way to get around the problems of global MutationObserver is to use shadowdom with each component having its own one.

I don't see why would you need a shadowdom for that. A custom Web Component wrapper usually is more than enough to make use of its lifecycle callbacks but as mentioned above I want to avoid having a special "component" structure and prefer working with native DOM elements. This also will allow people to "plug" their own framework of choice if they want. Note also that I've also explored in the past internal wrapper with the is attribute but this doesn't work on Safari. For now the MutationObserver approach seems to perform fine when inserting and deleting 10k nodes each with 3 children and at least based on that tests it didn't have noticeable impact on the performance.

How will people include their own themes for components that doesn't crash with other people's themes?

There are no plans to introduce scoped CSS if that's what you are asking. We'll have a documented UI kit but for the cases where users want to provide their own CSS they can simply prefix their classes with something unique to their plugin and bind their CSS based on that prefix.

If you look at ponys you'll see that it's leveraging many evergreen browser technologies.

I'm aware of Ponys but I don't find it ergonomic enough to work with and if we were going to use web components then I would just use Lit to be honest.

They stated that they want zero dependency and required minimal maintenance, current ui framework is release very often and sometime break things

If you have suggestion for anything specific, feel free to open a Q&A discussion but many of the "issues" that you've mentioned were discussed several times already and most of them could be handled via the existing app event hooks (for example, presence was discussed several times but the problem with who should have access to that information, how it should be structured (rooms, groups) and how it should work were never really generalized enough to make sense to have it builtin; it just vary too much from one use case to another and it is better left to the developers to handle on their own).

The UI rewrite is prioritized because it is practically hardcoded and there is no option at the moment (without forking the project) to customize the default behavior. That's not true for the backend part.

The documentation will definitely be improved once the APIs stabilize.

Ok. Thanks. I know some of the issues have been discussed, so I thought I'd summarize them. But these issues did not go beyond discussion. I've seen a few examples where PocketBase was used simply to store a single table (like a book), and the developer used it exclusively as a CRUD engine. But I don't think your program was intended as a simple CRUD engine. For larger projects, you'll need additional capabilities (again, if you follow principles like self-contained, simple, and extensible). So, we simply take any application—say, a simple online chat—and look at what's missing for implementation, and it turns out that to write a chat, you need the ability to retrieve a list of online users. And then from this another question arises: how to do it and where to store it. By closing the presence api implementation, you solve 90% of the problems of standard web applications at once.
Again, you've done a great job with the engine, and there's no point in trying to force my opinion on you. But answer the question: who needs Pocketbase/what for, and what skills does someone need to have to work with it?
Once again, congratulations on the grant. I hope you find time not only to work but also to relax.🎉🎈

Maybe there is a language barrier and my English is just bad, but I honestly don't understand the purpose of this comment and how it is related to the announcement, so I'll stop engaging further but will try to address some of it.

and it turns out that to write a chat, you need the ability to retrieve a list of online users.

Again this is not as simple to solve as you may think because it highly depends on your specific use case (for example the groups/rooms requirement). Unfortunately I can't explain it better than what has already been discussed (I think the most recent one related to this topic would be probably #5101).

who needs Pocketbase/what for, and what skills does someone need to have to work with it?

I'm not here to try to sell you anything. PocketBase was created primarily for my own use case (please read the FAQ) which just happens to be generic enough so that other users can also use it. If by reading the documentation you don't see why you may need PocketBase, then you shouldn't use it. There is no point to sugarcoat it.

This is just a hobby non-commercial open source project and it will remain such. The grant will help accelerating the development process but it doesn't change the direction or scope of the project.

Again, if you have suggestion or a blocker issue that you would like to be addressed, free free to open a Q&A discussion but try to be more specific about your use case so that me and other users eventually can assist you.

u don't see why you may need PocketBase, then you shouldn't use it. There is no point to sugarcoat it.

This isn't about me. I just wanted to raise the most active topics in hopes of including them in the pocketbase. But based on your responses, I already understand what the development priorities will be on current stage.

This is just a hobby non-commercial open source project and it will remain such.

I think everyone already understood this. You mention it in almost every topic. 👍😁

It’s entirely up to Gani to decide what to build and how to use the funds. He’s made it very clear that this is a hobby project, and he doesn’t owe anyone an explanation or justification. It exists to solve his own problems.

That said, PocketBase has gained so much traction that it’s natural for many people to have opinions, requests, and expectations. I agree with you, I also wish the project had taken a different direction or the community would have been involved slightly more.

Still, Gani is completely within his rights to run it as he sees fit. Secretly though, I hope that one day he’ll consider involving others so it doesn't feel like a one-man project anymore, simply because his fantastic framework has grown far bigger than he probably ever expected thousands rely on it. Again, not because he hasn't been clear, but because reality has changed things.

Gani stated his reason pretty clear what he want in that repo

... Since I didn't feel comfortable maintaining UI plugins system on top of another framework with dozens other dependencies that tend to change in a non-compatible way over time, I've decided to try building my own with minimal API surface and that can be safely "frozen".

I think there is some misunderstanding (with hindsight, maybe it wasn't a good idea of me combining the funding announcement and the UI rewrite decision into one).

The work on the UI rewrite has been going on for several weekends already (this includes Shablon) and it has no relation to the funding, it is just a happy coincidence.

The UI rewrite is not really avoidable if we want to have full-featured plugins support, aka. to be able to extend both the frontend and backend part of the application.

Addittionally note that Shablon is already 90% complete and there is nothing really much to it. If you ignore the jsdoc comments and tests, the source code is probably less than 600 loc, which is practically nothing.
Again, the framework will have only the minimal required things that what we need for PocketBase, there are no plans to add more features to it.

I've mentioned this previously, but will repeat my self again - the funding will help significantly speed up the development process (without it I was planning maybe a stable release for mid 2027/28) but PocketBase existence doesn't really depend on it or even on the number of users using it. In the end of the day it is primarily a hobby and it will continue to exist as long as I have use for it and I find it interesting to work on. I know that this is not very community friendly but I don't think I'll be able to manage it otherwise, so please adjust your expectations.

I'm not entirely sure that I understand what you are referring to but there are no plans to have different multiple visualizations in the dashboard for the existing fields out of the box.

The main difference with the new version ideally would be that users will have the option to extend the default functionality and either define a new field with its own completely different UI rendering OR modify the rendering of the existing fields (option to store arbitrary data, e.g. "meta", as part of the collection and fields configuration will be considered as it was requested several times already).

I understand, so it is somewhat similar, and I like it. I'll contribute when it's released.

I don't understand. What would be the benefit of this "thin line"? To make it more clear that it is the prod environment?

If that's the case then I don't think it would be necessery because the new UI will have a colored frame around the main app content and users will be able to select a "theme" for their app (there will be 3 or 4 builtin themes each with light and dark variants). I'm not sure how to explain it better but here is part of a very rough mockup (I don't want to share more details as it is still very much work in progress and most likely will change during integration):

Note also that there are plans to add a more general "PROD mode" which will supersede the current "Hide collection create and edit controls" + may require extra confirmation when changing app settings (or when editing records).

If you have other suggestions, please open a new Q&A discussion with more details about you use case to avoid spamming all participants.

FYI, if your deployed instance has a valid SSL certificate (which is likely for production environments), the PB favicon will be green.

Thanks, just noticed the icon change 🙏

To make it more clear that it is the prod environment?

Exactly sorry for not being clear. Your idea is even better 🚀