If you want to work on Linear's sync infrastructure or product – we're hiring. The day-to-day DX is incredible.
You should put pay bands on job listings to save everyone time and sanity.
Linear sent me down a local-first rabbit hole
101–110 of 228 posts
Re: Linear sent me down a local-first rabbit hole
#102Earlier quoted context omitted.
150ms is sluggish? 4000ms is normal? The comments are absolutely wild in here with respect to expectations.
150 ms is definitely on the “not instantaneous” side: https://ux.stackexchange.com/a/42688 The stated 500 ms to 1500 ms are unfortunately quite frequent in practice.
Interesting fact: the 50ms to 100ms grace period only works at the very beginning of a user interaction. You get that grace period when the user clicks a button, but when they're typing in text, continually scrolling, clicking to interrupt an animation, or moving the mouse to trigger a hover event, it's better to provide a next-frame response.
This means that it's safe for background work to block a web browser's main thread for up to 50ms, as long as you use CSS for all of your animations and hover effects, and stop launching new background tasks while the user is interacting with the document. https://web.dev/articles/optimize-long-tasks
Re: Linear sent me down a local-first rabbit hole
#103Earlier quoted context omitted.
Hm. While I'm not even remotely excited by Jira (or any other PM software), I've never noticed it being that bad. Annoying? Absolutely! But not that painfully slow. Were some extras installed? Or is this one of those tools that needs a highly performant network?
I've seen on perm Jira at large companies get that slow. I'm not sure if it's the plugins or just the company being stingy on hardware.
Yeah it’s probably both. Underfunded IT department, probably one or two people who aren’t allowed to say no.
Re: Linear sent me down a local-first rabbit hole
#104I’ve been working on a small browser app that is local first and have been trying to figure out how to pair it with static hosting. It feels like this should be possible but so far the tooling all seems stuck in the mindset of having a server somewhere. My use case is scoring live events that may or may not have Internet connection. So normal usage is a single person but sometimes it would be nice to allow for multi…
Honestly, having used InstantDB (one of the providers listed in their post), I think it'd be a pretty nice fit. I've been writing a budget app for my wife and I and I've made it 100% free with 3rd party hosting: * InstantDB free tier allows 1 dev. That's the remote sync. * Netlify for the static hosting * Free private gitlab ci/cd for running some email notification polling, basically a poor mans hosted cron.
I may end up doing that, but I really wish there was a true p2p option that doesn’t have me relying on someone not rug pulling their free tier sync server.
Re: Linear sent me down a local-first rabbit hole
#105Earlier quoted context omitted.
Unless you are running some really complicated globally distributed backend your roundtrip will always be higher than 80ms for all users outside your immediate geographical area. And the techniques to "fix" this usually only mitigate the problem in read-scenarios. The techniques Linear uses are not so much about backend performance and can be applicable for any client-server setup really. Not a JS/web specific proble…
My take is, that a performant backend gets you so much runway, that you can reduce a lot of complexity in the frontend. And yes, sometimes that means to have globally distributed databases. But the industry is going the other way. Building frontends that try to hide slow backends and while doing that handling so much state (and visual fluff), that they get fatter and slower every day.
This is an absolutely bonkers tradeoff to me. Globally distributed databases are either 1. a very complex infrastructure problem (especially if you need multiple writable databases), or 2. lock you into a vendor's proprietary solution (like Cloudflare D1).
All to avoid writing a bit of JavaScript.
Re: Linear sent me down a local-first rabbit hole
#106We'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.
Re: Linear sent me down a local-first rabbit hole
#107We'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.
Re: Linear sent me down a local-first rabbit hole
#108I really like electric approach and it has been on my radar for a long time, because it just leaves the writing complexity to you and the API.
Most of the solutions with 2 way sync I see work great in simple rest and hobby "Todo app" projects. Start adding permissions and evolving business logic, migrations, growing product and such, and I can't see how they can hold up for very long.
Electric gives you the sync for reads with their "views", but all writes still happen normally through your existing api / rest / rpc. That also makes it a really nice tool to adopt in existing projects.
Re: Linear sent me down a local-first rabbit hole
#109ElectricSQL and TanStack DB are great, but I wonder why they focus so much on local first for the web over other platforms, as in, I see mobile being the primary local first use case since you may not always have internet. In contrast, typically if you're using a web browser to any capacity, you'll have internet. Also the former technologies are local first in theory but without conflict resolution they can break dow…
Because building local first with web technologies is like infinity harder than building local first with native app toolkits. Native app is installed and available offline by default . Website needs a bunch of weird shenanigans to use AppManifest or ServiceWorker which is more like a bunch of parts you can maybe use to build available offline. Native apps can just… make files, read and write from files with whatever…
> Because building local first with web technologies is like infinity harder than building local first with native app toolkits.
You just have to write one for every client, no big deal, right? Just 2-5 (depending on if you have mobile clients and if you decide to support Linux too) times the effort.
You even say it yourself, you'll have to use Apple's sync and data solutions, and figure it out for Windows, Android and maybe Linux. Should be easy to sync data between the different storage and sync options...
Oh, and you have to figure out how to build, sign and update for all OSes too. Pay the Apple fee, the Microsoft whatever nonsense to not get your software flagged as malware on installation. It's around a million times easier to develop and deploy a web application, and that's why most developers and companies are defaulting to that, unless they have very good reasons.
Re: Linear sent me down a local-first rabbit hole
#110Earlier quoted context omitted.
To see this first hand try this website if you're in Europe (maybe it's also fast in the US, not sure): https://www.jpro.one/ ? The entire thing is a JavaFX app (i.e. desktop app), streaming DOM diffs to the browser to render its UI. Every click is processed server side (scrolling is client side). Yet it's actually one of the faster websites out there, at least for me. It looks and feels like a really fast and modern…
At least for me this site is completely broken on mobile. I'm not saying it's not possible to write sites for mobile using this tech... But it's not a great advert at all.
Hardly a surprise, given that:
> The entire thing is a JavaFX app (i.e. desktop app)
Besides, this discussion is not about whether or not a site is mobile-friendly.