7 ms·

(Speaker here) We appreciate your concern, the risk is real, and you're right – the hard parts cannot be put off. And we have not put them off. We've already th

(Speaker here) We appreciate your concern, the risk is real, and you're right – the hard parts cannot be put off. And we have not put them off. We've already thought through how to implement recovery, resync, long running sessions. We have several wiki pages worth of notes answering questions like how we will deal with network partitions, reconciliation, durable session state, dealing with OS sleep timer state, OTA code updates, etc. What we have not yet done is the implementation work, because our pilot use case driving our eng priorities – an internal support app for a Series B SAAS startup – does not actually have this theoretical problem you describe. Photon's protocol today is tolerant to arbitrary delays, IFF you can guarantee message delivery and ordering, which is the problem TCP solves. We do already have pending/loading states, which are trapped locally through reactive try/catch. BTW, the Photon codebase is only 2k LOC (analyzer, compiler & interpreter for JVM and JS targets, standard library) and a substantial part of that is redoing parts of the Clojure/Script analyzer infrastructure. "truly immense amount of engineering work that goes into making modern web system software appear reliable to users" That's a bit much for me. The current industry state of commercial SAAS/crud apps is a dumpster fire, Photon's speed and responsiveness is already miles ahead of literally every laggy SAAS tool we all suffer where programmers have manually hand-coded the network in the form of REST calls, manually split HTTP routes, backends-for-frontends, client side ORM, GraphQL resolvers, etc. How often do you Cmd-R your gmail or notion because it stopped working? React.js-era software is rotting to death, "reliable" is not a word that remotely describes my daily experience with web software today.

jungturk 4y ago
> our pilot use case driving our eng priorities – an internal support app for a Series B SAAS startup While your passion for the project and excitement at its prospects are clear (and I've very much enjoyed following along), this comment makes it sound you've opened a yak barbershop inside this poor support department.
- jameshart 4y ago
  Wanted a vanilla zendesk implementation; got a new UI development paradigm.
- arinlen 4y ago
  > While your passion for the project and excitement at its prospects are clear (and I've very much enjoyed following along), this comment makes it sound you've opened a yak barbershop inside this poor support department. Perhaps something useful comes out of it. If I recall correctly, CMake (the de-facto standard build system for C++ applications) originated as a yak shaving subproject of a medical visualization application.
- dustingetz 4y ago
  they are excited by our “lowcode for CRUD apps” RAD tool whose next-gen I/O requirements are the reason we made Photon- “minimum level of ambition that is useful” - see http://www.hyperfiddle.net http://www.hyperfiddle.net
  - jungturk 4y ago
    I'm happy to hear you're in a battlefield environment that's supportive of the additional opportunity, and I'm excited to see what pops out next.
- mananaysiempre 4y ago
  I hear the Facebook people once tried to make the unread notification counter stop getting stuck, and React came out :) In all seriousness, though, if people are constantly trying to shave the same place on the yak (like web frontend state) ... Maybe there’s just a concentration of unsolved suckage there?
  - kennytilton 4y ago
    Worse, I am pretty sure. That counter is what spawned the Flux architecture. Because React had no solution, mind you.
EGreg 4y ago
What is your Series B startup? How does it use what you are building here? And how did you get it funded? :)
sokoloff 4y ago
> Photon's protocol today is tolerant to arbitrary delays, IFF you can guarantee message delivery and ordering, which is the problem TCP solves. TCP solves that only within the context of a single TCP connection (which I’m sure you know). That doesn’t seem to handle even common moving laptop use cases, let alone actual mobile users.
Hermitian909 4y ago
> That's a bit much for me. The current industry state of commercial SAAS/crud apps is a dumpster fire, Photon's speed and responsiveness is already miles ahead of literally every laggy SAAS tool we all suffer where programmers have manually hand-coded the network in the form of REST calls This is a fair criticism! I am biased because my work history has placed me in companies that really care about maintaining this illusion. > React.js-era software is rotting to death, "reliable" is not a word that remotely describes my daily experience with web software today. I will say, that some of this is the result of how hard the problem we're talking about is. While React could definitely improve the affordances for this logic, having worked with a few systems that try to maintain the illusion of a reliable network I've found inherent tensions balancing speed, performance, cost, and time the UI spends in an inconsistent state. It's a Hard Problem™. Regardless, I'm wishing you the best of luck. I'm heartened to hear what you have is 2k lines, it will make a re-write much less painful if it's needed :)
- kennytilton 4y ago
  "I'm heartened to hear what you have is 2k lines, it will make a re-write much less painful if it's needed :)" My takeaway was that they successfully identified the small essence of the problem ("It's DAG, stupid!") and wrote a relatively few but intelligent lines of code to solve it. And they have gotten pretty far with the implementation. God does not require rewrites of such.

