Stick with SolidJS, or switch to React?

[samuelstroschein]

I want to use this discussion to end the debate of whether we should use SolidJS or React by March 10.

Warning
Keep in mind that a framework can not be replaced/changed easily. The decision we take now is the one we should stick with.

Problem

SolidJS 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:

1. Uncertainty about the necessity/clear benefit of choosing SolidJS to deliver an outstanding product experience.
2. The lacking ecosystem of SolidJS leads to (perceived) slower iteration speed.

Context

The 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

Loading

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

• Being able to deliver an outstanding product experience, e.g. whatever we choose must be able to handle the performance implications of the uncommon state management and performance requirements in the future.
• The inlang editor will expand beyond strings. Editing documents like PDFs, PowerPoints, and even audio/video will come with their own performance implications and requirements.

Arguments to stick with SolidJS

• SolidJS has best-in-class performance. The inlang editor, in its basic version, already has critical performance issues. Note however, that the root cause(s) of those performance issues are not necessarily due to the rendering framework, see https://github.com/orgs/inlang/projects/9.
• Batteries included. State management, data fetching and more are covered by Solid but not necessarily best-in-class.
• One reactive state management system across all apps and libraries of inlang (using the reactive system without the rendering library)
• The Solid community is tight-knit. We can contribute to and grow with SolidJS. That is an engineering upside that could turn into a business upside because we attract "above average" talent.
• (The web is moving towards a framework-agnostic future with the rise of Svelte, Solid, and other frameworks. React will stay dominant though.)

Arguments to switch to React

• React might be "good enough" performance-wise. External libraries are likely optimized for performance.
• The ecosystem of React should increase our iteration speed. For example, a UI library like https://www.radix-ui.com/ would help us. We could leverage https://zagjs.com/ but it's lower level than Radix.
• The requirements of the editor besides performance are unknown. If we need an audio editing feature, for example, React will have a library that we could leverage. For Solid, we would likely need to develop our own wrapper or develop our own library.

[openscript]

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.

[samuelstroschein]

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.
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.

The bundle size and "wow we are so fast" are not what I refer to with "performance". The elephant in the room is whether React will be fast enough to deliver a "delightning" user experience in the long run based on the uncommon state and performance requirements the inlang editor has.

If we start building out components for the UI, we are pretty much locked into the framework. Thus, we should have a debate on which UI framework to build on now.

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.

The business logic will be de-decoupled, but the design system and UI components will either be React or Solid-based.

[davedbase]

While there's a valid argument that speed to deliver USP is a preference for an early stage startup it can also be a negative. There are likely startups that have failed due assuming perf isn't. My suggestion would be to attempt understanding and discussing the performance characteristics that would matter and proceed accordingly.

The availability of a large ecosystem is sometimes an overstated need in some cases. Most applications end up requiring a few firm requirements such as a UI kit. With ecosystem utilities becoming more agnostic and the growth of Solid, the speed argument supporting React becomes weaker. This again something for a team to study, define and map out for at least the first 1-2 years. In that timeline ecosystem is likely to continue evolving significantly.

Another thing to consider is that you cannot easily optimize for performance. Once you've invested in a framework, there's no easy way to go back. It's a rebuild. If you start with Solid and for whatever reason the experience isn't fast enough or viable enough, then the switch to React would similar to a migration. Similarities of Solid and React have made migrating React -> Solid easy. A similar Solid -> React might be similarly as easy.

[samuelstroschein]

From Solids Discord by @fabiospampinato:

IMO runtime performance is possibly the best reason to pick something like Solid. And if you want an "outstanding product experience" the ecosystem probably doesn't help you much, like writing your own perfect components will never be beaten by glueing together a bunch of third-party general components.

[ivanhofer]

Until now I haven't seen an UI framework that covers all components I would need.
I can build a button component on my own in a few hours and don't need a framework for that. And once I have to implement my-custom-list-component I can't use the existing components anyways. You will end up writing a lot of code replicating the design of the existing components because you need to reimplement (or copy&paste) it.
Unless I'm really sure the framework covers all I need, I personally would not use an UI framework.

[mosheduminer]

I will point out that even in this case, there is an advantage of a headless library which handles complex behavior and accessibility (generally these components are a bit more complicated than a button). Solid does have some libraries which try to do this (such as solid-headless, the above mentioned zagjs, and the still-under-development kobalte).

[ivanhofer]

Those points mentioned above refer to "traditional" ui frameworks with built-in styling. I agree, headless frameworks indeed help to speed up the development process

[felixhaeberle]

And to jump in real quick, maybe a bit off topic but what prevents us from using multiple headless UI libraries as an exception? I don't see the disadvantage here until we use the same styling approach because otherwise it will get wild.

But if there's simply no other way, the usage of some other library instead of for example zag.js is not something I consider harmful. Given that the exception component has good code split and not heavy (no) dependencies on other libraries.

Also, there is the possibility to contribute to for example zag.js to add missing components which would be a super way to gain further traction, visibility and street cred.

