Remix's concurrent submissions are fundamentally flawed | Hacker News Reader

Remix's concurrent submissions are fundamentally flawed

dashbit.co

106 pointsbo0tzz14 comments

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

Is there a GitHub issue or discussion to subscribe for updates from the Remix team on this topic?

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.

The video he put out related to these concepts is super helpful to visualize the process: https://www.youtube.com/watch?v=fCdi7SEPrTs

There’s also funcaptcha (arkose labs) which definitely won’t let you use ChatGPT without JavaScript.

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.

Embracing the platform can hurt when the platform sucks

Which part of the problem described in the post, would you say, is caused by the platform?

All my API's have a "context" query string, if you use it to send a incrementing integer, you can ignore all late, out of order results

José seems to be far far far more enamored with ML than Elixir these days. Burnout and boredom happens, I get it, but it's still a bummer to see.

He's literally building a type system for Elixir. What the hell are you talking about?

Reply on news.ycombinator.com