jungturk 4y ago

> our pilot use case driving our eng priorities – an internal support app for a Series B SAAS startup While your passion for the project and excitement at its prospects are clear (and I've very much enjoyed following along), this comment makes it sound you've opened a yak barbershop inside this poor support department.

jameshart 4y ago
Wanted a vanilla zendesk implementation; got a new UI development paradigm.
arinlen 4y ago
> While your passion for the project and excitement at its prospects are clear (and I've very much enjoyed following along), this comment makes it sound you've opened a yak barbershop inside this poor support department. Perhaps something useful comes out of it. If I recall correctly, CMake (the de-facto standard build system for C++ applications) originated as a yak shaving subproject of a medical visualization application.
dustingetz 4y ago
they are excited by our “lowcode for CRUD apps” RAD tool whose next-gen I/O requirements are the reason we made Photon- “minimum level of ambition that is useful” - see http://www.hyperfiddle.net http://www.hyperfiddle.net
- jungturk 4y ago
  I'm happy to hear you're in a battlefield environment that's supportive of the additional opportunity, and I'm excited to see what pops out next.
mananaysiempre 4y ago
I hear the Facebook people once tried to make the unread notification counter stop getting stuck, and React came out :) In all seriousness, though, if people are constantly trying to shave the same place on the yak (like web frontend state) ... Maybe there’s just a concentration of unsolved suckage there?
- kennytilton 4y ago
  Worse, I am pretty sure. That counter is what spawned the Flux architecture. Because React had no solution, mind you.

EGreg 4y ago

What is your Series B startup? How does it use what you are building here? And how did you get it funded? :)

sokoloff 4y ago

> Photon's protocol today is tolerant to arbitrary delays, IFF you can guarantee message delivery and ordering, which is the problem TCP solves. TCP solves that only within the context of a single TCP connection (which I’m sure you know). That doesn’t seem to handle even common moving laptop use cases, let alone actual mobile users.

Hermitian909 4y ago

> That's a bit much for me. The current industry state of commercial SAAS/crud apps is a dumpster fire, Photon's speed and responsiveness is already miles ahead of literally every laggy SAAS tool we all suffer where programmers have manually hand-coded the network in the form of REST calls This is a fair criticism! I am biased because my work history has placed me in companies that really care about maintaining this illusion. > React.js-era software is rotting to death, "reliable" is not a word that remotely describes my daily experience with web software today. I will say, that some of this is the result of how hard the problem we're talking about is. While React could definitely improve the affordances for this logic, having worked with a few systems that try to maintain the illusion of a reliable network I've found inherent tensions balancing speed, performance, cost, and time the UI spends in an inconsistent state. It's a Hard Problem™. Regardless, I'm wishing you the best of luck. I'm heartened to hear what you have is 2k lines, it will make a re-write much less painful if it's needed :)

kennytilton 4y ago
"I'm heartened to hear what you have is 2k lines, it will make a re-write much less painful if it's needed :)" My takeaway was that they successfully identified the small essence of the problem ("It's DAG, stupid!") and wrote a relatively few but intelligent lines of code to solve it. And they have gotten pretty far with the implementation. God does not require rewrites of such.