Looks like a relatively new project -- only 59 commits, all by one person, starting from last September. And based on a GitHub search for "ficusjs," it seems that no other projects mention it.
It's only a bit over a thousand lines of code, and based on a cursory glance, the code is in pretty good shape. It should be able to fit entirely in your head, and for a lightweight framework, that's a good thing.
The API itself reminds me of the good old React.createClass({ ... }) days and I wouldn't be opposed to using it. Overall it looks promising for building an MVP, and shouldn't be horribly difficult to transition to a more complicated framework when needed :)
The first-blush API for defining a web component looks pretty nice and simple. Probably won't have the best performance in the world but that's fine for situations where I just want to sprinkle some interactivity to a server rendered or static site.
The store looks nice in some ways, but the actions/mutations language looks very boilerplatey and convoluted. I feel like I'd want something much simpler like jotai or zustand.
The event bus... seems on first blush like it'd be awkward to mix multiple event buses into a single component?
The event bus is one of the more interesting concepts. You could have a single component that includes the HTML table/view component and the add item dialog component wrapped into one bigger component. When the add component closes fires event to the view component to refresh based on the new data. A global state object might be easier, but I have yet to jump on the global store (flux/redux/NgRx) wagon yet. Although I do look forward to learning about how Ficus implements the global store and how I can use the concept in future projects.
and what is the problem with that?
"Single guy made a good looking and so far working product in only 59 commits since september" is a different way to present the same facts.
Honestly, I also took it as throwing shade. I had to read the whole thing and realised that GP clearly wasn't throwing shade.
I am wondering why I initially thought that. Maybe a mindset of inherently better software created by Teams that's instilled within us these days could be a part of it. Trusting a lone programmer, it's harder because you have to reject the "programming".
I think it's because of several points that can be interpreted as good or bad:
- "relatively new project" > code is fresh and certainly well-organized / maybe lacks stability
- "all by one person" > a single vision is a good thing / if that person gives up the project, it's dead
- "no other project mentions it" > [no good aspect in that] / no real-world usage
If you have any experience in the frontend field, those points are more often bad than good. You don't want to invest time and/or money in that kind of project that has a high chance of being dead within a year.
Now, that does not mean that it's a bad project (it looks pretty good actually), but it's just very young.
Edit: actually I like this framework very much (but I have a thing for underdogs). It might be ideal to quickly throw POCs or toy projects
Looks like a relatively new project -- only 59 commits, all by one person, starting from last September. And based on a GitHub search for "ficusjs," it seems that no other projects mention it.
It's only a bit over a thousand lines of code, and based on a cursory glance, the code is in pretty good shape. It should be able to fit entirely in your head, and for a lightweight framework, that's a good thing.
The API itself reminds me of the good old React.createClass({ ... }) days and I wouldn't be opposed to using it. Overall it looks promising for building an MVP, and shouldn't be horribly difficult to transition to a more complicated framework when needed :)