ryansolid

mobx-jsx

TypeScript2019–2024

ryansolid / mobx-jsx

mobx-jsx

Raw MobX performance without being restrained by a Virtual DOM

Explore on GitHub Read Hacker News discussions

4Distinct people

7Mentions

0Explicit recommenders

267GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Raw MobX performance without being restrained by a Virtual DOM

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year7 dated mentions

Observed mentions: 2019-06-20 22:38:53 UTC to 2024-05-06 09:51:28 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	3	3
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	1	1

What Hacker News says

7 sources

mst·May 6, 2024

Tangentially, Solid is fascinating - especially the dom-expressions backend meaning you can basically bolt compilation behaviour into anything that supports that. I have https://github.com/ryansolid/mobx-jsx/?tab=readme-ov-file#mo... on my list to try since I -really- like mobx for stage management (especially mobx-keystone) and am fascinated by how clean the results can be. Though for 'real' code I still tend to default to react + mobx-keystone because for all my gripes with react it's a pretty solid Schelling Point.

In A mostly complete guide to React rendering behavior (2020)

Ciantic·Mar 8, 2023

> When using React I usually just use MobX and everything just works. 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

Read the rest

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.

In React is holding me hostage

aidos·Mar 2, 2022

I've just skimmed the article but I'm definitely going to give it a proper read. 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/mob

Read the rest

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

In Building data-centric apps with a reactive relational database

aidos·Nov 30, 2021

I've been keeping an eye on your work for a long time now. We're a mobx shop so I was hoping to see you explore the ideas you had around that a little more (https://github.com/ryansolid/mobx-jsx). 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?

In 4x Smaller, 50x Faster

pier25·Dec 20, 2019

MobX is great. It's even better when you remove the virtual dom and rely only in its internal dependency tracking: https://github.com/ryansolid/mobx-jsx

In State of JavaScript 2019

pier25·Oct 28, 2019

I've used it in a small project. It has so many great things but I don't love some of the dev ergonomics. 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 stor

Read the rest

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

In Ask HN: What are your experiences with Svelte (JS framework)

pier25·Jun 20, 2019

I used to be a huge Vue proponent for about 3 years and stopped using it at the end of 2018. 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

Read the rest

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) [1] https://github.com/ryansolid/mobx-jsx

In Vue RFC: Expose logic-related component options via function-based APIs instead