I tried this out some months ago and had really mixed feelings, but I will give it another shot because generally speaking, Panic is awesome!
My main complaints at the time were a confusing extensions ecosystem; difficulty rolling your own; and the sense that (as with Coda) "programmer" means a person hand-coding web sites with HTML+CSS and maybe Javascript or PHP. Seemed like they weren't trying to convince anybody who already used VSCode et al.
That said, I have had some difficulty adjusting to Sublime's way of doing things, and VS never felt right to me, so maybe I'm just picky.
In any case I am happy to see another opinionated text editor in the mix!
[Edit: And right out of the box now, no support for Go files, not even syntax coloring, and it thinks go.mod is a media file and won't display its text. Searching extensions for "go" gets me three different extensions and no way to tell which is better/more-popular; and also shows me six totally unrelated extensions, three of which have "go" in their titles e.g. "django" and three of which do not. So... still not really shooting for the programmer market, but I will keep trying!]
[Edit2: Similar results for Rust. And extensions have to be written in Javascript, and the boilerplate is all for published extensions which maybe makes sense, but I really want an easy way to pipe ($BUFFER|$CLIPBOARD) to an arbitrary program and put the result in ($BUFFER|CLIPBOARD) with a pop-up on failure, and I find it really weird that there is so much shell integration but not that. OK shutting up now, playing with editor...]
> And right out of the box now, no support for Go files, not even syntax coloring, and it thinks go.mod is a media file and won't display its text.
I just had a similar experience, no Go or Swift (ok understandable maybe) support out of the box. But I paid for it it anyway since I like what they’re going for and have admired the company for a long time.
I wouldn't mind not having support for any given $POPULAR_LANGUAGE out of the box -- maybe there are license issues with that -- as long as there is a good extension and it was super easy to find.
Easy to find means if I open a .go file or relevant directory, the app should ask me if I want to install support for Go files. And it should have One Approved Extension, the others should be available on request (as all are now).
If there's no good extension for a common language, I think it's on Panic to convince the community to make one, or make one themselves. One way of convincing the community would be to make it easy! (A quick look at the comments in the extension READMEs strongly implies Panic has not made it easy. The updates to the Go extensions are ~ 6 months old.)
So what's a common language? You could probably use GitHub to figure that out. If Go doesn't qualify then OK, I'll go back to my cave, but I think baking in CoffeeScript instead is pretty arbitrary.
I think they're just heavily and narrowly targeting webdevs. Python for Django, Ruby for Rails, PHP, then a whole bunch of CSS/React-y stuff I'm not too familiar with.
I'm sure people use Go for back ends, but it's more for systems right?
When I looked at the list of natively-supported languages, which are not only webdev-focused but also exclusively dynamically-typed, I felt a blast-from-the-past from around a decade ago. Back when Mac-armed developers writing rails apps were culturally ascendant, and statically typed languages and SQL were uncool corporate dinosaurs. Maybe this company is still living in that time...
That’s the impression I get as well, but it’s a shame since MacBooks are super popular among back-end engineers.
I would even speculate that by now, Mac-centric web devs are handily outnumbered by non-web devs (plus web devs doing backend stuff in Go, Rust, whatever).
I get that maybe Panic just doesn’t see that as their natural market, but I really love the polish of their apps and do wish Nova (or back in the day, Coda) met my needs.
Interestingly, when I first saw this thread I thought Nova was an alternative to XCode. An actual native alternative for writing Swift -- Panic seems like in the best position to do that. But no, webdev it is.
>I tried this out some months ago and had really mixed feelings, but I will give it another shot because generally speaking, Panic is awesome!
Are they? They have a long history of getting bored with projects and cancelling them or letting them languish. Not the best assurance for a long term commitment like an editor...
That at some point they have to sunset tools that are not used by people any more (Like the Newsnet client, from what I remember) makes sense to me. It doesn't feel like they are just abandoning projects because there's something new and shiny to work on.
I was actively using Statusboard when they killed it... Yeah I've been using Transmit for 20 years but outside that they have a long history of releasing something awesome, rarely updating it, and killing it. Baby Google.
Reading that actually increases my confidence and trust in Panic.
It's not an "Our Incredible Journey" blog post light on details but an actual reasoning from a business perspective. Including them sharing the actual tiny revenue they made with the product. As a non VC funded business they have to stay sustainable and healthy and I'm supporting that.
They even offered a refund and published an update so it can run on as many devices as possible for as long as possible.
Apart from all of that, it's an app that was sold for 9.99 Dollar so if you got a few years of usage out of that it seems fair in any case.
I second the other commenter: this is very good form to copy — they explain the economics and getting partially superseded by new iOS features, offered a refund to recent purchasers, and gave clear expectations for the future. That’s way better than the Google-style neglect until the servers disappear or, worse, selling it to someone who’ll lard it up with ads and spyware.
For such a cheap purchase, that’s better than I’ve had with certain expensive enterprise software vendors who shall remain nameless.
I'd say yes, Panic are definitely awesome. The software they build is always high quality and their forays into games and hardware has been great. Part of the reason I like them is they are small (compared to Microsoft at least) and independent, so I suppose there is always the chance that they will have to abandon a project to be able to stay afloat.
With regards to writing extensions, I wrote one [1] to integrate the Luacheck analyzer for Lua code which pipes the buffer to an arbitrary program. It doesn't put the result in a pop-up (for that I think you can use Workspace.showInformativeMessage() [2] and its siblings, though I haven't tried it) but it does show how the output of the program can be fetched and parsed. Feel free to shoot me an email if you have any questions I might be able to help with. The dev forums [3] are useful too even though they use that godawful Discourse forum system.
I share this experience. I come back and check on it every few months. It continues to baffle me what their priorities are. VIM support but extensions can't even BUILD or RUN.
I love the idea of a native macOS IDE, but it seems like this will never be something I can actually use productively or ever recommend to anyone. Would happy to be proven wrong.
I really wanted to like Nova. I paid for it (and used it) for a year.
In the end, though... I switched back to VS Code. Native apps like this are much faster than such things, but I had too many use cases for the plugins.
Kind of the same experience as Sublime Text. It's _really fast_, but I just rely too much on plugins when the experience requires something more than vim.
I had a similar experience, but -- possibly counter-intuitively! -- ended up going mostly all-in back on BBEdit 14 when it was released with LSP support which has proven to be a lot less, well, flaky than Nova. I like VS Code a lot and may yet return to it as my main coding editor if I go back to a big project, but BBEdit has always been my old warhorse when it comes to my technical writing because it's just such a Swiss Army Knife for text processing. And BBEdit with Intelephense for PHP or with my own Elixir package for (surprise) Elixir has worked really well.
Nova is pretty, and I'm impressed that they've added a Vim mode, although I haven't been able to really give it a try (my year expired before that was added!). But for me, it wasn't just a lack of plugins, it was that functionality I wanted wasn't there and the functionality that was front and center, like integrated Transmit and Terminal tabs, just wasn't that important to me.
Sounds like we really did have a similar experience - Nova is _great_, but not what we need.
I have very specific and weird needs. For example, I need syntax highlighting for LaTeX, but in a non-mathematic-but-programmatic-control-of-layout way.
VS Code supports that, oddly enough. No other text editor does.
I tried out the Vim mode, it's actually one of the better emulations I've seen. Still suffers from the fact that for someone used to Vim there will be some keys you use regularly that aren't yet part of the emulation. I lasted a few days, but turns out I'm happier with actual Vim.
A shame, as they claimed to fix some of this in the newer versions... but of course my 30 day trial has expired and their model means I can't try out the fixes to see if it's actually worth paying for now.
About a year ago I decided it was time to finally modernize my Python coding setup.
I really, really wanted to use Nova, would have paid full price no problem, but for some reason the one main Python plugin was extremely flaky for me. Linter highlighting would sometimes work and sometimes not, unaffected by the plugin settings, and the primary Python plugin I was using was based on somebody’s github repro that hadn’t been touched in a year or two.
I spent a bunch of time but couldn’t figure it out. So I ended up going to VS Code. It works well. The Python plugins work well. It’s a pain in the behind to configure, and it’s not the prettiest thing to look at. But I can grind out working code fast, partially because those plugins catch problems almost as fast as I can type them.
I would try Nova again in a heartbeat if the Python support improves.
Is there a reason you didn't go with PyCharm? I tried vscode, and it works out of the box for particular things, but Pycharm is just a breeze on latger projects.
No major reason other than I might as well use VS Code since it seemed very popular for writing Python.
But I actually recently wrote a todo to try out PyCharm Pro. I haven't decided if that's pointless yak shaving since VSC works pretty well for me. But I would like to configure VSC more to make my workflow faster. And my guess is PyCharm Pro is probably better out of the box vs having to spend time configuring VSC settings (so many settings...) and plugins.
I have the official Python plugin and the Pylance plugin. I also have mypy enabled though that's not a separate plugin. I've avoided bugs because of that.
I'd encourage you (or anyone) that likes Sublime Text and says "but it [small problem]" to give it another go. _Really fast_ is an amazing feature: I am never waiting on my text editor. The incidental features and details that make a bigger IDE more compelling are all there: you just need to find them if they're native or install a plugin if they're not.
Once you've got it set up and then committed your process to muscle memory, the speed makes the software recede and your work the focus.
(_The Pragmatic Programmer_, a book I highly recommend, advised me to "use a single editor well" and that has really made a huge difference in my career. I don't look for new tools until the current ones go unsupported or perform poorly—looking at you jEdit and TextMate—and my work flows are ingrained.)
After trying Nova and looking at other paid editors, I ended up using these funds to make donations to authors of my favourite VSCode and Emacs plugins instead.
I've admired Panic for the entirety of my career, they're always doing really nice work, and I'm glad they're still going strong in a time where native desktop apps aren't really the du jour.
From afar it seems their strategy is "make cool shit." They published Untitled Goose Game for the Nintendo Switch, and years and years ago made some official licensed shirts for the PS2 game Katamari Damacy. They really are all over the map and it's wonderful.
I imagine part of their physical location requirement is their expensive custom office (https://panic.com/blog/the-panic-office/)... but they do a lot of creative work and in my experience it's hard to brainstorm and do creative problem solving remotely (not impossible, but also not the same).
They did a lot of cool stuff around the periphery of Firewatch though, like building the ability to actually print the photos you take in game. Panic is such a cool company.
> I imagine part of their physical location requirement is their expensive custom office.
I'm broadly in favor of the power of in-person collaboration, but I'd like to point out that this is a terrible reason to do anything. Sunk cost fallacy and all that.
Of course, Panic may have invested in an expensive custom office because they believe in its ability to enhance work.
If it's an independent business since 1997 the implication is they're not for sale, so equity wouldn't be likely to achieve any liquidity, hence relatively meaningless.
That employees are "screwed over" is always a weird argument to me. Presumably these employees are free to choose the company they work for, and so they could've chosen companies that provide equity over those who don't. I was under the impression that Mailchimp paid well through salary and bonuses.
To be compensated for many years and then cry foul when the founders exit and the employee having gotten nothing (because, they chose to work there and not elsewhere) is to want to have one's cake and to eat it too.
The founders repeatedly promised (and in at least one case I know of, convinced someone to work there based on that promise) that they would not sell. Perhaps the implication is that we should not believe the promises of founders.
Promises don't mean anything unless contractually obligated. One should always look out for oneself in terms of what's actually written down, not what's said or implied.
See my reply to the sibling comment [0]. It is not the responsibility of the founders to tell you the truth, they do as they will. It's is always our responsibility to discern the truth from the lies, through what's actually written down.
Anyone, the world even, can lie to us, that doesn't mean we must believe them implicitly.
Perhaps I worded it incorrectly. Sure, they might have a moral responsibility, but that doesn't mean they'll always tell the truth, and more importantly, you should not trust them to tell you the truth. You have to look out for yourself as much as possible.
This only follows for businesses that do not pay a dividend. Assuming Panic is profitable, equity could easily result in profit-sharing or dividends. Facilitating employee share sales would also allow employees to take on more or less Panic risk depending on their personal tolerance.
Other companies have done similar for decades/centuries.
Well, the strategy/all over the place, is something that can be argued.
But "Also, they're hiring, but they don't do equity, and they want you to be physically located at their office?". Well, it's up to them. You don't have to go work there.
These are the same folks that are making that wind up console?
I don't understand it. They're all over the place. A video game, a video game console, an SSH client, and a text editor. What's the strategy with all of this?
Also, they're hiring, but they don't do equity, and they want you to be physically located at their office?
What?
Perhaps they're filtering out the tech bros for whom equity and remote are deal-breakers.
Since you're not familiar with Panic, this is not a startup, it's a real company. It's been around for decades and has a sterling reputation in the tech community.
Think of it as an artisan technology group. It's a company with a reputation for being fun, and putting out work of a quality to which any FAANG should aspire. Even Apple.
Well this is a new definition of “tech bro” to me. In my experience the people who either identified themselves or fit the stereotype preferred office life, and all of the social life it affords/requires.
I’ve been remote most of my career and still prefer it despite difficulties posed by the pandemic. It’s quiet, I can focus on work goals without also accommodating a high school-like social atmosphere, and it’s… quiet. My sensory issues are limited to the things I live with at home.
It’s a shame if companies making cool and unique products think that’s some kind of a cultural signal that candidates are tech bros. They’re basically excluding almost everyone with autism and ADHD.
I have autism and ADHD and prefer working alone most of the time, but I’m also bad at making friends and enjoy occasional casual collaborative or parallel in-person work. I’d like going to an office once a week rather than 0 times.
There are many personal preferences that aren’t clearly defined by one option or the other… I wonder what kind of flexibility develops in-between the two?
I feel the same way (if not in the same proportions) for what it’s worth. I would definitely prefer an occasional in person work life if it’s available. But I’ve only really encountered that with places that are remote by default.
This is so very important, and something that people who don't have a lot of experience in a professional work environment often don't understand.
It took me at least a decade of working in a suit-and-tie environment before I started to understand the reasons for what people who chatter on HN consider antiquated customs and ceremonies.
I have tremendous social anxiety, and hate being in an office. It's so bad that I ended up starting my first company years ago because I didn't want to deal with people. I learned that you can't run a real business without interacting with people and using social skills. Unfortunately, I ended up back in the office because I needed a company that pays me better than I could pay myself.
It's hard. We all have our social/mental problems. But you have to learn to work through those, or at least cope with them, and not dismiss them as "high school." You might get lucky to work at a FAANG with a playpen environment. But you're not going to be there forever. What about your next job? What are you going to do when the business environment changes, as it always does every couple of decades?
The problem with doing that is that you've now created a substantial dependency for your commercial product, and not a dependency that's merely the "requires npm package foo" kind of dependency. Because Nova is not VSCode, being compatible with Code's extensions API means:
- committing to implementing every new documented Code API function as quickly, completely, and transparently as possible, because if you don't, extensions will break;
- resolving mismatches between how Electron apps do things and how AppKit apps do things, which may be easier said than done;
- possibly choosing not to support functionality in extensions that Code doesn't have;
- putting control of your flagship product in someone else's hands.
So I'm not really surprised Panic hasn't done that. If there were a way to create a basic converter that takes a Code extension as input and spits out a likely-needs-work Nova extension, kind of like there's a converter for TextMate syntax definition files to Code's format, that would be great, although that would almost certainly be easier said than done.
The fact of the matter is that VSCode's market share is massive, and expecting developers to port extensions solely because "it's a native macOS app" is not really a good pitch in 2020-2022. I would rather Panic suck it up and do the work to interop with the existing (massive) ecosystem so that those of us who like to run native apps can do so without it being a step down on just about anything else.
Something like this needs ecosystem buy in, and as far as I can tell right now, it doesn't have it. I wish it did.
I don't really see why Nova should attempt to be compatible with another editor just because they landed on JS as the integration language. It's doubtful that VS Code has the best API, and it's doubtful that VS Code's API is the best fit when the editor isn't primarily rendering HTML.
Because the editor works very differently, it's unlikely they'd ever manage to make the APIs completely compatible, and because of that it'd unlikely that you'd have much porting between the editors anyhow.
There are many editors out there with incompatible plugin APIs (sublime, vim, emacs, vs code, fleet etc.). There is room for Nova to do their own thing, and do their own thing better without catering to the crowd of another editor.
>There are many editors out there with incompatible plugin APIs (sublime, vim, emacs, vs code, fleet etc.). There is room for Nova to do their own thing, and do their own thing better without catering to the crowd of another editor.
No, there's really not. The marketshare for a native-macOS editor is comparatively small, and they would be better served just making it work and interop well.
There is nothing special about their extensions API and there is no glory in re-forging this path.
The selling point of Nova is being a native Mac citizen rather than a Electron wrapper. The VSCode Extension API heavily relies on the flexibility provided by the browser runtime which native apps like Nova cannot give.
How much experience do you have with the product in question...?
Last I checked it literally embeds a JS engine with a custom API for extensions. Unless something has changed since I last looked... but if I glance at this URL (scroll down to "Providing a TreeView") it doesn't appear to have:
There is simply no reason it has to be different from the VSCode API; you can set up JavaScriptCore to hook into whatever native components you need. VSCode owns the market, full stop. This should mimic the API as much as possible to enable wider extension porting.
Hell, you could cover even a fraction of the VSCode API and that would still be more useful than the current Nova extensions API.
I tried Nova when it first launched and again recently, and I switched back to VSCode due to the numerous plugins and prodigious output of its creators every month.
In my opinion, Nova (through its lack) shows the true power of network effects, even in code editors, because even though VSCode is an inferior product in many respects, like speed and resource usage, it still wins due to its sheer popularity and extensibility. In a way, it is the story of JavaScript itself: a bad language that only works due to its popularity; as one uses JS, one continues to use JS as others do too, creating a virtuous cycle.
> it is the story of JavaScript itself: a bad language that only works due to its popularity
This is a profound observation that gets to the heart of the matter with both VSCode and Javascript, both of which I resisted as long as humanly possible. What gives them the greatest utility is that they're immensely popular, in spite of not being the best tool for the job. I came to VS from 10+ years in Eclipse, and to Javascript as a main cross-platform client language only with the demise of Air/Flash.
But the "network effects" or, let's say, the value of the community-driven ecosystem, is undeniable. In 2008 if you wanted to build 3D games for web, you pretty much had to use Flash - and there was a sizable community maintaining libraries. The environment was imperfect for its own reasons, although certainly no worse than cross-platform JS is right now.
Maybe another way to state it is: If you get enough good coders around even the junkiest tooling, they'll make good code.
But I can't think of any other industry that really works this way, that gathers around a bad standard like buffalo around a waterhole in the desert. I think it's a major flaw in software development in the 2010s-2020s that in order to dance between these walled gardens, independent developers so often have to use tooling that wasn't made for the job. Flash/Air was a breach in all their walls, and that was a reason it had to be made an example out of.
I've heard a hypothesis saying that JS endures because it's bad, otherwise it would've been subsumed by other languages and we never would've been fed up with it to create Webassembly, which is more optimized for its use case than what the other languages we might've used instead of JS.
In other words, feeling the pain of JS over 20 years led to the creation of WASM that might not have been as needed had we had good languages on the web present.
> In other words, feeling the pain of JS over 20 years led to the creation of WASM that might not have been as needed had we had good languages on the web present.
honestly, that sounds like retroactive justification... bytecodes where a thing since way before js showed up, and afaik there was no technical reason it couldn't have been like that from the beginning
Before VSCode, same effects were conspicuously at work in Emacs and Vim. While JS has some warts here and there, vimscript is truly terrible. Nevertheless, a lot of advanced Vim plugins were built, drawing even more people to Vim, thus incentivizing more plugins, etc.
> VSCode is an inferior product in many respects, like speed and resource usage
This is a rote complaint but how often do you really notice it? Even on my ancient spare 2010 MacBook Air, VSC is responsive and it uses less RAM than other apps like Teams or Skype, or simply loading Gmail in Chrome. Yes, vim uses less RAM but it also has like 5% of the functionality.
Is it possible that this is specific to particular plugins or languages? I mostly use Python, JavaScript, Terraform, and Rust but I did notice that Java is, as always, a lot more demanding.
> Even on my ancient spare 2010 MacBook Air, VSC is responsive and it uses less RAM than other apps like Teams or Skype, or simply loading Gmail in Chrome. Yes, vim uses less RAM but it also has like 5% of the functionality.
Well, you specifically picked the most heavyweight experiences. The comparison was obviously against native text editors.
I was just pointing out that VSC is pretty far down the list of things where performance is something I notice unless I'm trying to do a benchmark of some sort. It's not quite as fast as, say, TextMate 2 was but it's pretty close on basic performance (e.g. when I measured keyboard-display latency it was within 20% of Text Edit or Terminal) and at some point the huge amount of additional functionality is a consideration. If the question is “what things slow me down at work”, it's close to the bottom of the list.
The place I notice it most is when launching it. I don't keep it open all day, I open it periodically to work on this or that and close it when done.
Opening it feels like it takes forever (5-10s) compared to something like Sublime Text (<1s) and when there are a lot of launches throughout the day, that adds up.
It takes about a second on my M1, which puts it below the threshold I have for caring about it. The big question is whether you count things like indexing projects against the editor or the toolchain, since things like firing up linters or the JVM is only partially under their control.
Until you’re the unfortunate person trying to debug an API deployment where the team behind the API decided to use ‘much more efficient protobuffs’ making them entirely unreadable and impossible to troubleshoot. Modern processors and networks are fast enough to allow us to spend a few extra bytes making protocols easy to work with as well as ‘efficient’, and I’d argue that at scale, those ‘efficient’ protocols waste probably 100x more developer time troubleshooting than their text based counterparts. YMMV.
Sometimes you just want to dump the bytes that are going over the wire. Sure you could pipe the output to a protobuf parser, but then you'd need to make sure the output of tcpdump or ngrep or whatever is what the parser expects. As an example, I needed to track down why some service traffic was getting misrouted, and I found the problem by tcpdumping the traffic and realizing one service was silently corrupting a header value - I could have added more debug logs to either service, but that would have taken a lot longer to implement and deploy.
Personally I'd rather stick with the simpler protocol until someone runs the numbers and finds something more efficient would improve performance or save money by a significant enough amount.
> until someone runs the numbers and finds something more efficient would improve performance or save money by a significant enough amount
This argument must be the ultimate defense in code review. The thing is, we have the field of theoretical computer science and things like big O so that we can reason about code without having to do benchmarks about every little thing, because that's impossible in practice.
Regarding protocols, I'd argue that the most important thing for them is to be efficient, at least when IO is still the biggest bottleneck of computing. The other comment already points out debug being a tooling problem.
One of the biggest culture shock moments when I came back to the web world after spending time in high performance environments was how many resources web applications were willing to waste on parsing and sending terribly inefficient wire formats.
I’ll never understand why we’d make the trade off of making crazy inefficient human readable protocols for talking between computers instead of learning wire shark.
They're not just inefficient, they're also harder to work with! Binary formats are rigid and less corner-casey. Human readable formats are a total false economy.
I think you’re correct, it is a tooling problem, but that’s just as valid a problem class as any other. Part of the issue with solving tooling to deal with binary formats is the lack of self documentation. Reading JSON off the wire, its structure is immediately usable and understandable, whereas in most cases for a complex API, a binary protocol requires some foreknowledge of the structure of the data coming back. In the future, if we can create an efficient combination of binary protocol and self-documenting data structure, I’ll gladly change my mind entirely.
> I’d argue that at scale, those ‘efficient’ protocols waste probably 100x more developer time troubleshooting
In another comment you said there should be numbers to back this sort of claim
Anyway, the problem with our software stack is that there are so many layers, so if we get performance wrong at every one of them, it'll compound terribly at the top. We should have some sort of strategy to decide priorities at each layers, say, lower layers like OS, container, programming language, network protocols, should be about performance, then we can be wasteful at higher layers, the domain code, if that gives us better abstractions and maintainability.
I get why you are saying an interpreted language is slow but given that people use python to orchestrate most compute intense (AI) and data-heavy (data science) work, it obviously does a pretty excellent job of being pretty 'fast' in practice - ie offloading the 'slow' bits to dedicated code.
as it stands right now, python is more complex and has worse type system comparing to typescript. It has all of javascript warts and more (those confusing underscore methods, GIL, pyproject.toml is only now standardized).
The good things about python have nothing to do with the language, it's the ecosystem and standard library (which is still not as good as, say, java's). So I'm not quite sure why people say javascript THE LANGUAGE is bad, but python the language is "better".
I don't understand why every editor these days come with a minimap, and many of them turn it on by default. I know Sublime introduced it but what does it do exactly? Why is everyone copying it? It just shows you the shapes of blocks of texts of a long file from ten meters away. It doesn't tell you what they are or what they do, or even how to get there. Every IDE since at least the early 2000s gave you an index or a tree menu or something for navigation, VS Code has a breadcrumb IN ADDITION TO the minimap, possibly because Microsoft realizes its gimmick nature. Why not just get rid of it to free up more screen real estate for actually useful things?
> Why not just get rid of it to free up more screen real estate for actually useful things?
Like? I have an 80 column width by default. To not let my code run the entire length of screen for obvious reasons. Also, it is code smell IMHO if you have to write that much code in a single line.
> I know Sublime introduced it but what does it do exactly? Why is everyone copying it? It just shows you the shapes of blocks of texts of a long file from ten meters away
Visual cues. I can immediately know if my linter finds something wrong. It highlights it in red. Without a minimap I'll have to scroll (or if you are using vim you would still need to ctrl+D till you find the problematic line).
If I am editing a Git repo, I can easily make out the additions/removals in the file. Additions in green and removals in red.
> VS Code has a breadcrumb IN ADDITION TO the minimap, possibly because Microsoft realizes its gimmick nature
I sometimes hide my Sidebar in vscode while working in Zen mode. I can then access the directory structure through the breadcrumbs. Especially useful when I don't remember the name of the file ahead of time to use it in command palette search.
Clicking on the filename in the breadcrumb gives me access to all the symbols defined within the file. Quick way to navigate between declared top-level variables/functions.
I definitively do not want to critique your workflow, that would be pretty dumb by me, just two comments to your points that I don't agree with in full.
> Like? I have an 80 column width by default. To not let my code run the entire length of the screen for obvious reasons. Also, it is code smell IMHO if you have to write that much of code in a single line.
What about a split view? I'd be far less productive if my screen wouldn't have space for 4 split view's for >> 80 columns in my editor + a small terminal split by terminal multiplexer.
> Visual cues. I can immediately know if my linter finds something wrong.
Hmm, while there are a few things like renames of variables/functions/... or (type) signature changes for that to happen outside the view one is currently editing in, it's only solving part of the problem — as other files can have those issues too and require changes, so one needs to run a check/lint test or build anyway.
> What about a split view? I'd be far less productive if my screen wouldn't have space for 4 split view's for >> 80 columns in my editor + a small terminal split by terminal multiplexer.
This includes using split views. Of course I have to mention that I use Mac as my primary development machine (which comes with 5K retina display). So already have plenty of real estate. It might be an issue on laptops. But I haven't tried it to give feedback on that. I just gave my personal anecdote.
> so one needs to run a check/lint test or build anyway
If your entire team is already using lint from the start you wouldn't have to worry about it. Even if not, you would have typically run the linter when you cloned the repo. The build process should have lint as a pre-step anyways. So the chances of you having non linted files elsewhere is minimal. And when you rename functions/variables you can rename as symbol, which will change it in all files that reference it. If you have the right workflow setup you wouldn't have to worry about other files being affected.
This I would consider as refactoring. It won't be just making normal edits anymore. Yes, when it comes to refactoring everything goes haywire. But that is a conscious decision isn't it? Then you'll for sure be running linter/tests anyways. So yes, in such cases what you said is valid. However, having a mini-map won't be a hindrance here. At least I don't see how it could be. It might be useless for this case. That I agree.
> Like? I have an 80 column width by default. To not let my code run the entire length of screen for obvious reasons. Also, it is code smell IMHO if you have to write that much code in a single line.
There are many useful things your editor can render on screen other than code. If you've used any IDE at all, you wouldn't be saying this. File browsers, syntax tree index, class hierarchies etc. Let you imagination run wild.
> Visual cues. I can immediately know if my linter finds something wrong. It highlights it in red. Without a minimap I'll have to scroll.
Again, lack of imagination here. You only need a red icon on a status bar or something to know if your linter has found something wrong, and a counter next to it to tell you how many. If you want to go to an error, you jump from the keyboard, not use your mouse to scroll.
> or if you are using vim you would still need to ctrl+D till you find the problematic line
As an Emacs user who's seen plenty of fancy vim configs of my colleagues, I suspect you didn't even bother configuring your vim at all.
> If I am editing a Git repo, I can easily make out the additions/removals in the file. Additions in green and removals in red.
LOL. Any reasonable editor has a diff mode and allows you to zoom in and out with something like cmd +/-.
As to the breadcrumb, I wasn't saying breadcrumb was a gimmick, I was saying the minimap is a gimmick, therefore Microsoft has to introduce breadcrumb to aid navigation because the minimap just takes up space.
> If you've used any IDE at all, you wouldn't be saying this. File browsers, syntax tree index, class hierarchies etc. Let you imagination run wild.
Which is already available in the VS Code Sidebar. You have everything you mention in VS Code already.
> Again, lack of imagination here. You only need a red icon on a status bar or something to know if your linter has found something wrong, and a counter next to it to tell you how many. If you want to go to an error, you jump from the keyboard, not use your mouse to scroll.
Which I already get in VS Code. I am talking about advantages I get with mini map. I don't want to use my keyboard or the mouse to know where the problem is (if any). I can get 10000 ft view of my entire code in the mini map without having to touch my keyboard or mouse. You won't get it if you haven't used an editor with mini map functionality for a period of time.
> As an Emacs user who's seen plenty of fancy vim configs of my colleagues, I suspect you didn't even bother configuring your vim at all.
I just gave you my take on VS Code features that I like.
I have configured Vim according to my liking. I use Vim within VSCode. But what use is that for this discussion? I don't want to take any extra steps to know the status of the file. I get that with the mini map. I don't want to touch the mouse or keyboard to know where the problem is. Or which part of the code I want to instantly navigate to.
> introduce breadcrumb to aid navigation
You literally have a file browser in VS Code in the sidebar. Apart from that you have a Command Palette that you can invoke to navigate between pages. Why would you need breadcrumb to aid navigation?
> LOL. Any reasonable editor has a diff mode and allows you to zoom in and out with something like cmd +/-.
I am talking about what I like about the minimap. All editors have diff mode including VSCode. I want to see it at a glance without having to touch my keyboard or mouse. Not use cmd +/- to zoom in and out. All these introduce extra steps that I just don't want to do.
> I can get 10000 ft view of my entire code in the mini map without having to touch my keyboard or mouse.
This is exactly what I'm trying to understand. Why? What *actionable* information does it give you that you can't get from a red bar next to the scroll bar or the error total on the status bar?
> I don't want to touch the mouse or keyboard to know where the problem is. Or which part of the code I want to instantly navigate to.
Why do you need to know where? Just jump to the first one from the keyboard. When you are done fixing one, jump to the next one from the keyboard until all of them are fixed. It's not like you can compile or commit before all of them are fixed anyway, and it's not like you can jump to the errors just by looking at the minimap.
> You literally have a file browser in VS Code in the sidebar. Apart from that you have a Command Palette that you can invoke to navigate between pages. Why would you need breadcrumb to aid navigation?
Because that's the only mechanism that will take you to exactly where you want in the syntax tree hierarchy within the same file. It's not great as it only takes you up and down one path, but it's better than having to click on a screenful in the minimap and then having to scan the entire screenful to find the thing you are searching for because all you have is the shape, you aren't even sure what exactly it is.
> I want to see it at a glance without having to touch my keyboard or mouse.
Why? Your compiler or linter or precommit script won't let you proceed without having them fixed anyway. What does it matter where in relation to everything else a blurry red line is in the file? If there's any type checking in your tooling, typically one error is going to lead to dozens and often half of the file will be red. The most useful information is the root cause of a massive error, how does a minimap help you besides telling you you broke half of your code in a file?
To put it simply you have to use it to know it. Give it a couple of weeks. I have been programming for solid 14 years of my life now. Even before VS Code came out. I can't work with editors that don't have a minimap anymore.
> Because that's the only mechanism that will take you to exactly where you want in the syntax tree hierarchy within the same file
That's not true. The quickest way is to Cmd + R. It opens the Command Palette with the list of all symbols. You can either fuzzy search or navigate to the symbol.
You also have it in the Sidebar. Check the Outline tab you'll get the entire list of symbols used within the file. I don't use the Sidebar Outline anyways because I have the Command Palette for it to jump to symbol. I find using Command Palette for most editor based operations much faster. That includes file navigation, going to a symbol (which you call syntax tree hierarchy) and other stuff (like running builds, running tests etc).
> Why do you need to know where? Just jump to the first one from the keyboard
Because I have a rough idea of what parts of my code is where. When I encounter an error, I simply know it is in that particular region of the mini-map and just click that region. It is so much faster than any keybinding that you can think of.
Also, if the error is in multiple places but I know the source for the error is not at the top of the file but at the bottom of the file, I can go straight to that region. Not all errors have to start from the first error that is encountered.
This is not something that can be explained. This is acquired experience that you get only after you give the feature a shot for sometime.
> besides telling you you broke half of your code in a file?
If that is your consistent experience then you have far bigger problems than the editor. I would look at why your code is so tightly coupled that it leads to half the file showing you red lines. That is not normal. At least in my experience I haven't had to deal with squiggly lines that span half the file. At most 2-3 lines. Unless I am refactoring code (which is not considered fixing in technical sense).
> Your compiler or linter or precommit script won't let you proceed without having them fixed anyway
I have a linter running in realtime in VS Code which auto-formats my file and points to any problems in realtime. The linter precommit script is only for extra layer of security and for those devs who have their own custom configurations which don't allow for realtime linter. I hope you realize that every developer has his/her own unique setup to make life easier for themselves.
That outline is hidden at the lower left in a small box collapsed by default. It's as if VS Code doesn't want you to look at it. In the case of breadcrumbs, clicking on it with the mouse is probably faster than searching.
I've been programming professionally since 2004, have tried the minimap on various editors since Sublime invented it, never found it useful.
As to tightly coupled code, well, ha, I don't know of a compiler/linter that won't spew 100s of errors because of one syntax error in a commonly used type.
I realize it's a unique workflow, that's why I want to know more why it's prioritized in every editor these days as I don't think this uniqueness qualifies it to ever become mainstream, much less prioritized.
> That outline is hidden at the lower left in a small box collapsed by default. It's as if VS Code doesn't want you to look at it.
I agree with you here that you have to go one extra step to open the Outline panel in the left. I would rather the Outline panel be in the right. However, I don't use symbols that often. My workflow is a bit different. So I don't particularly miss this feature. When I really need to look up by symbol, I just use Cmd + R and just fuzzy search for it.
> In the case of breadcrumbs, clicking on it with the mouse is probably faster than searching.
Again, this is personal preference. I find Command Palette faster. You find Breadcrumbs faster. But I guess since you already use Emacs, it is fastest with Outline panel on the right.
> I realize it's a unique workflow, that's why I want to know more why it's prioritized in every editor these days as I don't think this uniqueness qualifies it to ever become mainstream, much less prioritized.
Maybe Telemetry data shows that the feature is used a lot. I don't know. Even if it was by default turned off, I would turn it back on because I just feel comfortable having it on the side. I use it subconsciously so whatever I gave you were mostly from what I could remember. It is only when it is off (or when I am using another editor), that I subconsciously try to reach for the mini-map and find it jarring when it is not there. I gave you few examples. But I am sure there are few more that I am missing out on.
It doesn't explain why every new editor without telemetry data prioritize a minimap tho, surely it can't be that popular since there are plenty of established UI patterns more suited to the individual use cases you've described.
I mean, I can see why it got popular when Sublime introduced it. It was a time when most webdevs were editing in massive HTML templates, SASS/CSS and ES5, where the traditional outline view would return too much noise or missing important targets. But we've quickly moved past that era, it doesn't seem to make sense anymore for new players to prioritize it now.
Over time you learn what the various shapes in the minimap represent. It helps you generate an intuitive awareness of your location and what kind of content or data precedes and follows it--which in turn gives you more of an idea of what you're currently looking at.
You don't edit more than one file? Why would the shape meanings in one file carry over to another? Generally, the only signal that may carry over is the indentation levels. For the intuitive sense you speak of to develop, your file structures have to be highly regular across the board. TBH, I haven't even seen conventional Ruby on Rails code bases that can give me that.
Some shapes do carry over, e.g. in SQL dumps for certain types of applications. Spending a lot of time in one file, e.g., a large Rails controller, also confers the benefit. These are just two examples.
Overall I would say that trying to notice and measure the effect isn't productive. It's just a bit of extra context I realized in retrospect.
I thought I hated the minimap, but it turns out it was just too … large. The same signals I get from it can be compressed into the width of the scrollbar, and I find them incredibly useful. Navigating problems is either very mouse-heavy in a very mouse target dense area, or requires learning more non-standard keyboard shortcuts/chords, or just “click near the part of the scrollbar where the colors look wrong”. And it takes no additional screen real estate at all. (Which I’m not trying to conserve for pixel density, I run a comically large screen daily; but I try to keep things smaller to stay focused)
Its mostly useful to me if I’m scanning a longer file for merge conflicts. By clicking the minimap I can get to an error easily enough. It’s also a literal bird’s eye view when I’m reverse engineering something. YMMV
The minimap does help in passively locating where things are in a file, as "this is before/after this". It also gives a signature of which file you're editing just by glancing at the shape.
Not only the position in a source file is relevant for many languages, but if you're jumping to references/definitions blindly from another source, you can tell which source file it is and where you are in a single shot without looking at the rest.
That being said, I don't use the minimap. I did try to use it though to see what's the fuss around it. For me it takes too much horizontal space. I can have another vertical split pane instead of having minimaps showing. Heck, I'm not even using scrollbars.
Having an indicator of which function your cursor is currently inside provides very similar benefits to me. Not as immediate as a minimap I have to say, but more useful if you take the time to read it. This is a tradeoff people will argue on forever.
With my workflows, I really don't need that inch of my editor. The minimap is useful because it lets me instantly go anywhere in the file using visual cues. Some minimaps show you details when you hover or click and drag. Anyway, I have a hard time being productive without it.
In xcode if you put your mouse over a function it highlights the function, and puts a tooltip with its name next to your mouse. It's sometimes useful to quickly see what a given class contains and see how complicated it is (based on lines of code and number of indentations).
You could argue it's highly situational, but IMO it's nice to always be able to see how complicated your codebase is getting, tech debt is no joke
You are bothered by useless... Why did every new editor adopt the Visual Studio asinine default of fuzzy autocompleting (not only the new part) on enter or space? It's a stupid idea, with absolutely no upsides.
I didn't try this one (I'm not on a mac), but I fully expect it to do that too. All of them do. (I'll be glad if somebody tells me it doesn't.)
Came here to say this. In VSCode there’s the Outline panel that does the same thing. I find it incredibly more useful than the minimal. But hey, to each their own, I just disable the minimal and that’s it.
It can be very useful when the work you're doing requires jumping between 2-3 different parts of a file. Yes, you can probably do the same with ctrl-f, but for many people it's more intuitive to have the visual representation.
I've found minimaps to be useful when you're also using linters or compilers - you can quickly jump to the next error by looking at the little red dots or lines on the minimap.
Nothing to do with the IDE but I just want to point out that the homepage design is sick. The 3D space in the background did not affect the scroll performance and it adds a really good vibe without affecting the UX. Love it!
There was a design like that for another news yesterday or the day before. I wonder if we're headed back into the 80s with web design. It happened with clothes a few years ago (very high waist jeans.) There was no web in the 80s but there were arcade games and that front page looks like the start screen of some game back at the time. We'll see if it trends.
- Users’ familiarity with Coda as a reference point for its increased quality
- Statements about the hard work that’s gone into it
I say this as a huge Panic fan. It just felt ‘off’ to me, like the initial arguments for trying it are “look how hard we tried” and “it’s better than our old product”.
This may be an unfair assessment but it’s what stood out for me.
Although the page does rely a bit on things that mostly Mac fans will appreciate, I didn’t have the same impression. It’s fun to see how true Panic stays to their craft and it’s great to have the best native benchmark out there to compare to cross platform (web) approaches.
Congratulations Panic team! That's really great. I remember how exciting it was to first purchase Coda back in '07 or '08. Hopefully Nova works out as an equally awesome solution for those using Mac OS.
FYI they actually launched in 2020 [0], but there were a paucity of features back then compared to VSCode (like Vim mode). They've been updating it over the years so it's cool to see where they are now.
I've been trying Nova for the last couple of months. Native it may be, but the performance with larger files is not on par with Sublime. Also it has some weird bugs (mostly in Git and in the handling of files) and it does crash occasionally.
It's very promising though and if anyone can stick by a product it's Panic. Also their apps are classic Mac -- eye candy but with thought out UX.
highly usable but also EOLed and thus without security updates for more than a year now.
Aside of the security issues, I think it's asking a lot of a third party releasing a new product to ship with support for OSes not supported by their first-party manufacturer.
> For the curious, Nova has built-in support for CoffeeScript, CSS, Diff, ERB, Haml, HTML, INI, JavaScript, JSON, JSX, Less, Lua, Markdown, Perl, PHP, Python, Ruby, Sass, SCSS, Smarty, SQL, TSX, TypeScript, XML, and YAML.
Youre supporting stuff like Diff and Haml, but not stuff like Go or Rust?
Yep. Panic have always made tools that are mostly aimed at front-end web devs. Coda, the editor that became Nova, was marketed as a "web editor". Nova specifically still uses that phrase "web editor".
Coda's main competitors back in the day included tools like CSSEdit and Espresso, tools that helped those working on CSS by giving a nice front-end where you could click around in the UI and it'd insert the relevant properties for each style without you having to remember the syntax, and then updating a live preview. All of which seems rather quaint now we have pretty good developer tools in most browsers, but back in the mid-to-late 2000s, that was a big deal for a lot of web devs.
And for web developers who are writing predominantly HTML and CSS (possibly with some kind of template wrapping), a bit of JS, and a teeny bit of PHP/whatever on the backend, "it doesn't support Rust" etc. is not a major problem for them.
I wish there were more companies like Panic. Looking from the outside, it gives me the impression I got from pre 2004 Google and pre 2010 Valve. It seems like the primary focus is making cool stuff, and money is just a way to keep the lights on.
Reminds me a bit of GNOME Builder mixed with the (now defunct) Atom editor. Neither of them really clicked for me, but hey, at least it looks like they have VCS functionality figured out better than most people.
"Can a native Mac code editor really be that much better? Find out."
I'm pretty happy with VS Code, which is free (and before that, Atom, etc). Why put the onus on me to figure out why a $99 editor could be better? Show me. Tell me.
I realize that they make an attempt to show/tell down the page, but a list of features that my current editor already has doesn't answer the original question in the affirmative.
I managed to make Nova work for some trivial frontend stuff, but not having a built-in robust git client really threw my workflow off. I don't really like using a separate terminal for diffing, nor do I like the default diff viewer for git anyway, nor do I want to buy Kaleidoscope for a billion dollars for that one thing, which would be an external viewer anyway. Yes I want a native mac app, but it doesn't really count as a better experience if some of my interactions are slightly more spiffy and some key things aren't present at all. I do like something that is just a good text editor like TextMate was, but Coda and Nova were always trying to be in this middle-ground area. Macrabbit used to have a great app for thibg called Espresso which I loved for just CSS, HTML, and Basic JS. I'd give Nova another shot in a second if there was a significant feature-rich update, that includes things that other people rightfully get hung-up on.
Nova has something unique in both a product and market. The customer-base is willing to give it repeated shots before totally writing it off, and that's a blessing that the majority of companies don't get.
Maybe something like https://git-fork.com would work for you? It has a decent enough diff viewer (Even though I prefer Kaleidoscope for bigger rebases), is native and an actively developed indie app. I'm a happy user and can recommend it.
That actually looks pretty good, thanks for the recommendation. What I meant to emphasize was that I like having zero overhead to making commits, and vscode does this better than anything I've used. If I was so inclined, I could just use VScode as the default diff viewer and that would be fine, but I really like having it right there while I'm coding without having to go to any other app.
Bought this a year ago when I saw it on here before haha. Very happy customer, don’t need VSCode anymore - and I have Jetbrains for the “heavy” stuff :)
OT: How are "minimap" features in text editors actually implemented? Do they actually have a second rendering of your entire document running, just significantly scaled down? Are they building geometric shapes based on the shape of your text? What effect do they have on performance as document lengths grow larger and larger?
I've been using the VSCode remote ssh feature for a while now and I really can't see myself switching to another editor unless it also had a similar feature. Being able to quickly configure and use a remote server is just too huge a feature to give up now.
This looks great though, and the site is beautiful. Wish it was for me.
Nova does let you have projects with files accessed over a SSH connection. From the Launcher (project browser) window, select "Add Project…", then "Add Remote Project…"
I'm sure it does fine at that, but there are perils with SSHFS-type access (like file corruption risks when you switch between editing machines.)
And this really doesn't get close to what Visual Studio Code's Remote editing functionality can do. The Remote mode operates a full remote VSC environment over SSH or as a docker container, and that means things like being able to do find and replace at the remote end in the editor, but also manage git at the remote end using the built-in source control etc., but also it means support for extensions and build tools that run remotely.
It is astonishing.
I too cannot imagine going back to an editor that cannot do this. It has been so useful in conjunction with vagrant boxes, with a bit of ssh_config magic I wrote here that manages an ssh_config include file that (amazingly) VSC will follow:
> I'm sure it does fine at that, but there are perils with SSHFS-type access (like file corruption risks when you switch between editing machines.)
What does VSC do to mitigate that?
> And this really doesn't get close to what Visual Studio Code's Remote editing functionality can do. The Remote mode operates a full remote VSC environment over SSH or as a docker container, and that means things like being able to do find and replace at the remote end in the editor, but also manage git at the remote end using the built-in source control etc., but also it means support for extensions and build tools that run remotely.
Well, for search, there's still grep/git grep/ag (the built-in multi-file search might actually work over SSH; never tried it since I don't use it locally either), and for git, there's still, well, git. Nova (like Coda before it) is definitely more of an editor with some IDE-like enhancements than a full IDE, and I'm fine with that (in some ways Nova is even more focused since Coda had a built-in documentation reader and MySQL client and other tools I never used). Sometimes a nice butcher's knife is more useful than a Swiss Army tool.
Basically it's not running a block filesystem over SSH at all. You are editing your files remotely. So there is no risk of block corruption (which has bitten me on the arse before).
In fact, if you log in twice to the same remote host as the same user using VSC, your editors will magically update each other, live. This is the underpinning of a pair-programming aspect of remote VSC that MS intend to productise.
And if you log into that machine and edit a file that is open in VSC Remote using something like vi, VSC will know about the changes. Plus you can edit very large files remotely.
Yes, you obviously could/can do all of your git stuff in a terminal window -- that is how I used to work even with VSC before the Remote facility was added. After 30 years of using unix I'm fine with that if I have to do it.
But you lose all the editor integrations, because git cannot work effectively over networked filesystems. Whereas with VSC Remote, all of that stuff works exactly as if it was local. Including almost all extensions, which install into the remote. The normal file search does not work well over a slow SSH filesystem link, because to search all those files they have to be downloaded, whereas file search in Remote mode is done by the remote.
What I like about this is being able to work with pretty much any machine that can support VSCode, without having to worry about installing dev tools on that machine. I then also use Vagrant so I can separate concerns among my clients (I'm kind of working in a pre-Docker world in the wider sense in the job I do, still, so Vagrant boxes and my own configuration system are a good substitute). Or I could edit inside WSL2, while VSC itself runs on the Windows machine.
I think Nova looks very nice indeed, and as a Mac user and erstwhile Transmit mega-fan I wish them well, but I was never impressed with Coda, which was interactively slow in the editor -- in some situations painfully so. (The iPad version was an occasional lifesaver but I use GoCoEdit there now.)
But it's pretty inescapable that VSC Remote is its killer feature. It's just that unless you've used it, it's hard to explain. Now that I know how much it has helped me, I can't envisage going back if I have the choice not to.
I’m a longtime php dev using php storm on Mac. Php storm is ugly but the Symfony plug-in is great. My pain points are around local dev versions of different projects (never seem to get docker running) and running tests and setting up deployment pipelines. Nova doesn’t seem to move the ball in any of these areas
My biggest concern about this editor is actually the lack of cross-platform support. At our company, developers use a mix of Linux desktops, Windows PCs and Macs. And I think that’s actually an asset. Why force everyone onto the same platform? Developers know best what technical setup they are most productive with. Not to mention that being able to share settings and launch configurations across platforms is a big plus in favour of VSCode.
I totally get the performance argument. That’s why I will never use a Java-based IDE again. Like JetBrains IDEs are just painfully slow where every key stroke has this additional lag before something appears on screen. But thankfully VSCode isn’t like that. Whatever upside another editor might be offering wouldn’t make much of a difference for me.
I fear that the days of native productivity apps are over.
I'm truly confused about the notion of JetBrains IDEs being slow. I'm using both IDEA and VSCode, for different projects but sometimes even concurrently (because IDEA's Dart plugin is somehow dumber than VSCode's but IDEA's database explorer is so useful) and if anything then VSCode is slower with autocompletes and refactorings. Typing speed has never been issue with either so I'm really curious what sort of hardware you're running JetBrains products so that they are slower.
Ya no idea, I've used JetBrains IDEs for years and they've been great. I suspect a lot of people have 400 chrome tabs open and then open up their IDE and blame their IDE for being slow.
I've been following it for while, I really wanted to like it but I just do not see it (yet).
It's a huge investment to switch, and maybe I'm missing something but the only advantage atm seems to be "it's native". I don't have issues with speed, VSCode is plenty fast. Otherwise it's probably just struggling with plugins, and tbh I also don't particularly like how it looks.
That said, I hope they keep at it and give me a reason to switch!
Which is not impossible btw; I didn't like VSCode to start either (I was using Atom for a long time), but VSCode just won on support and that made me switch. It has come a long way, and I have come to like it after spending lots of time tweaking and theming everything.
Gorgeous design, I wish it would be available outside of the Apple ecosystem, I'd consider it even if I've been very happy with my paid Sublime4 license.
I think Sublime HQ showed that making a multiplatform editor is not much more difficult, but hey...
Indeed. If you ever poke around in the app you’ll spot platform-specific code all over the place. Sublime Text is one of the rare non-native apps that spends time caring about each platform, which generally gives them a huge boost when it comes to adapting to the platform.
Your last sentence….. The macOS version is awfully not-Maclike in ways that matter and that you can’t fix with plugins (last I checked). They’re pretty far from a native Mac editing experience, and nothing about Sublime actually requires that divergence; TextMate 2 is still a much better native-feeling experience.
Edit: that said, I’ve now realized it’s been at least three years since I tried Sublime, so this could be improved?
I mean I know it doesn't look very Mac-like but text editing matches native controls almost 100%, and they put in at least minimal effort to make windows and state restoration and whatnot work correctly–it's far better than most other cross-platform apps. It's no TextMate, of course, but is there anything in particular that's bad aside from the UI?
Nice! The download was painless, the memory footprint seems to be lower than VSCode. The set of extensions is really nice for 18 months of work since the original launch.
When will there be a Rego extension? (Rego is the OPA policy language)
VS Code is an Electron app. Pretty much anything that isn't a web browser will have a lower memory footprint.
Nova is a proper Mac app, which is one of the reasons I love it so much. No Electron to gobble up RAM and CPU needlessly and no slow multi-platform Java stuff with a wrong UI.
I love Panic and almost everything they do. I've bought many of their products and Coda was the first IDE-ish thing I've ever used. I love Coda but then I needed more powerful tools and Coda didn't cut it. Before Code 2 came out I had already move off them completely. I really wanted to like Nova and I hope others love it but I don't think I can go back from Intelij/IDEA. Best of luck to Panic in all their endeavors though, Transmit is my favorite app of theirs right now.
Hmm, no way to check syntax or run a file from within the editor? (or find the extension for the language you need?). Having a local terminal in the editor may work just as well, but that's a bit of a bummer.
To find extensions, select "Extension Library" from the "Extensions" menu.
Not entirely sure what you mean by "run a file," but under "Project Settings" ("Project" menu) you can set up scripts for building, running, and cleaning a project, and after you do so buttons to run those scripts appear in the toolbar.
In TextMate, you can say, run a Perl/Python/PHP script within the editor, and have the output printed in a new window. r just get a syntax check done on the file you're working on. Convenient.
TextMate is in comparison to Nova a little more "batteries included" in that sense - those extensions are already written and bundled within the app.
Without those tools in place, it's harder to jump ship to Nova.
Ah. Well, that's still something you can do with Tasks in a manner; just write a line of shell script to invoke the interpreter with the path to the desired file, and select "On Finish" from the "Open Report" menu that's near the bottom when you edit a task.
I can't recall a time that analytics have ever made a "fuss" for me, but that's not why I dislike them :(
I don't own a modern Mac, so I can't check the settings out myself, but that's the first thing I would look at after reading this in the features list. Looks great otherwise though, and it's cute how it rhymes with "Coda".
Yeah, I’ve never given it much though for personal use, but I’ve used VS code in a professional setting with strict policies around stuff like that, and “fuss” is a good word to describe the steps to use VS Code in that environment.
Yes, we need more competition. PyCharm feels so bloated and trying Nova, the speed is incredible. Keyboard latency is something that's underappreciated but it is night and day for me.
I was surprised to see that there is no language support for C++, C, Rust, etc... I saw that there are community plugins. But still, it does make me a little sad to see this shifting away from compiled languages to more scripted or web-based options, as for example: not a single (famous) compiled language in the default supported ones of a brand new code editor.
I like how Nova is getting solid updates regularly. It must be tough to write a new code editor from scratch knowing that you are up against VSCode, Sublime and Jetbrains apps. I think it's going to fit in nicely though, for a large enough group of Mac users to be a sustainable venture.
I'm not quite ready to replace my existing apps but it's getting there.
A cursory look at the Ruby/Rails extensions for Nova indicates most of them were created 1-2 years ago and haven't received any updates. I will check the vibrancy of the ecosystem a bit more before giving Nova a renewed try (it could be, of course, that these extensions just work without a hitch and don't need any maintenance).
The plugin architecture as of a few versions ago didn’t seem to be sophisticated enough to support s-expr languages. I expect this to improve over time, but it was enough to keep me from using the app/buying a license back then.
Same with Coda. I used it maybe four times, forget the price I paid but let’s say $40; probably came out to $10 per use. It was nice. I was happy with the purchase, or thought I was until they pulled the rug out. I thought it would have long term value. Planned to use it much more in the coming years when I get into some web projects. And now it’s orphaned. Why did they ask for my money if they were going to do that?
Love the apps that Panic makes, they are great on the UX front. But I'm still a bit hesitant to try/buy this. VS Code's rich extension marketplace has sorta 'locked me in' to their product.
Like other tradesmen I'm glad to pay for tools which make me more productive. Nova is the best code editor on the Mac in my humble (but correct) opinion and it has paid for itself many, many times over.
At $100, its coming in close to IntelliJ all product pack (I've had it since the Mayan end of the world).
Its also quite a bit more than BBEdit (which I've had since
If it was closer to BBEdit (which I've had since System 6 days), I'd consider switching the text editor - it looks nice.
For me, the price per year compared to products that I already have that have more functionality would be for something that I don't use as much.
It looks nice. If it was in the $25-$50/year, I'd be considering it for the situations where I open up VSCode instead of BBEdit for some functionality there... but the price for where it is in my toolchain doesn't replace something worth that much per year.
Though yes, the price if you're comparing a new purchase is $250/y.
Still, it's trying to get in the spot somewhere in the lineup of IntelliJ, BBEdit ($30 for an upgrade license, $50 for a new one, good for about 2-3 years with updates), and VSCode.
I would guess that if someone is willing to pay $100 for it (because the person likes the features that Nova has over their other tools), that it's likely that person will also want the new shiny features every year.
Also, I wouldn't be surprised that some plugins might take advantages of some new features.
I don't mind native apps, but if the trade-off is that it's platform exclusive then that's unacceptable in 2022. Platform exclusivity is such a massive step backwards.
I’ve loved Panic for a long time, going back to Audion back in the day.
Nova is the artisanal indie Mac app at its best. But unless your use case is exactly what Nova was designed to do, it doesn’t quite meet your needs.
Like a lot of people have essentially said, I love the concept of Nova, but it didn’t quite measure up.
In the meanwhile, Neovim (my primary editor) has really taken off and while some of the GUIs for it are great, they don’t have the fit and finish and polish of something like Nova.
Now if someone were to create a Panic-like UI/UX for Neovim, I’d pay for that in a heartbeat.
different strokes for different folks. I don't mind cross platform, but I find Electron unacceptable in any year as a massive step backwards in UI and usability. (Not that you mentioned any Electron-based competitors by name, but a lot of cross-platform big-name competition in the text editor space does use Electron, like VS Code, Atom, and Brackets.)
The competition they have to beat is VSCode and JetBrains - nothing else compares. Yes, VSCode is based on Electron but it shows that it can work well. That's the competition they have to beat. If I can't use an IDE because it's locked to a proprietary OS that requires me to buy specialty hardware to run it then it loses by default.
To echo what GP said, different strokes for different folks. For me I love that it's Mac native (whereas VSCode and JetBrains aren't, and it shows). I use nothing but Macs, and that isn't changing any time soon. Nothing but great for me.
Electron isn't the solution, but the fact that advocating for multiplatform usage on HN as opposed to boutique special Macs (because "I only use Macs and I love Macs") gets you (well, it was downvoted) downvoted is really sad. I only joined this community after the Apple CSAM incident after noticing this community began to lose their unyielding fanboyism for Apple products and began to adopt a more reasonable view on a megacorporation.
Seriously, what is wrong with this comment? Genuinely curious.
> Seriously, what is wrong with this comment? Genuinely curious.
Well, for one, it's telling another (highly successful) company how to run their business.
But also, I am a web developer who's been developing on Macs for all of my professional career and most of my hobbyist years before that. It's very unlikely I'll use anything else at least for the foreseeable future. I am grateful that there's at least one company that is making a decent Mac-native editor to help me do my work. Work done to port this to other platforms would be wasted on me, and at any rate cross-platform applications are great in theory, but in practice they, or at least their Mac ports, are very rarely well implemented and almost always stick out like a sore thumb when it comes to UX.
At any rate, if one really wants to shame companies that make single-platform software, there are a wealth of them doing that for Windows.
I wanted to love (Coda) it but it wasn't good enough for me to switch. This looks slick, but I work multi-platform so this while it looks great, if doesn't do linux I'm out. They even talk about the lack of cross platform in the copy. If I need speed I'll use Vim or emacs. For day to day I bought the JetBrains suite. For a pretty inovative company, it looks a lot like exiting editors.
I'll keep using Panic's transmit on Mac.. And hoping someone makes a sftp client as good on linux...
My main complaints at the time were a confusing extensions ecosystem; difficulty rolling your own; and the sense that (as with Coda) "programmer" means a person hand-coding web sites with HTML+CSS and maybe Javascript or PHP. Seemed like they weren't trying to convince anybody who already used VSCode et al.
That said, I have had some difficulty adjusting to Sublime's way of doing things, and VS never felt right to me, so maybe I'm just picky.
In any case I am happy to see another opinionated text editor in the mix!
[Edit: And right out of the box now, no support for Go files, not even syntax coloring, and it thinks go.mod is a media file and won't display its text. Searching extensions for "go" gets me three different extensions and no way to tell which is better/more-popular; and also shows me six totally unrelated extensions, three of which have "go" in their titles e.g. "django" and three of which do not. So... still not really shooting for the programmer market, but I will keep trying!]
[Edit2: Similar results for Rust. And extensions have to be written in Javascript, and the boilerplate is all for published extensions which maybe makes sense, but I really want an easy way to pipe ($BUFFER|$CLIPBOARD) to an arbitrary program and put the result in ($BUFFER|CLIPBOARD) with a pop-up on failure, and I find it really weird that there is so much shell integration but not that. OK shutting up now, playing with editor...]