thingortwo

This is basically "wanting" it to be true then it actually being there are so many variables and so many other things that even the minuscule benefit you gain from this heavily marketed science backed supplement could get completely offset by your other lifestyle problem like poor inconsistent sleep. I at one point was deep in this "optimizing" phase listening to all these pseduo-intellectual channels like "What I've Learned" and articles like the one linked and they always overblow the finding to support some conclusion. I tried creatine for full year and didn't felt any different no extra 20% energy nothing still fatigued after work same with fish oils all this stuff is at best either placebo or in case of creatine only tiny benefits that might only be felt by someone really at peak of their training.

The actual things that I now swear by and actually help is consistent sleep of whatever hours that doesn't make you feel sleepy in the day/night (depending on shift) since actual consistency matters more then timing and also in case of workouts really balancing the fatigue to intensity ratio. I understood this late and thought one should always push hard but there needs to be a balance. It's kind of like how cheetah can run really fast but only for 20-30 seconds and then it needs a 30 minute reset period or something. So if you go to failure or always at very high intensity it affects later sets and increases recovery period and in a way driving down overall weekly sets/volume which is main hypertrophy factor.

Which is exactly why I said this problem is better solved by your own custom sync engine which when scoped to your own problem is not as hard to build as you think the most simpler and effective version is just a change_log and replaying or occasional full sync.

My own app uses something like this and I have yet to encounter any issue whereas I did initially look into using electricsql , zero sync , instantdb , triplit but the amount of lock-in or DSL was not my cup of tea and most of these are now doing "AI Agents" marketing instead of their core original problem which further erodes any trust.

Most of the improvement opportunity is in the offline-first the cache or fast reads already have lots of solutions by using zero I lock my self in thinking in your library's design language and not in terms of what I already know that is raw SQL. If your happy/convenient/recommended path is ZQL then of course people will choose it and only later realize it only works for simpler queries like most ORMs I've been burnt by prisma before and now I don't touch any ORMs and simply use raw sql + sqlc (type safety + auto repo layer from your query.sql)

I would use these DSL if they provide 10x improvement but it seems to me like a downgrade in every way I will need to rely on you to keep this thing running 10 years down the road and hope you are still in business. Whereas raw SQL will probably work as is since past performance is usually indicator of future and sqlite/postgres are 25 years old and if I recall correctly you already had this similar project that is now no longer maintained: https://replicache.dev/ so this by default makes me trust this project less since it will touch critical parts of my app.

Also, imo the custom sync engine path is usually better because most of this turns into logical replication unless you are syncing simple notes and then teams already know what they need and a last-write-wins + row_id,table => changes_log tables isn't that hard the issue is usually that the client and server will need to duplicate functionality and I will be a lot more comfortable duplicating those using raw sql queries since you write those ones and use on both sides. Any half-sync or other optimizations usually just end up causing a lot of headaches in a relational db with foreign keys on.

So, I would use something like this only if it is a sidecar process like litestream seamlessly doing it's thing vs becoming a main concern in my app core. But that again is the issue logical replication vs physical replication and how can a sidecar know the intent.

this is not local/offline first and also seems massively over-engineered for the type of apps that might use it since now you can't use plain sql and need to learn your ZQL domain specific language/library. I mean look at this code from raw sql example:

```

const markAllAsRead = defineMutator( z.object({ userId: z.string() }), async ({tx, args: {userId}}) => { // shared stuff ...

    if (tx.location === 'server') {
      // `tx` is now narrowed to `ServerTransaction`.
      // Do special server-only stuff with raw SQL.
      await tx.dbTransaction.query(
        `
      UPDATE notification
      SET read = true
      WHERE user_id = $1
    `,
        [userId]
      )
    }
  }

```

This is just a matter of perspective. Backend IS being "shipped" to user via the API be it go or rust and inevitably the details and behavior do leak out to end user.

Why is that a problem if you are already going to be using specific software to interface with your notes don't you want it stored in an optimized foolproof format that is also one the preferred format recommended by library of congress?

And if you want always direct edit access and do it often why not then a simple plain text since either way you will be dependent on the software if you like the additional features it offers which aren't inside .md like linking and other

