Hacker News Reader

Comment by fizx | Hacker News Reader

> There is a (literal) speed of light limitation with this approach: your server can only be so close to your users.

The next step is to compile your server to WebAssembly and ship it to your clients. You can then use it to optimistically render responses while waiting for the real server to return.

Sounds a little crazy, but we've actually pulled it off for a project, and its magic.

View on HN

What about persistence? To me that’s the main purpose of the backend and running a server on the client doesn’t fix that. You still have the network latency of persistence, which is the ultimate server state that should win.

It sounds over-engineered. Lots of over-engineered stuff gets pulled off for no good reason.

There is a good reason: it becomes much easier to think about state transitions, because optimistic and “verified” updates both follow the same code path.

I've built a turn-based game that worked this way, where essentially every player and the server contains a copy of the same state machine, and the server determines the order of state updates. Like OP said, once you have the framework in place, it's magic.

It's over-engineered unless done properly, it which case it becomes a detail. I wouldn't be surprised to see some automatic conversion of server-side code to front-end by LiveView in the future for events where this behaviour is applicable, actually!

Well, in this case, most online multiplayer video games wouldn't work without it!

Why wouldn't you just use a Service Worker for this?

There's a couple different ways to skin this cat, but WebAssembly is definitely the "coolest". I'd imagine even a Service Worker is overkill compared to just inlining an optimistic response in whatever rest client you're using.

Kind of similar to the content of this article, I wish people were more upfront with their reasoning. Doing something because "it's rad" is definitely fine by me!

> WebAssembly is definitely the "coolest"

As always: when I doubt, it was likely because of CV-driven development

I just mutate the data object when using SvelteKit. Blasphemy, I know. But it works, and it works well. :P

Wow, that sounds cool! Can you share any more details?

That sounds a lot like the "client side prediction" that modern multiplayer games do.

local-first with a client-side sqlite db sounds way simpler for what seems like the same purpose

Wait, what's the difference to a fat client then?

Ease of distribution.

Reply on news.ycombinator.com