helge5

I don't think it is an experiment, AFAIK it is used in a widely used application by the author.

Yes, GRDB even w/ manual help is obviously not as fast raw SQLite. As much respect I have for the author "performance nearly identical as raw SQLite" is incorrect. Lighter also achieves some of the performance characteristics by avoiding allocations for bound parameters (such being statically generated). I didn't look into SharingGRDB yet, but it seems like those macros could accomplish similar performance, the other way around (Lighter works on the SQLite DB schema). What I'm not entirely sure of yet is why it even sits on top of GRDB in the first place, instead of just doing the SQLite parts itself. Marketing I suppose.

If you think that this library is "basically Swift/Core Data", you have to learn more about "Swift/Core Data" and what it does, and why and how.

No, both Rust and Swift can be seen as better C++'s. And both do not provide the Smalltalk like OO Objective-C has. Swift (only) on Apple platforms integrate w/ ObjC, but the core language is more like C++ and very little like Smalltalk.

The demo version now actually supports multiple rooms (I think the 4 or 5 last you clicked). The bigger issue usually is the lack of XOXC support (as the general API gateway lacks a lot of API features).

BTW: You can also get a refund. This is more to make sure that people actually try the thing before blindly buying something. Shrugs _does_ have limitations, so it's important to first test whether it fits the needs.

Thanks a lot! It is still lacking quite some functionality (check the FAQ for details), but we'll get there.

Thanks! Yes, it is very 1.0 and lacks quite some features. Message editing falls in the same batch of work like the RAM improvements and will very likely be part of 1.1.

Oh, the original comment was about the WebKit wrapper. Well, that this is using as much memory isn't very surprising. Why would Slack use less memory in a WKWebView than in an Electron frame? It is essentially the same app (with the Electron app providing a set of extra platform integration benefits).

Any performance differences between the two approaches should essentially boil down to the Chrome vs Safari differences.

My primary goal for Shrugs wasn't better memory efficiency but a better user experience (i.e. using native controls, having multiple windows, quicklook, etc). It uses quite some memory because it does (too) aggressive caching and prefetching of messages (I have enough RAM, fast access was more important to me).

It is worth noting that the official Slack app has gotten massively more memory efficient about a 1.5y ago, its bad reputation comes from the time before that (when it easily used more than 1GB of RAM). (I think it still has other performance issues, but they aren't as big anymore, it is doing quite well IMO)

Having said that I'm working on improving memory consumption in Shrugs.app - it is a tentpole feature planned for v1.1 (it'll take some time until this will be ready though).