mobx-jsx VS bagel

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.

Sure, you can use JSX without a framework! Be it MobX JSX, dom-chef or jsx-dom, it should feel right at home.

mobx-jsx is using MobX as the reactivity system together with Solid's DOM renderer.

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/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'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 (50k LOC), how big of a task would you say it is to move to something like Solid?

This is a very similar philosophy to the MobX library (normally paired with React), and also to the programming language I'm building: https://github.com/brundonsmith/bagel

I’m really strongly rooting for Deno. I’m even implementing my current passion-project on it (https://github.com/brundonsmith/bagel). But I have a couple of significant (but solvable!) criticisms, if anybody on the team is here.

1) The documentation for the standard APIs is extremely wanting. The main, and weirdest, problem is that it seems almost impossible for search engines to index (or at least DDG). I can search for very very specific things, and still get kicked to the home page and have to manually navigate to the part I’m looking for (and the navigation is also pretty difficult; I often can’t find the thing at all and have to rely completely on editor hover-overs for documentation). It can also be confusing- some things like certain standard APIs appear to have multiple conflicting reference-manuals? And it can be hard to know which one is current or correct. Even getting past all the obfuscation, the docs are just ok. They often leave out deeper details (this last part is less of a problem and more understandable, this being a young project).

2) The VSCode extension still needs work. It’s usable, and better than nothing, and it’s better than it used to be, but (ordered from most to least significant):

- When I open certain files - usually bundles or something; maybe files outside of the project directory? - the language server crashes over and over and over, each time popping the terminal back up to show the output and distracting from what I’m trying to look at. This doesn’t happen with my normal, in-project, Deno files at least.

- It doesn’t have auto-import as you’re typing; you can auto-import by clicking the lightbulb, so I assume it’s a relatively short hop to plug that in

- It chokes on absolute import-paths in Windows. Thinks they’re malformed remote URLs

- It has caching issues sometimes. I’ll change some type in one file and other files won’t get the updated type until I close and re-open them, or sometimes the whole editor. This is uncommon so it’s not a huge deal.

I list these criticisms because I want to see Deno succeed. Switching from using TypeScript on Node (with the build steps/configuration, ad-hoc testing and linting, and Node’s pathological legacy APIs) to Deno was a huge quality of life improvement, even with all these problems. Brought to its full potential, I think Deno could be a revolution.