Hacker News Reader

The majority of users leverage these technologies for a reason. If you use cross-platform technology you can simply reach a broader audience and in the case of a commercial product, generate more revenue with only minimal additional effort. From my personal experience users don't care at all if the app has a native look or not, as long as the app looks decent and works. I assume having the native UI components of an OS is a very specific requirement, that does not apply to the vast majority of users. In fact, the majority of users likely prefer having the same, highly customized UI of an application, rather than having a completely different looking app when switching platforms. Take Visual Studio Code as an example. Within a few years, this editor became one of the most popular code editors. The app uses mainly web technology and a browser window and does not look like a native application at all, yet for the majority of users, it feels like a very fast native application.

Why do you say that "VSCode does not look like a native app at all?" It has a Mac menu bar, context menus, drag and drop, familiar key equivalents. It's not a completely foreign experience like (say) vim.

Achieving these things has required heroics on Microsoft's part. Very few other electron apps go to those lengths.

Users switch between applications far more often than they switch OSes. Native behavior allows users to bring expertise from one app to another. I'd be productive more quickly with Chime, because I already speak its UI vocabulary.

Native menu bar and context menus are very much built into Electron, even Hello World will have a proper menu on macOS. Some of the stuff like integrated title bar is also pretty recent, and likely wasn’t a contributing factor to its adoption.

Not to say VSCode doesn’t put any effort in or anything but I think Electron apps are about on par with Qt apps in terms of native look and feel, albeit they have their own strengths and weaknesses and are not easy to directly compare.

> From my personal experience users don't care at all if the app has a native look or not, as long as the app looks decent and works.

The same can be said of Windows (that users don’t care about the user experience). But the users may just not be aware of choices or may have things foisted on them for various reasons. That doesn’t necessarily mean they don’t care for a good experience. This also depends on the platform and the age group of users. It’s possible that younger users and/or those on Windows don’t care much about annoyances or just give up thinking that this is what a computing experience will be. Users on the Mac, especially those who’ve used it extensively (and learned) are more likely to realize and talk about non-native apps. It’s the same reason why hardcore Mac users have panned the newer “Catalyst” apps from Apple in macOS.

> Take Visual Studio Code as an example. Within a few years, this editor became one of the most popular code editors.

Well I wouldn't expect normal users to even consider downloading VSCode in huge numbers. There isn't a reason for them to do so, but developers will and only should care about building and get things done. User experience is different for the type of user. Developers will make this judgement if a tool gets in their way, prevents them from working or forces them to Google the issue and fix it themselves.

Perhaps Slack and Discord are better examples of apps that normal users are expected to download in large numbers. They won't care on how it looks, but they will start to question why their laptops are burning on the laps and their fans at full speed. If you run a browser + electron combo then the computer is likely to be reduced to crawling speed which negatively affects the user experience.

> The majority of users leverage these technologies for a reason. If you use cross-platform technology you can simply reach a broader audience and in the case of a commercial product, generate more revenue with only minimal additional effort.

I understand the reason. I also understand the productivity/audience argument, since I also have done web-dev. It's just that it's suboptimal, and I expected at least some people to develop native apps.

> From my personal experience users don't care at all if the app has a native look or not, as long as the app looks decent and works. In fact, the majority of users likely prefer having the same, highly customized UI of an application, rather than having a completely different looking app when switching platforms.

No, it's not. Unless you're targeting Windows where nobody knows the advantages because nobody has ever seen a consistent application. People used to consider whether the app is Carbon or Cocoa in the early days of OS X; just because Carbon had a suboptimal integration compared to Cocoa (even when the two frameworks are both from Apple).

> Take Visual Studio Code as an example. Within a few years, this editor became one of the most popular code editors. The app uses mainly web technology and a browser window and does not look like a native application at all, yet for the majority of users, it feels like a very fast native application.

VSCode is a successful product in spite of being a electron app, not because of it. It doesn't feel native at all, and I know many people complaining about it. I expect many people to pass over when a native-based app that has a similar feature set with VSCode gets released.

(One can have a contrary opinion that the web-based architecture allows VSCode to develop more features than native; but in my experience, today's native app development isn't really that hard anymore. It has a similar barrier level.)

Been using Visual Studio Code recently for an embedded ARM project.

It's the only electron application I've seen that's not dog-slow.

Guessing most other developers don't put in the needed effort to make their Electron apps decent?

Matt here - developer and member of the team of two that works on Chime. Thanks for your kind words. There actually are a lot of Cocoa-based editors out there, but to my knowledge, Chime is the only one that puts such a large emphasis on language-level support. We intend to continue to focus on that going forward.

