gpui itself is maintained by the folks at https://zed.dev.

Also, Longbridge, who seem to be using this GPUI component library for their Longbridge Pro [1] app, look to me like a regular online brokerage company. What is your issue with that?

1: https://longbridge.com/desktop/

zed looks nice, but I am going to wait until the American port to use it.

May I ask what you mean by this? For all I know, Zed Industries Inc is incorporated in the US and funded by US venture capital.

BTW, I am not associated with zed in any way.

Its a stupid joke. Americans say Z==Zee, rest of the Anglosphere says Z==Zed

Thanks for the explanation :)

https://anytype.io is not open source, but source available, and even calls itself the "Everything App".

This reads like ai slop

I hope this one was written by a human, would be terrible to read such critique of the author didn't read them

well techincally an LLM could -read- (have in context) these books before critizing them.

i wonder now if -unbiased- llm based reviews could have a place for such

most reviewers are just stating what they experience/about their taste, but there's no objectivity on reviewing

I've read that the results improve if you ask them to write a program that creates the desired ASCII art. Haven't tried it myself yet so far.

I can second this. VisX will be a little more effort but it will let you build anything you could build using d3.

There is also https://httpie.io

I've been using it for a while. Coming from postman it's exactly what I was looking for. Just the features I need, no bloat.

I recently experimented with using pglite for API integration tests in one of my side projects. It worked pretty well and has much better DX than using something like testcontainers[0] to spin up postgres running in docker.

[0]: https://testcontainers.com

I see unit and integration testing as a massive opportunity for PGlite. I know of projects (such as Drizzle ORM) that are already making good use of it.

The team at Supabase have built pg-gateway (https://github.com/supabase-community/pg-gateway) that lets you connect to PGlite from any Postgres client. That's absolutely a way you could use it for CI.

One thing I would love to explore (or maybe commenting on it here will inspire someone else ;-) ) is a copy on write page level VFS for PGLite. I could imagine starting and loading a PGlite with a dataset and then instantly forking a database for each test. Not complexities with devcontainers or using Postgres template databases. Sub ms forks of a database for each test.

I would also love to use it this way in Go. Currently we dump SQLite compatible schema to use for SQLite powered integration tests even though we use postgres when live. It allows us to have zero dependency sub-second integration tests using a real database. Being able to use postgres would be even better, allowing us to test functionality requiring PG specific functionality like full text search.

I'm bothering the PGLite team a lot to help us enable this :-)

We have different options like embedded-postgres or integreSQL, but none match the simplicity of PGLite. I hope this wish comes true soon.

https://github.com/fergusstrange/embedded-postgres/tree/mast...

https://github.com/allaboutapps/integresql

What is the problem with https://github.com/fergusstrange/embedded-postgres/tree/mast... ?

I do exactly the same thing. I’m even running SQLite in wasm so I don’t have any C dependencies. Switching out for Postgres would be awesome

AFAIK, Ollama supports most of these models locally and will expose a REST API[0]

[0]: https://github.com/ollama/ollama/blob/main/docs/api.md

I can totally understand the quoted comment. I mean, we are talking about CSS as a language here. Anything that is formalized is expected to be implemented and supported by browser engines and vendors. Browser engines are already extremely complex, so it's fair to think closely about formalizing new things when it's not apparent that there is a big enough need.

I'm not claiming this is the case with the Mansory layout; I just understand that adding unnecessary complexity for a small target user base is a valid concern.

I totally get that. But for me there is a fundamental difference between "big enough need" and "well known websites need this".

How are potentially thousands of niche websites less of an argument than "instagram and co don't need it"?

Well-known == highly visited == native implementation will have large accumulated impact on end users (their performance, energy consumption, improved usability ...).