Most people actually just prefer convenience with web apps you just instantly go to a domain and can check it out also secure and sandboxed by default since I don't have to worry what they are doing in other parts of my system which is a big worry with current supply chain attacks and what not.

Their "PWA" marketing holds them back in addition to financial incentives of Apple and Google. Most people aren't familiar with term "PWA" also why is "installing" a feature who wants to manage these things through their OS which a lot of normies already find confusing. People want plug and play the whole benefit of pwa (seperate window etc) could basically be exposed as per origin setting inside the browser itself and if user want they can pin it to their desktop. Since in my own testing there isn't much difference it terms of API's exposed only lack thereof like no proper user controlled storage retention settings for apis like OPFS and also lack of syncing directly to a user specified folder across all browsers. If they improve these files workflows you will see a lot more robust web apps.

This is using webrtc and speeds are slower than a physical USB I get 3-4MB/s instead of local network speed of 30MB/s due to browser browser implementation bottlenecks. I needed fast local network sharing of files over 5GB and tried a lot of approaches and speed doesn't budge more than 6-7MB/s .

Also you don't even need a server atleast for now in chrome webrtc transfer can work over a file:// in firefox it doesn't. For signaling you could even use free peerjs tunnel or other when user is connected to internet and otherwise fallback to this QR or offer code sharing. This will become so useful if browsers eliminate those bottlenecks.

also even in localsend speeds are limited usually to my internet speed for some reason.

So what do you want another chromium based browser? The whole point of Ladybird is to kinda prove that a completely independent browser engine is feasible. Also, they are not doing everything from scratch for example it will use the same graphics library that chromium uses (Skia) and also now firefox. You should probably read the FAQ on their homepage:

https://ladybird.org/#:~:text=What%20does%20%22No%20code%20f...

I'm not dismissive of AI but I still do the whole "copy and paste" into chatbot approach simply because I use it as a boilerplate or research tool where the intent or workflows are already established and is targeted so it doesn't really matter how it writes since I can "parse" it's output quickly kind like an advance version of vscode saved snippet templates. I never use it do software design for me since this actually requires you understanding the problem but I can still use it to research existing stuff which is pretty cool.

I always see this point mentioned in "App VS Spreadsheet" but no one gives a concrete example. The whole point of using a "purpose" build app is to give some structure and consistency to the problem. If people are replicating spreadsheet feature then they needed "excel" to begin with since that is a purpose built tool for generalizing a lot of problems. It's like I can say well my notebook and pen is already in front of me, I can use this why would I ever bother opening an app? well because the app provides some additional value.

Why would you not be able to build a "web analytics tool" with what parent comment mentioned? At the end of the day it is just data and if you are just starting out pretty much anything will scale and if you already have millions of customers you also have capital and people to think about how to make some homegrown solution to specifically cater to that.

The market for these new breed of frameworks is not huge companies with crazy scaling needs but freelancers and your very early stage startups who haven't even found a product market fit since they are starting new they don't have anything to loose with newer stuff and chances are that newer stuff also helps them do more quickly like I haven't used convex but on it's marketing page it does mention a lot and same for other frameworks like pocketbase or SvelteKit combined with a db etc. Like always there is no silver bullet and every stack can seem "random"

I recently moved from just to mise. Just is great but it is only a command runner and I needed mise other features and I'm glad I made the switch. I just wish docs would improve a little in structure and explanation of usecases/history while drawing comparison with other things like nix,docker etc as a newbie it helps to know the why like:

"we often need to run programs as side effect" => "scripts" => "task runner" => "make/just" => "mise"

and also why not docker or nix pros/cons etc

How many expenses do you really have on a daily basis that they are too much to track? I don't like a spreadsheet for this since they have bad input UX on phones. I use a custom app I built and even though it is manual I don't really feel it since I have optimized the UX for n=1 and it just becomes a habit. I tried all these other automatic tracking apps like monarch money,mint,YNAB et al but they are just not real-time enough for me and don't keep me in touch as much, also the obvious data lock. Maybe I'll make it public someday but I haven't mostly because the common sentiment online is 'manual tracking is too much work' when it really isn't if you do it as you go vs all at once at the end of month etc.