When you start or build a new product/team and can freely choose which Framework you want to use, you can have a look at Svelte.
For our company Svelte is easier to use, it has (in our opinion) less bloated code (e.g. state handling) in our app as React or Vue (which we used before). BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React.
That React has better active contributers is one big point for React. But it depends on Facebook.
Do you have an example?
What do you mean 'at scale'. It's a UI framework that runs JS and mutates the DOM - there's no issues with 'scale' here.
That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.
This is complete and utter nonsense. Were you programming seriously before React? There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems. As an incumbent it has staying power because there is benefit in sticking with the herd, it remains a pretty nice developer experience, and because it has essential features other frameworks don't really provide yet (React Native being the biggest one although I do realize other frameworks are working on this now too).
Svelt isn't popular because to disrupt a solid incumbent you need something that is dramatically better at solving problems devs actually care about (not corner case performance benchmarks when React is "good enough" 99% of the time). Svelt has failed to do that, plain and simple.
Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community, maybe is a clue as to why Svelt has failed to be sufficiently introspective in either accepting it is a niche framework (which maybe it is great for) or that it needs to change if it wants to be more mainstream.
Indeed I was.
>There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems.
I'm not saying React isn't a good framework, it is perfectly nice, though I think you're overstating it. AngularJS was a perfectly fine framework as well, and that was out long before React.
>Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community
I'm not part of Svelt's community. I haven't actually used Svelt at all. I barely know about it. But I've been around for a while. Why certain frameworks go viral and others do not, is not always based on merit. I'll buy the argument that Svelt doesn't have enough of a benefit over React ... it also came out a few years later and doesn't have Facebook's marketing weight behind it either. Does that mean React is the best thing ever? Eh, it's alright. Having done everything from Flash/Flex/Starling, to Silverlight, to Backbone, to AngularJS, to React, I actually get more excited about State management patterns than widget overlays with some declarative patterns and data-biding. By the way, when it comes to ergonomics of building complex SPAs, I think we're just hitting the place that Flash/Flex was 15 years ago in Web Development.
And it still is. Mixing JS and HTML/DOM does result in fragile code and you shouldn't do it. React VDOM and JSX is not the same thing .. at all. Again, JSX isn't new. XML-based declarative UI frameworks with data-biding were an old thing by the time React arrived on the scene. That's how Flash Flex (MXML) and Silverlight (XAML) worked, for example.
It basically embodied the bad side of JS frameworks pre-React.
It managed to take alllll the wrong lessons from Flex.
Svelte vs React on a single side project I work on in my free time by myself is different conversation than Svelte vs React on a team that's moving fast and has more than a single dev.
I understood what you meant, I just disagree that this is a real consideration. Both are just UI frameworks following modern conventions in architecting your SPA code-base. From that point, both are just fine. Other considerations, like the fact that React is more popular and therefore more likely to be supported in the future, and therefore has more devs familiar with it, are way more important.
Large teams were using jQuery back in the day, with none of that HMR prettier-on-save Redux devtools fanciness. There's nothing inherently "unscalable" about the technology, especially now that most frameworks more or less use the same framework design paradigms.
> nothing about has convinced me to lead a project/team towards picking that over React,
This is just a cost of switching consideration. For better or for worse, first movers advantage is a thing. You're also not likely to switch from date-fns to dayjs or postgresql to mysql because you are invested into your choice of technologies, even though each pair might in theory be perfectly interchangeable.
Sorry to pick on this point but depending on your application this should be more (or much more) important. Too many teams have this same opinion and it's glaringly obvious how little they care about performance. I'd agree that raw performance isn't really important, but the ways you can and the tools you have to optimize the performance of the app are if you find that you have bottlenecks is and this does partially depend on the framework.
That said, I would agree, all frameworks would probably be fast enough for most use cases, and even with the optimization aspect arguably the most important aspects are about application structure and how the framework forces you to structure your application. As you mention, I think this is why React wins, the way it forces you to think about things unidirectionally, think about state and components separately, etc. are all big wins for understanding your application.
Also worth noting is that Svelte doesn't really have a big company backing it like React does and so the ecosystem is smaller, which could contribute to its relatively small size.
I've been working in React for ~4 years now, at all types of scale. While I've definitely seen performance issues, it's never been a case of a flaw in the approach the React takes.
I guess a better way to phrase my point - until I encounter a scenario where the performance is bad enough in React to warrant looking at other frameworks, choosing a framework based on pure performance is an over-optimization.
Of course, this would be a different conversation if React was known for being the one and only bottleneck in web app performance - but afaik that is a rare case.
One of the lead developers of Svelte uses it at the New York Times on some of their high traffic interactive data visualization pages, including their COVID charts.
I think what people mean when they say “at scale” is they want to see a large codebase, with a large team working on it, where Svelte is the primary front-end choice.
React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output.
Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.
The reason I think React works so well and is so popular atm is because it works just as well at a small scale as it does on a team with 5-6 active contributors (in my experience, at least).
That isn't to say that Svelte can't deliver the same wonderful experience at scale, I've just yet to see a truly shining example of it.
I may also be in the minority, but performance of front end frameworks is near the bottom of my evaluation checklist.
I've used svelte for some one off personal projects, just to get a feel. And it's fine but nothing about has convinced me to lead a project/team towards picking that over React, Vue, or even some SSR framework.