Hacker News new | past | comments | ask | show | jobs | submit login

I prefer VS Code over native alternatives. Don't conflate your anecdotal evidence with facts. Many users don't know much RAM a process consumes or what an Electron app is, they just care about what the app can do, how fast it is, etc.



>I prefer VS Code over native alternatives.

That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.

If there was a native editor with feature parity with VS Code (including the number of plugins and dedicated MS resources speeding up its development, and free), nobody would be using it.


> If there was a native editor with feature parity with VS Code (including the number of plugins and dedicated MS resources speeding up its development, and free), nobody would be using it.

Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development?

In other terms: Maybe the portable native full featured VS Code is the middle of the cheap-fast-good venn diagram.


>Is it possible that VS Code (for example) exists (in its feature specific incarnation ) only because Electron is a cost cutter in terms of portable development?

It could -- though I doubt it.

But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?


> But I was concerned with a more limited question: if there was a good VS Code alternative that's native, would many still prefer an Electron version?

I understood what you meant. I respect you disagreeing with my premise, but in the scenario where that premise is true, your question is not applicable.

Scenario: Would anyone choose MDF boards at IKEA if they could choose plywood or natural wood, or assemble their own furniture if given the choice (at the same price)? Barring a few applications, probably not. But IKEA wouldn't be IKEA if they were just another producer of wood furniture, meaning they got to market and stayed there because of the shortcuts and limitations they could justify when reaching a price.

Same thing here (IMHO). VS Code could have some cross-platform code and some platform specific code, but the cost would be higher and the output velocity would likely be lower. Assuming that is true, your question is misleading, albeit not on purpose.


Most people wouldn't care unless there was a performance difference between the two.


> That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.

There is sublime text.


Which is what I use. But ST3 doesn't have the full power of a 20+ strong MS team behind it, but a single person (and another hired to help here and there), and so doesn't have the same momentum -- and it's getting behind in features as well.


I never kept tabs on the development effort on neither VSCode nor Sublime Text, but it was always my impression that much of the power either editor has comes from 3rd party extensions rather than the editor core. As such, I believe it was the hype around Atom and VSCode that drove people to write extensions for them, leaving ST behind.


>but it was always my impression that much of the power either editor has comes from 3rd party extensions rather than the editor core

A lot of it, yes. But VSCode also invests a lot in core functionality (in what in other platforms would be plugins). The Git integration is one such example -- or the ability to debug Chrome in it.


>>I prefer VS Code over native alternatives.

>That's because, as the parent said, there are no good (e.g. equivalent) native alternatives.

But that's not true. I use Sublime Edit and have happily used BBEdit and TextMate. Emacs is fine for many people, and I still use vim for fast edits in terminal mode all the time. There are plenty of other great native editors for just about all platforms.


BBEdit is excellent. So is Notepad++.


I prefer Sublime Text.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: