4 ms·

The primary concern is performance. The editor is anticipated to become a VSCode for content (documents, video, audio, etc.). The state issues we have right no

The primary concern is performance. The editor is anticipated to become a VSCode for content (documents, video, audio, etc.). The state issues we have right now are non-issues with SolidJS. They don't trigger re-renders and thereby don't degrade the user experience. RE Vue JS: The nice thing about Solid is that state is de-coupled from rendering. I thought that building complex state with Solid will be easier than frameworks that couple state to rendering. I haven't evaluated VueJS in depth though. Here is an RFC I wrote about choosing Solid https://github.com/inlang/inlang/blob/main/rfcs/tech-stack/RFC.md#design-system-ui-library https://github.com/inlang/inlang/blob/main/rfcs/tech-stack/R...

rk06 4y ago
> The state issues we have right now are non-issues with SolidJS. They don't trigger re-renders and thereby don't degrade the user experience. This is because of fine grained reactivity which is same for solid, vue and svelte. >The nice thing about Solid is that state is de-coupled from rendering. Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components? First part is unique to solid. But vue and solid both share the second part. Vue's composition API can be used outside of vue. Alpine.js uses vue's reactivity internally I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't, even though Vue is more mature, more popular, and more performant in js framework benchmarks. That being said, it is not that important.I believe even if you did consider Vue, you would have still gone ahead with solid. Because Solid is more performant focused, and to make best of Vue performance, you would need to switch from jsx to template
- samuelstros 4y ago
  >> The nice thing about Solid is that state is de-coupled from rendering. > Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components? My mental model of Solid's reactivity is "plain JS". Components are also "plain JS" with a bit of syntactic sugar that auto injects one effect on render. No hook rules etc. That should make reasoning about Solid apps easier (in theory) and we might use the reactivity system outside of UI. In particular, we need to develop a filesystem implementation for the browser that could benefit from Solid's reactivity system. > I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't I started my web dev journey with Svelte (coming from Python + Flutter). The first prototypes were built in Svelte. It became clear that Svelte might be too restrictive for a complex SPA. Solid felt/feels like a baby of Svelte + React.

rk06 4y ago

> The state issues we have right now are non-issues with SolidJS. They don't trigger re-renders and thereby don't degrade the user experience. This is because of fine grained reactivity which is same for solid, vue and svelte. >The nice thing about Solid is that state is de-coupled from rendering. Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components? First part is unique to solid. But vue and solid both share the second part. Vue's composition API can be used outside of vue. Alpine.js uses vue's reactivity internally I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't, even though Vue is more mature, more popular, and more performant in js framework benchmarks. That being said, it is not that important.I believe even if you did consider Vue, you would have still gone ahead with solid. Because Solid is more performant focused, and to make best of Vue performance, you would need to switch from jsx to template

samuelstros 4y ago
>> The nice thing about Solid is that state is de-coupled from rendering. > Are you referring to the part that solid components "disappear" at runtime? Or that solid signals can be used outside of components? My mental model of Solid's reactivity is "plain JS". Components are also "plain JS" with a bit of syntactic sugar that auto injects one effect on render. No hook rules etc. That should make reasoning about Solid apps easier (in theory) and we might use the reactivity system outside of UI. In particular, we need to develop a filesystem implementation for the browser that could benefit from Solid's reactivity system. > I looked at that RFC and i found it interesting that Svelte was considered, but Vue wasn't I started my web dev journey with Svelte (coming from Python + Flutter). The first prototypes were built in Svelte. It became clear that Svelte might be too restrictive for a complex SPA. Solid felt/feels like a baby of Svelte + React.