To be honest, I think the multi-platform products available today are super-compelling. One of the reasons they are so immensely popular. But, I'm glad you're into what we're doing :)

> but to my knowledge, Chime is the only one that puts such a large emphasis on language-level support. We intend to continue to focus on that going forward.

Thanks for developing this great product! I'm so thankful for your efforts for integrating your app with AppKit (like - being basically the only editor that supports AppKit tabs which... AFAIK even Safari doesn't). I mean -- I'm compelled to learn Go trying to justify buying this :-)

By all means please continue this effort; and if possible, consider add support for other languages. By looking at your blogposts it seems it's running LSP under-the-hood for completion; by leveraging LSP, I hope Chime can gain multi-language support. That would basically justify a hundred dollars at least for me.

Thanks.

I'm just really happy that you're excited!

I've covered this elsewhere, but other languages aren't going to be an immediate focus for us. Possible, but even with LSP it's a lot of work to do something well. And, we still have tons of room for improvement just with Go.

Safari uses a custom implementation because its tabs predate AppKit's, but I'd like to think that the AppKit one is heavily inspired by Safari's. By the way, Sublime Text supports these (though it's a bit strange how they've implemented it).

Will Chime always be an Editor specially for Go only?

Also wondering on what motivate you to write an Editor in the first place?

Even though I dont use Go I will keep an eye on it. Simply because it looks brilliant.

It's a lot of work to support a language well. Our intention is to focus on Go for now, but we're open to others in the future.

Lots of reasons for building an editor, but mainly our technical backgrounds with compilers and macOS apps felt like a good combination. Also, there aren't many (any?) macOS-native editors with deep language integration, so it really felt like an under-served market.

Sounds like you're the target market for Panic's upcoming macOS-exclusive Nova Editor.

https://panic.com/nova/

Actually I'm already a Nova beta-tester... Surprise! :-)

Have you ever tried BBEdit[+]? I primarily use Emacs (preferring to run it in iTerm2) and VS Code, but BBedit is rarely not open in my dock and for some tasks I find it indispensable, e.g. complex search/replace in big plain text files. BBEdit's interface is definitely native and ultra responsive.

Even though I use it only about 5% of the time I spend on programming-related tasks, I have been very happy over the years to pay for upgrades to the latest major version of BBEdit.

[+] https://www.barebones.com/products/bbedit/

Chime team member here.

BBEdit is an incredible text editor. If you are working with text on macOS, it's hard to beat. But, I've struggled to use it for even basic programming work. It's just not built for that specific use case so much as general text manipulation.

That's fair, and I generally agree.

For core programming work I found Vim/Emacs superior to BBEdit, and ultimately settled on Emacs because of Magit[+] and my proclivity for Lisp/Scheme. I switch to VS Code when I need/want to use its JS debugger combined with its "cadillac experience" re: TypeScript and JavaScript.

Even so, depending on the use case, giving BBEdit a shot is probably worth the download and time spent — it's a great dev tool and I've never regretted paying for the license and upgrades. For example, BBEdit has been invaluable to me in recent years when trying to sort out broken webpack builds and I needed to efficiently hunt through multi-MB .js output files.

[+] https://magit.vc/

BBEdit was my editor of choice back in the day before I went on the search where I ended up using Vim.

How'd you manage that? I must've missed something, I've owned every single product Panic has put out and never got any marketing emails about it :(. How's it been?

> How'd you manage that?

Well... Nova was getting beta-testers when I was searching for editors. I thought Nova would be great, so I decided to beta-test right away.

> I must've missed something, I've owned every single product Panic has put out and never got any marketing emails about it :(.

I'm pretty sure Panic didn't send marketing emails for a closed beta test; it was a little buggy back then when it first started.

> How's it been?

Well, it's Panic; so you can trust the app quality. I stopped using it because the autocomplete for JS wasn't really great as it lacked a proper LSP client at the moment; there were tools (extension APIs) to trivially connect Nova to a LSP server, but I didn't have enough time to play around with writing extensions.

I think it now gained out-of-the-box LSP support; would be sufficient for now.

Edit: I tried it again, and out-of-the-box LSP support for JS still doesn't look like it exists; jump-to-definition is not working :-(

Does Nova support LSP? Their marketing page doesn't mention it so I've always wondered.

They do. There are extension APIs which allows you to trivially connect to a LSP server, but last time I tried out-of-the-box support didn't exist. (Edit: it still doesn't exist)

There is some more info here: https://novadocs.panic.com

