This one seems to be a native app for macOS, not an Electron app. So, hopefully this allows to achieve higher performance with much lighter resource utilization.
very interesting. i wonder about the tech behind it. always wanted to get into native mac app development but objective-c is a little daunting. i wonder if it's using swift ui?
> 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'd be happy to discuss! My first all-swift project. Was pretty rough at first, but Apple's done a great job of iterating on it. 100% AppKit, though. SwiftUI looks super cool, but it's just too new for me to feel confident relying on it. Plus, we currently support 10.14 as well.
thanks for replying! the app looks totally awesome. i was asking my question because i have been gathering resources for learning swift but from time to time i would read things like it's not mature enough with some macOS frameworks and you have to use objective-c. these comments and the fact that the language itself kept changing/evolving are often off-putting. but i think this just renewed my interest!
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.
You should be fine using all swift now. The only thing is there are FAR more resources for learning Swift in an iOS context out there then macOS and you may have to figure some things out on your own.
Non-native apps can be as performant as native ones. I imagine they checked alternatives to Electron and figured a native app would allow them to have better OS integration.
VSCode really stands out to me among Electron apps, which is why I would be really interested in a write up about what they are doing to get it so performant (I think Rust is a part of the answer). Of course you can write terribly performing code on all platforms, but certainly some make it easier and/or have their own performance requirements.
Part of it I think is the super text heavy use case. Unlike slack for isntance that'll have N 30MB gifs (probably multiple copies of each too) in memory at any given point.
Have you tried pasting a very long line or huge file into VSCode? I always have Sublime open for these cases where I need to look at a huge JSON file as VSCode just crashes or becomes unusable.
And with all the resources of Microsoft behind it still can't compete with something like sublime on performance. I know it makes up for it in other areas like extensibility but I wouldn't describe VSCode as particularly performant.
I do agree. My concern is about the future of the project. If they do a great job, I do think they should support others languages, perhaps having a ecosystem like jetbrains. I think it's inviable survive supporting only one language.
I’m not in their beta, but the following statement doesn’t give me a lot of faith in a native Jetbrains-like alternative:
> 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.
Even without that, I still think it's a niche worth pursuing. They'll be able to sell this if it really works well. All the Go developers I know use macOS as their primary development platform.
The last thing the world needs is another proprietary, payware IDE (that most likely involves all sorts of phone-home telemetry to benefit them and not you).
Chime has in-process crash reporting. Which is both open source (on our Github page) and you can opt-out via prefs. No other telemetry of any kind. To be honest, I'm not even sure how telemetry like that could even be used to be benefit us. But, perhaps we're just not in that mindset.
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.
Many parts of the system are open, and more are coming. We're just not savvy enough to be able to open source the whole thing and also continue to afford to work on it.
Sounds like you work on exclusively open source software. You're lucky!
Interesting, VSCode + Go plugin got very unreliable since I switched to the language server integration. I have to restart the language server at least once a day to make autocomplete in VSCode work again.
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.
There may be better way to describe my feeling. But I think this LSP thingie is Electron of language tools. With the amount of activity I notice on LSP for Go is astonishing. Writes, rewrites and re-rewrites, the constant work on refactoring and optimization seems unending.
When we started work on Chime, there were no viable Go language servers available, so we had all custom stuff. Now, gopls is fairly good, and has been progressing fast. But, yeah LSP isn't the holy grail. Progress on the spec is surprisingly slow, especially given how many holes it has. But, I'm very optimistic that it will get better. There's just so much traction behind it.
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.
While the switch to go modules was pretty smooth on the code front, the tooling was another matter. They had to rewrite everything to support modules and decided to create this concept of a "language server" which would then be universal across languages and help editors like VSCode support new languages that pop up as long as they provide their own language server that matches the spec.
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.
yea, I think Go's tooling has started facing the challenge of having an existing base to support..
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.
Also the “tf” in Printf in the example is syntax highlighted wrong.
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.
From the screenshot, it looks like the intention is that "Prin" has been typed by the user and "tf" is a suggestion, so it makes sense that "tf" would be gray and "Prin" would be green. (Of course, that could be made more clear.)
I swear it makes sense when you us it! But, the cursor is there. "Prin" before the insertion point, and the autocomplete suggestion of "t(<placeholder>)" comes after.
Makes sense! The image we're referring to is the one for the "Built for macOS" section, not the full screenshot at the top of the page. That one doesn't have a cursor in it.
The example before shows the author typing Prin with autocompletion. Maybe that was the original intent? I think that context is lost though and it would be better to just highlight the entire thing as you suggest.
I don't agree with that strategy. This isn't a SaaS company where they're actually resource constrained in terms of server capacity.
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.
As someone who spent some time on support, I can sympathize with their closed beta. If you reach too large an audience before you're ready, you could end up treading water because you spend too much time responding to similar bug reports and feature requests.
Yeah, so we didn't actually post this. And, to be honest, we weren't at all prepared for how much attention we got today. It's cool, but the timing wasn't awesome. We're trying to work our way through all the beta requests and HN/reddit comments. But, I'm a lurker, not a commenter, so I kinda don't know what I'm doing...
Pretty much all Go editor tooling is provided by "gopls" today, so if you have an editor that supports the Language Server Protocol, you can have all these features in your editor right now. I was never a tab completion person, but gopls changed my mind. It's fast and works really well. Jump to definition and related functionality also works very well. One keystroke to see the source code of any function you call is great.
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.
> (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.)
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.
This aligns with my experience. I switched from vs code because Goland was simply better. It just works. VS code, using the language server, could not even jump to declaration inside the same file
They're far from over. I tried out CLion because I just didn't have the time and patience to set up my environment for effective C++ development. No matter how well vim and emacs can support it, there's still a lot of scripting and configuration to get it to behave how you like.
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.
Whew, let me tell you. Chime has used three different Go language servers, as well as custom stuff. Every server was different, with different behavior, performance characteristics, and supporting different feature sets in different ways. And that was just for Go! I cannot imagine how it is for other languages.
Offering high-quality language support takes a lot of work, per-language and even per-server.
I’m not a Go user, so I’m not a bit of the target audience, but it’s so refreshing that it has the native UI on macOS. Today deceloper tooling is almost all electron/Qt/custom-framework based cross-platform; I was really disappointed when I tried to find a decent editor with autocomplete (based on LSP), project management with a cocoa-based UI (like native tabs and cocoa textfields) and found... nothing.
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.
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.
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.
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.
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.
> 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.)
> 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.
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.
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?
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 :)
> 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.
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.
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.
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.
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?
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 :-(
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)
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!
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)
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.
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).
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.
God I hope to see some great looking editor like this (or Panic Nova?) with .. somehow.. integration with Neovim, Kakoune and etc. Aka an editor that can be a frontend to "classical" CLI editors.
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.
I like the CLI too, and would still need it if I "left" the Terminal.
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.
yeah, I totally get that. I keep toying with VSCode for the same reason. The problem w/ gui based tools in general is that they don't usually follow unix design principles. You end up making lots of little compromises just to integrate into your editor.
Yea, which is why I want a real frontend, not an emulator or w/e. Ie, there are real frontends for both Neovim and Kakoune. They let the editor do the real lifting, and they merely change the UI.
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.
Final price is TBD. We've got a lot of beta testers now, so unsure how an open beta will go. It's quite possible we go right from closed beta to general availability.
I don’t think closed-source tools are ever going to be a major part of my development workflow in the future.
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.
Many people feel this way. This is why there are so many incredibly high-quality open source tools today. Chime is definitely not made for people that want to tinker. Some major components of the app are open source, though, and more are coming.
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.
Both :) We'll be using a "Sketch-style" pricing model, licenses work forever, but updates are only for a year.
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.
127 comments
[ 3.4 ms ] story [ 172 ms ] thread> 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...
> 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.
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.
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.
https://www.chimehq.com/assets/images/built-for-macos.png
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.
[0]: https://twitter.com/chimehq/status/922905555013947395
GitHub of the link submitter: https://github.com/dsego
Twitter of the Chime dev: https://twitter.com/mattie
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.
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
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.
https://panic.com/nova/
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/
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.
[+] https://magit.vc/
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.
https://www.reddit.com/r/golang/comments/ekdbiy/chime_a_go_e...
The creator of this editor contributed some comments to this post.
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.
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.
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.
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.