Hacker News Reader

> 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.

> 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.

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

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.

Wanted a vanilla zendesk implementation; got a new UI development paradigm.

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?

Worse, I am pretty sure. That counter is what spawned the Flux architecture. Because React had no solution, mind you.

> 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 :)

"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.

> 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.

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