4 ms·

On the surface it looks really cool, but I'm deeply skeptical because they've intentionally put off handling what I think is the hardest part making the idea pr

On the surface it looks really cool, but I'm deeply skeptical because they've intentionally put off handling what I think is the hardest part making the idea production ready: handling network unreliability. from the talk: > Photon is at least as reliable as today-era web applications, there are lots of well-understood ways to approach reconnecting local-first etc. We have not done this work yet I think this really understates the truly immense amount of engineering work that goes into making modern web system software appear reliable to users. Maybe Photon has a good solution but if my years in engineering have taught me anything it's that every line of code written and design decision made before tackling the hardest part of a problem need to be redone, so you should start with the hardest part first. I am hopeful that I'm proved wrong though :)

dustingetz 4y ago
(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?

dustingetz 4y ago

(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?