This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-08
Channels
- # announcements (4)
- # aws (1)
- # babashka (4)
- # beginners (75)
- # biff (4)
- # calva (13)
- # clojure (76)
- # clojure-android (1)
- # clojure-austin (9)
- # clojure-europe (14)
- # clojure-mexico (3)
- # clojure-nl (2)
- # clojure-norway (11)
- # clojure-uk (14)
- # clojurescript (19)
- # conjure (14)
- # cursive (30)
- # datomic (13)
- # gratitude (6)
- # hyperfiddle (71)
- # introduce-yourself (2)
- # juxt (5)
- # malli (5)
- # nbb (5)
- # nrepl (10)
- # off-topic (32)
- # re-frame (3)
- # releases (1)
- # shadow-cljs (5)
- # sql (38)
- # tools-deps (24)
- # xtdb (19)
I had this thought during the weekend, are p/server
and p/client
the only 2 parties we'll always care about? What if we have 2 backend services we want to communicate with? Or could 2 clj services use photon to abstract away the communication layer? If photon allowed e.g. comms through a TCP socket directly we could set that up between Service A and Service B and potentially deploy them from the same codebase? Someone can also have 2 web UIs etc.
yes, scales to N tier topologies, for example client-edge-gateway-server-database or larger cloud systems
by scales you mean "could scale in the future", right?
I mean our compiler today is hardcoded for client/server topology with p/server p/client markers, but it's just syntax. Our implementation can easily support N peers with a small amount of changes
(p/browser-webworker) is an interesting use case also – to offload work from the browser UI thread to a background job
The regression in demo-webview (where the reactive entity does not update in response to a transaction) is actually a Datascript issue (broken equality semantics on Entity instances) per https://github.com/tonsky/datascript/issues/433 ; the regression was introduced by a major improvement to missionary's continuous flows semantics (driven by Photon's "duplicate propagation" bug)
nice find! hopefully that can be fixed quick
databricks released an infra project called “Photon” so we may need to rebrand. any ideas as to the name? like “LiveView” it should be indicative of our magic in some way
“Tiered Clojure”
“Reactive Clojure”
I think photon is a bad name in general, too generic and nondescriptive. Probably 100 published projects with that name. Something cool like "hyperflow" would be better
ok, keep dropping ideas
we considered “Zero” (for zero boilerplate)
but I think "zero" is in the right direction in terms of suggesting what problem it solves as opposed to how it works
Haven't seen the code yet, but it brings to mind crossing of barriers, and my mind went to... Charon (ferryman over the river Styx) or Flux (rate of flow through a cross-sectional area or boundary)
we considered arroyo, a dry creek that floods with water seasonally
> I personally don't like names that are completely ungooglable Yeah, from a branding fundamentals perspective, it's advantageous to pick something short but also not overloaded, with many stakeholders competing for that term on search. You also love for it to be descriptive. ..naming things is hard.
fusion synthesis compose
“hyperfiddle + X” gives leeway with googling, the name can also be stylized like hf/zero
Never mind, the distance is too short and the search engine thinks you mean xkcd
what is xkce?
brainstorming I got these rio (Reactive IO) join chimera planner binder frame plain bare simplex force chronicle bridge
Back end, front end, bah! So... "Endless"? It will make them click thru, anyway. :) "Reactive Clojure" suffers from the word "react" having been (a) beaten to death and (b) misused by FaceBook. Also, is reactivity the magic? It underpins the magic, but the magic I understood is in hiding the communication between back and front end... "Seamless"? https://www.synonym.com/synonyms/seamless offers:
adjective. ['ˈsiːmləs'] perfectly consistent and coherent.
Hellasweet. As a product name it takes quite a bold stand while again forcing a click-thru to find out WTH I am talking about. 🙂
Did not see any good synonyms, but maybe "smooth". That would be fun.
Final thought: such naming conflicts are unavoidable, and is Databricks that dominant when it comes to mindshare?Maybe along the lines of streams and flows? Could pull up a list of river names
balance neo nanos (as in there is no framework, just small integrations, nanos)
Uniview TrueView
Things that start with h and end with f: hf/hoof (the thing all your weight goes on but which gets you where you're going) hf/half (maybe not) hf/hoffman (just a Dustin Hoffman mascot)
I did like the zero
idea. "Coke Zero" worked well. Not sure what goes before it. Maybe nothing? Again, provocative. And then we talk about zero network hassles as well as zero consistency worries (the reactive bit). The real zero even has a history. It had to be invented, and was banned by the Venetians for a while.
• Interweave • Tapestry • Mangrove ◦ An eco-system connecting 2 worlds • Estuary
(Contributed by Will)
Reminds me of ClojureScript One that was ditched when CLJS jumped on React. This is better, we get back to the fundamentals, and one step more: Clojure Zero. 😄 Many great ideas in the thread!
interlace, braid - but not sure how to associate that to views. what are more words for "View" in the LiveView sense?
View is the part of the name that I didn't like - but you've got a better idea than me as to why that's a good idea.
it doesnt have to be in the name but LiveView is just so obvious
Some ideas I've had were e.g. Hyperfiddle Fabric, Hyperfiddle Engine, Hyperfiddle Foundation but I do like a lot Zero, Endless, Seamless, and some others.
Fabric was the original repo name!
Oh!! 🙂 Sorry I buried Dustin's latest question, repeating it for others: > interlace, braid - but not sure how to associate that to views. what are more words for "View" in the LiveView sense?
Shen lang has this concept of the Ring
hyperfabric
Circle Circular CircleView
Echo Asynchrony Polyreme Rivulet
"App Fabric", in connection with
Hyperfabric
This post of yours I'd retweet in a heartbeat but I didn't like just those three words: "is wrong and"!!
ty for the feedback
Hyperfabric sounds quite fine; hyperbase hypercore
hyperbasis
UI Fabric ui-fabric
(simple like LiveView)
I feel like client/server is just the beginning and "view" is not the core of the abstraction. So words like UI or View, while correct now, might sound weird in a future discussion. > A: X told me I can use LiveView for my clojure project where I need 2 of my services coordinating through a TCP channel. I have no web UI though, just 2 backend services, so I'm confused? > B: Yes you can use LiveView without a UI, you just connect the 2 services and get the wire protocol handled for free
isn't the selling point that we don't have care about the connection at all? No protocols to control, no RPC/coordination code to write. You are managing the network. The DOM is just the first use case of that
I felt the same and it's why I resisted all sorts of View or UI-based names; curious about the answer; is our intuition correct or wrong?
with that framing my mind goes to hyperfiddle/wire, since that's what you're abstracting away / taking care of; or hyperfiddle/fusion, since that's how it feels to the user, 2 or more things blending and becoming one
it might even be that the DOM stuff will move to a separate library later, <future-name>-dom
rather than photon-dom being split out of photon into a new name, perhaps the opposite- the distributed fabric is split out of the UI lib (which keeps its name)
perhaps we should split them now - we considered this in the past (attempted to enumerate all the key components in the September 2021 blog post); but it felt complex and also a bit unfocused
quantum enganglement, superposition - "a language for UI whose functions exist in a sort of quantum state where they are both on the frontend and backend simultaneously"
quantum lambda
qubit
complex numbers that have real parts and imaginary parts complex functions, complex lambda
EulerView
QView
coherence
Middlend