Live data from Hacker News

The iOS and Mac markets are almost the same size?

inessential.com

101–110 of 120 posts

Re: The iOS and Mac markets are almost the same size?

#101
post #100

Earlier quoted context omitted.

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.

>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 worki…

> 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.

Re: The iOS and Mac markets are almost the same size?

#102

Earlier quoted context omitted.

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 nee…

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.

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

Re: The iOS and Mac markets are almost the same size?

#103
post #96

Earlier quoted context omitted.

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...

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 a…

> 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.

Re: The iOS and Mac markets are almost the same size?

#104
post #29

> given that Mac apps are less complex to write than iOS apps these days Do you agree HN?

Author is probably thinking about an Electron App. Otherwise I don’t see how that statement could be true.

Brent Simmons is definitely not talking about an Electron app.

Re: The iOS and Mac markets are almost the same size?

#105
post #99

Earlier quoted context omitted.

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 t…

>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'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!)

Re: The iOS and Mac markets are almost the same size?

#106
post #96

Earlier quoted context omitted.

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 a…

> 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 revi…

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.

Re: The iOS and Mac markets are almost the same size?

#107

Earlier quoted context omitted.

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…

> 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.

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.

Re: The iOS and Mac markets are almost the same size?

#108

Earlier quoted context omitted.

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.

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.

Re: The iOS and Mac markets are almost the same size?

#109
post #99

Earlier quoted context omitted.

>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'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 i…

>"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?

Re: The iOS and Mac markets are almost the same size?

#110
post #106

Earlier quoted context omitted.

> 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 revi…

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 wh…

> 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.

Post reply on HN