José Valim nails it: Remix's concurrent submissions have a fundamental flaw. Without causal ordering, you're stuck with race conditions and stale data, leading to poor UX. They need to rethink their approach or embrace causal ordering to fix this.
Regarding causal ordering, it's worth remembering that a convenient way of implementing way is with Lamport clocks, since there is only a single variable to keep track of – the single monotonic clock that comes from the combination of all the parties involved.
By the way, Martin Kleppmann's Designing Data-Intensive Applications book has a very good explanation of this subject.
Wikipedia say, "Remix is an open source full stack web framework. The software is designed for web applications built with front-end JavaScript frameworks like React and Vue.js. . . . Remix has been presented as an alternative to the popular React framework Next.js."
You can check the ChatGPT frontend source code that they do not use Remix's actions (submission and revalidate mechanism). And the fe does only one request to receive the data for chat. The mechanism has benefits like working without javascript and issues but you can avoid it if you dislike it. Did the author has checked it's own theories about why ChatGpt may be slow before making such arguments?
chatgpt .com does not work at all without JavaScript enabled.
For me, there are 11 network requests from sending 1 chat message. 2 appear to be related to the convo, /memories and /conversation.
For an example of what he is talking about, you can try deleting a chat from your chat history. It performs a PATCH to remove the single chat, then a GET with the full list of chats. Doing this multiple times can lead to the problems he’s outlining.
With wrangling, it’s probably also unnecessary in any given JS framework, but you have to be very intentional about it. With Phoenix LiveView minimal, efficient, and correct updates are included using the recommended patterns.
as i mentioned the source code does not contain Remix actions (ofc <form> will not work without js in this case), so the reason why it makes two request on chat delete could be intentional or this is how they designed their api. Also the mentioned issues with actions by author are valid the only nitpick i have are the statements against chatgpt website and the fact that you can avoid actions if you dislike them.
Most probably /backend-api/ that chatgpt's fe is calling is the go or java backend and has nothing with Remix.
It seems like you are using “actions” as a term of art specific to Remix that maybe the author is not using? ChatGPT definitely has Remix in its current source code. His point is how client-server state can be out of sync unless handled properly.
