9 ms·

Why NetNewsWire Is Fast

298 points by mrzool 6y ago

abhayb 6y ago
I love the detail in the post! A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand? Maybe the higher level tooling didn't exist when they started working on the platform so they had to pick things up out of necessity?
- cpach 6y ago
  Yeah, it’s impressive indeed. Simmons has been developing macOS applications for a long time, e.g. when he worked for Omni Group. Here’s an interview from 2003 where he talks about an early version of NetNewsWire: https://daringfireball.net/2003/03/interview_brent_simmons https://daringfireball.net/2003/03/interview_brent_simmons
  - wiredfool 6y ago
    He’s been doing Mac applications since the late 90s, when he worked on Userland Frontier,
  - abhayb 6y ago
    Ah dark knowledge through blood sacrifice. Was hoping they'd found an easier way :( Thanks for the pointer, been a bit since I read some OG John Gruber
- ken 6y ago
  There's no black magic here. Everything you see here can be found by running the profiler and reading the docs. I haven't been a Mac developer nearly as long as he has, and almost all of these are things that I do.
  - setpatchaddress 6y ago
    Mostly, yes; but the folklore like (paraphrasing) "don't use Core Data for this particular purpose" is also critical and isn't as easy to come by except through bitter experience (or war stories from other developers, if you're a good listener). There are no true shortcuts.
    - ken 6y ago
      It’s clear from the docs that CoreData can use SQLite internally but doesn’t give the programmer full access to all the features of the database. No bitter experience necessary.
      - inimino 6y ago
        The bitter experience is needed to learn that there are no shortcuts, and that the higher-level library that makes everything easy for you will also bite you in the ass sooner or later. We aren't born knowing these things, sadly.
- toast0 6y ago
  > A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand? 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[1], 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. [1] 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.
  - abhayb 6y ago
    Ah I wasn't even thinking about motivation! Yeah it makes sense that I'd have to start with motivation when I'm breaking down a perf problem. I'm reminded of the talk So you want to be a wizard [1]. It definitely understands what you're talking about. [1] https://jvns.ca/blog/so-you-want-to-be-a-wizard/ https://jvns.ca/blog/so-you-want-to-be-a-wizard/
    - inimino 6y ago
      Don't forget overcoming fear. SICP helped me most in that I overcame unconscious barriers of fear of complexity. The only way to defeat those is to embrace complexity and fight through it.
  - chrisbrandow 6y ago
    Knowing what little I do about the author’s experience, his facility in dropping to lower levels probably has a lot to do with his having worked extensively at those lower levels out of necessity in the past.
- developer2 6y ago
  Aside from the specific optimizations listed in the article, and caring about improving round-trip times for remote API calls in general, the fact is that any app built properly with native MacOS/iOS APIs will be extremely fast. 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.
  - saagarjha 6y ago
    > the fact is that any app built properly with native MacOS/iOS APIs will be extremely fast 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.
    - developer2 6y ago
      1. I did not mention Apple's own native apps as a perfect example. I have also noticed Activity Monitor as an imperfect sample. I'm not sure if it's a limitation of the APIs available, or if Apple engineers just fucked up. I 100% agree that Activity Monitor takes up far more resources than it should. Then again, monitoring every single process (plus thousands of threads!) running on an operating system is an intensive undertaking, so I'm not entirely sure who to blame, if anyone. 2. I will 100% defend Christian until the end of days. I respect the fact you at least know his name, assuming that you can in return understand that everything he does is amazing. Yes, some of what he does directly counteracts the weaknesses that are innate to the Apple platform (which should be called out against Apple). His most recent release, for example, offers a "Smart Rotation Lock", which swaps between portrait and landscape depending on whether a GIF or video is playing; something Apple should have built in from day one. Also, he had a volume bar in top-left corner on iPhone X and beyond before Apple even made that standard. IMO everything he does to break the "Apple philosophy" winds up getting adopted by Apple. Christian is that good. 3. Everything I said above, whether already existing at Apple or pushed towards the future, is already better than Windows or Linux. MacOS and iOS are positioned to take over the future of computing, minus one mother-fucking aspect (fuck you, Apple): gaming. Even if Metal is technically superior, vendor-lock at Apple makes Metal worthless vs. DirectX and OpenGL. This is the only thing I am willing to abdicate… Apple+MacOS+iOS needs to figure out how to play nice with cross-platform gaming.
