Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linear sent me down a local-first rabbit hole

bytemash.net

Post reply on HN
Print view View original

131–140 of 228 posts

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

#131

Post by OJFord »

incorrecthorse wrote: post #20

> For the uninitiated, Linear is a project management tool that feels impossibly fast. Click an issue, it opens instantly. Update a status and watch in a second browser, it updates almost as fast as the source. No loading states, no page refreshes - just instant, interactions. How garbage the web has become for a low-latency click action being qualified as "impossibly fast". This is ridiculous.

I don't know if 'the web' in general is fair, here the obvious comparison is Jira, which is dog slow & clunky.

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

#132

Post by 8n4vidtmkvmk »

rogerkirkness wrote: post #122
mentalgear wrote: post #27

Local-First & Sync-Engines are the future. Here's a great filterable datatable overview of the local-first framework landscape: https://www.localfirst.fm/landscape My favorite so far is Triplit.dev (which can also be combined with TanStack DB); 2 more I like to explore are PowerSync and NextGraph. Also, the recent LocalFirst Conf has some great videos, currently watching the NextGraph one ( https://www.youtube.com/wa…

Reminds me of Meteor back in the day.

Whatever happened to meteor? They made it sound so great. What I didn't like was the tight coupling to mongodb.

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

#133

Post by bob1029 »

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 RTT of 500ms, a SSR page rendered in 16ms would feel relatively instantaneous next to any of the mainstream web properties online today if delivered on that connection.

I propose that there is little justification to take longer than a 60hz frame to render a client's HTML response on the server. A Zen5 core can serialize something like 30-40 megabytes of JSON in this timeframe. From the server's perspective, this is all just a really fancy UTF-8 string. You should be measuring this stuff in microseconds, not milliseconds. The transport delay being "high" is not a good excuse to get lazy with CPU time. Using SQLite is the easiest way I've found to get out of millisecond jail. Any hosted SQL provider is like a ball & chain when you want to get under 1ms.

There are even browser standards that can mitigate some of the navigation delay concerns:

https://developer.mozilla.org/en-US/docs/Web/API/Speculation...

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

#134

Post by Izkata »

seanw265 wrote: post #123
ahofmann wrote: post #24

Earlier quoted context omitted.

This is not the point, or other numbers matter more, then yours. In 2005 we wrote entire games for browsers without any frontend framework (jQuery wasn't invented yet) and managed to generate responses in under 80 ms in PHP. Most users had their first bytes in 200 ms and it felt instant to them, because browsers are incredibly fast, when treated right. So the Internet was indeed much faster then, as opposed to now. J…

> Now they rewrite their frontend in react and it feels sluggish and slow. I find this is a common sentiment, but is there any evidence to find that React itself is actually the culprit of GH's supposed slowdown? GH has updated their architecture many times over and their scale has increased by orders of magnitude, quite literally serving up over a billion git repos. Not to mention that the implementation details of…

It's more of a "holding it wrong" situation with the datastores used with React, rather than directly with React itself, with updated data being accessed too high in the tree and causing large chunks of the page to be unnecessarily rerendered.

This was actually the recommended way to do it for years with the atom/molecule/organism/section/page style of organizing React components intentionally moving data access up the tree into organism and higher. Don't know what current recommendations are.

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

#135

Post by dustingetz »

dpflug wrote: post #115
dustingetz wrote: post #77

Earlier quoted context omitted.

it is my actual numbers from my house in the Philadelphia suburbs right now, 80 miles away from the EWR data center outside NYC. Feel free to double them, you’re still inside the 60hz frame budget with better than e-sports latency edit: I am 80 miles from EWR not 200

Like they said, for a small elite. If you don't see yourself as such, adjust your view.

what is your ping to fly.io right now?

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

#136

Post by do_not_redeem »

seanw265 wrote: post #123
ahofmann wrote: post #24

Earlier quoted context omitted.

This is not the point, or other numbers matter more, then yours. In 2005 we wrote entire games for browsers without any frontend framework (jQuery wasn't invented yet) and managed to generate responses in under 80 ms in PHP. Most users had their first bytes in 200 ms and it felt instant to them, because browsers are incredibly fast, when treated right. So the Internet was indeed much faster then, as opposed to now. J…

> Now they rewrite their frontend in react and it feels sluggish and slow. I find this is a common sentiment, but is there any evidence to find that React itself is actually the culprit of GH's supposed slowdown? GH has updated their architecture many times over and their scale has increased by orders of magnitude, quite literally serving up over a billion git repos. Not to mention that the implementation details of…

I don't see how GH's backend serving a billion repos would affect the speed of their frontend javascript. React is well known to be slow, but if you need numbers, you can look at the js-framework-benchmark and see how many React results are orange and red.

https://github.com/krausest/js-framework-benchmark

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

#137

Post by packetlost »

bob1029 wrote: post #133

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…

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, but this is 100% a case of privileged developers thinking their compute infrastruction situation generalizes: it doesn't and it is a mistake to take shortcuts that assume as such.

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

#138

Post by TimTheTinker »

bob1029 wrote: post #133

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…

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 app) is necessary to achieve developer happiness and a good UX. And in some cases (like this) it goes on to justify that compromise with promises of future network improvements.

The fact is, low bandwidth requirement will always be a valuable feature, no matter the context. It's especially valuable to people in third-world countries, in remote locations, or being served by Comcast (note I'm being a little sarcastic with that last one).

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

#139

Post by random3 »

bob1029 wrote: post #133

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…

> networks and servers are will only get faster

this isn't an argument for SSR. In fact there's hardly a universal argument for SSR. You're thinking of a specific use-case where there's more compute capacity on the server, where logic can't be easily split, etc. There are plenty of examples that make the client-side rendering faster.

Rendering logic can be disproportionately complex relative to the data size. Moreover, client resources may actually be larger in aggregate than sever. If SSR would be the only reasonable game in we wouldn't have excitement around Web Assembly.

Also take a look at the local-computation post https://news.ycombinator.com/item?id=44833834

The reality is that you can't know which one is better and you should be able to decide at request time.

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

#140

Post by CafeRacer »

floydnoel wrote: post #107
CafeRacer wrote: post #106

We're using dexie+rxjs. A killer combination. Described here https://blog-doe.pages.dev/p/my-front-end-state-management-a... I've already made improvements to that approach. decoupling of backend and front end actually feels like you're reducing complexity.

Are you using the cloud sync with Dexie? I built an app on it but it seems to have a hard time switching from local to cloud mode and vice versa. I’m not sure they ever thought people would want to but why bother making cloud set up calls for users that didn’t want it.

Nope, locally. Roughly I'm doing something like that https://gist.github.com/vladmiller/0be83755e65cf5bd942ffba22...

Example is a bit bad, but roughly shows how we're using. I have built a custom sync API that accepts in the body a list of : and returns a kind of json-list in a format

::\n ::\n

API compares what client knows vs. current state and only returns the objects that were updated/created and separately objects that were removed. Not ideal for large collections (but then again why did I store 50mb of historical data on the client in the first place? :D)

Post reply on HN