FicusJS
docs.ficusjs.org
docs.ficusjs.org
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 :)
You read the parent comment and took it as throwing shade. I read the parent comment and took it as pragmatic admiration.
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".
- "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
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.
1. Works more or less out of the box. You'll maybe need to set 5 or 6 CLI arguments but that's it
2. It's super speedy (sub-second in our case)
I can see the argument for JSX being more flexible, given that you can store little bits of JSX in js expressions, something you typically cannot do with the other component frameworks. But tools like svelte have their own DX improvements that make things like state management / reactivity arguably a lot easier than React.
Right that’s the DSL part. But TypeScript understands it out of the box, and you can write the same expressions without the DSL by calling the pragma function directly (which I’ll often do for some tooling code that needs to run without a build step).
> But tools like svelte have their own DX improvements that make things like state management / reactivity arguably a lot easier than React.
Part of the reason I mentioned JSX rather than React. There are great libraries with similar state and reactivity facilities that work with JSX (for example Solid). The cool thing about JSX is that it’s not tightly coupled to any particular implementation.
Could you please list the boxes that you were ticking?
For example, how many boxes would the following tick:
- Preact with htm (tiny, looks very similar to ficus) [0]
- LitElement (tiny, very close to native web components) [1]
- Svelte (the darling of many since recently) [2]
[1] - https://lit-element.polymer-project.org/
[2] - https://svelte.dev/
- https://modern-web.dev/docs/dev-server/overview/
- Which would allow testing and builds (if go that route)
- Seems that you can use any renderer (uhtml, lit-html,htm, Preact), so what-ever I learn will be useable outside the Ficus eco-system
- Event Bus: Use this model in another project and worked well.
- Stores: not sold on the whole redux pattern, but want to learn abit more about global stores to update components
- Was in analysis paralysis before finding Ficus and the more I learned the more confused on what I should try next.
- Mostly needed to make a decision as I want to dabble with Web-Components but seems starting from scratch is too low level so pick something just a tad higher than that.
Generally, I think an import specifier rewriting dev server like Web Dev Server is the way to go since it'll work with so many other libraries out there.
https://github.com/unrelentingtech/es-module-devserver
which is a tiny middleware that uses regexps to accomplish the task instead of dragging in a JS parser :)
No typescript then, eh?
Edit: ... if you're getting serious about standard web components per se.
Overall it's done a good job but I still find the build system somewhat esoteric (there are a number of different approaches and it took some effort to figure out the right one for our use case).
I have noticed development has slowed down over the past couple months: https://github.com/ionic-team/stencil/graphs/commit-activity
Hoping it's more a case of it approaching maturity as opposed to it being neglected...
I think my main question is how it differs from (e.g.) react: is the goal to be fast or to have few or different dependencies. Or does it solve different problems to react (or fail to offer solutions to the problems that react was meant to solve)?
React = component-based JS single-page app architecture, using a fully virtual DOM and event system, and a new template language called JSX to greatly simplify the dev experience.
React and web components are kinda orthogonal ideas. React gives you a framework for building apps using React's design choices (including breaking your page into small reusable JS components, much like web coomponents allow too). But React goes significantly further and has opinionated choices about how to build your app, how to template your components, etc.
Web components just give you a framework-independent way to ship new elements to browsers and users--that's it. You can (in theory) actually make a web component that wraps around a React component if you were really motivated.
Why you see so much buzz and mention about web components these days is that browsers have improved _greatly_ since React was brand new. Many of the reasons to reach for a big framework like React have gone away. You don't have to rely on a super complex build system, bundlers, webpack, etc. to ship your JS to users anymore--mainstream browsers have support to import JS modules directly. You don't have to template your components in JSX and add all the baggage and complexity of a build transpilation step--you can use ES6 template literal syntax.
And that's where stuff like Ficus appears to fit in. It's for folks who don't want to pull in the complexity of a huge framework like React, but still want to build pages with components instead of a mess of imperative JS, jquery, etc. There's a whole bunch of little micro frameworks like this popping up--check out Haunted for another example.
I think a better comparison if you want to research things further would be comparing React with a web component-based framework like lit-element. Lit-element uses web components for its components, but it adds on a lot of opinionated design choices in a similar vein as React. Is one framework 'better' than the other? Well... it entirely depends on your needs and preferences. They're all capable of building great pages and apps, it's kind of like fussing and fighting over the brand of paint that you might use as a painter.
- Battle tested choices for libraries
- Documentation outside of our own (O'reilly books, online courses, etc..)
- SO posts about issues and sticky points
- Patterns for implementation (lack of these is shitty for JR devs. The only place to learn is PR feedback)
- Popular style guides
- IDE plugins
...and many more. Like being able to list POPULAR_LIBRARY_FROM_JOB_DESC on a resume when I can finally leave this job where leadership prioritized the browser's needs over dev comfort and productivity
Also, the advantages of web components and shadow DOM have never shown up. They only make CSS and browser testing more difficult
Demo page: https://mrman.gitlab.io/services-as-dom-elements/
Blog post describing the idea: https://vadosware.io/post/sade-pattern-services-as-dom-eleme...
I personally think I'll choose lit-element in the future for web components I build, it was by far the best to use and was least-surprise (which I value more and more these days).
React, vue, angular, etc. are more fully fledged frameworks for creating apps. None of them focus on standard web components, and all have their own internal component state + structure.
I guess you would want this if you need your components to be standard web components, e.g. if they are consumed by a parent app written in a different framework. So maybe a comparison with Stencil[1], lit-element[2], or LWC[3] is more apt.