If you are interested in this, they are presenting at an upcoming indi-conference: "Have You Tried Rubbing A Database On it".

https://www.hytradboi.com/

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

Yeah, MobX is a great tool for fine-grained reactivity + managing state outside UI tree. I haven't seen anyone try relational querying in MobX, would be curious if that's a thing.

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.

That is an interesting question. Theoretically it should work - it's all just data - assuming you could implement relational querying efficiently in JavaScript itself

An event driven, local-first, UI that automatically reacts to changes in the underlying database is a pretty old idea.

https://docs.microsoft.com/en-us/dotnet/api/system.data.data... https://doc.qt.io/qt-5/qsqltablemodel.html

Am I missing something novel in the article? I really feel like I'm missing something.

I agree with your assessment, and it's just the younger generation catching up to older established wisdom.

The tragic irony is how hard many of that generation badmouthed the old ways of doing things. For instance ADO.NET with datatables/dataviews was often looked down upon, but through working more with people who did so it turned out that they just didn't understand it, so often that it's basically ten times out of ten.

How is DataTable an example of that? It’’s a class that’s usually used to hold the contents of a relational database table, nothing to do with UI.

Because you usually link it to a DataView and then the DataView updates when the underlying data changes. Same for QSqlTable, it links up with a QTableView.

This is really interesting - at a high level it reminds me of some of the approaches taken in Facebook's messenger app: https://engineering.fb.com/2020/03/02/data-infrastructure/me...

The relevant content is touched on briefly in the "Use SQLite" section.

I'd be curious to learn more about the differences in the two approaches.

From what I can tell, it sounds sort of like a simplified spreadsheet as a code library.

So … would this pair even better with Svelte, so we become even more reactive through the whole stack?

Yeah, Svelte or Solid is probably a more natural fit than React. But at the end of the essay we propose a weirder alternative, which is to implement the UI templating itself as just part of a DB query.

I've always had a soft spot in my heart for PHP style "raw query in the template". Even as we've moved away from that I feel like GraphQL recapitulates a lot of the reasons why having queries tightly bound to views is convenient.

It feels like "put the template in the query" is a great Uno reverse to "put the query in the template" and the associated issues it brings, but I'll have to think on the consequences more. Thought provoking article!

How is this different than Apollo GraphQL with an SQL backend?

anyone how what tool we can use to make those chart? It looks friendly.

This art style screams Paper by FiftyThree

Yep, we drew them with Paper. Great app.