Hacker News new | past | comments | ask | show | jobs | submit | andrewpareles's comments login

> I’d love a good summary on why Cursor, Void (and I assume other tools) decided to build new editors instead of just extending the incumbents (VSCode extension, Jetbrains plugins).

This is a great question. We think extensions are often buggy (e.g. Copilot, where the selection jumps), or unable to integrate very naturally (e.g. Codeium, other open source extensions). For example, a lot of extensions use the quick pick dropdown for the user to enter a prompt, which feels unnatural. Owning the IDE like Cursor is important to get around these issues, and we think this is why Cursor is so popular.

> While adoption for individuals and small companies might be easy, a lot of bigger places already have other integrations with existing IDEs and displacing those for yet another IDE will be a hard ask

You're right about IDE adoption. We want to build on top of an already-popular to help us reach smaller players, and hopefully we can win over larger companies in the long run with privacy and by centralizing nice AI features.


Hey, great question - you're right, extensions are more accessible - the thing is, there is no great way to build the native UI we'd want using them. For example, displaying the before-and-after is vital for us, and doesn't feel natural in an extension.

Extensions like Codeium do the most naive thing possible by writing something like <<<<<<< DIFF >>>>>>>> in your file, literally breaking syntax highlighting. Others like Copilot are super buggy.

Right now Void is built on top of an extension, but we're also modifying and hooking into parts of the IDE to make a more native UX.


Thanks for sharing! If Theia is built on top of monaco, I wonder if a form of one-click switch might work. The monaco editor is theoretically part of the vscode repo, while the "workbench" with settings/configs lives one layer up.

Pear consists largely of a VS Code extension built on top of Continue.dev's VS Code extension. We're building a more native integration into the VS Code editor, similar to Cursor. Is there anything you like about Pear that Cursor doesn't offer?

Great question - we're doing a VS Code clone to have access to features like language servers, debugging, extensions, etc - these are really annoying to build from scratch. We also think it's nice for users to just be able to do a one-click switch from VS Code to Void, and hard to win over Cursor users without it. I'm curious about how you're building your editor - are you building everything from scratch?

I've also made an editor/IDE from scratch and it is painful, for example implementing text rendering and Unicode support (emojis) is a PITA and takes a lot of optimization if you want below 1ms screen of text rendering. I however took the approach "every feature is a plugin", so when adding features I first made the core API able to handle the feature then implemented the feature as a plugin. So a few years into development I rarely need to touch the core API and can implement new features with a high level easy to use API in just days.

About adaption, it's very hard to make people switch over to a new editor, so by forking an popular editor you shaved off years of development, and it will be easier for users to switch over. But probably at the cost of implementing new features takes longer and large refactors more difficult.


We really like about on-prem models as well - it definitely seems they will get comparable and win over paying for API credits.

Will make the first batch of releases ASAP!


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

Search: