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)?
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