> 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?
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.
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.
> 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.
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.
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.
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.
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.
> 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.
"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.
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".
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.
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.
“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.
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.
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)
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.
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.
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.
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.
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).
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...
> 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.
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.
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?
> 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.
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 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?
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.
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.
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...
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.
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.
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.
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.
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
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.
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.
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.
> 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.
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.
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.)
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.
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.
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.
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.
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.
> 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.
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'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.
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.
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.
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.
> 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.
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 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 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 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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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?
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 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.
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.
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.
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 ∀.
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!
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.
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.)
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.
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.
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.
> 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!
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.
> 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.
"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.
548 comments
[ 3.0 ms ] story [ 329 ms ] threadSeems 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?
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.
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.
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.
https://www.panic.com/extras/audionstory/
https://youtu.be/8ZXWdR7RzV8
Cabel, and Panic in general, are true heroes of mine.
SoundJam's hierarchical playlist has yet to be replicated by any other music player to my knowledge.
Like playing music by albums, or artists and it would recursively play all of the music within those albums?
It would then be played in order, yes, recursing through all the layers.
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.
I definitely wanted to! (I'm the Charles in the story.)
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.
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.
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'm not sure how many good native text editors don't have their own text editing engine.
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.
Thank you.
It boggles the mind that anyone who can write code would ever use a closed source operating system.
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.
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.
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.
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)
But more to the point: Apple has proven it _can_ be that good, so I want a control that _is_ that good. Why would I ever go backwards?
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.
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.
There are keyboard shortcuts for those, which are even nicer imo. Reduces the amount of times you need to take your hands off the keyboard.
From GP:
> use a closed source operating system
That's not "Windows".
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.
Well, would probably work fine with an external keyboard/mouse :D
NVMe should crash right now like it did on Linux before 5.4, but the Linux patch for that https://github.com/torvalds/linux/commit/66341331ba0d2de4ff4... is absolutely tiny, I could probably replicate these quirks in FreeBSD in a few minutes.
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.
These days it just works though.
The term to look for is “Windows precision trackpad”.
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...
From my employers point of view it is irrelevant if I could fix the platform since they most certainly don't want to pay for it.
This is not evil. It's just how some parts of the industry work.
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
Which you have to create and convince the maintainers to accept. Some maintainers are gracious and others not so much.
Impression I get with Microsoft 'developer doesn't want to work on it' isn't a show stopper like it is with open source.
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...
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.
Someone has to do it. If you have the skills, why not you?
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.
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.
> 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?
My MFC/VCL applications work just fine today, and can be easily extended to take advantage of modern UWP APIs.
You can start by having a look at,
http://toastytech.com/guis/cedar.html
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
"Alto System Project: Dan Ingalls demonstrates Smalltalk"
https://www.youtube.com/watch?v=uknEhXyZgsg
"SYMBOLICS CONCORDIA ONLINE DOCUMENTATION HYPER TEXT MARKUP 1985"
https://www.youtube.com/watch?v=ud0HhzAK30w
You can see how NeXT builds on many of these concepts on the famous "NeXT vs Sun" marketing piece,
https://www.youtube.com/watch?v=UGhfB-NICzg
Sun also had some ideas along these lines with NeWS,
"NeWS: A Networked and Extensible Window System,"
https://www.youtube.com/watch?v=4zG0uecYSMA
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.
A perfect summation!
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...
Mozilla? Getting your patches merged is rather easy and very pleasant. Firefox is truly a community project we all build together.
https://bugs.webkit.org/show_bug.cgi?id=171934
"our joy at Panic comes from building things that feel truly, well, Mac-like"
"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.
Plus ca change in a proprietary world.
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.
Or at least, there's a loud one, and I guess they figured it's also a big-enough one...
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.
Fwiw before getting internet fiber, a 95MB file resulted in about 20 min download (my reference was 300MB an hour).
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.
Electron apps are bloated ick but I guess at least Electron is equally repulsive on all OSes.
Out in real life no one knows or cares about this
My hope is that they create enough momentum to force the VSCode team to rewrite in React Native.
Have been using SPM's "swift build" + some copy commands to create a fully functional signable bundle, no need even for an .xcodeproj.
[1] https://nshipster.com/vscode/
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.)
See: https://developer.apple.com/library/archive/documentation/Co...
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.
It was a big undertaking :)
[0]: https://github.com/cdr/code-server
1: https://theia-ide.org/docs/composing_applications/
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)
[0] https://github.com/microsoft/vscode/issues/70764
Seems reasonable, considering Panic’s last editor, Coda, has an iPad version.
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.
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.
Like that one.
Second I bet there are more Web Developers out there than there are for Mac or iOS.
I'm surprised it has no support for bash, or any other kind of shell scripting.
The starfield background also moves based on your cursor position, dang.
And the fact it's smooth-as-butter without even getting my laptop fan to turn on at all is even more impressive.
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.
At that price am I getting much more than the satisfying feeling of supporting Panic?
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'm probably not the target audience for this. I'm much too happy with Emacs.
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.
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).
Languages are important, but I wouldn’t say they are ahead by a large degree.
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 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.
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).
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.
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.
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 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.)
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.
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.
Emacs 27 (released recently) with native JSON support was reportedly a huge improvement.
The `native-comp` branch on master is receiving great feedback too.
https://seths.blog/2005/03/dont_shave_that/
It really depends on you wanting to use something like Emacs, of course.
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’m flipping between Jetbrains and VS code a bit, but Jetbrains is by far the superior experience.
If you're going to roll Jetbrains then the more RAM the better and a good CPU also helps.
Obviously, this means MacBooks that aren't fully kitted out are bad picks.
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.
Shitting on tools because you read a couple disgruntled comments about indexing without honestly evaluating the tool yourself says a lot.
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?
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.
Some of them are for minor customization like hot keys to move tabs. But the product doesn’t support Environment Variable configuration very well.
For example, Pycharm can’t injest a .env file. The devs point at a plug-in, but that doesn’t cover runtime and terminal / python shell.
I've enjoyed it for years now! https://marketplace.visualstudio.com/items?itemName=oderwat....
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.
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.
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.
Perhaps they should have started by targeting something other than web development.
These days, web development got both more mature, complicated, and simpler, all in ways that makes it hard for Nova to make sense.
What year is this. :)
[0] https://microsoft.github.io/language-server-protocol/
Basically we are all going to be waiting for the ‘And now Nova can import all your VSCode stuff seamlessly’.
That's a _great_ way to do a subscription.
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.
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.
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.
Buying a subscription gets you one year updates, and then whatever that last version is remains functional forever.
> When purchasing an annual subscription, you will immediately get a perpetual fallback license for the exact version available at the time.
https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...
(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.
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.
https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...
[0] https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...
[0]: https://sales.jetbrains.com/hc/article_attachments/203511589...
https://sales.jetbrains.com/hc/en-gb/articles/207240845-What...
The app now has a special licensing setup that restricts your installs to two machines.
Sketch made a thing about leaving the App Store.
But the App Store licensing and update process was way better than what it has evolved to.
That's the one thing that pushed me to Figma.
It was bad enough that it's MacOS only. Now I can only have it on 2 machines?
"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.
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 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 hope it works out for you!
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.
https://apps.apple.com/us/app/acorn-6-image-editor/id1233861...
- 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.
[0]: https://www.usertrack.net/
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.
1: https://marketplace.visualstudio.com/items?itemName=asvetlia... 2: https://www.onivim.io/
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 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.
setxkbmap -option caps:swapescape
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!
The animation is really cool especially that onscroll effect!
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.)
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.
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.
As another datapoint, I seem to remember IntelliJ doing >100 Million € in revenue p.a.
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.
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.)
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.
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.
What am I missing?
But as you said, can get the same in the scroll bar.
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.
> 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 made the scrollbar a literal screenshot of the code.
"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.
This was the first thing I looked for on their feature page!
Looks good.
(full list: CoffeeScript, CSS, Diff, ERB, Haml, HTML, INI, JavaScript, JSON, JSX, Less, Lua, Markdown, Perl, PHP, Python, Ruby, Sass, SCSS, Smarty, SQL, TSX, TypeScript, XML, and YAML)