aaronbrethorst 6y ago
Remember that Core Data manages a graph of objects: it’s not a database. 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.
- kitotik 6y ago
  I always thought that using it as basically the db or cache for remote API was a terrible misuse of CoreData, but a graph of objects does come in handy when driving complex UIs.
  - setpatchaddress 6y ago
    It is absolutely a terrible use of Core Data. Raw sqlite or wrappers are fine for that and will be considerably less difficult to debug when something goes wrong.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
D13Fd 6y ago
I’m looking forward to them eventually supporting Inoreader sync.
- Hamuko 6y ago
  I'm waiting for Feedly support.
  - guywithabike 6y ago
    It's open-source so there's no barrier to adding it, other than opening a Pull Request.
  - hylaride 6y ago
    Strangely, the iOS version supports feedly, but the desktop version doesn’t.
    - dewey 6y ago
      That's because it's a small project and they have to prioritize pretty strictly, highly recommend following the blog where he always posts updates. I'm sure it's "just" a matter of time.
minimaxir 6y ago
The relatively new iOS app for NetNewsWire is very good (and free!)
- webwanderings 6y ago
  What is a good use case of such "free" mobile app if the sync feature is behind a third party paid service? Am I expected to always check my feeds only on my mobile? How useful is that? As much as I would use NNW right away but it isn't really a useful service at this point in time.
  - Angostura 6y ago
    I mainly use RSS on my phone, it's useful.
  - kemayo 6y ago
    There's in-progress work on supporting other sync services. Most relevantly, there's work on using a CloudKit backend[1], which would effectively be a NetNewsWire-only feed syncer service. [1]: https://github.com/Ranchero-Software/NetNewsWire/issues/491 https://github.com/Ranchero-Software/NetNewsWire/issues/491
  - paulcole 6y ago
    It’s very useful to me! The only computer I have is the one I use at work. All iPad at home and NNW is great!
  - minimaxir 6y ago
    Hmm? The iOS app can be backed by Feedly, which is free. (supposedly that functionality will go to the desktop version soon.)
    - webwanderings 6y ago
      Feedly is limited with free account. The point I'm making is that NNW should be using its own service to maintain user's "read" states between its desktop and mobile apps. 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.
