Clojurians Log v2

To me, this is the most helpful format for a technical talk I've ever seen, Dustin. In the same format, I remember very fondly your first similar talk to announce how Electric 3 differed from Electric 2. I seem to recall, also, that your HYTRADBOI short talk was in a similar vein, although more static (probably more slide-ish), and almost as good. I suppose this one had been much more taxing to prepare? (Which kind do you like the most preparing? There is value to assign to this factor - bring your own voice and your own color, and meet us where we are!) I don't like a lot to learn from videos, but I think I could watch dozens of hours of tutorial content like this. You're a real expert, and yeah, I think that's the key: you're making tutorials to raise our thinking to the level of this new tech, and to help us see how it helps us and imagine what kind of success we could have with it. And you're honest that's it's far from being fully explored, and it's helpful from you. In this last talk (the one I watched live on Zoom), there did seem to miss some bits in the intro, and especially a conclusion. I left with the impression that you're still not sure if the impact of differential dataflow is sufficiently explored by your current material (or nailed by yourselves, maybe?) Your first v3 talk was much better with intro and conclusion (albeit its objectives were quite different), and I think it's very important in your case. In any case, great format for my taste. I wish you the best.

My impression was similar to @reut.sharabani . I found the talk fascinating and I enjoyed understanding more about how Electric works. At the same time, I wonder whether for an audience new to electric it might be effective to spend a few min at the start establishing the motivation, then wow them with some magic (eg robotics digital twin, virtual scroll), and only then show some of the details of how the magic trick is performed. Loved these lines from the tutorial and thought they could make a good talk opening to establishing motivation: We designed Electric to make possible next-gen product experiences that are otherwise beyond the frontier of what can be expressed in any other technology. Electric's mission is to raise the abstraction ceiling in web development. Imagine a world where any data structure, no matter what it was—database, cloud, file, microservice—was at your fingertips, as available as if it was process-local to your code. That is of course impossible, for many reasons: latency, data security, device memory constraints. Electric is the next best thing. From there you could go to demo a next-gen experience (robotics, virtual scroll). Now you've got the audience hooked and curious and you can dive into details (two clocks etc).

The reason we haven't gone into full sales/growth mode is that, a talk like that, would cause a tidal wave of tourists/newbies all trying electric, and electric is still too rough, they will all fail and all bounce, and the failures will ruin our brand for 2 years. I am terrified of this

Part of why React.js was adopted so rapidly is that Facebook had dogfooded it for years, it was released as a mature and bug-free framework with established idioms for all the common patterns (e.g. forms)

And, many of the issues a tourist will hit during the Electric activation sequence is Clojure-layer friction that is not in our financial reach to get fixed. Clojure's activation rate is like .1%, i.e., 99.9% of Clojure tourists hit a wall on the first try and bounce. ClojureScript is even worse (assuming the prospective user is coming in cold w/o Clojure knowledge)

I'm sure you have thought of this and have reasonable arguments that I have not seen, but how about electric only taking care of the state sync between client and server? I suppose that's already the case, you just don't need to use dom stuff. Maybe then it's a matter of focus. I hear stories about how spreadsheets never took off until, instead of being sold as a generic calculator, it was marketed as some tool to do X. Anyway, I have yet to read the whole doc you're asking to review, and with what I read so far I admire and support the courage to explain all this despite the opinion of your investors. I think it's the right choice.

Yes we have seen people using Electric as a sync solution and delegating rendering to their existing framework. I think this is a common way to get started with Electric, people start with bespoke sync layers w/ hand optimized client side caching (which take them 2 years and 20,000k LOC to develop), but then realize that there are too many bugs and it's never going to work, and then they delete it and substitute in Electric, and the bugs are gone, the 20k LOC are gone, and it is 10x faster. And then Electric spreads from there

I'd say that's a winning use case that clearly demonstrate value to the dev without them needing to understand what's happening in the background.

Re the tourists issue I’m thinking about this part of the reference: What benefit we want from you: • Brand building, marketing, you will talk excitedly about Electric as you build your projects and help us grow our audience especially in these early days. Does this mean that at this point in time you want to grow your audience within the world of experienced clojure devs, but not outside of that? If I were to write blog posts about “how to do x in electric”, targeted to clojure audience (who are already familiar with agent etc) does that help or hurt your cause?

Thanks for pointing out that tension. Blog posts for Clojure audience help. We do want to raise brand awareness. But we don't want to, like, declare "Electric leaves private beta, the silver bullet you've been waiting for is here, come and get it". It's a story of tradeoffs.

If you're specifically interested in contributing howtos, we can potentially just add them to the docs, now that we have a high velocity docs content authoring workflow in place (the google doc)

Since you're asking for feedback, here's mine. It's a good talk, it has given me a clearer mental model for what electric is, especially with how you draw over the code. I have however watched/read other materials on hyperfiddle, electric, missionary, so it's not like I was totally unprepared. Also I have been familiar with the differential dataflow concept since the Naiad time. Finally I am familiar with how clojure as a language can build other languages via macros. For those that are completely new to all or most of these subjects, like scalalanders, I can imagine how your talk may have flown above their head, Most are used to having a direct control of the logic on a single machine where data and logic reside in memory. Here such colocation goes away, and there are a few layers of abstraction between what the code says, and what eventually gets executed, meaning there are several levels of control/abstractions/indirections. As a result they have to consciously hold off the strong pathways of their mental model pushing them to read your code as if it's controlling execution directly and in-place. And let's not talk about static typing vs dynamic! As the talk is fast paced and dense, they have little time to adjust. So for them I imagine less density and more basic (un)learning would have made it easier to digest. That being said, the motivated in the audience audience will go back and rewatch the talk, and it may help to give them some prerequisite materials.

For me it remains the clearest explaination of what electric does (I have not watched every article/talk on electric though)

@jtlocsei the intended audience was the broader functional programming community (non-Clojure) – strong programmers not beginners, 10+ yoe. I did consider giving code snippets in JavaScript but it tested poorly, feedback was it's easier to learn Clojure on the fly than it is to twist JavaScript into a foreign evaluation model. As long as the snippets are short and I use my magic marker to walk them through it.

This is amazing, but if you're aiming for reach you have to use simpler terms and sacrifice correctness. You explain it with much clarity and I've even built a pretty significant tool with electric but I still don't understand (and honestly don't care about) all the bolts and screws. I care about what I can do with it and how it compares to other options. Not how it does things.

we are not ready to increase reach (i.e. work on growth) yet

but your point is noted

Looking forward to watching. What was your goal for the talk, in terms of the kind of person you wanted to reach and what you wanted them to come away with?