Given that the author did a recent article about technical programming interviews, I'd pretty much see this article as enough evidence that the author here knows their stuff in data structures appropriately and also optimising apps beyond his own ones and would bypass the programming interview stage anyway. (All this code is open-source in NetNewsWire).
Great article and nice work on NetNewsWire!
NNW is clearly a labor of love for the author who has been involved in macOS development and RSS for a long time. NNW is unabashedly Mac-only and unabashedly fast. I love reading about people's passion projects.
I'm not the author, but I've got this facility as well. I guess part one is to have motivation --- it's hard to know what to research before hand, but if you've got something that is actively too slow now, that gives you a clear direction. Part two is not being easily satisfied that things are fast enough, or fast as you can get. There's almost always a way to make UI faster, it's just a matter of what needs to break to make it happen, sometimes it's abstraction layers. You can go back in time and look at 1980s UIs and while some were slow, many were super fast, and yet the CPUs were slower than dirt compared to today. We're often marshalling a lot more data and pixels, but it just shows than processing everything in time for the next frame is a reasonable target. Learning to use the profiling tools available is a good concrete first step.
 But, don't let that stop you from research into things that are interesting to you, or seem like they might be useful. Knowing something can be done is immensely helpful to doing it, even if you don't remember how it was done.
There are no true shortcuts.
Apple's APIs for macOS and iOS are simply better than those provided by either Microsoft (for Windows), Google (for Android), etc. Apple's APIs are, for the most part, very well-thought-out; their engineers have put together fantastic layers in the operating system and its UI components. The primary reason so many apps perform poorly on Apple platforms is because those apps were developed using 3rd party cross-platform tools (eg. Electron, or making an iOS app with webviews rather than native elements).
Developers who make efficient use of Apple's APIs, and who spend time to reduce their backend response time on remote API calls, will always produce an amazing product. The best example I can think of off the top of my head is the Apollo app for Reddit on iOS; it is coded with 100% native platform APIs, with no slow cross-platform garbage. It's such a breath of fresh air to witness.
Nope, you’re reaching too far. Applications built using native frameworks will have a strong push to generally do it right, but nobody can save you from an O(n^2) loop. And even with native frameworks and engineers with access to the best resources, you can totally mess up: take macOS Catalina’s Activity Monitor app, which takes up approximately half a core updating a table view every second, which it managed to do previously with a mere fraction of the resource usage. You can’t fix everything.
> The best example I can think of off the top of my head is the Apollo app for Reddit on iOS; it is coded with 100% native platform APIs, with no slow cross-platform garbage.
Apollo is not cross-platform, but it doesn’t always use native platform widgets as I have pointed out to Christian in the past. I don’t think this has had a major performance impact, especially since they aren’t in the most computationally expensive path, but those parts probably do not interact with the platform at the layer you think they do.
At heart, Slack is a chat app. Chat apps have existed for 40 years and don’t require a whole lot of data.
The complex part might be displaying the data, but that’s not much different than what an RSS reader does.
Even calling a chat app “complex” sounds absolutely ludicrous. It’s just that devs are now used to shipping 100MB apps in the name of fast development, so Slack is what we get.
There's video calling, audio calling, screen sharing, file sharing, permissions, media files sent around. It's not comparable to some old chat app where you only have to get new messages and display them in a chronological list.
On the other hand, when using the Slack app as a simple chat app - formatted text only, a few formatted in-line code snippets, things like that.. the experience can often be abysmal.
Just the other day, I was typing a _text_ message in a private chat, text only - no images, no fancy stuff other than a few bold and italics and inline code tags, and I could visibly measure the delay between typing and the text appearing on the screen.
That should never happen, regardless of whichever other fancy features the app _might_ be able to do.
Back before Apple dumped half the features and renamed it Messages, iChat had literally all of these features and then some and it was fast. It was efficient. It didn't run my CPU up to max no matter how I was using it nor how much, and it used very little RAM for an application in its class. It ran very well on hardware that Slack would choke to death.
Slack is the way it is because Slack has other priorities above being fast and efficient, it's not inherent to the nature of a chat app with AV calling, screen sharing and file sharing (file sharing was table stakes for a chat app even 15 years ago or more).
Slack/others got where they are by not paying attention, not because it's all that difficult.
Besides, irrespective of what the founder (or someone) might say/indicate at times I really don't think Matrix/Riot is looking to compete with Telegram/WhatsApp/Signal. They are trying for a pie of what Slack and the kind have. I am giving up on Matrix as well for it to ever be a personal IM app/service. It' just doesn't make sense and biggest reason for that not happening are:
- People are not going to bother finding different instances, or host their own - they just want one service, one server
- The UI of Riot is specifically designed for group/team chats and I don't think they will try to stand in two boats in one app or have two separate apps.
- There's no money in personal IM apps. So unless there's a coffer like Fb/Telegram or someone like Acton donates handsomely at some point there isn't much there other than just being another Diaspora but in instant messaging space.
Reminds me of that time people where upset they had to download a hundred MB OS update file instead. Turned out someone forgot to downscale some installer images from the raw bitmaps. After that the update was actually a few MB's.
Discord always feels pretty fast once it’s started. Slack is a different beast, at least on my machine. I’m not doubting there’s room for improvement, just that the comparison to the RSS reader in the OP isn’t a good one.
and therein lies the primary reason that I try to never use Core Data if I can avoid it. I almost always want a database. I almost never want to manage a graph of objects. If the backends I spoke to were also organized as object graphs, maybe I’d feel differently about it.
> I can't imagine it would be worth optimizing this aspect of the code base.
Well, this is the code path taken when the news reader is starting up or refreshing, right? It feels to me like that's the most important place to optimize an RSS reader, because it has a direct impact on the time between when the user clicks the "Refresh" button and everything is updated. Even if the user doesn't actually need to sit there and do nothing when it's updating, if updating takes 3 seconds instead of 10, it makes the whole experience feel much faster.
Not critical but definitely noticeable - kind of like how the Atom editor had a bad reputation for input latency even if it was still usable, coloring your perception of the entire app.
If they found out that these operations are responsible for long enough delays, or high enough energy consumption spikes, it would make all the sense to optimize them.
But that part only took 1% of the total perceived processing delay, so the user sees a whooping 0.9% improvement.
Turns out this is a completely rewritten app and the NetNewsWire name went on quite a journey: https://inessential.com/2018/08/31/netnewswire_comes_home
As much as I would use NNW right away but it isn't really a useful service at this point in time.
I'm not a big innoreader fan but their mobile app is decent and their online service is synced together. In this case, I never have to worry about my "read" states getting out of sync.
When it comes to RSS adoption, the read-state needs to be seamless across all platforms.
BTW, NNW is not charging as of yet. What I was talking about in two of my messages above, is the adoption issue with disparate platforms without the availability of read-state feature. If I use NNW mobile, I'm bound to using it all the time (which is not practical). If I use it's desktop app, I'm bound to using it on my Mac all the time (again, not practical). Anyone with more than hundred or more feeds, would find issues adopting such service. I am not here to defend my likeness of NNW so I won't say anything in this regard.
This particular iteration of NetNewsWire only shares the name. NetNewsWire 5.0 was originally being developed as Evergreen because Simmons got interested in making another RSS reader. It would never exist as a web app simply because he’s not the type to want it to be anything other than a native app.
Less well known is he was also the original developer of MarsEdit before selling to Daniel Jalkut. MarsEdit to write blogs, NetNewsWire to read them.
Those are my reasons why I'd want a local desktop app, anyway.
I'm sure it's "just" a matter of time.