LSP support extension documentation is here: https://novadocs.panic.com/api-reference/language-client/

We're also super curious about this. We started Chime when Coda (pre-Nova) was all but abandoned. Panic is probably the best/worst competitor you can have for a macOS app, but we're very excited to see what they do. I'll probably lose sleep checking it out when I'm finally able to.

Checking out https://novadocs.panic.com/api-reference/language-client/ would help. It's the extension API documentation to connect LSP servers... but out-of-the-box JS LSP support doesn't yet exist. (Not sure about other languages though)

Edit: Python looks like LSP is working. This is a simple demo GIF: (warning - very big(23MB).) https://s5.gifyu.com/images/nova-python-demo.md.gif

Oh wow this is fascinating! It would have been pretty crazy to not use LSP, so that's good to see. Looks incredibly customizable, with a JS API. Definitely going to be popular!

> It was really disappointing to find that nobody developing the developer tools really consider user experience or nativeness

I understand the perspective around several editors that look alien and feel less native and don't use the Cocoa UI for its GUI. TextMate, CodeRunner and Coda-like apps which are still around are probably the great examples for great macOS apps for developers. UI consistency matters but matters less to a 'developer' as they usually have access to powerful machines and the Electron-cost wouldn't hit them that much and just want to get the work done. But for normal users, both consistency and user experience matter, which you have highlighted in your flutter arguments, but depending on the platform flutter targets, it varies.

Mac and Windows provide a consistent UX which is why it is straightforward for developers to look at one native GUI toolkit to write apps like Chime that look native on their platforms. I find it hard to see why Linux also could not have some native apps on their platform too. Perhaps its the multiple choices of alternative GUI stacks or the lack of a consistent desktop environment which makes it difficult for users to expect a predictable experience with their apps. I don't know.

I'd rather have more native apps altogether cross-platform or not and less of Electron-based apps on my MacBook. Or even better: An open-source OS that has a consistent GUI and SDK that benefits users and developers.

Not defending Electron, but Cocoa is an OS-specific, proprietary framework. It makes sense why most text editors (which are mostly libre software) wouldn't use it. I do have to ask, though: why not just use TextMate, at that point?

i dont know if textmate has this deep level of support, akin to an IDE (with autocompletion, parameter checking etc).

Chime team member here.

That's one reason exactly. TextMate is a phenomenal piece of software, and I've used it for years. Will continue to use it probably. In many ways, it was an inspiration for Chime. It can do many things Chime cannot. But, TextMate does not offer the same language-level support, syntax highlighting accuracy and speed. And, I like to think Chime has a more refined UI, but that's a personal thing :)

Is Qt sufficient? I think it does a great job of native behaviours on macOS (certainly better than Electron).

LiteIDE is a fast, native, FOSS IDE for Go: https://github.com/visualfc/liteide/releases/tag/x36.2

It supports highlighting, autocompletion, jump to definition, refactoring, cgo, vet, etc for both module and non-module projects.

I use this on Windows and Linux and prefer it over vscode - the tooling integration always seem to work more reliably for me,

Nah, Qt isn't; It's much better than electron (where nothing is consistent) but it's still distinguishable with it's non cocoa-text fields. I remember being annoyed that my custom keybindings in textfields don't work for some Qt based app.

(This seems to be https://bugreports.qt.io/browse/QTBUG-393 ).

> Today deceloper tooling is almost all electron/Qt/custom-framework based cross-platform;

Sublime Text comes to mind as an app that is native as well.

No, Sublime Text was one of the apps in mind when I said a custom-framwork based cross-platform (or homemade might been a better phrase).

I evaluated Sublime for my editor, and found that it’s OS integration was too bad; for one it’s tabs is custom-based and it’s text fields aren’t Cocoa (or at least it doesn’t feel like one). It’s primarily built as a cross-platform, so it really doesn’t consider OS integrations IMO.

You know, even TextMate appears to use a custom tab implementation.

And, it was a huge amount of work to get the AppKit tabs to work in Chime, even though they are supplied by the framework. All the NSWindod tabbing stuff just wasn't built to be flexible for apps that need consistent UI across tabs, like our file navigator widget.

Have you tried textmate? I used that for a lot of years and it was 100% cocoa focused.

Yeah, actually I did, and it was pretty decent; I really considered it seriously back then. I think I found the completion a bit limiting; I would like LSP running with it's context-based completion. It's non-cocoa based tabs were also not my preference; though that wasn't a dealbreaker for TextMate though.

I share what you feel as I (as a user) love native apps too but the situation is easy to explain: I wouldn't want to invest time in developing a non-cross-platform app either.