deleted 6y ago
[deleted]
rvz 6y ago
NetNewsWire is another great example of quality open source Mac applications that don't force my laptop in 100% CPU utilization, especially for RSS readers. 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!
- WaltPurvis 6y ago
  Wow, I had no idea NetNewsWire had become free and open source. I stopped using it after v3 (because v4 removed some AppleScript functionality I depended on, although I now can't even remember what it was) and completely missed the news that a free v5 had been released, and open source to boot. This is fantastic!
ryanwaggoner 6y ago
I used to use NetNewsWire like 12-15 years ago, so I was surprised to see it pop up here in this excellent article. 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 https://inessential.com/2018/08/31/netnewswire_comes_home
baby 6y ago
I used to use this, but switched to inoreader due to the mobile app and because it was easy to use. Is it time to switch back?
- deleted 6y ago
  [deleted]
- stereo 6y ago
  Yes! The NetNewsWire mobile app is great.
dhhwrongagain 6y ago
What does the pizza emoji at the end of the article mean?
- jakelazaroff 6y ago
  > Make sure, in other words, that performance isn’t just a topping — it’s the pizza.
dirtylowprofile 6y ago
I used to use NNW but one time my 2 year old kid just did a one quick swipe on my phone’s screen while NNW is open and just deleted the whole content. I’m not sure what gesture made it happen but I switched back to Feedly.
- Wevah 6y ago
  You can shake/three-finger-swipe to undo deletions, though it’s not very obvious.
tedunangst 6y ago
I wouldn't advocate for slower software, but is all of this really necessary for a fast RSS reader? My RSS reader downloads the entire XML file as blob, parses it into an array of structs, then walks over the array looking for new links. It's not particularly slow. I can't imagine it would be worth optimizing this aspect of the code base.
- nine_k 6y ago
  No optimization is worth the effort before profiling. 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.
  - jonstewart 6y ago
    Profiling is good at telling you which parts of your code account for most of the program’s runtime, but that’s it. It can’t tell you whether the performance is reasonable relative to the work done, or whether a totally different approach is necessary. Writing fast code goes well beyond using profilers, in keeping with the article’s thesis.
    - nine_k 6y ago
      Assume you locate a part of code which is 10x as slow as it could be. You make it 10x faster; great! But that part only took 1% of the total perceived processing delay, so the user sees a whooping 0.9% improvement.
  - vnorilo 6y ago
    However, you need to have a big picture view or potential optimizations when you architect. The profiler can't save you from slow architecture.
- chipotle_coyote 6y ago
  I don't know if it's "necessary," but you can really see the speed difference between NetNewsWire and, say, Reeder on the same hardware. It's not that Reeder is slow, it's that NNW is just really fast. > 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.
atonse 6y ago
I still find Reeder to be the gold standard for a really polished reader.
manigandham 6y ago
Any particular reason why this is a local (destop/mobile) app? I use Feedly and performance was never an issue, with the bonus that content and status is synced everywhere.
- setpatchaddress 6y ago
  The whole point of the app is to provide native macOS/iOS UI. I use Feedly to sync with NetNewsWire on iOS (and will on the Mac once it's supported, supposed to be in next update).
- zapzupnz 6y ago
  I don't want a website open all the time. I don't want to have to be connected to the internet to read my catalogue of saved articles. I want native performance, not "good enough" or "not really an issue" performance. I want 100% integration with my system; I want AppleScript-based automation. I want my system's accessibility settings to determine how I use the content, not depend on how some website's CSS handles my use cases — not that a lot of websites, particularly SPAs, are made such that VoiceOver can deal with them. Those are my reasons why I'd want a local desktop app, anyway.
- SllX 6y ago
  Developer preference. Simmons is famous in the Indie Mac world, even though a good portion of his career has been at companies. He’s still most well known as the guy who developed the original NetNewsWire before selling that to NewsGator, a kind of Feedly before Feedly existed, and then after some events I really can’t quite remember, taking it independent again and eventually selling it to Black Pixel who gave it back. I believe they were acquihired a bit after that if I’m remembering correctly (but don’t quote me on that), so it might have been because they knew they were soon to sell. 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.
fouc 6y ago
Imagine if Slack or Discord did any of these at all. Lots of performance gains to be had.
- gmueckl 6y ago
  How about building a proper native UI first?
  - mrzool 6y ago
    That would be the first step in that direction.
- dewey 6y ago
  These all have a lot more network overhead than an RSS reader that only has to periodically fetch a bunch of xml files. I feel like optimizing these kind of apps is a whole different problem space and a "native" app is probably not going to change that so much.
  - jcelerier 6y ago
    Ripcord is a Qt client for slack and discord which uses much less cpu and ram though.
  - Cthulhu_ 6y ago
    But they control both server and client, so they could use an optimized protocol over a socket like in the protobuf family. Keep in mind that XML is a weird format in that you take your data, convert it to text, then compress it, transfer it, decompress it, convert it from text back to data, then interpret it. With binary formats these steps are a lot faster and more native to the machine.
    - dewey 6y ago
      RSS readers usually refresh every 15 minutes per default. So it’s number of feeds requests every 15 min which is very low. Compared to Discord and Slack which are permanently polling and streaming. 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.
mikece 6y ago
I just discovered the iOS app for NetNewsWire and I am blown away that it is only 7.5 MB in size! I did Xamarin development for a while; a blank hello world application is about 45 MB. Kudos to the team!
BooneJS 6y ago
RSS applications all have a fixed feature set. Subscribe to feeds, check feeds for updates, organize & sync data for multiple clients, and present user's reading list to the screen. There are several RSS readers that all tick these boxes. 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.

298 points by mrzool 6y ago

I love the detail in the post! A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand? Maybe the higher level tooling didn't exist when they started working on the platform so they had to pick things up out of necessity?

cpach 6y ago
Yeah, it’s impressive indeed. Simmons has been developing macOS applications for a long time, e.g. when he worked for Omni Group. Here’s an interview from 2003 where he talks about an early version of NetNewsWire: https://daringfireball.net/2003/03/interview_brent_simmons https://daringfireball.net/2003/03/interview_brent_simmons
- wiredfool 6y ago
  He’s been doing Mac applications since the late 90s, when he worked on Userland Frontier,
- abhayb 6y ago
  Ah dark knowledge through blood sacrifice. Was hoping they'd found an easier way :( Thanks for the pointer, been a bit since I read some OG John Gruber
ken 6y ago
There's no black magic here. Everything you see here can be found by running the profiler and reading the docs. I haven't been a Mac developer nearly as long as he has, and almost all of these are things that I do.
- setpatchaddress 6y ago
  Mostly, yes; but the folklore like (paraphrasing) "don't use Core Data for this particular purpose" is also critical and isn't as easy to come by except through bitter experience (or war stories from other developers, if you're a good listener). There are no true shortcuts.
  - ken 6y ago
    It’s clear from the docs that CoreData can use SQLite internally but doesn’t give the programmer full access to all the features of the database. No bitter experience necessary.
    - inimino 6y ago
      The bitter experience is needed to learn that there are no shortcuts, and that the higher-level library that makes everything easy for you will also bite you in the ass sooner or later. We aren't born knowing these things, sadly.
toast0 6y ago
> A lot of this seems to boil down to the author being able to drop to a lower level of abstraction when necessary. I'm curious to know how they got that facility. Did they dig deep when they found something was slow? Or did they do a bunch of research before hand? 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[1], 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. [1] 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.
- abhayb 6y ago
  Ah I wasn't even thinking about motivation! Yeah it makes sense that I'd have to start with motivation when I'm breaking down a perf problem. I'm reminded of the talk So you want to be a wizard [1]. It definitely understands what you're talking about. [1] https://jvns.ca/blog/so-you-want-to-be-a-wizard/ https://jvns.ca/blog/so-you-want-to-be-a-wizard/
  - inimino 6y ago
    Don't forget overcoming fear. SICP helped me most in that I overcame unconscious barriers of fear of complexity. The only way to defeat those is to embrace complexity and fight through it.
- chrisbrandow 6y ago
  Knowing what little I do about the author’s experience, his facility in dropping to lower levels probably has a lot to do with his having worked extensively at those lower levels out of necessity in the past.
developer2 6y ago
Aside from the specific optimizations listed in the article, and caring about improving round-trip times for remote API calls in general, the fact is that any app built properly with native MacOS/iOS APIs will be extremely fast. 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.
- saagarjha 6y ago
  > the fact is that any app built properly with native MacOS/iOS APIs will be extremely fast 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.
  - developer2 6y ago
    1. I did not mention Apple's own native apps as a perfect example. I have also noticed Activity Monitor as an imperfect sample. I'm not sure if it's a limitation of the APIs available, or if Apple engineers just fucked up. I 100% agree that Activity Monitor takes up far more resources than it should. Then again, monitoring every single process (plus thousands of threads!) running on an operating system is an intensive undertaking, so I'm not entirely sure who to blame, if anyone. 2. I will 100% defend Christian until the end of days. I respect the fact you at least know his name, assuming that you can in return understand that everything he does is amazing. Yes, some of what he does directly counteracts the weaknesses that are innate to the Apple platform (which should be called out against Apple). His most recent release, for example, offers a "Smart Rotation Lock", which swaps between portrait and landscape depending on whether a GIF or video is playing; something Apple should have built in from day one. Also, he had a volume bar in top-left corner on iPhone X and beyond before Apple even made that standard. IMO everything he does to break the "Apple philosophy" winds up getting adopted by Apple. Christian is that good. 3. Everything I said above, whether already existing at Apple or pushed towards the future, is already better than Windows or Linux. MacOS and iOS are positioned to take over the future of computing, minus one mother-fucking aspect (fuck you, Apple): gaming. Even if Metal is technically superior, vendor-lock at Apple makes Metal worthless vs. DirectX and OpenGL. This is the only thing I am willing to abdicate… Apple+MacOS+iOS needs to figure out how to play nice with cross-platform gaming.

aaronbrethorst 6y ago

Remember that Core Data manages a graph of objects: it’s not a database. 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.

kitotik 6y ago
I always thought that using it as basically the db or cache for remote API was a terrible misuse of CoreData, but a graph of objects does come in handy when driving complex UIs.
- setpatchaddress 6y ago
  It is absolutely a terrible use of Core Data. Raw sqlite or wrappers are fine for that and will be considerably less difficult to debug when something goes wrong.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]

