6 ms·

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

by sturza 1y ago

captainregex 1y ago
this is such a clean and articulate way of putting it. The discussion around here the last few days about local and the role it is going to play has been phenomenal and really genuine
CharlieDigital 1y ago
> 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 something wrong with my day.
- virgil_disgr4ce 1y ago
  UI performance is "a weird thing to index on"?
  - CharlieDigital 1y ago
    Yes? If that's the primary selling point for a project manager versus being just a really damn good project manager with good visibility? I've never used a project manager and thought to myself "I want to switch because this is too slow". Even Jira. But I have thought to myself "It's too difficult to build a good workflow with this tool" or "It's too much work to surface good visibility". This is not a first-person shooter. I don't care if it's 8ms vs 50ms or even 200ms; I want a product that indexes on being really great at visibility. It's like indexing your buying decision for a minivan on whether it can do the quarter mile at 110MPH @ 12 seconds. Sure, I need enough power and acceleration, but just about any minivan on the market is going to do an acceptable and safe speed and if I'm shopping for a minivan, its 1/4 mile time is very low on the list. It's a minivan; how often am I drag racing in it? The buyer of the minivan has a purpose for buying the minivan (safety, comfort, space, cost, fuel economy, etc.) and trap speed is probably not one of them. It's a task manager. Repeat that and see how silly it sounds to sweat a few ms interaction speed for a thing you should be touching only a few times a day max. I'm buying the tool that has the best visibility and requires the least amount of interaction from me to get the information I need.
    - ajoseps 1y ago
      I mostly agree with you on this but JIRA tends to push the envelope in terms of unresponsiveness of its UX. As an IC I only really use it to create/update/search tickets but I find myself waiting a half to couple of seconds for certain flows, especially for finding old tickets. Not quite the same as responsiveness but editing text fields in JIRA have a tendency of not saving in progress work if you accidentally escape out. Also hyperlinking between the visual and text mode is pretty annoying since you can easily forget which mode you’re in. Honestly as I type these out there are more and more frustrations I can think of with JIRA. Will we ever move away? Not anytime soon. It integrates with everything and that’s hard to replace. It’s still frustrating though.
    - asoneth 1y ago
      > any minivan on the market is going to do an acceptable and safe speed Growing up my folks had an old Winnebago van that took 2+ minutes to hit 60mph which made highway merges a white-knuckle affair, especially uphill. Performance was a criteria they considered when buying their next minivan. Whereas modern minivans all have an acceptable acceleration -- it's still important, it's just no longer one you need to think about. However, not all modern interfaces provide an acceptable response time, so it's absolutely a valid criteria. As an example, we switched to a SaaS version of Jira recently and things became about an order of magnitude slower. Performing a search now takes >2000ms, opening a filter dropdown takes ~1500ms, filtering the dropdown contents takes another ~1500ms. The performance makes using it a qualitatively different experience. Whereas people used to make edits live during meetings I've noticed more people just jotting changes down in notebooks or Excel spreadsheets to (hopefully remember to) make the updates after the meeting. Those who do still update it live during meetings often voice frustration or sometimes unintentionally perform an operation twice because there was no feedback that it worked the first time. Going from ~2000ms to ~200ms per UI operation is an enormous improvement. But past that point there are diminishing returns: from ~200ms to ~20ms is less necessary unless it's a game or drawing tool, and going from 20ms to 2ms is typically overoptimization.
      - dustingetz 1y ago
        2000ms isn’t network latency, it’s the db query. Moving a slow query from the cloud (high compute, fast network under your control) to the client (low compute, unreliable network, not under your control) is not going to make it faster and you’ve damaged reliability. All to save 50ms network latency.
- nwienert 1y ago
  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.
JamesSwift 1y ago
Id say you are underreporting how much harder everything else becomes but yes, definitely agreed

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

by sturza 1y ago

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

this is such a clean and articulate way of putting it. The discussion around here the last few days about local and the role it is going to play has been phenomenal and really genuine

CharlieDigital 1y ago

> 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 something wrong with my day.

virgil_disgr4ce 1y ago
UI performance is "a weird thing to index on"?
- CharlieDigital 1y ago
  Yes? If that's the primary selling point for a project manager versus being just a really damn good project manager with good visibility? I've never used a project manager and thought to myself "I want to switch because this is too slow". Even Jira. But I have thought to myself "It's too difficult to build a good workflow with this tool" or "It's too much work to surface good visibility". This is not a first-person shooter. I don't care if it's 8ms vs 50ms or even 200ms; I want a product that indexes on being really great at visibility. It's like indexing your buying decision for a minivan on whether it can do the quarter mile at 110MPH @ 12 seconds. Sure, I need enough power and acceleration, but just about any minivan on the market is going to do an acceptable and safe speed and if I'm shopping for a minivan, its 1/4 mile time is very low on the list. It's a minivan; how often am I drag racing in it? The buyer of the minivan has a purpose for buying the minivan (safety, comfort, space, cost, fuel economy, etc.) and trap speed is probably not one of them. It's a task manager. Repeat that and see how silly it sounds to sweat a few ms interaction speed for a thing you should be touching only a few times a day max. I'm buying the tool that has the best visibility and requires the least amount of interaction from me to get the information I need.
  - ajoseps 1y ago
    I mostly agree with you on this but JIRA tends to push the envelope in terms of unresponsiveness of its UX. As an IC I only really use it to create/update/search tickets but I find myself waiting a half to couple of seconds for certain flows, especially for finding old tickets. Not quite the same as responsiveness but editing text fields in JIRA have a tendency of not saving in progress work if you accidentally escape out. Also hyperlinking between the visual and text mode is pretty annoying since you can easily forget which mode you’re in. Honestly as I type these out there are more and more frustrations I can think of with JIRA. Will we ever move away? Not anytime soon. It integrates with everything and that’s hard to replace. It’s still frustrating though.
  - asoneth 1y ago
    > any minivan on the market is going to do an acceptable and safe speed Growing up my folks had an old Winnebago van that took 2+ minutes to hit 60mph which made highway merges a white-knuckle affair, especially uphill. Performance was a criteria they considered when buying their next minivan. Whereas modern minivans all have an acceptable acceleration -- it's still important, it's just no longer one you need to think about. However, not all modern interfaces provide an acceptable response time, so it's absolutely a valid criteria. As an example, we switched to a SaaS version of Jira recently and things became about an order of magnitude slower. Performing a search now takes >2000ms, opening a filter dropdown takes ~1500ms, filtering the dropdown contents takes another ~1500ms. The performance makes using it a qualitatively different experience. Whereas people used to make edits live during meetings I've noticed more people just jotting changes down in notebooks or Excel spreadsheets to (hopefully remember to) make the updates after the meeting. Those who do still update it live during meetings often voice frustration or sometimes unintentionally perform an operation twice because there was no feedback that it worked the first time. Going from ~2000ms to ~200ms per UI operation is an enormous improvement. But past that point there are diminishing returns: from ~200ms to ~20ms is less necessary unless it's a game or drawing tool, and going from 20ms to 2ms is typically overoptimization.
    - dustingetz 1y ago
      2000ms isn’t network latency, it’s the db query. Moving a slow query from the cloud (high compute, fast network under your control) to the client (low compute, unreliable network, not under your control) is not going to make it faster and you’ve damaged reliability. All to save 50ms network latency.
nwienert 1y ago
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.

JamesSwift 1y ago

Id say you are underreporting how much harder everything else becomes but yes, definitely agreed