4 ms·

I will reiterate my chief complaint with this: it should have just copied the VSCode extensions API from day one and relied on easier porting of them.

jamil7 5y ago
Any info on what the reasoning was here? I would assume there's a technical reason they couldn't do it rather than a business decision.
- zshbleaker 5y ago
  The selling point of Nova is being a native Mac citizen rather than a Electron wrapper. The VSCode Extension API heavily relies on the flexibility provided by the browser runtime which native apps like Nova cannot give.
  - Klonoar 5y ago
    How much experience do you have with the product in question...? Last I checked it literally embeds a JS engine with a custom API for extensions. Unless something has changed since I last looked... but if I glance at this URL (scroll down to "Providing a TreeView") it doesn't appear to have: https://docs.nova.app/extensions/sidebars/#defining-a-sidebar https://docs.nova.app/extensions/sidebars/#defining-a-sideba... There is simply no reason it has to be different from the VSCode API; you can set up JavaScriptCore to hook into whatever native components you need. VSCode owns the market, full stop. This should mimic the API as much as possible to enable wider extension porting. Hell, you could cover even a fraction of the VSCode API and that would still be more useful than the current Nova extensions API.
  - jamil7 5y ago
    I'm aware of the selling point I was asking specifically about the extension API.
chipotle_coyote 5y ago
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.

jamil7 5y ago

Any info on what the reasoning was here? I would assume there's a technical reason they couldn't do it rather than a business decision.

zshbleaker 5y ago
The selling point of Nova is being a native Mac citizen rather than a Electron wrapper. The VSCode Extension API heavily relies on the flexibility provided by the browser runtime which native apps like Nova cannot give.
- Klonoar 5y ago
  How much experience do you have with the product in question...? Last I checked it literally embeds a JS engine with a custom API for extensions. Unless something has changed since I last looked... but if I glance at this URL (scroll down to "Providing a TreeView") it doesn't appear to have: https://docs.nova.app/extensions/sidebars/#defining-a-sidebar https://docs.nova.app/extensions/sidebars/#defining-a-sideba... There is simply no reason it has to be different from the VSCode API; you can set up JavaScriptCore to hook into whatever native components you need. VSCode owns the market, full stop. This should mimic the API as much as possible to enable wider extension porting. Hell, you could cover even a fraction of the VSCode API and that would still be more useful than the current Nova extensions API.
- jamil7 5y ago
  I'm aware of the selling point I was asking specifically about the extension API.

chipotle_coyote 5y ago

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.