Stick with SolidJS, or switch to React? #420
-
I want to use this discussion to end the debate of whether we should use SolidJS or React by March 10.
ProblemSolidJS has been chosen as framework due to the ambiguous performance requirements of the inlang editor and potential upside to deliver an oustanding user experience that would be hard(er) to reach with React. But:
ContextThe inlang editor allows translators to manage translations in git repositories ("VSCode for translators"). The inlang editor runs git client-side, in the browser, and clones repositories into a virtual file system. State management, and thereby rendering, is complicated. A reactive "chain" from the virtual file system to git, the AST, and UI needs to be maintained. One line of change in one file needs to propagate through the whole system. flowchart LR
subgraph FS [virtual filesystem]
file1
file2
more_files[...]
end
FS<-->AST
AST<-->UI
AST
UI
FS-->git
git<-->UI
Solid has mainly been chosen as the UI framework because of its performance. The "reactive chain" outlined above was/is expected to lead to performance issues. But, SolidJS has improvements that go beyond its performance. For example, Solid's reactive system and state management are decoupled from rendering. We could leverage Solids reactive system throughout the whole chain e.g. for the virtual filesystem too. Another benefit is that SSR is relatively simple and performant without additional complexities like React Server Components or NextJS. More reasoning can be read in RFC-002 Requirements of the editor
Arguments to stick with SolidJS
Arguments to switch to React
|
Beta Was this translation helpful? Give feedback.
Replies: 9 comments 21 replies
-
In my opinion the UIs rendering performance and file size shouldn't be top priority for the editor. Rendering performance and file size can influence the user experience, but aren't to only factors. The UI isn't part of the ideas core. With the first iteration I think it's a good idea to choose the tools for inlangs UI which doesn't slow us down, delivering the key features like collaborating on translations directly from the browser via Git. If we decouple the UI and the business logic of inlangs editor, the tools which are used to build the UI can be replaced later and also aligned with inlangs identity. Maybe it's a good idea to focus on delivering the key features or USPs and care about the rendering performance and file size of the editors UI when it starts to be a problem. |
Beta Was this translation helpful? Give feedback.
-
From Solids Discord by @fabiospampinato:
|
Beta Was this translation helpful? Give feedback.
-
This. Without going into detail of all the benefits + pros and cons of React vs Solid, I don't think its of any necessity to change it as of now, because the root issues of potential performance bottlenecks are connected to I/O with git / file system. The editor is fairly easy when it comes to UI, a few input fields, select fields etc. All of the modern frameworks are handling such use cases with no problems. Solid looks promising, lets give it a try and benefit from its performance. It's very similar to React, so a rewrite to React if inlang hits a hard walk with it is also possible and not that scary like switching from any other framework to React. |
Beta Was this translation helpful? Give feedback.
-
React could help increase the speed short term because existing components can be used. Once a custom component needs to be implemented, it will be probalby slower to build it in react, because you need to care about performance, rendering issues, choosing the correct variant of the 10+ I think it will be hard to switch framework in the future. The inlang editor can be extended and this probably needs to happen with the same framework the core editor uses. So when switching from react to solid, it will break all existing extensions, which is bad. React has the bigger ecosystem, so there are potentially more developers who could write an extension for the editor. But a good react developer should also be able to pick up solid in a reasonable amount of time. I'm in favour of the technically superior framework: solid |
Beta Was this translation helpful? Give feedback.
-
I think the current focus of React core team is to do as much of rendering server side as possible and stream updates down. Which is not something useful for the kind of experience inlang should have as most heavy logic operations are done on the client (git loaded in). So Solid is a great choice. I also stand by Fabio's comments, the argument that React has a huge ecosystem doesn't really translate as from what I see everything inlang editor will be able to do is going to be custom written components. I am also very curious how full reactivity be achieved. I think Solid's signals and some code on git side is a possible way to achieve this. |
Beta Was this translation helpful? Give feedback.
-
This reply by Dan was a nice read on React as it compares to signals. I personally hold the opinion of Evan on the issue too. I think the low effort to higher performance you can do in solid is very nice. You don't have to think about memoization etc and React Forget is not here and not sure when it would land. But to be fair, I don't know how complex Inlang editor plans to become, Linear etc. show that you can build well performant apps in react too so whatever choice is picked be it react or solid I think will be good. I also personally love Solid's community, their Discord is a lot more active than Reactiflux/NextJS for sharing novel ideas. |
Beta Was this translation helpful? Give feedback.
-
Clarifications on potential performance issuesPeople misunderstand what I mean by "we likely need performance". I am referring to the problem of maintaining MB (entire repos) of (reactive) state client-side that is spread across 3 different states + the UI state = 4 states. SolidJS could be of substantial value to manage and render the states. 1. The inlang editor has close to no external I/OThe inlang editor clones entire repositories into the browser memory/local storage. Every change a user conducts in the UI modifies client-side state. Think of the inlang editor as VSCode for translators; everything is running client side. 2. The editor needs to keep 4 different client-side states in syncIf a user updates a translation in a text input field, the change modifies the AST which subsequently triggers a re-write to the virtual filesystem. Changes in the filesystem trigger a need to be reflected in the git state and thereby the UI. 3. Explaining the 4 states, the "reactive chain" problem, and how SolidJS could help
the.editors._reactive.chain_.state.problem.mp4 |
Beta Was this translation helpful? Give feedback.
-
@inlang/contributor Everyone expressed to stick with SolidJS. Thus SolidJS stays. @davedbase (a SolidJS member) Thanks for participating in the discussion! |
Beta Was this translation helpful? Give feedback.
-
just saw this thread from twitter, and while reading the initial post, I noticed this part and I wanted to add a bit on it:
Ark-UI recently was made public, it is built using zagjs and is meant to be a framework-agnostic Radix-UI alternative |
Beta Was this translation helpful? Give feedback.
@inlang/contributor Everyone expressed to stick with SolidJS. Thus SolidJS stays.
@davedbase (a SolidJS member) Thanks for participating in the discussion!