The iOS and Mac markets are almost the same size?(inessential.com)
inessential.com
The iOS and Mac markets are almost the same size?
https://inessential.com/2020/03/27/the_ios_and_mac_markets_are_the_same_siz
118 comments
Apple fan/dev here: he's an old school Mac influencer who got famous for writing the first popular Mac RSS client, and blind to the effects his particular narrative would have on those numbers - it's the same 30,000 people who are hip to Mac blog culture, not independent discovery on two separate platforms
The Venn diagram of people who use BBedit and NetNewswire is roughly a circle.
What am I missing about BBEdit? I’ve tried to get into it a few times and it just seems archaic and weird and less capable vs even my emacs setup, let alone something like Visual Studio Code these days.
I'm a fan of vim, BBEdit, and Visual Studio Code, but "less capable than emacs" describes just about every text editor.
While I'm using VSCode a lot more these days, I still like BBEdit a lot. It's a Mac-native programmer's text editor that manages to remain performant on large files.
I think part of the problem is that in order to make a good programmer's text editor, you need a large community of people who're able and willing to make good plugins for it, and any text editor with a userbase smaller than "half of all linux nerds" isn't going to have enough engineer hours put into all its per-language tooling. Visual Studio Code manages to attract enough developer attention to get people to work on compatible language servers and whatnot, but the granddaddy of all Mac text editors can't attract that much attention.
Plus, I get a _lot_ of mileage out of multiple cursors. Way more than I'd have expected ten years ago.
While I'm using VSCode a lot more these days, I still like BBEdit a lot. It's a Mac-native programmer's text editor that manages to remain performant on large files.
I think part of the problem is that in order to make a good programmer's text editor, you need a large community of people who're able and willing to make good plugins for it, and any text editor with a userbase smaller than "half of all linux nerds" isn't going to have enough engineer hours put into all its per-language tooling. Visual Studio Code manages to attract enough developer attention to get people to work on compatible language servers and whatnot, but the granddaddy of all Mac text editors can't attract that much attention.
Plus, I get a _lot_ of mileage out of multiple cursors. Way more than I'd have expected ten years ago.
> Visual Studio Code manages to attract enough developer attention to get people to work on compatible language servers
Not to nitpick an otherwise good argument, but the whole point behind LSP and language servers are that they are completely editor-agnostic.
A language server which enables great functionality in VSCode should be able to provide the same for other editors too.
Not to nitpick an otherwise good argument, but the whole point behind LSP and language servers are that they are completely editor-agnostic.
A language server which enables great functionality in VSCode should be able to provide the same for other editors too.
I know what you mean but VSCode tends to have the benchmark front-end implementation for any given language server in my experience. Not how it should be, of course.
>"less capable than emacs" describes just about every text editor.
Fair, I think what I meant is that Visual Studio Code has more IDE features than my emacs does (I know it's possible to have more but things seem less stable when I start using LSPs and such), but BBEdit has even fewer than emacs.
Fair, I think what I meant is that Visual Studio Code has more IDE features than my emacs does (I know it's possible to have more but things seem less stable when I start using LSPs and such), but BBEdit has even fewer than emacs.
Personally I keep it around because it can handle opening a 250MB sql dump and searching it fairly quickly. And it’ll do easy multi file searches without all of the overhead an IDE brings, but still has syntax highlighting and character conversion stuff.
Maybe it’s for people like me that have never learned emacs.
Maybe it’s for people like me that have never learned emacs.
BBEdit probably isn't the best choice for code by modern standards, but it's super good at being a fast Swiss army knife for text.
This is a frustratingly hard assertion to defend, at least in very short form, but I've been a technical writer for years now, mostly working in Markdown, and I keep coming back to BBEdit. It's not one huge thing that it does better for me than other editors, it's a collection of little things: every editor has some kind of "open file by name via fuzzy searching" command, for instance, but BBEdit lets me open multiple matching files at once. (Yes, this turns out to be immensely useful for me.) It keeps a search and replace history and lets me save patterns with a meaningful name. Its "multi-file search" window isn't as fast as some other editors, but it's insanely targetable, and again, lets me save my criteria with names (i.e., "All but JSON"). The "Process Duplicate Lines" command lets me easily find "duplicates" defined with a match pattern in a 75,000-line JSON file (don't ask). I can build complex operations up and save them as a text factory. I occasionally do operations with its "Shell Worksheet" capability, sort of a weirdo hybrid between a built-in terminal and a persistent text file. (I also like that every project gets its own persistent shell worksheet and persistent "scratch file," which you can set to be any language type.)
I've tried a lot of other editors over the years, including VS Code, and either they don't have features that I use in my technical writing or they don't, at least to me, implement them as well. And as lame as some people undoubtedly think "it works like a Mac app" is as a feature, well, it's actually kind of refreshing to have a full-featured text editor that does that BBEdit works like a Mac app. It seems almost quaint to have an actual preference window come up in a text editor when you select "Preferences..." these days, but it turns out they're actually really good at, you know, setting preferences. (Modifying keyboard shortcuts is so much nicer in BBEdit than in any other editor I've used.)
Again, for coding, BBEdit has fallen behind the times; the structure is there for it to mostly keep up, but the ecosystem just isn't there and, barring a strange resurgence, probably never will be. Personally, I use MacVim for coding bigger projects now -- although I'll generally use BBEdit for short shell or dynamic scripts if it already happens to be open. But for managing huge honking websites with thousands of Markdown source files -- or even just dozens -- I just haven't found anything that beats BBEdit.
This is a frustratingly hard assertion to defend, at least in very short form, but I've been a technical writer for years now, mostly working in Markdown, and I keep coming back to BBEdit. It's not one huge thing that it does better for me than other editors, it's a collection of little things: every editor has some kind of "open file by name via fuzzy searching" command, for instance, but BBEdit lets me open multiple matching files at once. (Yes, this turns out to be immensely useful for me.) It keeps a search and replace history and lets me save patterns with a meaningful name. Its "multi-file search" window isn't as fast as some other editors, but it's insanely targetable, and again, lets me save my criteria with names (i.e., "All but JSON"). The "Process Duplicate Lines" command lets me easily find "duplicates" defined with a match pattern in a 75,000-line JSON file (don't ask). I can build complex operations up and save them as a text factory. I occasionally do operations with its "Shell Worksheet" capability, sort of a weirdo hybrid between a built-in terminal and a persistent text file. (I also like that every project gets its own persistent shell worksheet and persistent "scratch file," which you can set to be any language type.)
I've tried a lot of other editors over the years, including VS Code, and either they don't have features that I use in my technical writing or they don't, at least to me, implement them as well. And as lame as some people undoubtedly think "it works like a Mac app" is as a feature, well, it's actually kind of refreshing to have a full-featured text editor that does that BBEdit works like a Mac app. It seems almost quaint to have an actual preference window come up in a text editor when you select "Preferences..." these days, but it turns out they're actually really good at, you know, setting preferences. (Modifying keyboard shortcuts is so much nicer in BBEdit than in any other editor I've used.)
Again, for coding, BBEdit has fallen behind the times; the structure is there for it to mostly keep up, but the ecosystem just isn't there and, barring a strange resurgence, probably never will be. Personally, I use MacVim for coding bigger projects now -- although I'll generally use BBEdit for short shell or dynamic scripts if it already happens to be open. But for managing huge honking websites with thousands of Markdown source files -- or even just dozens -- I just haven't found anything that beats BBEdit.
>BBEdit probably isn't the best choice for code by modern standards
Yeah, I think perhaps this is what I'm missing. I'm a software engineer and at minimum in an editor I want syntax highlighting and code formatting (completion is a nicety but still largely a hassle outside of IDEs) and it's just not there for the languages I want to use.
I definitely appreciate the "works like a Mac app" angle, although in many ways it feels more like a Mac app from 25 years than I would like. It doesn't feel modern.
Yeah, I think perhaps this is what I'm missing. I'm a software engineer and at minimum in an editor I want syntax highlighting and code formatting (completion is a nicety but still largely a hassle outside of IDEs) and it's just not there for the languages I want to use.
I definitely appreciate the "works like a Mac app" angle, although in many ways it feels more like a Mac app from 25 years than I would like. It doesn't feel modern.
It's easy to add simple syntax highlighting for new languages to BBEdit -- more so than for other editors [edit: other editors I've tried to do syntax highlighting for, at least!] -- but it doesn't have a very feature-rich highlighting engine. And code formatting is pretty much a dead end, even though I'm fairly sure it would be possible to set it up. (One of the frustrating "what ifs" in the Mac editor world to me is: what if BBEdit's makers had added packages and, better yet, a package manager, to the editor a decade ago? It wouldn't have taken over the world, but it might have helped it stay a lot more competitive.)
As for the modern aspect, I dunno. It doesn't look anything like Atom or VS Code, to be sure (let alone like MacVim or Emacs), but it's hard for me to look at the UI of BBEdit 13 and find anything that makes me go "oh, yeah, that widget right there looks really creaky." It doesn't have a tabbed interface for files, but I actually like its method of having a "currently open documents" list more than tabs. (When I've used VS Code, I configure it to do that, too!)
As for the modern aspect, I dunno. It doesn't look anything like Atom or VS Code, to be sure (let alone like MacVim or Emacs), but it's hard for me to look at the UI of BBEdit 13 and find anything that makes me go "oh, yeah, that widget right there looks really creaky." It doesn't have a tabbed interface for files, but I actually like its method of having a "currently open documents" list more than tabs. (When I've used VS Code, I configure it to do that, too!)
>"oh, yeah, that widget right there looks really creaky."
It's not so much this so much as it is not having the sort of Yosemite-esque translucency (I think vibrancy was the official name?) effect on sidebars and stuff which I've gotten extremely used to.
>One of the frustrating "what ifs" in the Mac editor world to me is: what if BBEdit's makers had added packages and, better yet, a package manager, to the editor a decade ago?
iirc it actually had/has a half-decent package format, but no manager or central repository for packages. The latter two are basically obligatory these days for a solid code editor, in my opinion.
>And code formatting is pretty much a dead end, even though I'm fairly sure it would be possible to set it up.
Really all that I want is a hook to run a shell script on save that runs the current buffer through mix format or rustfmt or whatever. Is that more feasible?
It's not so much this so much as it is not having the sort of Yosemite-esque translucency (I think vibrancy was the official name?) effect on sidebars and stuff which I've gotten extremely used to.
>One of the frustrating "what ifs" in the Mac editor world to me is: what if BBEdit's makers had added packages and, better yet, a package manager, to the editor a decade ago?
iirc it actually had/has a half-decent package format, but no manager or central repository for packages. The latter two are basically obligatory these days for a solid code editor, in my opinion.
>And code formatting is pretty much a dead end, even though I'm fairly sure it would be possible to set it up.
Really all that I want is a hook to run a shell script on save that runs the current buffer through mix format or rustfmt or whatever. Is that more feasible?
> iirc it actually had/has a half-decent package format, but no manager or central repository for packages. The latter two are basically obligatory these days for a solid code editor, in my opinion.
Yes, and yes, and yes. :)
> Really all that I want is a hook to run a shell script on save that runs the current buffer through mix format or rustfmt or whatever. Is that more feasible?
It would totally be possible, with the caveat that this is where you hit the one thing that does look really creaky: BBEdit's native scripting language is AppleScript. You can "attach" scripts to every single menu item, to several kinds of events (including both before and after saving a document), and the script could basically just be a wrapper around a shell script, but AppleScript will unavoidably rear its verbose yet inscrutable face.
Yes, and yes, and yes. :)
> Really all that I want is a hook to run a shell script on save that runs the current buffer through mix format or rustfmt or whatever. Is that more feasible?
It would totally be possible, with the caveat that this is where you hit the one thing that does look really creaky: BBEdit's native scripting language is AppleScript. You can "attach" scripts to every single menu item, to several kinds of events (including both before and after saving a document), and the script could basically just be a wrapper around a shell script, but AppleScript will unavoidably rear its verbose yet inscrutable face.
Going to check it out when I get the chance :)
I think studying old UX paradigms is super useful.
I think studying old UX paradigms is super useful.
perhaps some weird nostalgia thing? I first saw it in... 1998? was at a web dev shop, and most of the Mac people there were all in love with bbedit. it seemed fairly odd and slow (as did most of the Mac stuff they ran), but it might have been one of the only decent text editors around at that time? I wasn't much of a Mac person then (as likely evidenced by my comments above).
For code, you’re probably right it isn’t all that great. But as text editor on the Mac it can do anything.
What Photoshop is to images, BBEdit is to text.
What Photoshop is to images, BBEdit is to text.
As far as flexibility goes, I'd be very surprised if anything can touch Emacs.
>What Photoshop is to images, BBEdit is to text.
Yeah I get all these platitudes and stuff but I have used it and it doesn't seem more flexible than emacs here.
Yeah I get all these platitudes and stuff but I have used it and it doesn't seem more flexible than emacs here.
As, I expect, is the Venn diagram of those that use NetNewswire on macOS and those that use it on iOS.
Pretty sure BBEdit has wider appeal than NetNewsWire. For one thing BBEdit is the only decent text editor on Mac App Store (not that it’s a high bar to clear).
I've switched to CotEditor for lightweight text editing.
Thank you for this. I've been using SublimeText as a text editor but always felt weird since its targeted as a more powerful quasi-ide... This fits the bill nicely for what I want.
The only thing that stops me from using CotEditor is the inability to open a directory rather than individual files.
It sucked less.
Loved that tag line.
Loved that tag line.
Ah, yes, the same crowd that wonders why people won't write native Mac Apps but then rarely acknowledges the documentation is utterly lacking in significant places.
I say this as someone who writes those apps.
I say this as someone who writes those apps.
Not only documentation is lacking, but Apple has the annoying tendency to change their frameworks every few years. Writing a MacOS app is a fight against the constant changes.
Which frameworks? AppKit is mostly stable, even too stable.
Plus the experience of Electron apps is generally superior lately. Look and feel may not be as consistent as the ideal but it generally never was in the first place, even among native Cocoa apps. The web has won on desktop.
> Plus the experience of Electron apps is generally superior lately
Uh, I'm going to hard disagree on that. They take longer to open, they're slower to use, they take up more battery, and they don't behave in a consistent way with the rest of the OS.
Uh, I'm going to hard disagree on that. They take longer to open, they're slower to use, they take up more battery, and they don't behave in a consistent way with the rest of the OS.
I think he meant the developer, not the user experience is better.
Really I was just thinking of VS Code and a vague memory of some other Electron apps I've used in the past, excepting one in particular which I will not name. But VS Code is just great.
VS Code is the proverbial exception that proves the rule. :) It's kind of frustrating that there seem to be so few Electron apps that live up to its standard.
And frankly, on macOS, VSCode isn't even THAT great. The UI certainly doesn't follow platform conventions, the scrolling is janky, and it just feels out of place.
Additionally, I have yet to encounter a single native Cocoa app that has such a strong effect on battery life.
Additionally, I have yet to encounter a single native Cocoa app that has such a strong effect on battery life.
When the developer doesn't have experience with anything but JavaScript...
* I’m practically never so productive that I’m counting seconds for an app to open.
* VS Code is just as quick to use as Xcode, actually more responsive in many actions, demonstrating effectively that it’s the algorithm which must change for a serious speed up
* MBP batteries are laughable in the first place and they’re basically portable desktops that need to stay plugged in all the time
* The rest of the OS hasn’t behaved consistently with itself the whole time I’ve been using it, just like every other OS I’ve used for the past 25 years; consistency was a pipe dream
* VS Code is just as quick to use as Xcode, actually more responsive in many actions, demonstrating effectively that it’s the algorithm which must change for a serious speed up
* MBP batteries are laughable in the first place and they’re basically portable desktops that need to stay plugged in all the time
* The rest of the OS hasn’t behaved consistently with itself the whole time I’ve been using it, just like every other OS I’ve used for the past 25 years; consistency was a pipe dream
> * MBP batteries are laughable in the first place and they’re basically portable desktops that need to stay plugged in all the time
Probably because you’re using so many electron apps. This is not the case in lab testing by MacWorld, etc.
Probably because you’re using so many electron apps. This is not the case in lab testing by MacWorld, etc.
More likely the 7 years straight of full time development I've done on this laptop, constantly running compilers and image editors and browsers. I could complain about those too but in the end, laptop batteries have to support the software that exists, not the software in a hypothetical ideal world.
My Mac (just over three years old) reliably gives me 7+ hours off a full charge if I’m not constantly compiling anything; just reading mail and Hacker News can easily give 10+ hours. I very actively ensure that Electron is never running on my Mac.
I'll second this opinion - when I don't have Chrome running, my 2015 MBP runs forever.
If the thing is 7 (!) years old it’s no wonder the battery is done. That is not an issue with Mac batteries.
Disagree on all points...
"Counting seconds" may mean little to you but by proxy you can look at conversion statistics for web stores vs response time and see a pretty clear correlation
VSCode's 'performance' is the result of an obscene amount of tuning the base framework, far more than most applications would need. Most other Electron apps do not see anywhere near this level of optimization (and they desperately need it).
MBP batteries on a new machine are respectable. Like all li-ion batteries they decay with use
Mac OS apps behave very consistently when they are native. True, Apple's user interface guidelines allow for pretty wide latitude in some areas (like skeumorphism) but all the basic OS/interaction contracts are intact. One can expect menus to behave the same way, file open/save dialogs to behave the same way, and so on.
"Counting seconds" may mean little to you but by proxy you can look at conversion statistics for web stores vs response time and see a pretty clear correlation
VSCode's 'performance' is the result of an obscene amount of tuning the base framework, far more than most applications would need. Most other Electron apps do not see anywhere near this level of optimization (and they desperately need it).
MBP batteries on a new machine are respectable. Like all li-ion batteries they decay with use
Mac OS apps behave very consistently when they are native. True, Apple's user interface guidelines allow for pretty wide latitude in some areas (like skeumorphism) but all the basic OS/interaction contracts are intact. One can expect menus to behave the same way, file open/save dialogs to behave the same way, and so on.
First of all Apple does not follow its HIG in many ways. But even aside from that, the HIG itself changes every few years, sometimes drastically such as the iOS 7 departure. And it takes many apps time to catch up. One example is Apple's own new Mac App Store which doesn't even allow selecting or copying text in app descriptions last I checked.
Apple has definitely been shitting the bed on UI in the past few macOS releases.
The Mac App Store is a fairly well known atrocity which might as well be a Catalyst app for how bad and out-of-place it is.
The ability to copy text from UI labels was never part of the contract. Generally when that happens it was because the label control was some kind of textbox with most of the visual features disbled
From Mac OS X 10.0, labels were simply text boxes with editable set to false, both being NSTextField, and when it seemed reasonable that the user might want to copy it, you used Interface Builder to mark it as selectable.
I mean VSCode is the best Electron app ever made and it still kind of sucks. The median is miles underground.
Consistency is a sliding scale but Electron is a whole new (lower) level. Extremely basic interactions like "the menu bar highlights to acknowledge key equivalents" are missing.
Consistency is a sliding scale but Electron is a whole new (lower) level. Extremely basic interactions like "the menu bar highlights to acknowledge key equivalents" are missing.
In my experience, purely from a UX perspective (both visuals and responsiveness), a hand-crafted macOS app tends to be moderately better than an Electron app, but an Electron app is usually vastly better than a shoddy or cross-compiled native app.
A well-crafted, organic, gluten-free macOS app is generally the best UI and UX experience on any platform, by a mile. Apps that come to mind are Things by Cultured Code and (the as of yet unreleased to the public) Nova editor by Panic.
No Electron app has ever even come close for me, certainly not VSCode that everyone seems to love so much.
Then there's performance...
No Electron app has ever even come close for me, certainly not VSCode that everyone seems to love so much.
Then there's performance...
Agree with the first part.
But I would say the Slack UX, from a visual and performance perspective (not necessarily intuitiveness), is as good as nearly any native Mac app I've ever used. VSCode, from a visual and performance perspective, is better than any native Windows app I've ever used, and also as good as many native Mac apps.
I know people like to gripe about the memory usage and disk space usage of Electron apps, which, fine. But it's a fairly academic complaint. Those things don't honestly affect my experience as a user. The only time an Electron app has ever felt sluggish to me was Atom, fully loaded with plugins (~3 years ago), and I honestly suspect that had more to do with its naive and non-cooperative plugin architecture than with Electron itself.
But I would say the Slack UX, from a visual and performance perspective (not necessarily intuitiveness), is as good as nearly any native Mac app I've ever used. VSCode, from a visual and performance perspective, is better than any native Windows app I've ever used, and also as good as many native Mac apps.
I know people like to gripe about the memory usage and disk space usage of Electron apps, which, fine. But it's a fairly academic complaint. Those things don't honestly affect my experience as a user. The only time an Electron app has ever felt sluggish to me was Atom, fully loaded with plugins (~3 years ago), and I honestly suspect that had more to do with its naive and non-cooperative plugin architecture than with Electron itself.
Strange, I’ve always thought Electron apps felt weird and slow. Slack has improved, but it still wigs out in low network situations.
The Slack UX that crashes and self reloads when you read a conversation and don't click on anything?
> I know people like to gripe about the memory usage and disk space usage of Electron apps, which, fine. But it's a fairly academic complaint.
Whether it's academic depends entirely on how much memory you have, and what else is using that memory. As with most resource-intensive software, you can brute force it with raw specs, but you're left with less computing power than you paid for.
I was watching The Verge's review of the new Macbook Air last night, and they were talking about battery life. I'm paraphrasing, but they said something like: "Apple claims 13 hours of battery life, and you can get that if you live in Safari and other Apple apps. But I'm living my life in Chrome and Slack, and with those apps open I get closer to five hours."
Chrome and Slack are, of course, the same thing.
As strongly as I dislike locked down platforms, situations like this do make me somewhat understand why Apple doesn't allow web rendering engines other than Safari on iOS.
Whether it's academic depends entirely on how much memory you have, and what else is using that memory. As with most resource-intensive software, you can brute force it with raw specs, but you're left with less computing power than you paid for.
I was watching The Verge's review of the new Macbook Air last night, and they were talking about battery life. I'm paraphrasing, but they said something like: "Apple claims 13 hours of battery life, and you can get that if you live in Safari and other Apple apps. But I'm living my life in Chrome and Slack, and with those apps open I get closer to five hours."
Chrome and Slack are, of course, the same thing.
As strongly as I dislike locked down platforms, situations like this do make me somewhat understand why Apple doesn't allow web rendering engines other than Safari on iOS.
The weight of Chrome as a browser and the more general concept of using the web as a desktop app platform are two different things. I think that when most people complain about "electron apps", what they're complaining about is the latter. If you're complaining about the former, I think that's more fair. Although, I do question whether a third-party browser even has access to the APIs that make Safari's efficiency what it is.
What I'd like to see, personally, is for the three major desktop OSes to agree on a "desktop WebView" standard. Then they can use whatever browser internals they want when it comes to launching those web apps. They could even let you pick your own, the same way you can pick your default browser now. This would not only allow people to use desktop safari for their "electron apps" if they want to, it would avoid one of today's major problems which is shipping a whole copy of the browser with each app. Web-based desktop apps would be no larger than native ones, and depending on how the OS handles them they could be roughly as performant.
What I'd like to see, personally, is for the three major desktop OSes to agree on a "desktop WebView" standard. Then they can use whatever browser internals they want when it comes to launching those web apps. They could even let you pick your own, the same way you can pick your default browser now. This would not only allow people to use desktop safari for their "electron apps" if they want to, it would avoid one of today's major problems which is shipping a whole copy of the browser with each app. Web-based desktop apps would be no larger than native ones, and depending on how the OS handles them they could be roughly as performant.
> The weight of Chrome as a browser and the more general concept of using the web as a desktop app platform are two different things.
I understand where you're coming from, but when someone says says "Electron apps are slow resource hogs", they're fundamentally referring to the underlying engine that makes those apps slow. If that engine was fast and light on resources, the complaint wouldn't exist.
Apple _does_ allow developers to use Safari Webviews within desktop apps, but by using Chromium everywhere, developers don't have to deal with cross-browser issues. Case in point: Slack video calls don't work in any web browser other than Chromium, because they don't implement WebRTC properly.
I understand where you're coming from, but when someone says says "Electron apps are slow resource hogs", they're fundamentally referring to the underlying engine that makes those apps slow. If that engine was fast and light on resources, the complaint wouldn't exist.
Apple _does_ allow developers to use Safari Webviews within desktop apps, but by using Chromium everywhere, developers don't have to deal with cross-browser issues. Case in point: Slack video calls don't work in any web browser other than Chromium, because they don't implement WebRTC properly.
> they're fundamentally referring to the underlying engine that makes those apps slow. If that engine was fast and light on resources, the complaint wouldn't exist.
Firstly: in that case you'd have to compare it to the weight of the entire desktop environment. I would bet money that Gnome + your GTK app is not meaningfully lighter-weight than Chrome + an Electron app. It's just that the former has a privileged place in the OS, and is a dynamically-linked dependency instead of a statically-linked one (using those terms loosely).
Secondly: The web itself is not fundamentally slow. People who aren't web developers love to repeat this mantra, but it's simply not true. That's what I'm trying to get to the heart of here:
1) JavaScript is slower than C++, but it's very rare that enough actual work is being done in JavaScript for it to become a bottleneck (on the UI side), even in complex web-apps. Most of the grunt-work, including recalculating layout, is implemented in C++ as part of the browser.
2) Layout calculation can be slow-ish in extreme cases, but that's a direct tradeoff for the benefit of using the world's most advanced UI layout system, which provides real value.
3) Under normal circumstances an entire web page runs in a single thread, which can be a problem when the occasional expensive operation blocks other ones, but Electron gives you several options for moving expensive operations to separate threads. By default the web view runs in a separate thread from the "main" process, and you can spin up workers or even split your UI into separate web views so each panel gets its own thread.
I think the origins of this myth are:
1) Websites have become much slower than they need to be with the increase in JavaScript dependencies. 90% of this is due to ads and analytics, which couldn't care less about their impact on page performance. The rest has mostly to do with the initial load-time of that 1-2MB script, rather than the runtime of the actual JS code.
2) As with any technology that lowers the barriers to making things, there's been a dilution of less-skilled developers putting things out into the world, decreasing the overall perceived quality of the space. But this isn't an indictment of the technology; if anything, it's a complement. It has to be distinguished from the actual merits of the tech.
> but by using Chromium everywhere, developers don't have to deal with cross-browser issues
I think it has more to do with being able to build and ship copies for all systems through a single channel. Building a "first-class" Mac app (a dock icon, hooks into system APIs, etc.) that uses Safari's web view right now would probably mean opening XCode and writing quite a bit of actual Swift as a wrapper around the web UI. People don't want to do that; it defeats a lot of the purpose. My proposal in my last comment would solve this problem.
Firstly: in that case you'd have to compare it to the weight of the entire desktop environment. I would bet money that Gnome + your GTK app is not meaningfully lighter-weight than Chrome + an Electron app. It's just that the former has a privileged place in the OS, and is a dynamically-linked dependency instead of a statically-linked one (using those terms loosely).
Secondly: The web itself is not fundamentally slow. People who aren't web developers love to repeat this mantra, but it's simply not true. That's what I'm trying to get to the heart of here:
1) JavaScript is slower than C++, but it's very rare that enough actual work is being done in JavaScript for it to become a bottleneck (on the UI side), even in complex web-apps. Most of the grunt-work, including recalculating layout, is implemented in C++ as part of the browser.
2) Layout calculation can be slow-ish in extreme cases, but that's a direct tradeoff for the benefit of using the world's most advanced UI layout system, which provides real value.
3) Under normal circumstances an entire web page runs in a single thread, which can be a problem when the occasional expensive operation blocks other ones, but Electron gives you several options for moving expensive operations to separate threads. By default the web view runs in a separate thread from the "main" process, and you can spin up workers or even split your UI into separate web views so each panel gets its own thread.
I think the origins of this myth are:
1) Websites have become much slower than they need to be with the increase in JavaScript dependencies. 90% of this is due to ads and analytics, which couldn't care less about their impact on page performance. The rest has mostly to do with the initial load-time of that 1-2MB script, rather than the runtime of the actual JS code.
2) As with any technology that lowers the barriers to making things, there's been a dilution of less-skilled developers putting things out into the world, decreasing the overall perceived quality of the space. But this isn't an indictment of the technology; if anything, it's a complement. It has to be distinguished from the actual merits of the tech.
> but by using Chromium everywhere, developers don't have to deal with cross-browser issues
I think it has more to do with being able to build and ship copies for all systems through a single channel. Building a "first-class" Mac app (a dock icon, hooks into system APIs, etc.) that uses Safari's web view right now would probably mean opening XCode and writing quite a bit of actual Swift as a wrapper around the web UI. People don't want to do that; it defeats a lot of the purpose. My proposal in my last comment would solve this problem.
In user interface, sure. Performance-wise Electron usually loses even to things like GTK.
Every GTK app I've ever used that didn't come with the OS (granted, I've never actually paid for one) is, compared to most electron apps, a) ugly/buggy, and b) feature-anemic, because it's so much less easy to add features to it. And as a user, I've never noticed a performance difference. I know Electron uses more memory and such, but it just doesn't impact actual usage in my experience. Whereas things not getting implemented because of developer friction absolutely does.
The fact that Electron apps try to always fit everything into one window is an antipattern for many kinds of applications. Just try using MS Teams and you'll find yourself constantly switching between different modes (a call mode and a chatroom mode for example), while in Skype for Business (which was admitedly terrible in many other ways) they were just two separate windows.
> Yes, the iOS app has more downloads, and it got there in only a few weeks. But if the iOS market were so much larger than the Mac market, you’d have expected this to happen within a day or two of launch day.
Based on what logic? Everything about this article feels like it's based on vague and incorrect assumptions.
Based on what logic? Everything about this article feels like it's based on vague and incorrect assumptions.
I feel like being on Hacker News sometimes warps the context of a personal blog post.
If I put out a tweet that said "Huh, my app got about the same number of downloads on iOS and Mac, I think the market's about the same for certain types of apps" would you say my tweet is full of vagaries and incorrect assumptions?
If I put out a tweet that said "Huh, my app got about the same number of downloads on iOS and Mac, I think the market's about the same for certain types of apps" would you say my tweet is full of vagaries and incorrect assumptions?
sometimes warps the context of a personal blog post
That's true but those blog posts end up making poor HN posts. This one is very short, contains a little bit of data and would not have been hn-noticed other than for the deliberately provocative title which then becomes the central topic of the HN discussion. People familiar with the author/blog don't have any trouble recognizing their chain is being playfully tugged; on HN it's just a bombastic one-liner sitting on the front page, demanding rebuttal.
A lot of tweets that are perfectly fine tweets make bad HN posts for similar reasons.
That's true but those blog posts end up making poor HN posts. This one is very short, contains a little bit of data and would not have been hn-noticed other than for the deliberately provocative title which then becomes the central topic of the HN discussion. People familiar with the author/blog don't have any trouble recognizing their chain is being playfully tugged; on HN it's just a bombastic one-liner sitting on the front page, demanding rebuttal.
A lot of tweets that are perfectly fine tweets make bad HN posts for similar reasons.
I’ve had my personal blog be linked on HN without my knowledge and the comments damn near made me stop writing altogether. Everyone assumed I wrote the post for them to read it, when in reality I just wrote it for myself and someone else submitted it.
the difference between your hypothetical tweet and this article is that humble qualifier "I think".
what I've seen hn (and startup culture in general) distort is people's confidence in their own opinions. this is probably because it is repeated ad nauseum that you cannot start a successful startup without being an iconoclastic innovator.
what isn't repeated ad nauseum is that you should save that kind of arrogance for your vc pitch rather than take it on as a mantle.
what I've seen hn (and startup culture in general) distort is people's confidence in their own opinions. this is probably because it is repeated ad nauseum that you cannot start a successful startup without being an iconoclastic innovator.
what isn't repeated ad nauseum is that you should save that kind of arrogance for your vc pitch rather than take it on as a mantle.
One of the first things I learnt in English 101 is that "I think" is redundant.
Your writing something automatically implies that it's what you think.
Unless you explicitly say something is a "fact" or quote a 3rd party.
Your writing something automatically implies that it's what you think.
Unless you explicitly say something is a "fact" or quote a 3rd party.
Linguists call "I think" when used this way a "stance marker"[0]. It's definitely not redundant: it reveals pragmatic information[1] about the context you're speaking in, namely by tempering your stance and revealing your level of confidence in the statement you're making.
See this for example: https://www.tandfonline.com/eprint/SC59wwEkK64tvQsDb9hC/full
[0] Here, "stance" means: https://en.wikipedia.org/wiki/Stance_(linguistics)
[1] For more info, see here: https://en.wikipedia.org/wiki/Pragmatics
See this for example: https://www.tandfonline.com/eprint/SC59wwEkK64tvQsDb9hC/full
[0] Here, "stance" means: https://en.wikipedia.org/wiki/Stance_(linguistics)
[1] For more info, see here: https://en.wikipedia.org/wiki/Pragmatics
"I think" is not always redundant. It serves the same purpose as "in my opinion" or "I'm pretty sure", which is to temper the confidence of the statement or indicate an unverified intuition.
Example:
"Hey, where's the emergency toilet paper supply?" "I think it's in the cupboard under the stairs."
I think (but am not sure!) that this use of "I think" is intuitively obvious to most native English speakers, especially when paired with voice tone.
Obviously, if you're sure that a statement is true, then adding "I think" only weakens your point. Unskilled writers might not know to avoid it in (say) an essay, which may be why you heard that advice in school.
Example:
"Hey, where's the emergency toilet paper supply?" "I think it's in the cupboard under the stairs."
I think (but am not sure!) that this use of "I think" is intuitively obvious to most native English speakers, especially when paired with voice tone.
Obviously, if you're sure that a statement is true, then adding "I think" only weakens your point. Unskilled writers might not know to avoid it in (say) an essay, which may be why you heard that advice in school.
Then let's hope you did not end at 101
Q: What's the best phone out there buddy?
A1: The iPhone Super Max
A2: I think it is Samsung S20, but there are several options out there
A3: I think it is the iPhone Super Max, though i agree, there are plenty of competing options around.
--
"I think" is very important in establishing/shaping context and clarifying the source of the opinion you are referring to.
Q: What's the best phone out there buddy?
A1: The iPhone Super Max
A2: I think it is Samsung S20, but there are several options out there
A3: I think it is the iPhone Super Max, though i agree, there are plenty of competing options around.
--
"I think" is very important in establishing/shaping context and clarifying the source of the opinion you are referring to.
It is not always redundant. It can be used to politely signal that you may be wrong about something you are asserting, even when you are sure about it and everyone knows you are sure. This is especially helpful when you have visible authority over the other parties in the discussion.
I was taught this too, but it was more of a guideline for students who got away with writing basically substandard essays in high school. It was like having to teach Javascript the Good Parts to kids that just started every sentence in a paragraph with ‘I think that ...’.
i meant exactly what i said: it's a humble qualifier . "I think" functions as an admission of fallibility. it transforms a certain claim into a proposition subject to change. its purpose is rhetorical rather than formal.
Quoting the linked article: "I've thought for a long time that, for some types of apps, a Mac app would do as well as an iOS app." Isn't it pretty clear that when he's asserting that the relative downloads of NetNewsWire for iOS vs. macOS "confirms" that thought, he's (a) describing that as his thought, rather than trumpeting it as an immutable fact, and (b) both admitting that this is just one piece of data ("admittedly just one app") and confining even his hypothesis to "some types of apps"?
tl;dr: I get what you're saying, but I think you're giving too ungenerous a reading in this specific case.
tl;dr: I get what you're saying, but I think you're giving too ungenerous a reading in this specific case.
I don't know about that... I think the only conclusion you could draw from this might be that the market for iOS and Mac _RSS readers_ are almost the same size. You might even be able to stretch it to say they are the _same_ market.
I wouldn’t even draw that conclusion. NetNewsWire is very old school with an old fan base, and outside its existing fan base I don’t think it’s particularly relevant today (sorry). I doubt a user new to RSS or new to RSS reader on Apple platforms today would land on NNW.
(I’m a longtime Reeder user.)
(I’m a longtime Reeder user.)
Being a heavy, long-time RSS user and having tested both the macOS and iOS app of NNW, I think you’re wrong. NNW it’s incredibly well-done, fast and polished, and it’s the best RSS app I’ve ever used, and I’ve used plenty. It’s not unrealistic to think it will become successful and relevant, maybe even contribute to a resurgence of RSS and bring in new users, given enough time.
The new NNW is a total rewrite which started off as a different app.
Kinda. The original NetNewsWire was made by the same guy behind the current NetNewsWire. It's just that there was a period in between where NetNewsWire was owned and developed by someone else.
Same guy. 100% different project. He required the NetNewsWire name well after the start of this new open source RSS reader.
If it does the same thing and has the same name and creator, is it really a different project? Many software releases are actually complete rewrites under the hood.
The only reason what became Net News Wire 5 originally had a different name is because NNW was owned by BlackPixel at that point.
The only reason what became Net News Wire 5 originally had a different name is because NNW was owned by BlackPixel at that point.
>If it does the same thing and has the same name and creator, is it really a different project?
Yes? I don't even understand how this is a question.
>The only reason what became Net News Wire 5 originally had a different name is because NNW was owned by BlackPixel at that point.
From the post announcing the new name (https://inessential.com/2018/08/31/netnewswire_comes_home):
>You probably know that I’ve been working on a free and open source reader named Evergreen. Evergreen 1.0 will be renamed NetNewsWire 5.0 — in other words, I’ve been working on NetNewsWire 5.0 all this time without knowing it!
There's no evidence there is supposed to be continuity between the projects other than the name changing. You can say it's old school but the entire thing is written in Swift to modern UI standards. Not sure what more you could ask for.
Yes? I don't even understand how this is a question.
>The only reason what became Net News Wire 5 originally had a different name is because NNW was owned by BlackPixel at that point.
From the post announcing the new name (https://inessential.com/2018/08/31/netnewswire_comes_home):
>You probably know that I’ve been working on a free and open source reader named Evergreen. Evergreen 1.0 will be renamed NetNewsWire 5.0 — in other words, I’ve been working on NetNewsWire 5.0 all this time without knowing it!
There's no evidence there is supposed to be continuity between the projects other than the name changing. You can say it's old school but the entire thing is written in Swift to modern UI standards. Not sure what more you could ask for.
> Yes? I don't even understand how this is a question.
Well that's where we philosophically disagree I guess. To me, version 10 of Mac OS is still the continuation of version 9 of Mac OS, even though they're fundamentally different systems under the hood.
Well that's where we philosophically disagree I guess. To me, version 10 of Mac OS is still the continuation of version 9 of Mac OS, even though they're fundamentally different systems under the hood.
>To me, version 10 of Mac OS is still the continuation of version 9 of Mac OS, even though they're fundamentally different systems under the hood.
Sure, and it carries over certain parts and leaves out others. Substantially similar? I'll buy that. Arguably the same thing, ontologically? I think that's a lot harder to prove, which is what the OP I replied to was saying.
Sure, and it carries over certain parts and leaves out others. Substantially similar? I'll buy that. Arguably the same thing, ontologically? I think that's a lot harder to prove, which is what the OP I replied to was saying.
In this case, the major version of the software was increased (ie. NetNewsWire 5.0).
Or the Mac market is so much smaller that the iOS market that there is practically no competition for an in-demand RSS reader on Mac and barely any space to enter the market on iOS.
Isn't that weird though? Isn't reading the news the sort of thing you'd do on your phone more often than your computer?
This was my first thought. Especially as I would guess that Mac users who use RSS readers are extremely likely to have both Macs and iPhones and install their RSS reader on of them.
(I fall in to this bucket.)
(I fall in to this bucket.)
RSS readers are a very specialized market. Around me, only techies and nerds have heard of it. Mobile Natives haven't and are using FB/I/Twitter instead (sad !).
So this boils down to th enerd market on iOS and MacOS is the same size. I'd go one step furter: it's probably not only the same size, but, simply, the exact same.
> And, given that Mac apps are less complex to write than iOS apps these days, a Mac app could be more profitable than an iOS app.
And you can charge more for a Mac app.
And you can charge more for a Mac app.
> given that Mac apps are less complex to write than iOS apps these days
Do you agree HN?
Do you agree HN?
I write both: iOS during the day and macOS at night. iOS is significantly less buggy and has less legacy baggage than macOS. iOS has some features that macOS doesn't, so there is more to learn. I spend a lot less time working around platform brokenness on iOS than on macOS. macOS lets you do a lot more than iOS in ways that are unmaintainable (e.g., private APIs), which helps you create accidental complexity for yourself.
Both platforms have a long tail of little-known behaviors (such as accessibility features) that make it hard to create well behaved applications. But iOS mostly just works (once you know which features are toxic and avoid them), while macOS's brokenness has completely metastasized.
Both platforms have a long tail of little-known behaviors (such as accessibility features) that make it hard to create well behaved applications. But iOS mostly just works (once you know which features are toxic and avoid them), while macOS's brokenness has completely metastasized.
I’m curious which features you would advise a dev to avoid in iOS, because their problems, i.e. toxicity. I’m getting more into iOS programming and it would be great to know some pitfalls on the roadmap.
Anything added after iOS 6 is the cheeky answer, but it’s not totally wrong either. Auto layout is incredibly hard to debug; it’s great when it works right, though, fwiw. The audio APIs are a garbage fire (equally on both platforms, at least!) Mapkit has a lot of sharp edges if you try to do anything more than Apple envisioned, which is true of a lot of iOS and macOS APIs. View controller transitions are a mess, but they may have fixed the bugs by now—I’ve stayed away since being traumatized by them five years back. The Metal shader compiler is an absolute shit show of bugs on the Mac, but is better on iOS. Core Bluetooth has caused me pain (just doesn’t work sometimes). Stringly types objective c-isms like KVO. In app purchases are a mess (I’m told, haven’t used it myself). CoreData might look like a good idea but you will live to regret it if it’s an important part of your app. UITableView is really powerful but also gets complex fast, with legacy baggage showing up when you try to get fancy (like auto layout and dynamic row height). The security API is hard to use correctly, also on both platforms.
Mostly though Xcode is the worst piece of software I’ve ever used, besides Wind River’s IDE and Windows ME.
Mostly though Xcode is the worst piece of software I’ve ever used, besides Wind River’s IDE and Windows ME.
No I don't agree. I have written both. Based on that I think the issue of which is easier to program depends more of the complexity of the app than on the platform. I will admit there are times that macOS feels more like a hell-hole of a poorly though out or incomplete programming environment.
IMHO react native makes the latter less complex (for those with JS experience only)
The way I understand it is that you can reach roughly the same amount of users on both marketplaces, which goes to show just how horrible discoverability is on the iOS store.
>News reading is probably more of an iOS thing than a Mac thing in general
I think that is where the assumption gone wrong. News Reading /= RSS. I mostly consume Social Media on my Mobile. Or easy to read, digest, bite-size information. Easily hoping on and off in the timeline. My RSS feed is none of that, for me it tends to require more focus and longer time to digest. Hence I never do any RSS reading on mobile.
I think that is where the assumption gone wrong. News Reading /= RSS. I mostly consume Social Media on my Mobile. Or easy to read, digest, bite-size information. Easily hoping on and off in the timeline. My RSS feed is none of that, for me it tends to require more focus and longer time to digest. Hence I never do any RSS reading on mobile.
Markets for RSS app developers^
[deleted]
[deleted]
Any iOS app has a ton of competition within its category for a many-times larger audience. Any macOS app has very little competition for a tiny audience. 36k downloads can mean that you've captured a larger audience on one platform than the other, and that seems more reasonable than the conclusion that the audience sizes are the same.
Discoverability is horrible on the iOS App Store. I have looked for a good RSS reader on there in the past and only been served shovelware.
I found out about NNW from DF the other day. Even after using and installing it, it is nowhere to be seen when I search for RSS.
Apples broken App Store system surfaces cheap crappy apps. Apple wants users to make impulse purchases so they can skim 30% off the top. It’s a bad experience and is doing tremendous long term damage. Steve Jobs would be pissed.
I found out about NNW from DF the other day. Even after using and installing it, it is nowhere to be seen when I search for RSS.
Apples broken App Store system surfaces cheap crappy apps. Apple wants users to make impulse purchases so they can skim 30% off the top. It’s a bad experience and is doing tremendous long term damage. Steve Jobs would be pissed.
> Steve Jobs would be pissed
Discoverability on the App Store has always been horrible.
That, and App Store performance (search, page load, etc) are high on the list of things that baffle me most about Apple.
These are not hard problems to fix. There is no incentive to not fix them. Customers are suffering. FTFAS.
Discoverability on the App Store has always been horrible.
That, and App Store performance (search, page load, etc) are high on the list of things that baffle me most about Apple.
These are not hard problems to fix. There is no incentive to not fix them. Customers are suffering. FTFAS.
I can't even remember where App Store hides the search button every time I look for an app (which I have to do because iOS provides no other way to search for an app already installed on my device)
> There is no incentive to not fix them.
I think there is an incentive not to. If you buy Apple hardware, you are stuck with these stores. They know you will complain but ultimately comply and accept.
I think there is an incentive not to. If you buy Apple hardware, you are stuck with these stores. They know you will complain but ultimately comply and accept.
That makes no sense. Wouldn't Apple want you to download as many apps / spend as much money on new shiny things as possible?
I think it's just incompetence.
I think it's just incompetence.
you mentioned zero incentive.
no incentive to fix =/= incentive to not fix
no incentive to fix =/= incentive to not fix
You gotta control here for variables, hon.
Actually, when Apple launched the Airbuds, I computed that it was very likely the AirBuds would generate more profit for Apple than Mac hardware.
IIRC assuming 70% profit on the Airbuds and 30% on the Mac (because lots more R&D, lots more support, lots more warranty, lots more dev...), a 30% attach rate made the Airbuds more profitable.
IIRC assuming 70% profit on the Airbuds and 30% on the Mac (because lots more R&D, lots more support, lots more warranty, lots more dev...), a 30% attach rate made the Airbuds more profitable.
# Air Bud
* Budget $3 million
* Box office $27,771,629
# Air Bud: Golden Receiver
* Budget $11 million
* Box office $10,224,116
Air Bud: World Pup, Air Bud: Seventh Inning Fetch and Air Bud: Spikes Back are direct-to-DVD movies, so we don't know about their box office performance, sadly.
* Budget $3 million
* Box office $27,771,629
# Air Bud: Golden Receiver
* Budget $11 million
* Box office $10,224,116
Air Bud: World Pup, Air Bud: Seventh Inning Fetch and Air Bud: Spikes Back are direct-to-DVD movies, so we don't know about their box office performance, sadly.
Um, what has this got to do with this article?
Let's just assume AirPods did make 3x more Net profits than Mac.
AirPod ASP is roughly ~$169, Mac ASP is roughly ~$1300, AirPods would still need to sell roughly 2.6 times more for it to be more profitable than Mac. That is 46M to 50M AirPod per year.
Even the most optimistic estimate of AirPod sales fall far below that number.
Let's just assume AirPods did make 3x more Net profits than Mac.
AirPod ASP is roughly ~$169, Mac ASP is roughly ~$1300, AirPods would still need to sell roughly 2.6 times more for it to be more profitable than Mac. That is 46M to 50M AirPod per year.
Even the most optimistic estimate of AirPod sales fall far below that number.
AirPods