Live data from Hacker News

Linear sent me down a local-first rabbit hole

bytemash.net

181–190 of 228 posts

Re: Linear sent me down a local-first rabbit hole

#181

I'm all-in on SSR. The client shouldn't have any state other than the session token, current URL and DOM. Networks and servers will only get faster. Speed of light is constant, but we aren't even using its full capabilities right now. Hollow core fiber promises upward of 30% reduction in latency for everyone using the internet. There are RF-based solutions that provide some of this promise today. Even ignoring a wild…

This is called happy-path engineering, and it's really frustrating for people who don't live on the happy path.

Re: Linear sent me down a local-first rabbit hole

#182
post #69

Earlier quoted context omitted.

Me neither. Considered we are talking about collaborative network applications, you are loosing the single-source-of-thruth (the server database) with the local first approach. And it just adds so much more complexity. Also, as your app grows, you probably end up to implement the business logic twice. On the server and locally. I really do not get it.

You can use the same business logic code on both the client and server. With the Linear approach, the server remains the source of truth.

It’s difficult to ensure that it’s always the same logic when client and server software versions can get out of sync. You can try to force the client to reload whenever the server redeploys, but realistically you’ll probably end up dealing with cases where the client and server logic diverge.

Re: Linear sent me down a local-first rabbit hole

#183

I'm all-in on SSR. The client shouldn't have any state other than the session token, current URL and DOM. Networks and servers will only get faster. Speed of light is constant, but we aren't even using its full capabilities right now. Hollow core fiber promises upward of 30% reduction in latency for everyone using the internet. There are RF-based solutions that provide some of this promise today. Even ignoring a wild…

The use case for SSR now and in the future is on initial page load, especially on mobile.

After that, with competent engineering everything should be faster on the client, since it only needs state updates, not a complete re-render

If you don't have competent engineering, SSR isn't going to save you

Re: Linear sent me down a local-first rabbit hole

#184

Earlier quoted context omitted.

If you could simply drop in a library to any of your existing SSR apps that: - is 50kb (gzipped) - requires no further changes required from you (either now or in the future) - enables offline/low bandwidth use of your app with automatic state syncing and zero UX degradation would you do it? The problem I see with SSR evangelism is that it assumes that compromising that one use case (offline/low bandwidth use of the…

> - enables offline/low bandwidth use of your app with automatic state syncing and zero UX degradation > would you do it? No, because the "automatic state syncing and zero UX degradation" is a "draw the rest of the owl" exercise wherein the specific implementation details are omitted. Everything is domain specific when it comes to sync-based latency hiding techniques. SSR is domain agnostic. > low bandwidth requireme…

> the extra 50kb gzipped is starting to feel kind of heavy compared to my ~8kb (plaintext) HTML response

I thought we were living in a utopia where fast high-speed internet was ubiquitous everywhere? What's the fuss over 50kb? 5mb should be fine in this fantasy world.

Re: Linear sent me down a local-first rabbit hole

#185

Earlier quoted context omitted.

Latency is additive, so all that copper coax that and mux/demux in between a sizeable chunk of Americans and the rest of the internet means you're looking at a minimum roundtrip latency of 30ms if server is in the same city. Most users are also on Wi-Fi which adds and additional mux/demux + rebroadcast step that adds even more. And most people do not have the latest CPU. Not to mention mobile users over LTE. Sorry, b…

uh have you ever tried pinging a server in your same city? It's usually substantially <30ms. I'm currently staying at a really shitty hotel that has 5mbps wifi, not to mention I'm surrounded by other rooms, and I can still ping 8.8.8.8 in 20ms. From my home internet, which is /not/ fiber, it's 10ms.

latency != throughput

Re: Linear sent me down a local-first rabbit hole

#186

I developed an open-source task management software based on CRDT with a local-first approach. The motivation was that I primarily manage personal tasks without needing collaboration features, and tools like Linear are overly complex for my use case. This architecture offers several advantages: 1. Data is stored locally, resulting in extremely fast software response times 2. Supports convenient full database export a…

very cool!

Re: Linear sent me down a local-first rabbit hole

#187
post #86

Local-first buys you instant UX by moving state to the client, and then makes everything else a little harder

> instant UX I do not get the hype. At all. "Local first" and "instant UX" are the least of my concerns when it comes to project management. "Easy to find things" and "good visibility" are far more important. Such a weird thing to index on. I might interact with the project management tool a few times a day. If I'm so frequently accessing it as an IC or an EM that "instant UX" becomes a selling point, then I'm doing…

Actually it's both instant UX and far simpler code. With Zero I define a table schema, relationships, and permissions in beautifully simple code, then I also write my queries including relations with a nice typed query-builder, and I get not just instant UX but also perfectly fetched and synced data with permissions and mutations that are fully consistent without any extra thought.

Doing that with any other system, sync-engine or not, requires a huge mess of code and ends up implementing some sort of ad-hoc glue code to make even a part of this work.

I'm building an app right now with it and I'm currently so much further ahead in development than I could be with any other setup, with no bugs or messy code.

Your choice is either 100% server-side like v1 Rails, or some sort of ad-hoc sync/update system. My argument is either you should stick 100% server side, or go all the way client properly with a good sync engine. It's the middle part that sucks, and while there's a chunk of apps that benefit from fully server, it's not really an argument that you can build much faster responding apps client-side and that users generally prefer it, rightly so.

Re: Linear sent me down a local-first rabbit hole

#188

Earlier quoted context omitted.

Latency is additive, so all that copper coax that and mux/demux in between a sizeable chunk of Americans and the rest of the internet means you're looking at a minimum roundtrip latency of 30ms if server is in the same city. Most users are also on Wi-Fi which adds and additional mux/demux + rebroadcast step that adds even more. And most people do not have the latest CPU. Not to mention mobile users over LTE. Sorry, b…

uh have you ever tried pinging a server in your same city? It's usually substantially <30ms. I'm currently staying at a really shitty hotel that has 5mbps wifi, not to mention I'm surrounded by other rooms, and I can still ping 8.8.8.8 in 20ms. From my home internet, which is /not/ fiber, it's 10ms.

If you've ever used speedtest.net, you've almost certainly been using benchmarking against a server in your own city, or at least as close as your ISPs routing will allow. Ookla servers are often specifically optimized for and sometimes hosted/owned by ISPs to give the best possible speeds. Google's DNS servers use anycast magic to get similar results. Basically no service you actually use outside of very, very large providers is likely to be anywhere near you an won't get that kind of latency, even with a very good ISP and LAN.

10ms is a best case for DOCSIS3.0/3.1, it means you have near optimal routing and infrastructure between you and the node or are using some other transport like ethernet that is then fed by fiber. I currently get 24ms to my local Ookla host a couple of miles away over a wired connection with a recent DOCSIS3.1 modem. Hotel internet is likely to be backed by business fiber. They're likely throttling you.

I worked for an ISP for several years, there's a huge range of service quality even within the same provider, zipcode, and even same location depending on time of day.

Re: Linear sent me down a local-first rabbit hole

#189

I remember being literally 12 when google docs was launched, which featured real-time sync, and a collaborative cursor. I remember thinking that this is how all web experience will be in the future, at the time 'cloud computing' was the buzzword - I (incorrectly) thought realtime collaboration was the very definition of cloud computing. And then it just... never happened. 20 years went by, and most web products are s…

I feel the same way. The initial magic of real-timeness felt like a glimpse into a future that... where is it? I'm still excited about the prospects of it — shameless plug: actually building a tool with one-of-a-kind messaging experience that's truly real-time in the Google docs collaboration way (no compose box, no send button): https://kraa.io/hackernews

That's a really cool project! The realtime message aspect reminds me a bit of https://honk.me/, but for like, docs.

Re: Linear sent me down a local-first rabbit hole

#190

Earlier quoted context omitted.

I feel the same way. The initial magic of real-timeness felt like a glimpse into a future that... where is it? I'm still excited about the prospects of it — shameless plug: actually building a tool with one-of-a-kind messaging experience that's truly real-time in the Google docs collaboration way (no compose box, no send button): https://kraa.io/hackernews

Agreed, I did a talk about exactly this earlier this year: https://www.youtube.com/watch?v=RjV3Dm5giko

Interesting talk. I think it's just a matter of making tooling where it's so easy, cheap, and simple enough that doing realtime doesn't introduce any extra time cost to a business compared to CRUD.
Post reply on HN