D13Fd 6y ago

I’m looking forward to them eventually supporting Inoreader sync.

Hamuko 6y ago
I'm waiting for Feedly support.
- guywithabike 6y ago
  It's open-source so there's no barrier to adding it, other than opening a Pull Request.
- hylaride 6y ago
  Strangely, the iOS version supports feedly, but the desktop version doesn’t.
  - dewey 6y ago
    That's because it's a small project and they have to prioritize pretty strictly, highly recommend following the blog where he always posts updates. I'm sure it's "just" a matter of time.

minimaxir 6y ago

The relatively new iOS app for NetNewsWire is very good (and free!)

webwanderings 6y ago
What is a good use case of such "free" mobile app if the sync feature is behind a third party paid service? Am I expected to always check my feeds only on my mobile? How useful is that? As much as I would use NNW right away but it isn't really a useful service at this point in time.
- Angostura 6y ago
  I mainly use RSS on my phone, it's useful.
- kemayo 6y ago
  There's in-progress work on supporting other sync services. Most relevantly, there's work on using a CloudKit backend[1], which would effectively be a NetNewsWire-only feed syncer service. [1]: https://github.com/Ranchero-Software/NetNewsWire/issues/491 https://github.com/Ranchero-Software/NetNewsWire/issues/491
- paulcole 6y ago
  It’s very useful to me! The only computer I have is the one I use at work. All iPad at home and NNW is great!
