Clojurians Log v2

Oh, thanks for the kind offer! No, not at the moment. Just looking around.

My pleasure. Are you looking for a web solution or mobile? Looking for sth sitting atop React? I am not crazy about Dart at all, or even Flutter's heavy OO, but I like the universality across platforms. And I have to admit my bias against Flutter's hundreds of classes originates in leftover attachment to the sublime simplicity of HTML. That said, I imagine the links here are broken, too. 🙂 https://github.com/kennytilton/flutter-mx

Web. I came across this channel because I’ve been looking into Alpine.js as an alternative to React and was wondering if anyone on Clojurians was using it. I found a message from you in this channel about it.

Interesting. Reminds me of HTMX. https://htmx.org/. Are we looking at framework burnout, with these libs taking hold? This write-up is about the JS version of mxWeb, but conveys my thoughts on framework simplicity: https://tilton.medium.com/simplejx-aweb-un-framework-e9b59c12dcff The best part to me is that, like the HTML extender libs, the excellent MDN doc is the mxWeb doc, so that just leaves explaining the fun, reactive stuff.

I’ve read that many people combine Alpine.js with htmx, actually. They use the former for logic that doesn’t require a round-trip to the server and htmx for the logic that does.

> framework burnout Just exploring the landscape of alternatives. Will read your article!

"I’ve read that many people combine Alpine.js with htmx, actually." I am reminded of Greenspun's Tenth: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule#:~:text=Greenspun's%20tenth%20rule%20of%20programming,of%20half%20of%20Common%20Lisp. By the time we are done we will be right back at <insert massive framework name here>! Ah, here we go: https://alpinejs.dev/globals/alpine-store I have done UX for forty years, so I always check the state management solution, the key to dynamic and self-consistent views. And the answer is almost always some variation on Facebook's original state solution, the Flux architecture's global store. Flux was not a bad attempt at managing state, but I would have ditched it when I saw the boilerplate, and the downside of isolating state.

I think the idea is to not use it in situations where you’re building a SPA, and thus would need a global store.

My specific application is one where I need a handful of self-contained interactive components, for instance.

Most of the applications of Apline that I’ve encountered are small enough that they don’t use Alpine.store at all. They just define small bits of state in via x-data attributes and retrieve and manipulate it with the other x- attributes.

A bit part of the value proposition, as I see it, is that if you do things this way you don’t need a front-end build at all.

Yep. If the number of nodes in the state graph are manageable, apps are exponentially simpler. Cue Fred Brooks, from "No Silver Bullet"

Digital computers are themselves more complex than most things people build; they have
very large numbers of states. This makes conceiving, describing, and testing them hard.
Software systems have orders of magnitude more states than computers do. 

Regarding global stores, I don’t spend a ton of time on the front-end, but from a distance there’s always appeared to be a mild tension between global stores and reusable components.

I recall re-frame being a joy to use, but if I remember subscriptions and dispatches are a part of the component which makes reuse challenging.

Perhaps your article will go into this. simple_smile

No, I beat up on Flux over here :): https://github.com/kennytilton/matrix/wiki/introduction#in-place-state-management-flux-need-not-apply You have to click on "In depth: A deeper look at the problem with Flux" for the good stuff.

As I said, I can see the divide and conquer appeal of a separate store, but it immediately creates three new problems. I throw ideas away when I get to two new problems. 🙂

Oh, I misread your earlier comment!

Sorry.

I’ve been looking into Svelte as well.

Ah, yes, Svelte. I looket at before.

Updating some count value — and all the things that depend on it — should be as simple as this:

   count += 1;

Since we're a compiler, we can do that by instrumenting assignments behind the scenes:

   count += 1; $$invalidate('count', count);

So a little more like Reagent’s ratoms.

I actually did quite an exercise porting my AskHN Who's Hiring browser to Reagent: https://github.com/kennytilton/hiringagent, and by the time I was done had gotten beyond ratoms to cursors and maybe sth else. It went well, but it was to me still an artificial state solution, where every ratom/cursor was like a secondary store, only more granular. Matrix just takes properties we want to use anyway and let's us define them as functions of other properties we are using anyway, so there is no disconnect. And the granularity is much finer. For example, in mxWeb I can define the HTML style of a widget as a formula, or even define an individual style attribute as a formula. Not a huge performance win, but great for self-documentation.

Ah, no, I read too much into the simple Svelte example I found. Svelte uses the Flux model for anything other than local component state: https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/Svelte_stores Shocked to find any specific framework on MDN, but luckily they anticipated my shock 🙂 : https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks#which_frameworks_did_we_choose Looking even at Svelte's own simple tutorial example we see explicit subscribe and unsubscribe. https://svelte.dev/tutorial/auto-subscriptions Are you familiar with the origina MobX, @zane? I usually cite that as closest to Matrix. https://github.com/mobxjs/mobx The funny thing being that someone came along and based MobX State Tree (MST) on MobX. It's a Flux. 🤦

I’m not, but I’ll read up on it!

Me, too! I just realized I do not know the MobX story for long distance state dependency. I am slowly discovering that that is the difference between MX and Flux.