> Here's a little editor story for fun. During beta we found some bugs in Apple's text layout engine that we just could not fix. Our solution? Writing our own text layout manager… from scratch. Not only did this fix the bugs, but it also boosted our editor's performance. We're not messing around!
Seems like there's nobody better than Panic at doing this sort of thing. They're willing to push Apple's UI forward, but they always do it in a way that feels Apple-y. Didn't they also pioneer a tab UI that Apple ended up adopting?
To me, the quote and what you put after came as a big surprise - I was ready to nod in agreement as you recognize this as a sad story about the platform.
The last time I was working on a text editor (KDE's Kate) and found a bug in the text layout engine it was written against (Qt's), I wrote a patch, submitted it upstream and it made everyone else's apps better, too.
I can't imagine the world of hurt, discomfort and frustration of developing against a lib set I can't read source code of or improve.
I've been a professional macOS developer for almost 20 years now and I can't tell you the number of times that this has been an issue.
With no access (or ability to patch) the platform source code you are left with a) hacky work-arounds, b) re-implement the component or c) change the app's design or feature to compensate. All of which are a pain / more work / risky etc, etc - just to work-around bugs in the platform.
Sure you can file radars (I do), but whether something gets fixed or not, is up to the gods...
That is likely to be non-trivial to develop unless you’re very comfortable with large, complex C++ projects and then you have to convince them to accept and ship ship it. That’s better than not having the option but it’s not for the faint of heart.
Chromium — yeah, seems like not friendly towards outside contributors, and nobody has convinced Google to accept stuff they don't care about (JIT for unpopular CPUs, support for new windowing systems, video decoding acceleration APIs, …).
Mozilla? Getting your patches merged is rather easy and very pleasant. Firefox is truly a community project we all build together.
Sure, but this is a thread about how Linux is better than MacOS because you can modify Linux. Those same criticisms you have I think could apply to Linux too.
True. In my experience though, it tends to work out. If 100 people are affected by a bug it's a drop in the ocean in the grand scheme of things, but now you only need a 1 in 100 chance of someone being up to the task! And the others can help with info and testing along the way.
Sure, but this is a thread about how Linux is better than MacOS because you can modify Linux. I think a Linux patch would take much longer to reach users. Modern browsers auto update frequently, but I don't think Linux users update Linux as frequently.
> It boggles the mind that anyone who can write code would ever use a closed source operating system.
Some of us want our work to actually reach people who don't write code or sysadmin their own computer, i.e. most people in the world. I, for one, think my effort is wasted if it doesn't benefit those people. So while working exclusively on a free-software platform is tempting from an ideological purity point of view (edit: and I envy people like you that manage to make a living doing it), I don't think I'd ever actually do it.
Edit: I should be more concrete and less snarky. Working on developer tools is good and necessary, and you can do that effectively on a free-software platform like Linux. But I choose to focus on end-user-facing software, particularly in the field of accessibility. I could work on desktop Linux accessibility, for the vanishingly small number of blind people who use desktop Linux (and that number is shrinking; one of my blind programmer friends just switched to Windows). Or I could target one or more of the mainstream platforms where the users actually are. I suppose I could work exclusively on web applications, but I don't think that would be the best use of my skills. And even then, while I could develop primarily on Linux, I'd have to test on other platforms too.
> Some of us want our work to actually reach people who don't write code or sysadmin their own computer, i.e. most people in the world
The majority of the internet is run on free software, and free software touches nearly every stack, even ones that are otherwise proprietary.
With regard to accessibility, there are open source tools out there that are pretty great for blind users, but they still need more work. There are also blind users that can't afford a Windows licenses or expensive screen reader software. I've worked with a local charity that helps people with sight impairments, and the money just isn't there when it comes to expensive software licenses and hardware.
If more open source options for people that have sight impairments become available, that would help a lot of those that are currently priced out of using modern technology for work, leisure and social interaction.
Or you could realize that your "mission" would be to break the chicken-and-egg problem, write more end-user-facing software in an open platform so that non-developers can actually enjoy the same benefits that developers do.
Someone has to do it. If you have the skills, why not you?
> I could work on desktop Linux accessibility, for the vanishingly small number of blind people who use desktop Linux
> one of my blind programmer friends just switched to Windows
Where they happy that their choices were being reduced to using a closed source operating system, now forever being dependent on the support of a giant corporation, partially because their friends like to write code that "actually reaches people" instead of contributing to an open and accessible solution used by a vanishingly small number of blind people?
Working on a free software platform is not mutually exclusive with reaching the majority of end-users. You can develop web apps for example or use cross platform toolkits for native apps. That's what I do and it works great.
One of the major selling points of the Editor posted here is that it isn't a cross platform app or built with web tech. Those already exist and it's great that we have choices but some developers like Panic have carved out a niche selling software thats very specific and tightly integrated into the platform. For those developers using the platform they're developing for makes a lot of sense.
I have a zillion plugins and vim is still snappy. Plus, editing requires so much less effort that it'd be better even if there was lag, which there isn't.
Do you not see how this is a self-defeating attitude? Do you recall when I suggested that you would be a great fit for leading an organization devoted to improving accessibility in free software? Have you resigned yourself to failure in the pursuit of improving access to open source for users with accessibility requirements? It'd be a pity to know that was the case.
I really wish you would step up and embrace the ideals you espouse, because I think that you could make an amazing impact if you applied yourself to it.
I like developing on Windows. Especially since the programs I write are run only on Windows. That's what the specific trillion dollar industry my employer serves uses mostly on desktop.
I don't want to tweak the platform. I want to concentrate on the code I write. I could be equally productive on OS X or Linux, but frankly, I don't care. They are all interchangeable computational substrates for me. As long as you can write any program on them, that is...
It's almost as if none of the replies read Drew's comment. Drew is talking about developing an editor for a closed source system and dealing with interfaces that break and then are hard to change, unlike open source systems that receive patches. It has nothing to do with "tweak[ing] the platform." Fixing a bug (which upstream would do, not you) is not tweaking, a bug is unintended behavior.
From your employer point of view you might be able to save a lot of time and money by submitting a patch for the bug upstream, instead of having to write your own text layout manager from scratch to work around an issue, which if you're unlucky won't even add any additional value to the client by itself other than enabling that feature.
As experienced devs with love of open source, they made this choice after thinking about it. They just have different value weights for their goals and those aren’t the same as other folks. Not a biggie
Is is not incomparably faster to fix a problem in an open source component than it is to write a full replacement for it? Would your employer not prefer to see you spend a few days digging through source and submitting a patch upstream than spend many weeks writing a text layout engine from scratch? The result is the same (working text layout), but the time (== money) required is substantially less in the open source situation.
I get your argument for a closed platform where you have a direct phone line to its developers that will fix any platform bugs you find ASAP, but MSFT hasn't been that kind of platform for years...
Naturally OS/2, BeOS, Windows, macOS, iOS, and even Android share some of the ideas.
Now, before I proceed note that actually modern Linux distributions have all the tooling to make these concepts happen, but it fails short to have everyone agree on a proper stack.
So basically, the main idea is to have a proper full stack in place for developing a Workstation computer as one single experience, from bottom all the way to the top.
On Xerox's case, they used bytecode with in-CPU execution via programmable microcode loaded on boot, and later on just a thin native glue on top of host OS.
The environments had frameworks / modules for the whole OS stack, supported distributed computing, embedded of data structures across applications (OLE can trace its roots back to these ideas), REPLs that not only could interact with the whole OS (commands, modules, running applications), it was also possible to break into the debugger, change the code and redo the failed instructions.
Linux distributions get kind of close to these ideas via GNOME and KDE, but the whole concept breaks, because they aren't part of a full OS, rather a bunch of frameworks, that have to deal with classical UNIX applications and communities that rather use fvwm (like I was doing in 1995), and use a bunch of xterms, than having frameworks talking over D-BUS, embedding documents, all integrated with a REPL capable of handling structured data, and call any kind of executable code (including .so, because the type information isn't available).
And then every couple of years the sound daemon, graphics stack or whatever userspace layer gets redone, without any kind of compatibility, because it is open source so anyone that cares should just port whatever applications are relevant.
It is quite telling that most Linux conferences end up being about kernel, new filesystems, network protocols, and seldom about how to have something like a full BeOS stack on Linux. Even freedesktop can only do so much.
> It is quite telling that most Linux conferences end up being about kernel, new filesystems, network protocols, and seldom about how to have something like a full BeOS stack on Linux.
They do, when they introduced the precision touch-pad. However ironically it created a lot of problems in software that responded poorly to the high precision events. Chrome being one of the most obvious offenders, took months for them to finally fix it (hence edge scrolling so much nicer then chrome on its release).
As long as PC laptops continue to use that terrible Synaptics touchpad system, they will always be inferior. Anybody I've seen who claims any PC touchpad matches a Mac doesn't know what they are talking about. And I say this as a user of both but mostly PC.
I'm kind of the opposite. I have a ThinkPad X390 Yoga and a MacBook. The ThinkPad touchpad is perfectly usable, but not great like the MacBook. The dealbreaker is that the Linux part of the ThinkPad is a complete pain (Intel WiFi headaches - went as far as submitting a kernel bug), while the MacBook just works.
“Solid” does not mean comparable. I have both high end dell and Lenovo laptops for work, and my Mac at home. My girlfriends MacBook Pro is far nicer to use despite being slower. Even for Windows.
Macs, with their amazing touchpads, are (at least for the moment and the last ten years or so) general purpose computers that can run pretty much every widely available open source operating system. This is a false dichotomy.
> that can run pretty much every widely available open source operating system.
That's just not true, though. Here's a git repo listing what works and doesn't work in Linux for all of the macbook pro models since 13,1 (released in 2016): https://github.com/Dunedan/mbp-2016-linux
You'll notice that power management (suspend/resume) doesn't work for any model, wifi only works for a few select models, and support for audio is pretty spotty. If you buy Mac hardware, you're pretty much locked into MacOS if you want to have a reasonably acceptable experience.
BSD support is much, much, much worse--it basically doesn't work at all for any relatively recent model.
The SPI keyboard and touchpad thing though is just.. WHY?? Everyone went with HID over I2C, Apple went with a completely new protocol over SPI. So annoying. I wouldn't want to work on supporting that crap.
> power management (suspend/resume) doesn't work for any model
um, that page says that you have to disable a power saving state on NVMe and it would work on any model with Intel GPU.
MacBook’s touchpad is so good that I was not using the mouse anymore just a few weeks after having my first Mac. It happened naturally and at some point I just stopped connecting the mouse.
Because like they just pointed out, you can only use this magical touchpad on a Mac running MacOS.
It's not like Apple benevolently gave this touchpad to the world, for our betterment and happiness, but for the singular, exclusive purpose of luring you into their ecosystem. But you don't benefit when they profit, you were the prize.
You should demand they give it away for free, because you should not give a shit about their profit because they (it) do not give a shit about your life or freedom or the economy of the social strata you live in. It's an alien machine that will eat you or it will fight you but it won't know the difference.
For me it's this, it's been proven I can get an OS that is open and free, doesn't mean I have to support and buy into some terrible multinational corporation whose goals I do not agree with, and that I get to have control over my own OS in a sense that is utterly freeing compared to MacOS or Windows. So why would I ever go backwards?
I pay Apple for hardware and software. I get good value in exchange. I don't particularly care beyond that.
You're trying to change this into an argument about freedom and open source. It's not. I want a trackpad that feels premium, the same reason I buy a nice car. I do not care how it's done and I do not care about the price.
tl;dr If the Linux ecosystem could provide it, good - I'd consider it. Put up or shut up.
100% of the time for me, I wouldn't wipe my butt with a trackpad, let alone use one for work.
It's always fun for me to meet people who do things the complete opposite I do them. It's oddly satisfying, like, I'm glad someone is my polar opposite on an issue or activity.
It depends. For lists, I do spaces. Allows for more levels than a tab would. But for everything else, tabs.
I've also grown to loathe that first-line tab beginning the second paragraph. It makes left-aligned text look wonky.
I loathe centered text too.
I'm not a rounded rectangle person.
I think the colored block UI that's all over Android, sites like HN, etc. looks tacky. We went from semi-transparent glass UI to flat colored blocks, and somehow interfaces got slower and more processor intensive. Now, that's a horse of a different color.
Trackpads are really un-ergonomic when they're attached to the laptop. Both your wrist and neck are bent because the trackpad and screen are attached that way.
Consider getting a separate USB trackpad and putting it in a "mouse like" position so your wrist is straight and you can raise the laptop to just under eye level.
I position my MacBook where I'd place my standalone trackpad. I could probably get a Magic Trackpad from work. But that would mean I need to carry another accessory with me.
So I'll have a proper monitor and a standalone keyboard in front of me. And the MacBook screen on the side is being used to display secondary information (chat windows and logs I don't need to actively look at).
Having the fingerprint sensor and the TouchBar lock button within reach are also nice (yes, I actually like the touchbar)
I use a dedicated keyboard, but I put the MacBook on side and use the trackpad as my mouse. It's smooth to use, has great gesture support for switching between applications.
And the most important feature for me. I can work a full day on it without any RSI related symptons. No other mouse can do that for me.
I use a normal mouse on my gaming rig, though. Because trackpads are awful for gaming.
If linux wouldn't require you to send patches upstream that would be great. Last time I checked the font rendering was off. So Linux seems to need to catch up to system 7 maybe? Certainly it's lagging osx 10.0.
The company itself would likely have become part of Apple if not for one bit of unlucky timing. Apple wanted to turn Panic's Mac OS 9 music player, Audion, into iTunes.
What order did the folders play? Was it usually just the order of the album tracks, or was it more folders of playlists where you custom ordered each? So you might have a playlist of playlists of programming music for instance.
I might be able to replicate this by building a front-end for it which converts it into a flat playlist for Spotify/Apple Music etc.
> Jobs wanted to know how big we were, and how long we've been doing this. He wanted to know a few more things that I can't even really remember. I remember he asked, "Do you have any other ideas for apps you want to work on?" I replied, genuinely, "Well, we've got an idea for a digital photo management program..." and he replied with a simple, "Yeah. Don't do that one."
This is a great example of how Jobs did not want to compete with his developers, he just want to make a better Mac for their customers.
That's such a great story that's equally well-told. I think that story is what turned me on to Panic in general. Their blog was a must-read for me for years.
It's not becoming part of Apple that's the success, it's earning millions, if not billions in one go and being set for life, both financially and in terms of reputation.
"Writing our own text layout manager… from scratch". I would be pessimistic of the magnitude of this statement.
I do a significant amount of text engine work and I'm skeptical what they implied by this. The likely case is they glued together other solutions (Like HarfBuzz/FreeType/etc) and expose their own API on top of that. This is perfectly acceptable and even encouraged for accessibility reasons. It may be that CoreText isn't acceptable for their use case.
What I think this would be misinterpreted as them writing the whole stack from scratch. For example, shaping is part of layout and it would be monumental if they wrote their own shaper given even HarfBuzz, DirectWrite, and CoreText do not have complete coverage yet. Additionally, BiDi + line breaking + shaping has bugs even in Chrome on some edge cases.
Like you I immediately had disbelief. However to most people assembling a pipeline like the one you indicated is equivalent to a new layout engine.... it struck me as normal to use "from scratch" here.
That's fair, the text rabbit hole goes fairly deep and most people aren't aware of the complexities at play. Implementing the glue on its own isn't a trivial task, so the work may have felt like doing it "from scratch". I only took issue with the wording and wanted to be a bit more precise with it on this thread.
For a text editor, why not just drop BiDi? I guess it sucks if you use a BiDi language for your comments, but there’s nothing per se wrong in making a solution that doesn’t work for everyone around the world if it works better for a subset of people.
You'd also want BiDi for general-purpose "text" documents like markdown. There are many aspects of text rendering that aren't necessarily relevant here (think: word- and line-breaking) but directionality strikes me as a major feature.
For what it's worth, I fired up BBEdit (another popular commerical Mac code editor) and pasted in some Arabic text. It didn't behave remotely correctly -- the text shifted around bizarrely as I moved the intertion point.
I think it's entirely plausible that Panic also shipped a text-layout system without full bidi support -- maybe that's why theirs is faster and less buggy on LTR text. The left-to-right language market (English, Spanish, French, Russian, Chinese, Japanese, Korean...) is probably big enough to support a Mac app development studio on its own.
I don't think saying to Hebrew/Arabic programmers "sorry, this product isn't for you because it would require a large amount of effort and we can't support it" is an unreasonable thing for a small shop to do. Yes, Apple and Microsoft and Gnome should support RTL because it's important for someone to do it, but there's nothing wrong with saying "this product isn't designed to solve all problems in all languages".
I also fondly remember how wonderful the web development deployment workflow was in Coda. This was back before source control was ubiquitous and CI/CD was required for any real production environment. It was the cleanest way I'd seen to go from saving in your test editor and having a clear path to SFTP it to the server. I half recoil in horror and am still in awe of how considered their experience was.
> This was back before source control was ubiquitous
Your memory may be playing tricks on you, it wasn't that long ago. Coda 1 had SVN support out of the box, and at the time SVN was already old and in decline, not to mention CVS and other lesser source control systems. By the time Coda 2 came out, git had won the DVCS battle, and was built into it.
Now, granted, back then I wasn't very keen on version control either but it's not because it wasn't there, it's because I was young and inexperienced, and didn't know any better. Plus, those days the only common use for source control was actually, well, source control, unlike today. It was something you had to discipline yourself to use for no immediate benefit.
From my memory in the mid 2000 version control and automatized deploys weren't ubiquitous for the audience Coda mainly targeted: web site development.
I started my career at around that time in a company using Python for web application development and everything was in SVN but already in the progress of being moved to git and while there wasn't a CI/CD server, all deploys were done running a single cli command. On the other hand for years to come I have seen e.g. people and agencies doing websites in Wordpress making changes directly in production.
In that circles, which often included people with no heavy technical background like designers that learned some php/html/css Coda was quite a relevation I think.
100%. Coda was especially useful if you weren't running your server stack on your local dev machine. Hit "Publish" and all your changed files are pushed up automatically. So much better than hunting through an FTP client every time you make a small edit.
They entirely rewrote something because apples implementation wasn't good enough, that doesn't feel appley to me.
"Appley" would be living with the limitations of apples implementation because apple knows best, and they tried their hardest to lock you out from any alternative option.
Can you share what bug did you encounter with the apple text layout engine? I too have written simple text layout code for a text editor (dealing with wrapping, tabbing, cursors and all those things), and those are the most logically chaotic and ugly code I've ever written, turned out buggy and not maintainable, I'm interested to know how other people did it
I really like their pricing structure here. If you want updates forever, it's functionally a subscription (which makes sense - constant updates require constant dev work). The key difference is that if you stop paying, you keep everything you've paid for previously (the app and all past updates).
As I understand it, the IntelliJ version you can keep using forever is the one from the beginning of the subscription.
So while the subscription was valid, you got upgrades, and then if you don't renew, you have to downgrade. It's their way of nudging customers to keep paying. It's working for me.
This is a bit misleading; you only get a perpetual license for the version you had at the beginning of the 12 months, as you can see with the second graphic[0] on that page.
The version is refreshed on an annual basis of payments. So your fallback version will always lag, but it won't be significantly out of date if you have a 4 year old account, for instance.
There was some confusion, and I'm not sure if they changed policy, but IntelliJ gave you a perpetual license for the version on the day you purchased it, not the last version at the end of the support contract
Though it is made slightly (?) better for the fact that if you for 12 month consecutively, then your fallback license is upgraded to the version 12 months ahead.
(That is, the next sentence in the bit you quoted is:)
> You will receive perpetual fallback licenses for every version you’ve paid 12 consecutive months for.
I never bothered to understand what "perpetual fallback" actually meant until you explained it here. It seems like a fair arrangement except that some releases of IntelliJ have a notable quality dip while new features stabilize - it's a bummer if the 12 month period you pay into happens to be in one of those dips.
Sketch customer service recently described it to me:
"Your [sketch] license can accommodate up to 2 devices — one for each seat you've purchased, plus an extra one we offer as a special perk."
I had to reply specifically calling out that this was not a special perk. I've paid the full license price at least three times. It should be available to install on as many machines as I want if I'm the only one using it.
It is Sketch's job to catch when someone is abusing this and create tech to handle that.
I think that this is actually not about preventing privacy, it is to try and get people to move to their cloud product.
I've been spending a lot of time lately thinking about what I'd want for a subscription service. I've paid for subscriptions that allow you to continue to use the old version indefinitely, as well as subscriptions that completely turning off access to software at the end of the subscription.
I think the "use the old version indefinitely" is actually irresponsible as soon as the application opens a network port: it's critical for users to apply security updates as frequently as possible. I don't want any of my users finding the need to run older software: it puts them at risk, and makes customer support more difficult.
So, if users can always run the latest-and-greatest regardless of their subscription status, (it seems that) the only way to reward people for having subscriptions is for some subset of functionality to only be available to subscribers.
For PhotoStructure's case, I'm not willing to hold their libraries "hostage" in exchange for an active subscription, so even when people allow their subscription to lapse, they still can open and browse and interact with their libraries using the latest-and-greatest version.
Paid features are (like auto-updating "smart" folders, auto-organization, geo lookups, and face detection) are applied if a subscription is active.
I'm hoping this will be a reasonably fair approach, but I know that it's always a challenge to get people to pay for anything.
I'm doing the same, with https://httptoolkit.tech/: the core features are free, but there's advanced extras that require an active subscription.
I'm this exact case you cover: it's a powerful developer tool that's very connected to the network & captures the traffic of many of your other apps & devices. It _must_ stay up to date, or users could be at serious risk. Holding back updates from users would be irresponsible. I've noted this in the past, but never really spelled this out fully, and it's important context, thanks!
For cases like ours, the upside of freemium over simple paid software though is that the end of the subscription doesn't completely shut down a user's life (unlike totally losing access to your IDE, or your cloud data), and you do need to ensure that. Instead the free user limits are put back into place, but those should generally make workflows inconvenient or less effective, and not catastrophically blocked.
In my case, for example, free users lose the ability to import/export collected traffic, but the exported HTTP traffic is in a standardized format anyway (HAR: http://www.softwareishard.com/blog/har-12-spec/). Some automated built-in tools go away too, but manual workarounds exist for free, for immediate & short use cases. Those fallbacks & that portability ensure nobody is ever totally locked up by the end of a subscription.
It's a very delicate balance (they need to be limited a bit, or nobody buys anything!) but it's been working well for me so far, and as a bootstrapped dev a free basic option is _incredibly_ useful as free marketing. Good luck with PhotoStructure - feel free to get in touch if you want to chat about any of this.
At that point, you're basically selling a freemium subscription, which is very hard to pull off properly for desktop software, and requires walking a very fine line: if too much of your functionality is paywalled, then the "free" version is useless and the whole exercise is pointless; but if too little of the functionality is paywalled, nobody will pay for your software. IDEs are a great example, because there is little functionality that is important enough to make users want to purchase a subscription, yet doesn't render the software redundant when a user stops paying and it's disabled. But I'd imagine there are also plenty of niches (like yours) for which this type of business model works incredibly well.
Sketch has a 'soft' way into making you constantly buy subscription. Plugins usually target only the latest released version of Sketch, so if you are dependent on plugins (and you ARE dependent on plugins if you use Sketch), then you either upgrade or eventually lose extended functionality. Because plugin manager will update plugins regardless of their compatibility with your current version.
if you need to hold back on an old version (whether because your license lapsed or whatever else), you should stop updating your plugins as well. They don't force auto updates or anything.
A lot of plugins require some external APIs. They get obsoleted way faster than you can imagine. And it doesn't end at plugins. If you use any design resources, they are more almost always using the most recent version, so you are doomed to load them with issues.
I use Sketch rather rarely once in maybe few weeks, but i've found out that it quickly becomes uncomfortable to use if you don't renew the license.
Main issue is that ongoing changes in the environment will eventually render whichever Sketch version you are using possibly unusable. I am on a version (that isn't too far out I think) that now can't save anymore on Mac (I suspect the file system/access changes they introduced). So where I previously had a version of Sketch I was totally happy with feature-wise, I now have one that I can't really use anymore. Would've been nice if there was a separation of "free fundamental" updates and paid-for feature updates.
That’s Apple’s fault. You could, say, dedicate an old Mac to Sketch and keep it on an old OS, and the setup would work basically forever.
I do think Apple could do much better with backwards-compatibility. They don’t need to go Microsoft’s extreme. I thought they’d found a good compromise for years on the Mac, but it’s tipped much too far towards just breaking everything lately.
But sadly Sketch is garbage now. I've gone from paying for v.x.0 - x.09 and its solid and stable. Now I pay $XX a year and it bricks with every update. It was a great program for awhile there. Its making me look at XD at this point... SMH
It’s honestly been made irrelevant overnight by Figma.
Once even one person on your team moves to Figma it becomes absurd to use something where you have to share fixed files around and are stuck with only using Macs for your design work.
I still use Sketch for things that only I work on outside of work because I’ve already paid for it but having living documents and being able to share with the rest of the company without them installing software is essential now. Not to mention being able to use my powerful PC workstation not just my Mac laptop is great too.
Sort of; before the SaaS was that big a thing (which coincides with general availability of the internets) we got annual versions, every year they tried to cram in features (and backwards incompatibility) to warrant upgrading to a newer version.
But in the past decade or so we've seen companies move away from that; leaders (I would say) are companies like Google whose Chrome browser was "evergreen" and released / updated constantly with no extra cost, and Apple who made iOS free and changed MacOS / OSX to the same system (although they still do only big bang annual updates, probably for marketing reasons), as well as pretty much all software on iOS - although with that platform, microtransactions also became a thing.
I have a similar, but slightly different pricing structure for my self-hosted analytics app[0]:
- Users can pay a monthly subscription, and while they are subscribed they receive updates and have access to support
- Users can also purchase a lifetime license (cost is about 12-14 months of the monthly subscription) which includes lifetime updates
Initially I only had the lifetime pricing but I recently added the subscription, my reasoning was that by having the subscription:
- It assures potential buyers that product will still be maintained
- They can try the product for a fraction of the normal cost (eg. pay only $7.99 instead of $99, so the risk is a lot lower)
- They can have the option to support me and the development as long as they're using the product
After I added the monthly option (I actually show it as the default one), the sales are about 50%-50% for each option (monthly vs lifetime).
There are also buyers who "hack" the scheme by getting a subscription and cancelling within a month, so they get the product but won't get any updates or support. I did expect this to happen, but I think it is actually a good thing, as most people who do this wouldn't have purchased the lifetime version anyway.
I personally don't like the SaaS pricing in general, especially because it is so over-priced. As a solo developer I am having a hard time finding affordable services to use. For example I use GitBook to publish my docs, their pricing is reasonable at $8/user/month, only that it starts at 5 users and forces you to pay $40/month. I would have gladly paid the $8/month for my usage, but $40/month for hosting a single docs website is absurd. The biggest problem is the so-called subscription fatigue, when you reach one point where paying for all the subscrptions you need adds up to a huge monthly amount. Not only that, but you also get all those monthly invoices that you have to take care of and pay taxes on. Buying a product is so much easier, you pay once, one invoice, you can use it as much as you want without worying about data caps.
Acorn's (an image editor) model is also good: They release major versions as separate apps on the App Store; Acorn 4, Acorn 5, Acorn 6. They're permanent purchases, and only the latest version is visible but if you had purchased previous versions you can redownload them from the App Store.
I wonder if this subscription model can be sustainable for web applications that have recurring expenses like server and storage costs. Does anyone know any successful examples?
It's strange that Nova would target web tech as their top priority, and not Swift. If you're Mac-exclusive, why not advertise top-class support for Apple ecosystem app development?
Since Nova is prioritizing web workflows, VSC is the elephant in the room and a very deadly competitor. It's free and open source, it's available on Windows, MacOS, Linux, and it can also be ported to the web. And it's Insanely popular and very high quality.
Meanwhile, all notable features Nova lists are default to VSC. One VSC feature that's been quite the remote lifesaver is shared sessions with voice chat.
Going for Swift means competing with XCode, which wouldn't make sense as Swift is generally used along with the entire iOS/macOS Dev tools (Simulators, UI Builders, Device Manager etc). Not a wise thing to do.
New thing this year, but VSCode + with Apple's SourceKit LSP extension [1] has been working surprisingly well for me. Glad to have more alternatives to Xcode.
Have been using SPM's "swift build" + some copy commands to create a fully functional signable bundle, no need even for an .xcodeproj.
Yes! The build just produces a single executable. For example, in a Mac app this would be the file inside Contents/MacOS.
You then need to create a folder with an .app extension, set up a simple folder structure, and add some necessities such as the Info.plist file and your resources like the app icon/images. And codesign or notarize depending on your deployment requirements.
Code completion works great for dev and I've found VSCode to be snappier than Xcode even if the underlying engine (SourceKit) is supposed to be the same. The only thing "missing" is not having Interface Builder, but probably most serious projects use code-generated UIs anyway. You could, of course, still make an .xib file in Xcode and use it in your VSCode project. (I don't have a MainMenu.xib myself.)
It's the same for VSCode and JS/TS support though. Fighting against a fully featured, free, open-source and well-established product just on the basis of speed is going to be an uphill battle.
The vast majority of developers aren't hanging out on HN though. I'll wait till there are real benchmarks but I'd be very surprised if Nova is actually noticeably more performant than VS Code.
Just the fact that Nova is ~36MB and VSCode is ~3x that at ~95MB should at least point you in the right direction. Also note that Nova already includes features that are only available via separate plugins on VSCode.
But 95MB is small enough that it doesn't matter—1/3 the size of basically nothing is still basically nothing. Even in terms of memory or CPU usage, VS Code is relatively efficient compared to some other products on the market such as the JetBrains IDEs.
Say what you will about Electron apps in general, but Microsoft has done a great job in making VS Code not feel like a typical Electron app.
> VS Code is relatively efficient compared to some other products on the market such as the JetBrains IDEs.
That's not really a fair comparison I think. JetBrains IDEs do a lot more than VS Code. You'd have to load it up with plugins to make something resembling a fair comparison, and in that case I'd be very interested in how efficient VS Code still is.
I completely agree, but I would wager that VS Code would still be noticeably faster even if it had all of the functionality that IntelliJ does. As a daily user of the latter, it seems like they have a lot more room for optimization, whereas VS Code seems to have been built from day 1 with performance in mind. But this is pure anecdote so I could be wrong.
It's more about "enough proportion of ..", and my 5 cents are that using mac hardware _always_ with a very tiny internet connection is kind of rare. So not enough to base an argument on, in my opinion. Kinda having expensive mac hardware most probably implies access to some time of a good internet connection to download/update tools needed.
React Native for Windows and macOS is developed by Microsoft, and they continuously show how Electron bloat means it uses 300x more resources than Win32, UWP, React Native applications.
My hope is that they create enough momentum to force the VSCode team to rewrite in React Native.
I wonder if they have a plan to move to iPad their codebase after it’s battle tested. There’s a lack of a serious editor over there, and in particular VS Code can’t compete because of it’s business model.
> and in particular VS Code can’t compete because of it’s business model.
What do you mean by that? If there was real demand for it, creating an iPad distribution for VS Code probably wouldn't be that difficult. It already runs great fully in a web browser.
I meant that it's open source with a mix of a number of OSS projects that would all need to arranged and accepted to be packaged in an app to be able to come to the App Store.
There has been interest in doing something to have VSCode in some way or shape on the iPad for a long time [0].
I see a lot of "you just need to" iPad on VSCode tricks that basically describe running a part of the UI locally and the rest hosted somewhere else (most fantastic setup I saw was to stick a RPi 0 on the side of the iPad connected through USB-C and VNC/SSH to it).
Codespacets is to me a variation of that, I'd want an actual node runtime powering a full native app with command line, native code execution etc. (a la Pythonista), and not just a reduced interface. I still prefer using Coda or Textastic for instance than coding in Safari.
I completely fault Apple for this, still doesn't change it looks like a dead end for now)
Every single limitation you mentioned will apply to Nova and other editors as well. It would be great to write and run code on an iPad, but that's simply not happening. Cloud-backed is the best we can do, and VS Code already excels at that.
VS Code is built with Electron, so making an iPad VSCode would require porting Electron to Safari (Apple doesn’t allow alternative browser engines on iOS) . That should be doable seeing as the VSCode ports to the web seem to work okayish on Safari, but it world be a pretty big undertaking.
I use code-server[0] to access VSCode on my iPad in Safari, and it works pretty well. There are some rough edges, but (aside from the better shortcut integration and UI polish) I don't think a native app is going to provide a lot benefit because I can't execute arbitrary code on the iPad anyway. You're going to end up with a mostly remote experience either way.
Targeting web development first seems like the obvious business decision. If building an Xcode competitor is a good idea, then it's still a good idea after you have made an editor that's worth using for broader tasks and vetted by the market.
People who care already edit Swift in their favorite editor and use Xcode for the rest of the dev iOS process. You'd be better off trying to capture the hearts of people so that you're their favorite editor than specializing to implement the "rest of the iOS dev process" on day 0.
As an iOS developer, I think most people start off disliking Xcode but then settle into a reluctant but productive relationship with it. The only things I need to use it for (device simulation, interface builder) are hard to build and yet they're not the things that annoy me about Xcode. Or rather, I wouldn't rather be wrestling with them on someone else's ultimately buggy attempt at reimplementing them.
> It's free and open source, it's available on Windows, MacOS, Linux, and it can also be ported to the web
Common misconception. VSC's most novel/valuable features are not open source. VSC is only "open core"; all of the real value-adds are proprietary and cannot legally be forked/reused.
> One VSC feature that's been quite the remote lifesaver is shared sessions with voice chat.
If they were to target a native "full powered" editor it would make sense to first capitalize on core competency. This editor definitely isn't for me but it makes sense for Panic.
I see a lot of folks here comparing this to VS Code and asking "Why would I use this instead?" — I am exactly on the opposite side of that equation. Why would I use VS Code when I can use this?
I've been using Atom for most of the decade (plus a bit of Sublime, and TextMate before), and I've loved being able to hack it to look and feel exactly how I want. There's a ton of custom CSS in my setup.
Now, Atom is slow. That is a daily frustration for me. The latency on every keypress is grating. I've stripped out every package I can, and that custom CSS I mentioned is mostly hiding things I don't want to see. But still, the lag! I feel it all around.
I tried switching to VS Code, but it was appreciably worse for me. I couldn't configure it to look as nice as Atom (and it had the unshakable feeling that it was made by folks from the Windows school of design — plenty of weird [to me] spacing and typographic choices). It also didn't feel any faster.
So why does Nova appeal to me? Well, Atom is no longer supported, so I'm going to have to switch to something anyway. Nova doesn't look as minimal as I'd like, but I can live with that — at least it looks nice! And it's a native app, so it should (in theory) be buttery smooth.
When it comes to a tool I will spend all day, every day in, $50/year is peanuts. This is my working life. It's worth spending a relatively tiny bit of money to have something nice instead of something good enough. Price is a non-issue for me.
As for extensions... I don't use any. I stripped them all out to try to make Atom faster. So now I get to discover what extensions are available, without being left longing for something I had to give up. Maybe I'll build an extension for myself. This is a new frontier for me.
So we'll see. I tried Coda, didn't like it. I love Transmit, though. So if this tool lives up to its promises, and succeeds on its own terms, I'll be thrilled. For the folks happy with VS Code... that's fantastic. I'm glad you have found a tool you like. For folks like me, for whom VS Code just felt off, this seems like a great option.
Honestly this isn't possible. VSC had better perf than Atom 4 years ago[1]. I say this as a long-time Sublime user, which is best-in-class[2] when it comes to perf.
> I've loved being able to hack it to look and feel exactly as I want
What is not customizable in VSC? When I first started using VSC, I installed an extension that made all my keybindings exactly as they were in Sublime, then I installed extensions to make it look almost exactly as my Sublime setup had looked (just took installing a UI theme and a color scheme).
If you want buttery smooth, Sublime is where to go. Native doesn't compete with Sublime's low-level text rendering.
But seriously there must be something wrong with your setup if VSC is lacking in perf and Atom wasn't.
I didn't mean to suggest that VSC was slower than Atom — only that it wasn't meaningfully faster. The fact that the typing latency felt equivalent (ie. not native), and that I couldn't visually customize VSC to my liking (despite spending days trying) turned me off it.
They didn't write their own text rendering engine AFAIK, they wrote their own layout manager. The layout manager determines where the lines go. I'm sure they are still using Core Text to render.
What do you think of Sublime? I'm like you and something about VS Code's design really bothers me. It's incredibly heavy and can't stop getting in my way. Sublime on the other hand feels like a sharp kitchen knife or a carbon road bike, it's amazingly light and nimble to use. I love it.
Really what I miss is 2015-2018 Atom, but it seems like its time has gone.
Sublime has fantastic perf, and for the first while with Atom (when it struggled with any file bigger than a few dozen KB) I kept Sublime around for big files.
But I don't like how Sublime looks. It doesn't look designed to me — it just looks like an accretion of features placed around the window. To me, that matters a lot. That is, after all, why I'm a Mac user. Why I'm fond of indie Mac software.
I change platforms many times a day (macOS, Linux, occasionally Windows) and VS Code being cross platform is essential for my use of it. Being Mac-only is a complete deal-breaker.
I've been testing cloud-hosted VS Code (Codespaces) for the portability between platforms and I'm liking it so far.
There are certainly drawbacks but running everything on the cloud allows me to code on a lightweight machine like MacBook Air or Microsoft Surface with extended battery life regardless of the workload. It also keeps the machine cool and silent.
That's pretty much my setup for the past few years. I find there's a significant productivity boost from being able to resume exactly where I left off hours or days ago, without having to depending on accessing with the same devices from the same location. For this, mosh + tmux are super lovely. I do use VS Code locally, but I export the filesystem, typically with sshfs.
How do you deal with the difference in common keyboard shortcuts / text selection with keyboard (i.e. option vs ctrl, command vs ctrl)? I also go back and forth between macOS and Linux and it always takes me 30 min to get the correct muscle memory back.
I have a mac vscode running alongside a windows vscode connected with synergy with a physical kb and mouse. At first the different shortcuts were annoying but with enough practice I just got used to them. Some of the lesser used ones like delete file I have to resort to using the mouse on mac, but I do try to make a conscious decision to learn both sets of shortcuts.
Touché. I do desperately miss macOS's emacs bindings across the board and the wonderful Cmd that leaves Ctrl alone. I constantly look for a Linux distro that actually "get it", but so far all I've seen are efforts to make it _look_ like macOS, without making it _feel_ like it.
It is a massive amount of work to rework every single application's shortcuts. Higher level frameworks (e.g. KDE) may have ways of doing so centrally, but most applications do not use the higher level frameworks.
If you were to suddenly change 1/3 of the applications on Linux to use Mac style shortcuts, it would make usability worse.
It might also matter what languages the poster is using. Programming typescript in vscode is a peerless experience. But writing C and Rust feel much worse - I get 200+ ms latency navigating around and typing sometimes, and cmd+click navigation gets janky and breaks very regularly in both of those languages.
I assume the culprit is half baked language extensions. I love vscode for typescript but I’d happily switch which editor I use for rust and C if I find something better.
Man, and I'm here thinking it's just my VSCode that's super slow and sluggish while editing C++ code. I switch to Clion and it's surprisingly more responsive than VSCode, given Clion is a whole IDE in itself.
Yeah I highly recommend giving VSCode another try if you ever end up writing typescript. Typescript in vscode is so great that its weird to me that Nova is targetting web development. VSCode sets a really high bar for this community.
In comparison, programming Swift in XCode lags so much sometimes that it starts missing keystrokes, and I end up with variable names that are missing half their letters. (This happens particularly when filling in a function's arguments). Its terrible, and it leaves me second guessing the idea that native editors are superior by default. This seems to me like a much more useful target for a new IDE.
I work with CoffeeScript (yes, I'm the one person, hah), SCSS, and HTML. No frameworks. No editor extensions. As minimal a setup as possible, aside from my two fave transpilers.
The perf I'm taking about is just purely motion to photon, with a plain text file.
> Well, Atom is no longer supported, so I'm going to have to switch to something anyway.
Is there an official source or announcement for this? I've noticed that recent release notes and changelogs have become much less substantial, but I've yet to see anything indicating that it's approaching EOL.
There isn't an official announcement but I wouldn't wait for one. The lack of updates coupled with the fact that Microsoft now owns GitHub indicates a very high likelihood that Atom development is practically dead.
Even if Atom itself is not dead the ecosystem is. The kick that finally got me onto VSCode was the stagnant plugin updates for things that were very important to me.
I haven’t really looked back, except that Atom had better git support in its native UI.
Looks pretty, but is there really no Vim extension? I couldn't find one on the Extensions page. This is a deal-breaker for me, I can't use an editor or IDE without Vim bindings, this would kill my productivity.
This was the first thing I looked for too. Perhaps one is planned or perhaps they're counting on the community to write one using their API.
TBH the only feature I truly use JetBrains for is their Cmd+Click to jump to definition, otherwise I'd be happy sticking with tmux+vim as IDE (as I did for about a decade).
I'm mostly well served by a slew of ruby/rails plug-ins along with tags - but this so answer might be a good, somewhat modern starting point. I'm going to check out if vimspector can help me with my debug flow:
I don't know which JetBrains product(s) you are referring to, but in IntelliJ you can use ⌘ + B to go a symbol's definition instead of using your mouse/trackpad with ⌘ + Click.
There's probably a similar shortcut in their other IDEs (try right-click > Go To > Declaration or Usages and note the key combination listed next to it).
Not to speak for parent comment, but the reason I use vim plugins in JetBrains IDEs is to have all that shit "just work". Yeah, you can setup stuff to autogen tags, but it's not always reliable. If you care about other IDE features (I do) then the list of crap you need to do to get vim/nvim to work properly piles up endlessly. I'll take the IDE with it's nice appearance and features and slap the keybindings in any day over the reverse.
I suspect the reason a lot of people don't seem to refactor their code is because they would have to do so semi-manually with whatever hip-but-feature-bereft editor they've sworn allegiance to.
ctags (which is the way I used to do it) was always sort of hit or miss for me. JetBrains OTOH just works. Apparently there's a new way of doing it though, which I should look into.
As M4v3R noted, what Vim does is not usually possible with just custom key bindings. If you're not familiar with it, I would highly recommend giving it a try; even as a beginner if you know only a few commands it'll still save you a ton of time. I find it hard to watch co-workers press arrow keys repeatedly or select text character by character when the same could be accomplished with one or two key presses.
You have two lines and want to swap them? ddp – that's it. 3 key presses. You have a string on the same line as your cursor and need to replace it? ci" – also 3 key presses (Change Inside "Quote).
No editor has configurable key bindings that can do this.
Vim support is more than just key bindings. The most powerful thing about Vim is that it’s modal, ie. you have several editing modes - insert, normal, replace, visual, all with their own set of commands.
I can do away Vim itself. It's the modal editing feature that I really need. That's why I am satisfied with IdeaVim even if it is not a full blown Vim instance.
I've been using the beta version of Nova for a few weeks now and I've almost used my trial period for the 1.0.
As a TypeScript developer, if someone made me choose between paying $99 for the actually-free VS Code, or buy Nova, I would by VS Code without hesitation.
Before it began getting long in the tooth I was a big Coda fan. On the whole I like VS Code but I do suffer the occasional runaway process so I am open-minded to a new editor from Panic.
Nova is faster than VS Code, but barely. I like the default rainbow indentation, though I'm sure there's a VSC plugin for that. The contextual spell-checking is excellent and I know it's a better experience than any VSC plugin.
But this thing can't even auto-format a comment block. You can't set format-specific options (so for instance no line-wrapping on only Markdown/MDX files).
The default editing experience is lightweight, and that's a good thing. But the plugin story is dire. Plugins like ESLint and Prettier crash constantly, requiring an app restart. Prettier has a format-on-save behaviour that seems to format after save on some file types. Typescript cmd-click definitions are broken, cmd-click import filepaths are broken.
It's not a bad effort but it speaks to how much ground they have to cover to get within the same galaxy as the VS Code experience. I genuinely think it'll be years before they can charge for this with a straight face.
This part of your comments nails 100% why, for me (web developer, 90% in typescript these days), it's nearly impossible to justify paying for an IDE.
Visual Studio code has almost everything that I need, and what it's not baked in, is easily done with a plug-in, which in the worst case I can write myself. But that's really a worst case scenario, since to this date it has never materialized as all my needs are covered by existing, and excellent, plugins.
I almost agree; but in my experience, JetBrains IDEs are worth every cent. I am more productive on them than in Visual Studio Code, even for "simple" tasks, like raw HTML/CSS/JS editing.
Weird, I can't stand them. Mine falls over on a moderately sized project and it feels like it's always melting while re-indexing-- which also totally blocks inspection operations.
In my experience, indexing takes longer, but after that the autocomplete is actually instant, as opposed to VS code’s ‘lets wait 10 seconds to show you the hint you might want to automatically import this’.
I’m flipping between Jetbrains and VS code a bit, but Jetbrains is by far the superior experience.
The proactive indexing sure does require a decent CPU and a good bunch of RAM, but most developers have both these days. I've noticed on Windows that anti-virus is a major bottleneck for Jetbrains editors, even with a decent CPU and plenty of RAM.
In my experience, the lazy autocomplete takes less resources at start but the result is that autocomplete suggestions are loaded in as files are being parsed. The larger projects grow, the slower this process is.
I suppose slower CPUs like the i3 series and low i5 series Intel chips will probably have a lot of trouble with the indexing. You need a laptop with a decent sustained core speed to do the work (which can be a major deal breaker in cheap Windows laptops and the lower tier Macbooks), but the few seconds wait you get on a professional machine when a project gets loaded in is well worth the wait to me.
JetBrain products (in my experience) are a ram eater, much more than any other IDE I've ever used, but in that similar vain no other IDE is as powerful as IntelliJ is for me.
I default to WebStorm and sometimes CLion and Idea. I recently tried Rider as a Visual Studio Community replacement, and holy smokes, it's really fast compared to VS+R#, looks really good, and has all the other JetBrains stuff.
R# left a bad taste in my mouth. It quintupled start-up time for my solution (which has dozens of projects, to be fair), and destabilized VS. VS and R# ways of doing things would often conflict, and IntelliSense would frequently break. Input latency was abysmal.
VS has now mostly caught up with their feature set, and the only thing I miss is namespace refactoring (which I could implement myself with Roslyn.)
Is R# just an exception, perf-wise, to their track record?
I guess it's how they have to implement it on VS. I tell you, CLion with Resharper++ or Rider with R# compared to VS is like night and day. Visual Studio takes 1 min woth R# to start and analyze a Unity project and the UI lags. Rider OTOH does it very fast and there's no noticeable lag with background tasks.
I tried WebStorm and made myself use it for 2 months. I went back to VSCode. WebStorm had its positives. I realized how much I hate setting up debugging environments in VSCode and how well they work in WebStorm, especially Node. I really liked the refactoring. But in the end, I preferred VSCode. I had performance issues (the team was fixing them and fixed some), scroll wasn't as nice, it ran worse on large files, the extensions weren't as nice in my opinion. Maybe I'll try it again in a few years.
> it's nearly impossible to justify paying for an IDE.
The reason I pay for IntelliJ IDEA is exactly the fact that I don't have to install any plugins, or fiddle with config settings, or really do much of anything; the product works extremely well out of the box with all of the IDE features I would ever want (and then some). The last time I seriously tried VS Code[0], I felt like I was constantly trying different plugins and changing various settings in order to get it working the way I want, and many of them weren't quite as polished as what I get immediately with IntelliJ.
[0]: Admittedly, this was over a year ago, so it's possible things have improved. But I'd rather pay $89/year than spend the time to find out.
I used Emacs for 10 years. When I started writing JS almost exclusively at my current job, I switched finally to VSCode (albeit with emacs keybindings).
The plugin/extension experience between emacs and vscode is, of course, almost an apples to oranges comparison. But VSCode is much better in that regard in my opinion.
I want yak-free IDE. After ten years my Emacs config is a herd of beautifully shaved yaks. VSCode is yak-free, for me, right now.
The problem I've had with VSCode - and also Sublime, as it happens - is that on a moderately large JS project it's something of a CPU hog. Both editors seem to do a lot of indexing, and this is even with loads of ignore folders configured.
The irony is that this has driven me to try emacs. I am being driven nearly to distraction by the fact that every single operation seems to almost glory in using a different key combination than any other editor I've ever used. Even TAB can't be used for indentation because emacs is "opinionated" (or, as I prefer to call it, "a twat") about it in most modes, but you can get what you want with M-i.
The thing it absolutely seems to nail is performance. I'm getting zero CPU thrashing on the same project, and auto-complete-mode, whilst not quite as good as VSCode's autocomplete, is much better than Sublime's. For one thing it seems to work well across files, even when using ES5 with no typing hints.
The payoff in a cooler laptop and longer battery life is worth the sometimes seething frustration in the meantime.
(Of course, at the moment I'm squandering most of that extra battery life looking up keyboard shortcuts, but that will pass.)
> The thing it absolutely seems to nail is performance. I'm getting zero CPU thrashing on the same project, and auto-complete-mode, whilst not quite as good as VSCode's autocomplete, is much better than Sublime's. For one thing it seems to work well across files, even when using ES5 with no typing hints.
Speaking of ironic, yeah. Emacs used to be the massive resource hog, compared to it's competition (BSD vi?) back in the day -- the joke was that EMACS stood for "eight megs and constantly swapping", back when 8MB of RAM was a lot. It's just that, after that, they failed to keep up with Wirth's law.
Ha! I remember that. The joke had started to come unstuck a bit by the time I first used emacs in 1999/2000 (my own machine had 128MB, quickly upgraded to 256MB of RAM), and we weren't making much use of the multi-user aspects of UNIX, but it still had some currency amongst older hands in the department (and in my first job or two).
One would imagine that most CPU load because of rescanning would happen in the language server, and those should be the same between VS Code and Emacs.
Yeah I tried to use Emacs, but the LSP had way worse performance than in VSCode and was very glitchy. I was disappointed because I really enjoyed Emacs in other ways, but I couldn't get that to work reliably. Maybe I was doing something weird.
In saying that, it's astonishing how much the the smart IDE features are better in Visual Studio/C# compared to VSCode/Typescript.
The text editor in VSCode is better than VS (multi cursor support isnt great in VS). I would love to see VSCode get the smart refactor features from Visual Studio, working with Typescript.
I would hazard a guess that this is more to do with the soundness of C# relative to TypeScript, which had to make many sacrifices to stay compatible with decade old JavaScript conventions.
> I genuinely think it'll be years before they can charge for this with a straight face.
Well, I payed for it a few days ago, and I don’t remember seeing any crooked faces. I very much enjoy it so far. Considering the scope of the project and the high quality of the design in every nook and cranny of the app, I think it’s a bit of a miracle that something like it even exists. Not even Apple makes Mac apps of this caliber anymore.
I agree that the competition they’re up against is fierce, but criticizing a 1.0 for a few hiccups and a small ecosystem seems misguided. They are offering something no one else is.
If I were them, I think I would try really hard to build a low-effort conversion process for VSCode extensions. If they can do that in such a way that the top XXX VSCode extensions could be used with a good experience in Nova and fix the couple of non-plugin gripes you mention, I think they've probably bested the VSCode experience for enough people to make it profitable.
I am not sure if I am pessimistic enough to call that "years" once they've got that migration path planned. If they're not planning something like it, though, then I think I agree with you.
It's a really high quality protocol, and supporting it gets you 95% of the way to supporting dozens of languages (only remaining work is coordinating launching the language server and connecting it to the editor, usually <100 lines of code).
Highly disagree. Having support for “python” is good, but useless without support for the ecosystem (poetry, pipenv, requirements.txt, virtualenvs, pytest, a REPL, Django-specific stuff, etc).
Languages are important, but I wouldn’t say they are ahead by a large degree.
That is somewhat above my pay grade, so to speak, but I imagine that you would need to write a plugin that talks to a language server (I think this is true for Code and other LSP-aware editors, too). You'd probably start by checking "show extension development items in the Extensions menu," then select "Create New Extension..." in that menu and choose "Language Server Extension" in the pane that comes up next. That looks like it creates a skeleton extension for you with the basic details filled in.
I was impressed with the way that oni2 did this, any vscode extension is a valid oni2 extension. I ended up sticking with neovim for the time being but I feel something similar could work for nova’s benefit.
> The default editing experience is lightweight, and that's a good thing. But the plugin story is dire. Plugins like ESLint and Prettier crash constantly, requiring an app restart. Prettier has a format-on-save behaviour that seems to format after save on some file types. Typescript cmd-click definitions are broken, cmd-click import filepaths are broken.
This is all fair. I've been using the beta on and off, and so far it hasn't compelled me to switch from VS Code yet. But this is a 1.0, and Panic has a pretty great stellar track record — I can see them closing the gap pretty quickly.
I hope so and I do root for them. But I remember Coda development felt sluggish compared to the pace we see in VS Code. And this 1.0 is something they feel is good enough to sell for $100, which IMO is wild.
Yeah, I kind of wonder if it might have been savvier for them to do something like "$29 for new users until the end of September and $49 until 1.1 ships." I appreciate that'd be a scary proposition revenue-wise, but I suspect the difference between "surprise hit" and "also ran" is going to depend almost entirely on how quickly they can get their extension ecosystem up to speed.
I like Panic’s products a lot, particularly Transmit, but for something I use day in and day out to write code, munge datasets to solve production incidents, build and run code, etc., I can’t imagine improving upon a terminal with vim and standard Unix utils. I’m not a total console-chauvinist, I use a GUI email client. But every time I’ve tried any IDE or graphical editor like this, no matter how customizable it is, it still falls short in comparison. At best they only begin to approach what I can do with Unix, but require tedious mouse aiming and typically introduce much greater feedback latency.
Have you tired IDEA (or siblings)? They focus on keyboard shortcuts and offer much more than vi can offer (full, integrated static analysis across with numerous languages and numerous context-sensitive tools like SSH, SCP, DB connectivity, etc).
I use IDEA and feel absolutely crippled and useless in vi. It's largely because I never use vi and don't care to learn it. I'm very impressed with the IDEA tooling. There's a vi plugin for it if you want to get a head start.
IDEA has the lead on raw features (and integration, since all the core plugins are made in-house), but at least on macOS the editor performs like trash. There are hundreds of milliseconds' latency for nearly every interaction, and that's despite spinning up the fans and impacting the rest of the system. I'm not a latency-buff; I happily used Atom until VSCode came along. But IDEA is unbearable in my experience (again, I've only used it on macOS so YMMV).
There are known issues with scaled resolutions on macOS and JetBrains IDEs. If that is the case for you, using a tool like resolutionator to scale instead of the native macOS scaler, should solve the performance issues.
It’s due to the Retina displays. The scaled resolutions don’t map in a clean way to pixels. The renderer renders everything at the native resolution of the panel and then has to downscale it to the scaled resolutions. For the “native” Retina view, it’s just /2, so it’s easy and pixel perfect. The others are more like /1.523134... and there’s more work to figure out what color each pixel should be.
I do use phpStorm for its interactive debugger during the rare instances that I need to. In any other language I would set a breakpoint and navigate the code from whatever terminal was running the code, but PHP is so awful that I can’t do that.
As far as IDEs go, I’ll give it 4 stars, but it still pales in comparison to writing VIM macros on the fly, jump-to movement keys, setting and jumping back to markers, being able to select lines in visual mode, pipe them out to any process I want and pipe the results back into my buffer, etc.
Running build tasks via clumsily configured toolbar buttons is absolutely horrid in comparison to make or any other CLI-driven build system that I’ve used (except maybe all the JS ones).
I think that depends what language you're using. IDEA is a must for Java, but vim with ccls works great for me on C/C++ projects and clion doesn't seem to do more there.
That's why I'm surprised they bother with the bathrooom sink. Everyone will use the code editor. Not everyone will use terminal/git. Make the editor first.
I’ve only just read about it thanks to your comment, but I’m wondering what advantage it has over just mounting a file system to share between your VM And host OS and just running commands via SSH.
I think the plugins run on the VM, and then e.g. a remote C++ plugin is actually aware of the linux environment on the host and can pick up the correct includes/symbols there.
Whereas if you have things locally the tooling assumes that you are developing for the local machine. There are obviously some ways to fix that - e.g. by pointing to a remote sysroot and overriding flags - but it's not a very straightforward process.
That's a shame. I love the vibe of this project and the VSCode monoculture gives me a vague sense of unease, but sadly it's really hard to compete with a tech giant that's putting all their effort into a free product.
For me the lack of auto-complete that _I_ prompt (ctrl+space / otherwise known as intellisense) is a deal breaker, and TypeScript story is completely broken. Cmd+Click (goto definition) doesn't work across files (though I do like they've implemented 3D touch as an alternative to Cmd+Click).
Update: looks like if you context click on a path > Typescript > Goto definition works; Weird that it is not unified with the editor's concept of goto def though.
Agree with parent that it's a valiant effort, just way too immature w/ no compelling features over VSCode at this point.
Edit: Native editor is compelling for battery, but not at the expense of developer experience - and even then, it's been quite a while since VSCode has felt slow to me.
I also had the beta for a few months and work exclusively on TS development for work.
Nova is a great editor but the hard thing is taking a step back and realizing that Microsoft has clearly designed VS Code to be the Typescript Dev tool in the same way that XCode is the Swift/SwiftUI development tool.
The leaps and bounds in features JUST for TS is incredibly hard to replicate mostly because it’s almost Microsoft’s exclusive goal with VSCode development.
I imagine if one doesn’t work in TS that Nova is far more competitive, it is not a bad IDE at all when judged on what IDEs prior to VSCode meant.
I love native Mac apps, I love Panic…but I’m not sure what this gets me over Visual Studio Code, besides a Preferences pane that isn’t inscrutable.
I’m not sure there’s enough of a market on the Mac for another commercial code editor, as we already have BBEdit for hard-core text wrangling. (And obviously all the open-source options.)
I'm not sure whether I'd consider Nova to feel that much more "Apple-y", especially when that meant something. BBEdit does that, this just feels a bit too MacOS/iOS convergent.
The market is huge. There are quite a few programmers, and they are more willing than most to spend money on software. Graphic design is probably bigger, but other than that? I know accountants and lawyers that are fine with Google Docs and Sheets these days.
As another datapoint, I seem to remember IntelliJ doing >100 Million € in revenue p.a.
Considering that for iOS/mac/apple platforms devs will probably chose xcode, and given the premium one has to pay for mac computers these days (justified or not, I'm not saying either), I fear the answer is no.
Most devs that do _not_ make native apple apps (e.g. web devs) do not need a Mac, so the market of devs that do not use xcode, that prefer a Mac and that are willing to pay for a proprietary solution, over other proprietary solutions, is likely not that big.
There are still a lot of web developers who choose a Mac even if they don't need one. Nice hardware running unix with a decent UI is worth a premium price to lots of people.
I think you underestimate how many developers are willing to pay for their tools proprietary or not. We know better than most how difficult it is to make software and so I think as a group are more willing to support each other financially.
> I’m not sure there’s enough of a market on the Mac for another commercial code editor, as we already have BBEdit for hard-core text wrangling.
That's going to be my issue with Nova, I think -- well, already is, as I've been beta-testing it. (I even have a theme in Nova's extension gallery!) There are a few things specifically relating to text manipulation rather than coding that BBEdit just does super well for me, and when I want a more IDE-like experience I end up in VSCode. Nova has foundation to be a great competitor in this space if and only if their extension library gets built out quickly, but that's, well, going to be a challenge. I'm still giving them a year of support to see what happens, though.
Mm-hmm, and despite my skepticism, I am also tempted.
What’s your experience with the theming engine? I use Hugo for my static site generator, and I doubt there’s a theme for that particular flavor yet. (I severely doubt my ability to craft a theme, regardless of how easy it is, but I am tempted.)
It was surprisingly easy to make a Nova theme -- if anything, it was a little easier than TextMate's theming (which is what virtually everybody else bases their theming on, it seems), and unlike VS Code, it supports changing background color in text runs. Which is actually something the theme I wanted to port uses!
> It's new, hyper-fast, and flexible, with all the features you want: [...] a Minimap
Do people actually find the Minimap useful for coding? If so, how? And why is it better/different than just a scrollbar, or searching?
I've always thought of Minimaps as a thing that seems like it should be adding something to the interface, but actually isn't at all. Seems like pointless eye-candy, to me.
I scan it for different colors in VS Code quite often. Oops, something red down there. Or quick scan to see where the various colored things that represent git diffs are (red for deleted, green for new, blue for changed).
But as you said, can get the same in the scroll bar.
I use my minimap sometimes. Some people are just more visual.
Like, if I have a big file that has a class somewhere, and I know I took a bunch of notes on it, I can scan the minimap for the big block of green comment text, and click that section to jump directly to it.
Regardless, I'm not really short on horizontal space in a world where monitors are huge and 80-character lines are still the norm, so it costs little to keep it there.
This is it. In my head the code file I'm working on is closer to a (geographic) map than to a Table of Contents in a book. There are large islands and small ones, some of the small ones form archipelagos (like grouped up constant definitions at the top). The minimap is good at conveying the "shape" and relative size of these code sections at a glance.
I feel the same about minimaps. In the same extract they list "editor overscroll"; the feature set must be limited to list that on the landing page.
> It's new, hyper-fast, and flexible, with all the features you want: smart autocomplete, multiple cursors, a Minimap, editor overscroll, tag pairs and brackets, and way, way more.
It's refreshing to hear I'm not the only one who doesn't like those. As stupid as I know this is, the Minimap actually kept me from trying Sublime Text initially, because it seemed like that was the big feature it was pushing in its earliest days. :)
I only use it to jump to sections that are modified from source control, flagged as FIXME/etc or have a compile/lint issue. Having the graphical representation of code density isn't helpful to me normally.
It's so hard to target web development with how fragmented the ecosystem is, so it's nice to see they have a lot of extensions already.
That said, because of how fragmented the ecosystem is, it is difficult for me to jump in. For example, my main side project right now is a Vue app that uses SCSS syntax in components, which the Vue extension for Nova does not yet support. This might sound like a small detail, but it's a total dealbreaker - and while, if this was a totally open source editor, I might be interested in contributing to the extension, I can't say that I'm interested in paying $100 and then helping out. It's a very difficult chicken and egg situation.
Panic makes the juiciest GUI apps and have the strongest presentations, but I can't stand an editor that isn't 60fps scrolling, feels like Atom all over again (downloaded VS Code just to make sure it's not my computer that's slow, and VS Code did give me smooth scrolling, curious about why a browser based editor is smoother than a native mac one)
ps. just found out they're the devs of Untitled Goose Game and Firewatch nice nice
I tried to open a 300MB file and it gave me the spinning wheel. If there's one thing I would expect of a new editor (and they even wrote their own text layout engine), then that it's designed for large files and incremental loading from the ground up.
Indeed. Great performance too (much more CPU efficient on Safari than Chrome for some reason).
Also: P3 colors all over :) the Nova logo burns my eyes nicely on the Ultrafine 5K's :) color(display-p3 1 .012 .29 / 1) learn something new every day.
The site reminds me of early Panic work which was also pushing the web envelope forward in tiny attentive details.
I see some interesting things here. The bundled Git tools look really clean, I like the overall UI, it seems to already have some of my most used extensions ported over... but as someone who paid for and uses Sublime Text and finds it to be more than enough text editor for me, does anyone see something here that is worth switching for? At $99 it seems to be competing directly with ST3 ($80, fyi), not to mention the free editors VSCode and Atom.
At that price am I getting much more than the satisfying feeling of supporting Panic?
Depends on what you are doing - and what you value.
I have VSCode and SublimeText both running all day. VSCode competes with Nova, not as much SublimeText. If your priority is beautiful Mac apps, at perhaps the cost of the more mature plugin/code support from VSCode, then maybe Nova speaks to you. If you are just slamming through tons and tons of text files, and just need a really high-performance text file tool - SublimeText beats out both of them.
I am so confused why they didn't put efforts into making this an iPad app. There is a market for something like this that developers are crying out for, but on mac why would anyone use this over VSCode (and pay $99 for the privilege?)
Panic has an iOS code editor -- right now it's built off Coda, Nova's predecessor, but I'm sure if there's market demand for it, an iOS version will be coming.
Having said that, a lot of software developers -- including Panic -- have not had great experiences trying to sell development tools on iOS. It feels like there should be a big enough market for this, but it's unclear there's actually much of one. If Apple brought Xcode to iPadOS it would likely require changes to the OS to support that kind of development toolchain, and that would make it easier for other companies to bring their tools, both commercial and free. But I half-suspect the official Apple answer to "when are you gonna let us develop on iPadOS" will be "may we interest you in this Apple Silicon-based, touch screen MacBook that natively runs iPad apps."
To straight up answer your question: Yes, I have friends who really like the iPad so much and wants to do development on it. Will it practically work? I really don't know. Until I see Xcode and/or Docker on iOS/iPadOS I am not very hopeful.
Yes - I do it regularly. Blink SSH to get to my workstation at home + tmux + [console editor of choice]. Works great when I'm somewhere I don't want to carry my laptop to, have a cellular connection, and find a few minutes where I feel like doing some work. For context, this is day-job work in high performance computing. The only awkward part is when I'm editing papers, although I've been happy with working copy (for git) + local tex editor/compilers on the iPad. Not ideal for producing final copy, but good for editing and drafting.
I’ve been developing full-time on an iPad for the past two years. I got the idea from a series of blog posts that were written in 2011, so it’s not a new idea. If you search Twitter for #codespaces you’ll see after Microsoft announced Github Codespaces (a web-based IDE based on VSCode), much of the attention was on how this will further enable development on an iPad. Personally I used AWS Cloud9 which does the same as Codespaces.
The iPad is a computer with a keyboard and mouse and a full-featured web browser. There are also language-specific native IDEs like Pythonista and Play.js. There are Git clients available natively as well. Pretty much the only thing you can’t do is make iPad apps on the iPad, which is a pretty small subset of programmers. Pythonista costs $10 and has nearly 1k reviews, so someone must be using it.
So why do people constantly ask “does anyone really want to develop on a computer that offers many development options?” The answer is yes, of course people seriously want to develop on an iPad.
I am currently on a long path towards a central machine that I can remotely access from an iPad (and a laptop). In addition to connecting via ssh or screen sharing, I'd love to be able to clone git repositories on the iPad and edit locally.
If I could Handoff something like a shallow clone of a git repo and its working index between iPad and mac, I'd be in love.
I think the main problem is what are you gonna do with the code once you’ve written it? There’s no way to run any sort of server or back-end service on iOS.
You're getting downvoted but a legitimate question is if vim binding support is coming or is even possible in the extension framework? VS Code vim binding support is very buggy and breaks frequently, but otherwise works well. I could see myself switching if vim bindings were better on this because I think the sweet spot of editors is a nice GUI/project tree/etc. with vim bindings.
It's worth checking out if the Neovim VScode plugin[1] works for your workflow. It's not as mature, but was much smoother when I tested it out. I'm not able to make the change until they implement a "toggle vim mode" command available... but once they do I'll jump. Also check out Onivim[2]
quickly looking at the docs, I see no support for keybinds without modifier keys or changing cursor shape, both of which are essential for decent vim emulation.
I agree. I like how light Vim is and its simple looks but I can understand why people may not like it. What I can't understand is how one can do without modal editing :D
You are some kind of special. I have heard tales of creatures like you, but they are very reclusive and tend to run back into the woods when spotted!
I am no vim ninja, but nor am I a vim novice. I can use it to write new utility scripts on remote servers, or updating existing files. However, when it comes to long coding sessions with multiple files in the package, I do enjoy a good UI with tabs and drag-n-drop.
I converted to IDEs when I was working on a humonguous enterprise Java application with thousands of classes, all with similar methods with slightly different signatures.
Also, because of the strong typing, the IDE knows which method is called where, and could thus support refactoring really well.
So if I wanted to change the name of the "save" method in one tree of 87 derived classes, but not the other 532 classes that also had a "save" method, then the IDE made that very easy. Of course, it changed the callers, too!
Wow, ok, never thought of that as a possible hack. Relying on the fact you won't ever use the kj combination. I'll keep that in the back of my head thanks.
I do the same (but with jj) and it's much better than escape. I do it with a bunch of symbols as well; e.g. years back when I was doing logic I'd use vim to take notes and bound AA to ∀.
Great to see the up-to-date pricing model find another high-profile adopter.
Subscriptions for non-service-based apps are terrible for customers, while major version upgrades make it hard for developers to plan around a steady revenue stream. Up-to-date models, as Panic has implemented with Nova, offer the best of both, with perpetual licenses for customers and a regular income stream for developers.
Panic seems like it would be a cool company to work for. I'm not a Mac guy, so this particular product doesn't interest me, but I've had my eye on the Playdate.
You couldn’t find the download link? The one that everyone else in this discussion is raving about?
It’s the huge blue button right in the middle of the page that reads “Download Nova for free.” They couldn’t make it more obvious unless the forced an auto-download.
Indeed somehow I missed that. Scanned right past it, even though I took a minute to play with the stars. I guess I registered the "buy now" link and then went right into the content section.
Clearly my bad, looking at it now obviously it's a prominent call to action.
I feel if a domain has a very well evolving, competitive open source offering (VS Code), it's really hard to sell something else if the feature difference isn't big.
Perhaps they should have started by targeting something other than web development.
Nova feels like an editor for 10, 15 years ago when they were making Coda. It feels like its for when you have a bunch of simple static HTML files and maybe a sass watcher.
These days, web development got both more mature, complicated, and simpler, all in ways that makes it hard for Nova to make sense.
It can also be a great motivator. The new app has a lot to do and knows where to make improvements. The existing app has then one up them to stay relevant. Adobe Illustrator and Macromedia Freehand used to do this with each release. Now you see it between platforms like FB/Insta/TikTok/Twitter etc.
For different reasons, I use VS Code (pretty, JS stuff), Sublime (fast), IntelliJ(rust) and a SQL Tool(sql!) at the same time.
I like the idea of coda of being more IDEish with transmission and ssh built-in, but one thing that no editor I have use is good at, is to see logs, sql and CVS/JSON data.
In the case of CVS/json, I kill for a way to turn it in auto-datatable with built-in search (do a lot of tabular data manipulation).
So, then after use sublime to load stuff, need ALSO to open excel OR numbers (which one open this CVS file is a gamble) do the edits there, then go back....
I love Panic and am pretty sure this will be a great app, but I have a question on the category.
Is there some reason that text macros aren't a built-in feature more often? I spent a lot of years using the very simple PFE on Windows because it had text macros and code snippets / templates. VS Code doesn't have them and neither does this one. Do people not find this useful or at least useful? I guess I do a lot of data munging with coding.
Anyone else tired of this underlying form for IDEs? I get why the side toolbars make sense, from a space efficiency perspective, but the amount of information to take in is always overwhelming from a zoomed-out perspective, considering the whole app window. Why do app designers continue to force us to select what to focus on amongst a sea of visual stimulation? Make it hidden by default, and appear only when we want it!
I feel like buying it to support them because Mac native app companies are few and far between. And Transmit was good when I needed to use it (haven't forever). And Coda was my main editor for a long time.
But I'll still use VS Code cause I work on a Mac and on Linux and it's nice for it to just be the same. And I have no complaints to solve with VS Code. It does exactly what I need for Python and other stuff.
I love Panic and I love hacking, and I started hacking on the Mac and will always have a soft spot for the macOS. I'm glad they built this and their other cool (but proprietary) software, despite the fact that software freedom is really important.
That said, I'll never use a toolchain that isn't free software. These are my work tools, into which I invest decades of muscle memory and configuration. Between Apple's lack of emphasis on long term application BC, and their increasingly locked down hardware (and I type this on an iMac Pro with T2 and firmware security on), I just can't invest my time and energy into the most critical of my development tools (an editor) that isn't going to come with me to any platform or device that I ever end up using, or, more importantly, be hackable.
It's sort of like fire insurance. I hope to never, ever need to use it (recompile my editor with a change), but the idea of having some of my most valuable resources/investments at risk, with no recourse should the worst happen, is insane to me.
Looks like it's still chugging along. There was a big twitter update a month ago with some in-progress third party projects from developer preview units that shipped.
Just downloaded, looks and feels great but I don’t see any way to configure a Python project? It does per-file syntax highlighting but no cross-file symbol resolution and I don’t see any place where I can configure the location of my virtualenv so it can find all the libraries. Am I just being stupid or is there no proper Python support yet?
> Can a native Mac code editor really be that much better?
I honestly thought that this must be a fork of Text Wrangler.
Footnote: Text Wrangler was merged into BBEdit and this was superficially complicated enough that I never made the switch. I think this is an I promise the problem is with me situation.
As much as I would like to use this, the lack of cross platform support is a big no go for me.
The same way I became 1Password customer _after_ they introduced support for Windows and Android (which I need).
It looks like a wonderful product for someone who is dead set locked into Apple eco system.
Eager to try this out. Coda was far ahead of its time, but became dated as others caught up. Hopefully Nova is just as far ahead.
Moreover, I'm getting tired of VS Code's slowness and quirks, so switching back to something from Panic would be great. If it crashes less often than VS Code, it's half way there.
For those who don't know, Panic is well known for decades for making incredibly high-quality software. It's not a big, flashy SV startup, but a small team in Portland that emphasizes quality over quantity.
Also important: Panic takes purchase orders, which is the only way the company I work for will buy software. A multi-billion dollar company where only the C-levels have credit cards. Panic bent over backwards to sell us several products.
Am a big fan of the clean, simple UI of Coda. And the SCP built-in for web development. Would never consider VS Code or Atom. If I did make a change and not migrate to Nova, I would consider Brackets. It looks to be the most Coda-like. Any thoughts on that?
Other than the Cocoa UI what feature did it introduce?
> Panic is well known for decades for making incredibly high-quality software
They make great UIs that for sure, but other than that I wouldn't consider them a great software company.
Transmit 4 is one of the slowest FTP clients I've ever used. [0]
Coda 1 and 2 were extremely slow. I remember years ago a coworker had to wait a minute or more to be able to open a medium sized file while Sublime chew it in a second or two.
Tried it out a few minutes. While I like the polish, this cannot (yet) compete with Sublime Text for me (and remote editting is one of the major weaknesses of Sublime currently, even with available extensions, while it looks as if it might be one of the strengths of Nova).
It already starts with the editor itself, which has only one word wrapping mode (the other mode is horizontal scrolling), where it will wrap the lines at pretty arbitrary locations due to its desire to implement "word" wrapping, instead of also offering a simple mode which simply breaks the current work :-(
If basic editting does not fit my style, it is a no go no matter what other niceties it might have, once the extension stuff starts going for real.
Unfortunately, I don't seem to be able to answer the only question I have, which is how they handle syntax highlighting.
I'm going to assume they support .tmLanguage, because it's the de facto standard.
Do they support .sublime-syntax? If they do, I'm interested, if not, well, I'd circle back if they add it, but lack of support is a deal-breaker for my use case.
More generally, it's a great splash page, but it doesn't appear to link into extensive documentation, and that's not a good sign. Should be right there on the top bar. This is a tool I'd spend hours of my life a day in, and every text editor in existence is an immensely complex beast which requires good documentation.
Lovely looking editor with a bunch of features, but they seemingly forgot to include support for something as ubiquitous as C? That's kind of a weird omission.
I'll be following the development of this, but for now I'm not playing with it much further.
Hm. Looks quite nice but does not work out of the box with fish shell and or Node installed using nvm only. It gives me a hint like this:
> Prettier couldn't be found because npm isn't available. Please make sure you have Node installed. If you've only installed Node through NVM, you'll need to change your shell configuration to work with Nova. See https://library.panic.com/nova/environment-variables/
Unfortunately the documentation is for zsh and bash only. Has anyone an idea how to get this up and running with any other shell?
I use Sublime Text 3 for nearly all my DevOps work. I figured that I'd give Nova a try as I was a big Coda fan back in the day.
I opened up Nova and first installed HCL (language support for HashiCorp's Terraform and Packer). Then I looked for Shellcheck[1] validator, but was disappointed it did not exist. Then I search for Kubernetes and Helm wondering if there were any specific extensions, but no results. Next up was installing Dockerfile and ENV syntax highlighting.
Overall still tinkering around, but Nova seems very promising.
Is there a vim-mode? If so, is it any good?
I couldn’t see any mention of it on the webpage or in the extensions.
I used to love Coda back in the late 00s, especially for its live CSS mode (not so revolutionary today with this built into every browser these days), and would happily give Nova a try if they support a decent vim-emulation mode, but without it’s a non starter for me. These days I feel heavily handicapped without it, just recently some tool dropped me into nano and I felt like a child adding random characters to various places in the document while trying to force myself to navigate the text correctly, muscle memory is a strange beast.
While this editor looks very nice I'm still confused on why I would use this over sublimetext or vscode. It doesn't try to contrast at all just lists a bunch of features that I already have in other editors.
Edit: I think my performance with the background is a super niche one. It runs fine in Microsoft Edge on my Windows install on a Macbook Pro 2015, but not on Chrome.
The animation is really cool especially that onscroll effect!
I don't think so. I've never had any site, even ones that use complex animations like Stripe's site bring my machine to a crawl like this. I'm pretty confident it's the Canvas animation causing this. I disabled JS and the site runs fine.
Sorry, I was just making fun of the specific model laptop. I'm on a 2016 model, and my s,d,f,t, and left-cmd key caps all come off while typing. I would love to see how much it is going to cost me to have fixed, but I've had to live with it since all of the Mac Stores in my area were closed. Now, I'm just used to it even though my WPM has taken a major hit.
> We don't have built-in diff yet, but it's on our list!
Fair enough - a good diff view has a lot of subtleties.
One of the things i love about IntelliJ is having access to most of the normal editing tools in the diff view. If i'm reviewing my changes for a commit and i realise a method name could be improved, i can refactor-rename it right there. For some reason, possibly just keybindings, i can't use the broader set of refactorings (extract, inline, etc) in the diff, and i wish i could use those too. The diff could potentially be my main interface for programming.
I haven't found a diff tool for macOS that is as good as WinMerge from fifteen years ago.
Kaleidoscope is fairly close but you still can't merge individual lines from a block of changes, and you can't make up for it with manual free-form editing of the text. Sometimes I want to perform the merge by copying and pasting segments myself. Sometimes I want to fix up indentation after merging.
Really, how? I've got a Kaleidoscope merge open right now and I can't edit text. Is there a mode I need to toggle or a button I need to press? I've looked through all the menu items, preferences, all of the toggle switches in the UI, and searched the documentation. I'm running version 2.3.2.
(But you can when dealing with merge conflicts? Wow. Quite remarkable for a seemingly basic bit of core functionality to stay humming on the to-do list for seven years, despite the very same feature already implemented in a nearly identical context!)
Ah, I’m so sorry. I said it was the exact thing you were describing, but I misunderstood you. I indeed meant conflict resolution, and it is surprising they left it out elsewhere.
Seems like Panic is billing Nova as a text editor only—not necessarily an IDE. They’d have to add in functionality for a whole host of other things to make that a reality, including compilation, build, debugging, and so on. I doubt all of that can be done with their build scripts and extension framework alone, but, hey—I’ve been wrong before.
The state of the IDE landscape on Mac amazes me. It seems like there a $#!*-ton of Java/C++ developers using standard-issue MacBooks at Big Corp, Inc. who are staring at ugly IntelliJ windows for eight hours a day.
If there was a native-feeling, good-looking IDE for the Mac I can’t imagine why it wouldn’t print money. (Or if XCode ever decided to branch out beyond honest-to-goodness support for things other than Objective-C and Swift...)
IntelliJ is definitely ugly, but not quite as bad as NetBeans or Eclipse. It's really powerful though and I prefer WebStorm and PyCharm for a number of things. I think it's because of how complex the interface is, combined with looking like a cross-platform app. It feels to me like I'm using a Windows app that happens to run on mac.
Long-awaited. Enjoyed Coda for a long time, then switched to Atom. It looks like a polished Atom version, and Nova is likely going to replace Atom for me.
Not that it's a bad thing but it looks like the extension API and architecture has lifted a fair amount from VS Code.
I kind of wish they went all in on LSP and made their extension API via additional JSON RPC methods on top of the base protocol. Because that's what extension authors are using to share code between an extension/editor, LSP is the only thing somewhat consistent and the client surface area is tiny.
I love Panic. Transmit was awesome when I needed a great sftp client gui. But I don't need it anymore.
Coda was baller. But I don't need it anymore.
I think I'll go ahead and buy Nova to check it out and support them. But VS Code does everything I need and I have no complaints about it. Plus I can use the same editor on my Mac and on my Linux desktops.
I find it interesting they're getting into this space, but more power to them.
It's not a matter of keybindings -- Nova is a modeless editor, and Vim is a modal one, so you need to have an entirely different interaction model. Not every editor's extension system is capable of that. (AFAIK, Vim itself isn't capable of changing interaction models -- while I've seen "Emacs keybindings" for Vim, they don't make Vim into a modeless editor.)
I just don't understand why all this work didn't go into making an iOS text editor. Why did they choose Mac OS? It's the most saturated platform when it comes to editors.
Meanwhile, the only thing that keeps me from using my iPad Pro full-time is the lack of a serious text editor and terminal.
Probably because for most of the use cases, you couldn’t actually do anything with the code you write without involving another machine. It’s not like you can spin up a node server.
I too would like to use my iPad Pro for work stuff, but I would say the thing standing in my way is Apple.
I'm a bit confused by the value prop here, or maybe I'm just missing it. There seems to be much talk of theming and extensibility, features which every existing text editor has.
This is not meant to put down the product—I've bought and enjoyed multiple Panic products in the past.
I probably won't use this (I'm fine with my current editors) but I want to give the creators credit for what looks like a very complete and feature-packed first release. So many things on day one! Nice to see software that looks ready to use.
Nova is pretty, i liked the synthwave neon mode (probably would not use it for an extended amount of time though). Markdown preview was not great. App crashed when I attempted a git commit. I think I'll wait for a little while before trying it again.
Does anyone have React Native + TypeScript development/debugging experience with Nova? I'm currently using Vscode, and I'm wondering if I should have a look at Nova for this. (Nothing wrong with Vscode, I'm a bit into adventure)
Ok, so some feedback: I'm sad to report I stopped testing already. For my particular job I tend to debug and work with large files, especially JSON. A lot of debugging apps and looking through large crash logs, then looking at application states. This is probably not typical, but it's crucial to me.
The transition is made hard because of the odd default key mappings (they hotkey editor is very difficult to use. I went back and forward and couldn't understand why my mappings weren't working only to find that it was due to having to use the hotkey editor in a specific way). I really think a good keymapping is the first hurdle people have to overcome, so shipping it with an hotkey extension for Sublime, VSCode, etc. would be a big win off the line.
The autocomplete and jump to definition seemed to work well. I had a hard time figuring out if "Find references" were working. It kept telling me to go to some obscure tab or place somewhere but since it's all symbols, I don't know where to actually go. VSCode is easy by comparison - a "peek" window shows up prioritized references.
However, Nova is a no-go for me because it simply stalls when opening a >2 MB JSON files. Forget about trying to search-replace - it's simply too slow. In defense of Nova, Sublime also can't deal with it.
My impression going away from Nova is: It's like Xcode and VSCode had a baby. Perhaps with time it'll improve in performance and be fine tuned to a point where I can use it daily - but given it's primarily paid (not "free with nag screen" like sublime), I can't review it any time soon again.
I see. So I think I won't be giving it a shot too, at least for now. Let's see where Nova evolves, if it does. If it becomes some obscure hipster tool where developers with some niche need use, I'll leave it alone. If the baby of Xcode and Vscode grows up to be a wonderful, mature IDE, sure, I'll give it a try.
Thank you for your detailed review, greatly appreciated!
Given that it starts with the huge handicaps of being proprietary and commercial, requiring a proprietary OS with very limited hardware support, and having far less extensions than VSCodium, it seems very unlikely it can compete.
Panic should stop making editors, and if they _must_ make a new one, they should not continue to make and market "web" editors.
There is a class of tech workers who find apps like this and then stop exploring. As a result, they become marginally effective using Panic's oversimplified workflows, and then stop exploring. I'm thinking in particular of Coda's remote editing - and wouldn't you know it, remote file browser is a promoted feature of Nova too! Built-in diffing is "on their list".
So I naturally assume that anyone who uses Panic's apps is incompatible with any project I'd be working on; because they're going to try to educate me on how much simpler and faster remote editing is than using a VCS. (Edit: and it's not their fault, it's Panic's fault, for trying to make money off text editors for people who are afraid of the command line.)
"IC 009. US 021 023 026 036 038. G & S: Downloadable web site development software; Downloadable computer software development tools"
I guess the trademark it's very specific and not in conflict with let's say a model of a car. But also other companies can challenge the trademark later if they deem it in conflict with theirs.
Landing page UI took me by suprise. It's refreshing in some sens, but little bit broken. Can't really click on the items in the navbar. Have to scroll down little bit first, and only then the links are clickable.
I'm mixed on these Mac only apps. While they do look/feel better than cross platform apps, I really, really love being able to use SublimeText on my work laptop (Mac), and my personal desktop (Linux).
I'm just happy to see Panic still exist. I loved their FTP client and most of their macOS "classic" software. Apparently the FTP client still exists actually :)
Platform exclusivity should be a thing of the past, especially as technology to make cross-platform apps has become so accessible. For me the app becomes practically useless as soon as it's only on one platform as I frequently switch between Linux and Windows.
The developers in my team work on a mix of MacOS, Linux, and Windows.
In the face of VSC, a MacOS-exclusive app simply does not compete.
And for me any app that becomes cross-platform loses some appeal. I do not swtich paltform when writing some code, so all those compromises and trade-offs made in the name of being cross-platform are a loss to me, not some gain.
More and more I see new apps being released and having a subscription model. Pay X for the tool plus Y every year to get updates. Paying 99$ and then 49$ each year is (at least for me) too much money and a no go. If after a year bugs are discovered on the purchase that I initially made, why shouldn't I receive that for free? Subscriptions are ok for services and I don't really care, but products shouldn't be on a subscription model. Just my opinion.
They call it “native”, but I don’t know, those screenshots look nothing native to me. Being “native” doesn’t just mean having a C++ codebase, it also means using the native OS UI frameworks.
It does look like it uses Cocoa. What are you seeing that doesn't look like Cocoa? Custom controls doesn't count; those can still be based on NSView and use other Cocoa controls in their implementation.
Even if NSView-backed, custom views that replace basic functionality aren’t really native to me. Here, the entire window frame, all widgets, etc. are not native. It looks, to me, like an Electron or RN “app”.
The only custom controls I see are the tabs, tab bar, and a few modals (like when opening a new tab), and a handful of buttons and segmented controls in the sidebar. Everything else is native, unmodified Cocoa controls: NSWindow, preference window and its contained controls, the sidebar, etc.
I actually am a bit curious about the decision to have those NSButtons with custom backgrounds … they don't really look right both on Catalina or Big Sur. Native-looking NSButtons are used everywhere else, though.
> the entire window frame
About the only thing that looks unusual here is the custom buttons at the top-left with the diagonal lines. No more custom than Xcode, iTunes.
If the problem is that the toolbar seems to be in the titlebar, that's been an accepted, Cocoa-supported window style for a long time — and much more prevalent in Big Sur.
It has the correct translucency behaviour in Big Sur. Maybe one day they'll update it to use Big Sur-style full-height sidebars.
> It looks, to me, like an Electron or RN "app"
Electron and React Native apps wish they could integrate with Cocoa as well as this.
Those never look like anything more than a plain NSWindow with a plain, thin titlebar with a web view inside — or worse, not even an NSWindow but one painted with custom controls.
Electron “apps” don’t have much of a choice; they can’t even add toolbar items. This is why it puzzles me why a Cocoa app would choose a unique look. I am just not a fan. Regarding theme frame, it looks like a different gradient to me. It certainly isn’t how it looks like Bug Sir.
As a small business owner, I envy Panic, in a good way. They do great work, and charge good money for it, and people don't mind paying because if you know Panic, you know their product is worth the cost. That's priceless. I wish they did more, TBH. I'd pay just to enjoy their work.
They are a Mac developer shop from day one and that's what they are good at. If they'd start building some hybrid cross-platform solution they'd compete with VSCode and all the other free or cheap editors. Doesn't make sense at all.
I don't mean to complain about Nova, but I don't think being platform-specific is something to be applauded (in itself). It's like making your webapp only for Chrome -- that's not a feature, per-se.
Platform specificity typically comes with native performance and, in the case of Panic, a UI that closely follows OSX conventions. For some (many?) these are meaningful value-adds.
Ah yes. Nova, the team that sent me the most pompous “rejection email” I’ve ever had for a product.
“You weren’t randomly chosen for the Nova Private beta”
“After six months, our Nova Private Beta is gradually drawing to a close. Unfortunately, we had far more people apply to test than we could reasonably accept as testers.
We’re sorry to report that you were not randomly chosen for testing this time.”
Seems like there's nobody better than Panic at doing this sort of thing. They're willing to push Apple's UI forward, but they always do it in a way that feels Apple-y. Didn't they also pioneer a tab UI that Apple ended up adopting?