What does HackerNews think of mobx-jsx?
Raw MobX performance without being restrained by a Virtual DOM
MobX is signals library. In other words, you are already using the signals way of doing things if you mostly manage your state with MobX. I still use MobX as well if I think I can't use SolidJS.
SolidJs if you haven't looked has MobX-like tools built in, computed, autoruns and all the same tools, it triggers "renders" when one of the signals changes. In reality it doesn't have renders, because it's not based on VDOM, but it makes it look like it does.
However I like to keep my signal library separate, I would wish SolidJS had separate signals library I could use elsewhere as well.
Also SolidJS is big library and framework by now, it comes with risks if Ryan Carniato were ever to loose interest.
Edit, I also found that Ryan has created an example of MobX and JSX without React, it's a good way to demonstrate that React is not as important with signals libraries: https://github.com/ryansolid/mobx-jsx since you know MobX that example probably makes sense.
We've built an architecture somewhat like this where we're using MobX objects in the frontend (a graph of the db objects effectively) that's patched by subscriptions to tables via hasura. So we effectively have all the data on hand locally all the time and use the reactivity on top of that.
We actually played around with sqlite in wasm because I really really miss having a real relational db in the frontend. We decided that there was just a few too many unknowns to proceed further with the idea. Initially we were using indexdb as a frontend cache but dropped that since without adding more layers to it it doesn't provide much value.
(Also played around with using Solid's direct mobx -> jsx library without having react inbetween https://github.com/ryansolid/mobx-jsx but, again, too much unproven tech to build on).
The work you're doing here is super exciting. The developer experience of what we currently have is pretty nice and I can definitely see your model working out well in the future.
I like and know where I'm at with React, but bringing a beginner through it recently definitely made me re-appreciate how nuanced it is. Also, you have to do a bit of voodoo to get good performance, and when you do the intention of the code vanishes pretty quickly.
For someone using React on top and mobx stores in the background (say 50k LOC all in), how big of a task would you say it is to move to something like Solid?
My first big problem is that you can't have more than one component per file, much like single file components in Vue. If you're working on a component that has many sub-components it becomes very tedious to switch around files. In Vue instead of creating new small components when using SFC I tended to complicate the template and logic of the current component... This made the workflow less tedious at first but I quickly learned is a terrible long-term approach. In more JS centric frameworks like React or Mithril I don't have this issue. It's ironic since Rich Harris preaches the "1 screen rule" and this completely breaks that.
The other issue I had with Svelte is the official reactive stores. The first weird thing is in Svelte a store is a reactive variable, not a bunch of reactive state like in other libs/frameworks. It quickly becomes tedious if you need to model semi complex data. Vue has the same problem in Vuex with its shallow (and dumb) objects. MobX IMO is so much better in terms of data modeling since you just define your models in any way you wish (pojos, classes, etc) and you just add decorators for the reactive properties/variables.
You can indeed add MobX to Svelte but then what's the point? It would be better to use Mobx-JSX which adds minimal overhead over MobX and is insanely fast.
https://github.com/ryansolid/mobx-jsx
Of course the problem with MobX is that while it has very nice dev ergonomics it's a very complex piece of machinery.
After fiddling with reactive state for about 4-5 years I've come to the conclusion the best approach is the one that Mithril and Imba follow: no reactivity. Your data is whatever you want and you don't need expensive tooling like MobX/Redux/Vuex to make it reactive. Whenever there is a user event everything is re-rendered automatically and the v-dom or memoized system take care of rendering the DOM parts that need to change. If the data is updated from an API response or some WebSocket the developer just calls a method to let know the renderer the data has changed. It might not be the ultimate fastest approach in terms of performance, but it makes development much more simple and it's fast enough for 99% of use cases.
I moved to Inferno + MobX because the cognitive overhead is practically nil. You can architecture your application and specially your state in any way you wish since your reactive data is made of objects, classes, or whatever you want to use.
MobX also makes your React/Inferno components much more enjoyable. No need to use setState() anymore since your component state is reactive much like Vue or Svelte do.
After using that for a while and coming back to an old Vue/Vuex project I realized how many conventions and ad-hoc abstractions it has which was quite oppressive.
A couple of weeks ago I discovered mobx-jsx[1] which is pretty interesting. It's a very thin rendering library that compiles JSX to imperative DOM instructions and relies on MobX for tracking state changes which makes the virtual dom irrelevant. It adds loops and conditionals which IMO are the biggest annoyances of using JSX. This is probably what I'll be moving on in future projects.
(Actually what converts JSX to DOM instructions is a babel plugin from the same author)