[davedbase]

I will point out that even in this case, there is an advantage of a headless library which handles complex behavior and accessibility (generally these components are a bit more complicated than a button). Solid does have some libraries which try to do this (such as solid-headless, the above mentioned zagjs, and the still-under-development kobalte).

There's also solid-bootstrap which is extremely well maintained. SUID as well as HopeUI if you don't need SSR. Kobalte is moving at a very nice pace. You can find the growing list of ecosystem utilities here: https://www.solidjs.com/ecosystem as well as: https://github.com/one-aalam/awesome-solid-js.

[felixhaeberle]

Note however, that the root cause(s) of those performance issues are not necessarily due to the rendering framework, see https://github.com/orgs/inlang/projects/9.

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.

[ivanhofer]

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+ use hooks etc.

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.
Maybe a "microfrontend"-solution would make it possible to use react inside solid but ideally a single framework should be chosen.

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

[samuelstroschein]

React has the bigger ecosystem, so there are potentially more developers who could write an extension for the editor.
The inlang editor can be extended and this probably needs to happen with the same framework the core editor uses.

We should probably not mandate a framework to extend inlang with. Let people choose React, Solid, Svelte, Vue, whatever they like.

I'm in favour of the technically superior framework: solid

Noted!

[ivanhofer]

We should probably not mandate a framework to extend inlang with. Let people choose React, Solid, Svelte, Vue, whatever they like.

Ideally yes.. but if it takes 3x as long to build it to support all frameworks, then I don't know..

[davedbase]

Your team should have a look at Mitosis (https://github.com/BuilderIO/mitosis) for the cross-framework implementations. You write in one target and compile to each framework. If this of interest I can facilitate a chat with Sami, the current maintainer. It would save time in deploying your framework SDKs.

[nikitavoloboev]

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.

[davedbase]

In all fairness React Forget is also designed to help bring more client-side performance benefits to the framework as well. But who knows when and if that will be an advantage to your project anytime soon.

[nikitavoloboev]

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.

[felixhaeberle]

Interesting reads, thank you for bringing them up!! But let's not confuse UI speed with data I/O.

Linear has almost no classic data I/O (like REST, GraphQL) but makes everything real-time
in very small data packages over a pubsub like system. This is why it's "fast". But the fast part is not the UI framework, but the data I/O.

Solid and React have both no measurable speed impact in terms of UX. That's just numbers and well, Solid performs better at these numbers. What makes UI slow is not well-architected components and component trees. What makes applications slow is data I/O.
Inlang has to fight first and foremost with data I/O.

[samuelstroschein]

Clarifications on potential performance issues

People 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/O

The 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 sync

If 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

• Changes in the AST would not diff/re-render the entire UI of the AST (compared to React)
• Solid's reactive system can be used for the virtual filesystem and git too, maybe eliminating the "reactive chain problem" (sync and optimizing the states) alltogether.

the.editors._reactive.chain_.state.problem.mp4

https://beta.tldraw.com/r/v2_c_odwtgE93zFDuYkocvM3AS

[mosheduminer]

That is correct. However, care must be taken to avoid memory leaks, primarily around the use of effects. Effects needs be created in the scope of a root, so that the effects are cleaned up / disposed of when the root is disposed. In the render tree, this is usually taken care of for you (render and control flow components create roots for you), but if you're building something outside of that, you need to take care (unless your intention is that the effect should never be disposed). You'll see a warning in the console if you create an effect without a root.

[samuelstroschein]

Correct. One Solid member is, amusingly, building a reactive filesystem this weekend that we could leverage/take as inspiration.

[felixhaeberle]

Correct. One Solid member is, amusingly, building a reactive filesystem this weekend that we could leverage/take as inspiration.

🎊 I want to see this!! Any issue / PR / repository were this is happening yet?

[samuelstroschein]

No, Alex Lohr (https://github.com/atk) said he is going to work on the reactive filesystem this weekend for the new SolidJS docs. I'll comment again once I know more.

[samuelstroschein]

@felixhaeberle reactive file system WIP solidjs-community/solid-primitives#341

[samuelstroschein]

@inlang/contributor Everyone expressed to stick with SolidJS. Thus SolidJS stays.

@davedbase (a SolidJS member) Thanks for participating in the discussion!

[davedbase]

Yay! I'm pleased to hear that. I hope you and your team finds incredible value in Solid. Please do not hesitate to reach out for anything, I will do my best to connect you with the right sources in our growing community.

[astahmer]

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:

The ecosystem of React should increase our iteration speed. For example, a UI library like https://www.radix-ui.com/ would help us. We could leverage https://zagjs.com/ but it's lower level than Radix.

Ark-UI recently was made public, it is built using zagjs and is meant to be a framework-agnostic Radix-UI alternative

[samuelstroschein]

Thanks for the ping! we heard about ark from the chakra team directly. it is early but I wouldn't be surprised if we end up using it