I was thinking about this problem and found a while ago that Unison lang has a cool concept, I recommend you give it a read [0].

- [0] https://www.unison-lang.org/docs/the-big-idea/

I suppose it is just the convenience of having an opinionated app that works with agents out of the box, tmux could be more powerful but similar to vim vs vscode, you need to tune it in.

Compared to the usual agent manager guis, it's not even that opinionated.

> The amount of great games under $20 that you can get these days is overwhelming

I think that's the problem, there are too many to choose from, where you end up overwhelmed and ends up choosing none.

tsrs also has an LSP, so will be interesting to see how much memory it consumes vs tsgo.

I'm tired of all the new tools that comes out every day, but I would say, this is basically the Vite team and if they implement it with Vite+, then I'm all for it, less decisions about tooling to be made, one config file, etc.

Windows and Linux do the same, they store the data in the user home folder. So not sure if your argument stands, maybe Android is different in that regard, but also it's easier to back up the data this way.

Windows started out with both the app and the app's data stored in the app's subfolder in `C:\Program Files`. That might not have been the official convention but it was what nearly everyone did. Until Vista forced everyone's hand by gating write access to `C:\Program Files` behind the UAC prompt even for admin users, while also introducing the new %AppData% and %LocalAppData% folders

> they store the data in the user home folder.

that's a very dishonest or at least inaccurate depiction considering the multiple, semantically confusing places app data can be stored on win/linux

The app data directory on Windows is quite literally a subdirectory of the user directory; `%APPDATA%` == `%USERPROFILE%\AppData\Roaming`.

> can be stored

Rogue apps doing whatever when consistent standards exist seems more of a dishonest/inaccurate depiction

> Worse compatibility with the millions of Android apps already out there.

Most of the apps on Android and iOS aren't necessarily useful.

The only reason to choose Node is because it's boring, is a long lived project and I think it will outlive Bun and Deno.

With Vue, you require each library you use to be Vue specific, Nuxt UI, Vuetify, etc, while Svelte works seamlessly with vanilla JS libraries, also Svelte feels more like vanilla HTML/CSS/JS with some sparkles over it.

Ya, exactly this.

Other advantages of Svelte over React/Vue is that it does not require a Svelte specific library or wrapper, you can use vanilla JS libraries and it works seamlessly. I consider that as plus, you can old good old Chart.js, Ag-grid, etc without any wrapper, I tried some libraries with React/Vue that had wrappers for multiple frameworks, and most of them were painful, because each framework/library has their way to do things that collides with them, while Svelte is basically vanilla web tech with some sparkles over it.

I use React, Vue, and Svelte extensively, and I don't think that there is any problem with integrating 3rd party JS libraries in any of these frameworks.

React, as the most bare-bones framework, might be simplest to integrate, and you can see that by the enormous size of its ecosystem.

Vue and Svelte will have problems with integrating various devtools, due to the fact they use custom syntax to mimic native web tech. In Vue, this problem is solved by framework popularity and the fact that the Vue team produced most of the key devtools, so Vue is, of course, supported.

Svelte, on the other hand, still works badly with Storybook and linters.

A good counterexample to your take will be that I was unable to use the JS version of Framer Motion with Svelte without huge caveats that made making any complex animation impossible. I wasn't able to do so with Vue, for roughly the same reasons, but Vue, as a big framework, got 1st party support.

Integrating React with third party libraries has always been a pain for me.

The re-render model just doesn't quite fit with the way most JS libraries work. They hand you a class that you have to keep around. This can be solved with useState, but you have to use this weird construction `const [instance] = useState(() => new Whatever())`. Or even worse if the library needs an element to instantiate.

Then, you likely need some event listeners. They ended up not implementing useEvent, so this has to happen in useEffect. God forbid if you need to rebind the listener because a prop changes (possibly every rerender) or the library does something heavy on adding them.

Then, if a prop changes and you need to do something (like recenter a map), useEffect.

Occasionally you might want to reach for useSyncExternalStore but then get hit by the identity issue. The return value must be the same between renders or you end up with infinite rerenders. Many libraries just do `return { foo, bar}`. Not good enough for react.

Basically every JS library integration ends up with a thousand use effects, various useMemos (and useCallbacks) and I've never got (or seen) a satisfying result. There's always sync issues or too many rerenders or...

I've used various vanilla js libs with Vue over the years. It was always pretty easy to make a wrapper component and hook whatever library up to the lifecycle, usually just a few lines of code. I'd prefer that over just making random charts everywhere if I was using something like highcharts.