But its far from the worst.
It was the first framework to put together JSX, a functional way of defining components and simplifying state. This was a monumental improvement. As a result they earned mass adoption.
As a result its the framework that now has a community moat that is not going to crumble until someone else can break ground in the way they did.
Sure, some of these could be considered "better" but they're all better due to incremental improvements for Frontend Engineering.
None of which are substantial enough to unseat the king
That's rather amusing. "Am I wrong? No it's the rest of the world!"
How are these other frameworks so far ahead? I've used a couple of frameworks and React has been the easiest from the big ones to wrap my head around.
I can only speak for Svelte, in Svelte 3/4 it was so dead simple that I built my first basic webapp with 0 javascript, css or html experience in 3 days.
By week 2 I was trying out different UI libraries and css frameworks, that part was super rough though, back then lots of compat issues.
Also, vue interops better with webcomponents and non-framework code than React in my experience. Most non-React libraries need a React wrapper to work in a React project.
It can be made better if you write it using non standard patterns - but the community is so dogmatic you'll get laughed out of the room.
All of my personal react projects use the MVC/MVVM architecture and are so much easier to work with
export class AppViewModel {
@rx accessor message = new TextField()
}
export function App() {
const vm = useViewModel(AppViewModel)
return <div>
<p>{vm.message.value}</p>
<input
onChange={vm.message.fromEvent}
value={vm.message.value} />
<div>
}
Makes it vue/angular/svelte-like, but unlike Vue/Angular/Svelte, you pick the version of TypeScript, the tools and don't need brittle plugins for your IDE to work with it.- You can test the view model independently of the rendering logic
- Dramatically reduces the code that lives directly in the component (it's only TSX)
- Allows for better abstractions and state management (services)
- Clear path to leveraging threads in front end applications
- Simple "visual" components (like <Input />, <Button />) don't need view models, just orchestrating components.
In practice, when writing traditional React, I focus too much on rendering cycles and the nuances of managing component state while spending much less time on making the application look good and feel performant/nice to use.
Having a component be pretty much exclusively TSX gives me a clear separation of "view" and "what the view needs" - so I just think of the html structure and css. I tend to create much better looking and nicer applications this way.
> It's way more skipping around in the codebase to find the parts you actually care about
Not really. You cnt+click to an implementation. Say you have "await someApi.getItems()" - you just click and go directly there. Traditional React apps need to thunk with redux or have a bunch of custom hooks that quickly become a source of confusion.
There are some examples under: https://github.com/alshdavid/mvvm/blob/main/examples/basic/i...
One day my dream is to delete 75% of the code, sprinkle some svelte into the business logic, and be left with a strictly superior, more performant version of the platform.
That means it is mostly React/Next.js and in some cases, Angular.
Anything else will get side looks on why are we not using the official SDKs from partners.
Better update performance by default.
definitely better dev tools