Chime – A Go Editor for macOS
chimehq.com
chimehq.com
It was really disappointing to find that nobody developing the developer tools really consider user experience or nativeness... even on the mac where Cocoa is very emphasized by the users. (For more of my arguments about native UI, see my comment against flutter: https://news.ycombinator.com/item?id=20612195)
This product with some C/Rust/Lisp support would be the product I would have to like to find, and I’m really looking forward to this product with the expectation where this might be more configurable or some other language support is added.
Great job for the developer, I really is thankful for showing that a cocoa-oriented editor is possible & feasible. Thanks.
Sublime Text comes to mind as an app that is native as well.
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.
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.
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.
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.
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.
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.)
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.
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?
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,
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 :)
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.
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.
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.
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.
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 :-(
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
There is some more info here: https://novadocs.panic.com
LSP support extension documentation is here: https://novadocs.panic.com/api-reference/language-client/
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 :)
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'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.
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.
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.
It'd probably be hard to switch as there's a bunch of other plugins for VSCode that I use on top of all the keyboard shortcuts but it's nice to have an option if it continues to be developed.
However, Chime still contains a huge amount of custom language handling stuff, and will for the foreseeable future. LSP on its own is just insufficient for a good experience.
It's a nice idea but has been (and continues to be) super painful for anybody actually trying to get work done. This was a huge fuckup on the part of the Google engineers to combine the rewrite with module support. They should have first added module support to the existing tools THEN bitten off the totally new paradigm of a language server. Yes it would have been more total work but so many person-years of productivity was lost with the approach they took and we are still counting.
I remember using vim-go few years back, and I was very impressed of how much it "just works", it really turned my vim into a Go-IDE with very little effort.
I had to come back to go recently after not using it for quite a while, and a lot of the magic seems to have faded somehow. Ran into a number of issues that I had to find workarounds for.
So what's the point in posting this?
Chime has been under development since at least October 24, 2017 [0] and there's no ETA on a public alpha/beta/GA.
Assuming that the poster is (one of) the author(s) of Chime, they shouldn't post this until everyone can download it. It can be alpha/beta software, but to post what amounts to a handful of screenshots is pointless in my opinion.
GitHub of the link submitter: https://github.com/dsego
Twitter of the Chime dev: https://twitter.com/mattie
> It's mostly custom drawing on top of a customized AppKit textview. The Cocoa text system is wildly powerful, quite hard to do pixel perfect drawing with. No OpenGL or any fancy graphics libraries.
I think Swift is there now. There were some very painful migrations, but for the past 2-3 years it has been different. It is true that it's a real pain to use some C-based APIs with it, but those are pretty rare. And, often you can find a Swift wrapper for them if you really need to. I've been using ObjC for 25 years, but I'm now pretty into Swift. I'd go for it.
This may be true. However, Electron apps cannot be as performant as native apps can be, which seems to be what they are getting at.
https://szibele.com/memory-footprint-of-gui-toolkits/chart.s...
Are they leveraging the same codebase in any way? How does Chime want to be different? I think lime is also written in go.
LimeText is still actively being developed here: Github: https://github.com/limetext
https://www.reddit.com/r/golang/comments/ekdbiy/chime_a_go_e...
The creator of this editor contributed some comments to this post.
> Our whole philosophy is fewer features, built with more polish. Attention to detail and thoughful design is what Chime is all about.
They seem to be pretty focused on editor usage, not tooling and ecosystem. That could definitely change over time, but I’m not currently interpreting this application as a pluggable IDE-like scenario.
They also have barely any information on their site, so it’s hard to form an opinion on this. It’s something to keep an eye on, though.
For now, we're 100% focused on delivering a great Go experience.
Regardless, there's nothing like this in Chime and there never will be. But I get that not everyone wants a closed-source tool. There are many open source options, including a number of high-quality macOS native ones.
Sounds like you work on exclusively open source software. You're lucky!
All of us who know how to program and build good products have such a privilege.
I would pay so much to be out of the Terminal, but I need to use my normal editor (Kakoune in my case). I want to pay for a high quality frontend.
I fear the market isn't there and so the product I want will never be made. My hope however is that someday someone can make a great editor GUI that could be pluggable for users like me.
What I mean by out of the terminal is that I simply want my editing experience to have variable fonts, popups, borders for windows that aren't bound to font size, better icons, underlines, etc etc.
That is what I want, but in a super well presented manner. I'd happily pay ~200/y for that. BUT, I think this frontend would also have to have a "normal" editor built in, because I don't think people like me would pay enough to allow a dev to write this editor full time.
If it doesn't use gopls, then it will probably break in every corner case like previous tools did. When modules first came out, you had to go like 3 forks deep in "gocode" (the previous completion provider) because the original author stopped caring at go 1.10, then the person who forked that didn't support modules, then finally the author of gopls started maintaining it. This maintenance overhead was exponential, given that gocode was not the only editor integration; syntax highlighting, godef, etc. all had to be tweaked for every editor and every go release. Now gopls handles all of this and is maintained by the go team itself, so it will support new features in the go language at the same time as go.
(I believe even dedicated go IDEs like goland have always been a little behind go itself. It simply doesn't scale to have every editor implement their own go tooling.)
gopls also addresses interesting corner cases. Say you build your project with Bazel, and you generated protocol buffers as part of your build so that developers don't have to find the right version of the protobuf compiler, install it, and then debug why changing one name in the proto file caused a 600 line diff. gopls and go itself can't know that you are generating some Go files with a build tool, so Bazel projects will have squiggly missing import underlines below your proto imports, won't be able to tab complete, and godoc won't be able to show you documentation for the protos. But, there is a solution; the "package listing" functionality is modular and can have a "driver" set at runtime, so all the go core tooling CAN find these generated files and treat them as though they were natively checked into your repository. It is reasonable to write one plugin for your build system to support Go tools, but kind of insane if every Go editor had to do this. gopls exists to make this work.
So with that in mind, every Go editor should be about the same. If you want new features, add them to gopls. If you are writing a new code editor today, just support the Language Server Protocol and you get great Go support, and support for every other language. https://langserver.org/ contains a list of supported languages, and it's pretty much everything. Last I looked, even things like Arduino were moving to LSP.
So I think the age of editors-for-a-language are over. Even if you restrict your focus to just one language, which isn't that useful to begin with, you will always be behind for some reason, be it new build systems, polyglot apps, new language features... it's not worth it. Just use LSP and focus on core editing.
This isn't true in my experience. Goland worked well with go modules the day the Go release candidate including them was published.
The jetbrains ecosystem is also overall great for polyglot apps including stuff like different language injection in string literals in another language.
Afaik they are explicitly not using language servers, as they have their own generic language representation, which enables a lot of refactorings by itself.
All in all, whenever a teammate complained about something not working in vs code, I was successfully using it in Goland.
Meanwhile, my shiny new C++ specific IDE (that isn't Visual Studio) knows everything about Cmake, and code completion, and linting, etc. Not all of it is correct, and the IDE isn't my favourite thing to use, but it helped me focus on the code and not my setup.
Even moreso when it comes to debugging.
Offering high-quality language support takes a lot of work, per-language and even per-server.
Uhh, none :) It's built specifically for Go, and today supports no other languages. I'm not sure when, or even if, we'll do a public plugin API.
Every part of my toolchain needs to be subject to my own itch-scratching, as well as the ability to patch out the telemetry/spyware that everyone seems to want to put in their apps these days.
But, there's no spyware in the app and there absolutely will never be in the future. Of course, if you don't want to take my word on that (and also do not trust Little Snitch), open source is the best option. There are tons of good things out there, even specifically for the Mac.
Your decision is an outlier, and you should reconsider.
Sorry for the nitpick, but a typo in this particular sentence was too good to pass up.
Admittedly, I’d rather a development team spend more time and attention on their app than their landing page, but they should probably fix that since it kinda sticks out. Hopefully they’ll see these comments.
I am a Sublime Text user and would be hesitant to pay money for just another editor.
I'd say that most developers are like you, invested in one editor. It's hard to change, especially given how much customization is possible. Chime's really tailored to people looking for a dialled-in macOS experience. Usually, the people that want that kind of thing are out looking for it. It's pretty niche.