FicusJS(docs.ficusjs.org)
docs.ficusjs.org
FicusJS
https://docs.ficusjs.org/index.html
65 comments
Web components = build your own custom HTML elements (in a nutshell). Instead of building complex interactive things with <div> <span> etc. and a mess of styling & JS, you ship a JS file and users create in their HTML <date-picker>, <file-open-dialog>, etc. that you defined.
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.
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.
Thank you. Was trying to type something up, but you beat me to it and its better too :)
These descriptions are helpful for a very focused view of one piece of a project. As somebody who writes lit-element every day, I miss React and Angular like crazy for everything else they solve and provide.
Interesting comment. Hopefully after building something with Ficus I can better appreciate Angular. The biggest issue I have is updating projects. Its fine if you only support 1 application but when you have 2 or 3, they start to end up on different versions and when you get back you have to spend a month updating to the latest versions, instead of adding tangible value to the product. Maybe I am just bitter as started on Angular 2 updated app to 3 then 4 then 5 then 6 then moved to another app for a year. Get back to app 1 and now we are 5 versions behind, and we are slowly moving forward again. Update to 7 this release and go from there, I guess.
Having worked in Angular 1 before there was such a distinction, and watched Angular as it exists now release and evolve... I hear you. React (and the huge JSX ecosystem) is much closer to what you created. And much more stable than all of that.
[deleted]
Try React. Breaking changes are few and far between, generally very easy to update to (a few hours at most for a medium sized app), and they almost always introduce new "new way" of doing thing at least one release before the old way is removed (if it ever is).
What exactly do you miss?
Everything, really.
- 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
- 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
So I recently got around to writing some code around a similar idea — enabling people to build websites using only components by treating data (the remaining bastion) as web components:
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...
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...
Interesting read. I knew it was possible but think this is the first time seen so many web component libraries used on 1 single page. Bookmarked.
Oh yeah, that was also something that ended up being a nice side effect of the insane amount of yak shaving I did and a nice way to sell the post to r/javascript -- I got a chance to look through the world of native web components and get a feel for most of the popular libraries.
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).
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).
I was hoping for this to be a project that helps you draw ficuses on websites
Here it is the github repo https://github.com/ficusjs/ficusjs
Why this over react, vue, or angular?
Not author, but this looks like a set of three small functions for a) creating web components, b) managing app state, and c) pub/sub event bus. It seems to focus on creating web components first and foremost, and then provides a couple of utilities to interact with them in a application.
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.
1: https://stenciljs.com/
2: https://lit-element.polymer-project.org/
3: https://lwc.dev/
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.
1: https://stenciljs.com/
2: https://lit-element.polymer-project.org/
3: https://lwc.dev/
Hi All,
I use Angular 6 – 10 at work every day @day$job and have used Vue.js for some side projects / school related. Long story short have been looking into standard web components for my next side project and FicusJS seems to check all the boxes. Problem is there is almost no information about FicusJS other than what I can find linked off https://webcomponents.dev/new/
The other ones in the running are GitHub/Catalyst, AppRun, CanJS or compiler Riot, Stencil, ect…
I think I want to stay away from build tools until I can’t
Does anyone have any experience with FicusJS? Seems FicusJS uses lit-html in all the examples so maybe start there? Good or bad would love to hear your story.
Cheers!
> Long story short have been looking into standard web components for my next side project and FicusJS seems to check all the boxes.
Could you please list the boxes that you were ticking?
For example, how many boxes would the following tick:
[1] - https://lit-element.polymer-project.org/
[2] - https://svelte.dev/
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/
- Great question. The main thing I was looking for was going build-less and the section of Ficus docs kinda sold me on the idea. Seems we still need to use a dev-server to allow native imports like
- 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.
I work on LitElement and if you want to use it buildless you can do so with the JavaScript reactive properties API (so you don't need TypeScript or Babel decorators to declare properties) and Chrome 89's support for import maps.
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.
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.
How lightweight is Web Dev Server? Back when the official way to go was still polyserve, I've had to make this:
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 :)
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 :)
Thanks, will give it try.
I don't think you'll ever get away without a build chain using LitElement. If you are, I think your project is a toy, hobby, or very far from complete
I have been using lit-html for years now, and lit-element for a couple years all in vanilla js for evergreen browsers with the only build step being bundling for production. Here is one of the projects: https://cisterna.app
You may want to take a look at lit-html coupled with ApplicationState [1] (disclaimer, I'm the author of ApplicationState)
https://github.com/claytongulick/applicationstate
https://github.com/claytongulick/applicationstate
How does ApplicationState compare to e.g. https://immerjs.github.io/immer ?
Thanks, will check it out. Bookmarked.
The x-element library published by Netflix [1] takes the best features of other web components libraries like Polymer and LitElement, and focuses on a standards based approach, e.g. es6 module loading at runtime, which is done intentionally to avoid a build step.
https://github.com/Netflix/x-element
https://github.com/Netflix/x-element
There's a chance Netflix will port to x-element to be an extension of LitElement: https://github.com/Netflix/x-element/issues/53
Thanks, going to read-up on x-element.
No experience with Ficus but others. I'd been trying to avoid that ceremony tooling/build step too. But, modern JS I've realized that's wasted effort. Embrace the suck.
Have you tried esbuild? It's still a build step, but it:
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)
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)
You can make vanilla web components with Svelte, and Svelte has a much better DX than React, Vue, and Angular. It also performs better thanks to the compile step. I highly recommend checking it out!
I think the DX claim is pretty subjective. I find JSX much easier to use than all the others mentioned, and a great deal more flexible. The ease of use being that it’s just JavaScript (or more importantly TypeScript), with some DSL. That means it follows all the other rules of the environment in which it runs, and uses all the same tooling. It also produces a data structure that’s renderer-agnostic, so it’s trivial to adapt to different platforms and build targets.
Well JSX is not really just javascript/typescript - it needs to be transformed first, just throwing a .jsx file into a script tag won't work. It does compile down to just javascript, but the same can be said for svelte.
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.
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.
> Well JSX is not really just javascript/typescript
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.
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.
Last I tried, though, certain kinds of value updates didn't work in WC mode and I had to fall back to non-WC mode to finish :(
Please add enough documentation to use FicusJS without prior knowledge of Web Components! It's very important for adoption as a framework in its own right with web components as one component.
Stencil is the real deal.
/$.02
Edit: ... if you're getting serious about standard web components per se.
Edit: ... if you're getting serious about standard web components per se.
Question: I’ve done Stencil in the past and quite liked it. I especially liked how helpful the community is on e.g. slack. Now I’m experimenting with lit-element. My initial expression is that it is not as fully fledged out as Stencil is. Do you have any experience with either lit-element or Salesforce’s lightning web components and are able to compare them?
Been using Stencil for the past year or so as a way of extending our Angular app with client-specific apps (eventually looking to open this up to clients to upload their own components / apps).
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...
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 have researched Stencil a few times and agree it seems to be like you say 'the real deal'. In time I might end up there but going to take the long way :)
> I think I want to stay away from build tools until I can’t
No typescript then, eh?
No typescript then, eh?
I use TypeScript everyday at work, and love it. No not a requirement for side projects. When they grow to something more change extension to .ts and go from there.
You can always annotate your code with JSDoc comments and type check your code with `tsc --noEmit`, i.e. typescript without the build step.
No strict null checks is kinda a deal breaker tho
How is performance compared to something like LitElement, which does bare minimum DOM updates in place? Also, does this have any functionality to support data binding? Passing values down a hierarchy of components and injecting them into the DOM is half the battle with web components.
The DOM update mechanism is part of lit-html, not LitElement. This thing allows you to plug any rendered in it seems, but the examples all use lit-html.
This is how I am reading the docs also. Not super obvious depending on how familiar you are with Web Components to begin with.
I was implying LitHTML in my question, but yes, it's pluggable in LitElement. So I'll rephrase, how does it compare to LitHTML?
Initial impressions:
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 :)
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 :)
Adding initial impressions:
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 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?
Thanks for the analysis.
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.
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.
Thank you for the analysis.
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.
Language is so interesting.
You read the parent comment and took it as throwing shade. I read the parent comment and took it as pragmatic admiration.
You read the parent comment and took it as throwing shade. I read the parent comment and took it as pragmatic admiration.
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 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
- "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
Minimalist web frameworks are better in my opinion. Less code that can break, less friction between you and DOM.
Did GP say there was a problem?
This does look cool. I wonder if there’s any interest in supporting JSX?
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)?