Clojurians Log v2

As a clojure / react noob I think the readme looks pretty solid. Reading the blurb at the top makes me think that a webapp dev wouldn’t have to be concerned about local/remote data storage - that once configured, hyperfiddle would manage that for me and I just ask for what I need. Is that about right ?

@ivar That's correct! Thank you for the feedback

I think that’s such a powerful feature that it’s a bit tough to wrap one’s head around. Maybe have a ELI5 / tldr at the top without the specific tech and a high level overview of the pros & cons of hyperfiddle.

@ivar if we listed the concerns that Hyperfiddle considers essential complexity vs accidental or optional, would that help?

(Keep in mind my feedback is from someone who’s just approaching clojure, so I bring “beginner’s mind” - which might not be your target audience)

I’d say that a fair assessment of the effort / complexity for initial configuration would suffice

but also, I imagine the app developer loses control over network traffic / latency management..

which might not be a big deal?

ie: would hyperfiddle be reasonable for a chat service ? what are example apps (real or imagined) that would a) benefit from and b) be a bad fit for hyperfiddle?

@ivar your questions are insightful. The short answer is the I/O runtime is about 1000 line "kernel" and can be replaced, so if you want realtime push over websockets, you can drop down to that level and code it like usual. The I/O runtime implementations are general purpose and could be shared or plugged into any other hyperfiddle app

The point is that userland is sheltered from all that

also, afaict it seems that reframe is making strong headway in terms of being the ‘go to’ SPA framework. Your readme’s section on interaction with reframe (https://github.com/hyperfiddle/hyperfiddle#faq-and-anti-features) is a bit confusing. On the one hand you write that Reframe’s use of local state doesn’t jive with hyperfiddle (non-idiomatic) but then the last sentence in the paragraph states “you should have no trouble using Reframe”.

cool. so the plan (or existing state) is to support different swappable IO implementations?

Yes, we have a couple, different apps have different I/O needs. A simple example is you can serve the app completely without javascript and rely only on server side rendering, http://hyperfiddle-consulting.com works like that

BTW it turns out that disabling javascript is actually slower, Hyperfiddle is similar to https://www.gatsbyjs.org/ and is faster with javascript once the entire app data dependencies are in browser cache

Anyway its up to the I/O runtime to make those decisions, the default one is very good, most apps dont need to think about this