4 ms·

The problem with doing that is that you've now created a substantial dependency for your commercial product, and not a dependency that's merely the "requires np

The problem with doing that is that you've now created a substantial dependency for your commercial product, and not a dependency that's merely the "requires npm package foo" kind of dependency. Because Nova is not VSCode, being compatible with Code's extensions API means: - committing to implementing every new documented Code API function as quickly, completely, and transparently as possible, because if you don't, extensions will break; - resolving mismatches between how Electron apps do things and how AppKit apps do things, which may be easier said than done; - possibly choosing not to support functionality in extensions that Code doesn't have; - putting control of your flagship product in someone else's hands. So I'm not really surprised Panic hasn't done that. If there were a way to create a basic converter that takes a Code extension as input and spits out a likely-needs-work Nova extension, kind of like there's a converter for TextMate syntax definition files to Code's format, that would be great, although that would almost certainly be easier said than done.

Klonoar 5y ago
You say these things as if they're non-obvious... The fact of the matter is that VSCode's market share is massive, and expecting developers to port extensions solely because "it's a native macOS app" is not really a good pitch in 2020-2022. I would rather Panic suck it up and do the work to interop with the existing (massive) ecosystem so that those of us who like to run native apps can do so without it being a step down on just about anything else. Something like this needs ecosystem buy in, and as far as I can tell right now, it doesn't have it. I wish it did.
- Skinney 5y ago
  I don't really see why Nova should attempt to be compatible with another editor just because they landed on JS as the integration language. It's doubtful that VS Code has the best API, and it's doubtful that VS Code's API is the best fit when the editor isn't primarily rendering HTML. Because the editor works very differently, it's unlikely they'd ever manage to make the APIs completely compatible, and because of that it'd unlikely that you'd have much porting between the editors anyhow. There are many editors out there with incompatible plugin APIs (sublime, vim, emacs, vs code, fleet etc.). There is room for Nova to do their own thing, and do their own thing better without catering to the crowd of another editor.
  - Klonoar 5y ago
    >There are many editors out there with incompatible plugin APIs (sublime, vim, emacs, vs code, fleet etc.). There is room for Nova to do their own thing, and do their own thing better without catering to the crowd of another editor. No, there's really not. The marketshare for a native-macOS editor is comparatively small, and they would be better served just making it work and interop well. There is nothing special about their extensions API and there is no glory in re-forging this path.
aloer 5y ago
> kind of like there's a converter for TextMate syntax definition files to Code's format Got a link for that? I was looking for a TextMate grammar to Monarch converter and couldn’t find anything that works

Klonoar 5y ago

You say these things as if they're non-obvious... The fact of the matter is that VSCode's market share is massive, and expecting developers to port extensions solely because "it's a native macOS app" is not really a good pitch in 2020-2022. I would rather Panic suck it up and do the work to interop with the existing (massive) ecosystem so that those of us who like to run native apps can do so without it being a step down on just about anything else. Something like this needs ecosystem buy in, and as far as I can tell right now, it doesn't have it. I wish it did.

Skinney 5y ago
I don't really see why Nova should attempt to be compatible with another editor just because they landed on JS as the integration language. It's doubtful that VS Code has the best API, and it's doubtful that VS Code's API is the best fit when the editor isn't primarily rendering HTML. Because the editor works very differently, it's unlikely they'd ever manage to make the APIs completely compatible, and because of that it'd unlikely that you'd have much porting between the editors anyhow. There are many editors out there with incompatible plugin APIs (sublime, vim, emacs, vs code, fleet etc.). There is room for Nova to do their own thing, and do their own thing better without catering to the crowd of another editor.
- Klonoar 5y ago
  >There are many editors out there with incompatible plugin APIs (sublime, vim, emacs, vs code, fleet etc.). There is room for Nova to do their own thing, and do their own thing better without catering to the crowd of another editor. No, there's really not. The marketshare for a native-macOS editor is comparatively small, and they would be better served just making it work and interop well. There is nothing special about their extensions API and there is no glory in re-forging this path.

aloer 5y ago

> kind of like there's a converter for TextMate syntax definition files to Code's format Got a link for that? I was looking for a TextMate grammar to Monarch converter and couldn’t find anything that works