[feature]: Move from React to Solid

[snnsnn]

Is there an existing issue for this feature?

• There is no exsiting issue for this feature

Summary

I know you just move to React for rendering but React is not performant enough for relatively large pages which makes tablet or mobile devices freeze especially during re-rendering after state update like settings change. Actually that is how I realized you are using React.

As an alternative you can use Solid.

Solid compiles to native elements and does not use VDOM. It is way more performant than alternatives especially for large lists, such large lists that it is impossible for React to render and requires virtualization.

It uses JSX, you will feel at home.

UI updates are localized thanks to fine grained reactivity. Far superior to VDOM model.

Also React's component logic forces user to add unnecessary wrapper around elements to implement additional behavior, solid has custom directives to address this problem.

It supports SSR.

It is something to consider. We can discuss further if you like.

Your purposed solution for this feature

Consider alternatives for rendering, Solid seems better alternative for your use case.

[azizsafudin]

While migrating from react to solid is possible, it's not very straightforward. It's better to build your own client with solid and move towards getting feature parity. Or perhaps a more performant, lightweight, barebones client for low spec devices.

[adiled]

Just came here to express this need for performance, and I got the feeling because I landed on legacy version while looking for script without tashkeel, and it was a breath of fresh air. At this point of frontend evolution, it would be hard to argue that current state of React is more performant and better DX than alternatives.

But it would also be unfair to think of React-to-Solid migration as a convenient feat. @azizsafudin recommendation is indeed the feasible way, but it will be challenging to coordinate a transition of quran.com itself to the new version. On the other hand, it would be very sad to see quran.com ending up in any anti-productive, non-inclusive vendor lock-in, despite alternatives.

I haven't reviewed the current issues, I will do it now, but being on a mid-sized machine, though years, I've faced consistent trouble with fetches simply bailing on me, audio jamming up, despite constant maintenance and updates on repo. I think these are more of reactivity concerns but there are certainly other React-specific performance factors jeopardizing LCP.

I wish to invite core maintainers to welcome and support the notion of migration from within the codebase. An inclination there will open the right doors InshaAllah.

[snnsnn]

it would be hard to argue that current state of React is more performant and better DX than alternatives.

I don't know what makes you say that but React is neither the most performant nor the easiest one to write. https://krausest.github.io/js-framework-benchmark/current.html

React uses VDOM which requires to re-building of DOM tree whenever the state gets updated but it also keeps the state inside the component which makes very hard to maintain good performance and simplicity at the same time. State update are executed inside the event loop, crossing the async boundary everytime state gets updated. This cause inconsistent state and performance degradation. There are many more downsides. I have been using React almost from the day one it became public.

I believe vendor lock-in should not be any concern since there is little benefit from avoiding it.

Quran.com is a static website with very specific use case, so it should not be that hard to have good and performant application.