Another one !
GitHub - BuilderIO/mitosis: Write components once, run everywhere. Compiles to Vue, React, Solid, Angular, Svelte, and more.
One project to unify them all
Similar to useFetch in vue
It's hard to debate about the best technologies. So here are a summary of the arguments of the author.
Main Argument: React isn't great at anything except being popular.
- React is good.
- React laid down the groundwork for other web frameworks. Vue 3 and React hooks, Svelte's conventions from React, Nuxt from Next, ... The component based-model owes much to React-
- React’s greatness is more in what it meant at the time than what it currently is today, absent that context
- React has aged. And I don't think most people—particularly those using it regularly—realize how much or how poorly. → when you live in the React world, you only see improvements. It shields you from React's velocity compared to other frameworks.
- React doesn’t do anything better than other frameworks.
On a greenfield project, how do you make the call on the front-end framework you'll use for the next several years? Things to consider:
- Performance → Vue, Svelte, Solid, Inferno and a host of others generally provide markedly better performance than React.
- Learning curve → JSX allows HTML into a JS function. The only thing worse than using JSX with React is not using JSX with React. Many things other front-end frameworks handle for you or make trivially easy require manual intervention or significant boilerplate. React is built for Facebook, others frameworks for the world.
- Bundle size: not the smallest
- Scalability: React doesn’t have anything special here; it just has the most examples.
- Community and support: does not mean a better choice. A big community can be a downside, too, especially in the case of a so-called “unopinionated” framework such as React. It can mean too many packages to choose from, and too many different, competing opinions that you’ll have to decide between and take a stance on.
- Financial backing: Vue is one of the most successful and well-funded open-source projects in history. [Through examples] backing is not an issue among major front-end frameworks
- Developer experience: React placed behind both Solid and Svelte in terms of satisfaction in this year’s State of JS Survey results. React also placed behind Svelte, Solid and Vue in terms of interest React's satisfaction and interest have been declining steadily for years, while its usage has flatlined.
- Hireability: This is the one area where React definitively comes out ahead. If you need to hire a dev who knows your thing already, React is clearly the choice.
- vs Competitors: But bear in mind that choice also gives you absolutely no tech advantage over your competitors. They’re all (mostly) using React, too.
Why react stays on top?
Because we don’t always value the strongest choice as much as we value consensus.
One other thought here: it’s possible we’re already moving past React, but we just can’t see it at a high level yet.
Also available as font, svg or react component.
Sizes are 16, 24 and 32 px with a stroke of 1, 1.5 or 2.
Re-renders only affect the component that owns the state + its descendants (if any).
When a component re-renders, it tries to re-render all descendants, regardless of whether they're being passed a particular state variable through props or not. [... Because] it's hard for React to know, with 100% certainty, whether another component depends, directly or indirectly, on the updated state variable.
In an ideal world, React components would always be “pure”. A pure component is one that always produces the same UI when given the same props.
A tweak is to declare a component with
React.memo. If the props have changed, React will re-use that current component rather than going through the trouble of generating a brand new one.
Some argue that rerender is cheap too.
- React is a UI library.
- React component libraries are always for UI
- Components will update, whether you want them to or not
- useEffect is a major to control the rerendering
Comparing common concepts of web frameworks daily usage.
For each concept, an example in the framework is provided.
Does the same effect as slot/template in Svelte and Vue.
Especially what I was looking for :)
This causes some people to claim that Svelte doesn’t scale, but that’s premature. The real question that matters is: where is that point? Clearly, nobody’s worried about whether React scales, so when does Svelte lose its advantage over React? Turns out: the scale at which Svelte's advantages disappear is actually unrealistically high for just about any application.
But to summarize both: Svelte’s advantage disappears somewhere around 150 kB of components loaded onto the page.
Alternately: are you choosing a technology for a relatively new startup or project? Svelte will likely enable you to move more quickly and build something that’s more performant, but hiring or collaborating may be a challenge, given the relatively small pool of Svelte devs
Geoff Rich on Twitter: "Sure, React has a rich ecosystem. But Svelte has a Rich ecosystem." / Twitter
Sure, React has a rich ecosystem. But Svelte has a Rich ecosystem.
Some definitions: declarative programming, data binding, reactivity
In general, I don’t think the question should be whether a component uses its own framework or not. Instead, the question should be: Is this component small enough/fast enough for my use case?