- minimaxir 6y ago
  Hmm? The iOS app can be backed by Feedly, which is free. (supposedly that functionality will go to the desktop version soon.)
  - webwanderings 6y ago
    Feedly is limited with free account. The point I'm making is that NNW should be using its own service to maintain user's "read" states between its desktop and mobile apps. 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.

deleted 6y ago

[deleted]

rvz 6y ago

NetNewsWire is another great example of quality open source Mac applications that don't force my laptop in 100% CPU utilization, especially for RSS readers. 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!

WaltPurvis 6y ago
Wow, I had no idea NetNewsWire had become free and open source. I stopped using it after v3 (because v4 removed some AppleScript functionality I depended on, although I now can't even remember what it was) and completely missed the news that a free v5 had been released, and open source to boot. This is fantastic!

ryanwaggoner 6y ago

I used to use NetNewsWire like 12-15 years ago, so I was surprised to see it pop up here in this excellent article. 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 https://inessential.com/2018/08/31/netnewswire_comes_home

baby 6y ago

I used to use this, but switched to inoreader due to the mobile app and because it was easy to use. Is it time to switch back?

deleted 6y ago
[deleted]
stereo 6y ago
Yes! The NetNewsWire mobile app is great.

dhhwrongagain 6y ago

What does the pizza emoji at the end of the article mean?

jakelazaroff 6y ago
> Make sure, in other words, that performance isn’t just a topping — it’s the pizza.

dirtylowprofile 6y ago

I used to use NNW but one time my 2 year old kid just did a one quick swipe on my phone’s screen while NNW is open and just deleted the whole content. I’m not sure what gesture made it happen but I switched back to Feedly.

Wevah 6y ago
You can shake/three-finger-swipe to undo deletions, though it’s not very obvious.

tedunangst 6y ago

I wouldn't advocate for slower software, but is all of this really necessary for a fast RSS reader? My RSS reader downloads the entire XML file as blob, parses it into an array of structs, then walks over the array looking for new links. It's not particularly slow. I can't imagine it would be worth optimizing this aspect of the code base.

nine_k 6y ago
No optimization is worth the effort before profiling. 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.
- jonstewart 6y ago
  Profiling is good at telling you which parts of your code account for most of the program’s runtime, but that’s it. It can’t tell you whether the performance is reasonable relative to the work done, or whether a totally different approach is necessary. Writing fast code goes well beyond using profilers, in keeping with the article’s thesis.
  - nine_k 6y ago
    Assume you locate a part of code which is 10x as slow as it could be. You make it 10x faster; great! But that part only took 1% of the total perceived processing delay, so the user sees a whooping 0.9% improvement.
- vnorilo 6y ago
  However, you need to have a big picture view or potential optimizations when you architect. The profiler can't save you from slow architecture.
chipotle_coyote 6y ago
I don't know if it's "necessary," but you can really see the speed difference between NetNewsWire and, say, Reeder on the same hardware. It's not that Reeder is slow, it's that NNW is just really fast. > 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.

atonse 6y ago

I still find Reeder to be the gold standard for a really polished reader.

manigandham 6y ago

Any particular reason why this is a local (destop/mobile) app? I use Feedly and performance was never an issue, with the bonus that content and status is synced everywhere.

setpatchaddress 6y ago
The whole point of the app is to provide native macOS/iOS UI. I use Feedly to sync with NetNewsWire on iOS (and will on the Mac once it's supported, supposed to be in next update).
zapzupnz 6y ago
I don't want a website open all the time. I don't want to have to be connected to the internet to read my catalogue of saved articles. I want native performance, not "good enough" or "not really an issue" performance. I want 100% integration with my system; I want AppleScript-based automation. I want my system's accessibility settings to determine how I use the content, not depend on how some website's CSS handles my use cases — not that a lot of websites, particularly SPAs, are made such that VoiceOver can deal with them. Those are my reasons why I'd want a local desktop app, anyway.
SllX 6y ago
Developer preference. Simmons is famous in the Indie Mac world, even though a good portion of his career has been at companies. He’s still most well known as the guy who developed the original NetNewsWire before selling that to NewsGator, a kind of Feedly before Feedly existed, and then after some events I really can’t quite remember, taking it independent again and eventually selling it to Black Pixel who gave it back. I believe they were acquihired a bit after that if I’m remembering correctly (but don’t quote me on that), so it might have been because they knew they were soon to sell. 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.

fouc 6y ago

Imagine if Slack or Discord did any of these at all. Lots of performance gains to be had.

gmueckl 6y ago
How about building a proper native UI first?
- mrzool 6y ago
  That would be the first step in that direction.
dewey 6y ago
These all have a lot more network overhead than an RSS reader that only has to periodically fetch a bunch of xml files. I feel like optimizing these kind of apps is a whole different problem space and a "native" app is probably not going to change that so much.
- jcelerier 6y ago
  Ripcord is a Qt client for slack and discord which uses much less cpu and ram though.
- Cthulhu_ 6y ago
  But they control both server and client, so they could use an optimized protocol over a socket like in the protobuf family. Keep in mind that XML is a weird format in that you take your data, convert it to text, then compress it, transfer it, decompress it, convert it from text back to data, then interpret it. With binary formats these steps are a lot faster and more native to the machine.
  - dewey 6y ago
    RSS readers usually refresh every 15 minutes per default. So it’s number of feeds requests every 15 min which is very low. Compared to Discord and Slack which are permanently polling and streaming. 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.

mikece 6y ago

I just discovered the iOS app for NetNewsWire and I am blown away that it is only 7.5 MB in size! I did Xamarin development for a while; a blank hello world application is about 45 MB. Kudos to the team!

BooneJS 6y ago

RSS applications all have a fixed feature set. Subscribe to feeds, check feeds for updates, organize & sync data for multiple clients, and present user's reading list to the screen. There are several RSS readers that all tick these boxes. 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.