Comment by codethief
4 months ago
> the idea that we are a standalone complete source of truth for an IDE
So that XML-like tree would become the source of truth?
> where Tree-sitter only wants to be half the story: it expects to sync with a text buffer where the text buffer is the source of truth.
There are probably a ton of reasons for this, e.g. 1) The source of truth at the file system level is actually the bare text. 2) Performance reasons. 3) Stuff like git diff is easier to implement.
Yep, the XML-like tree would become the source of truth.
Because we're designing a new and radically simpler IDE we'll just skip the part where the source of truth is bare text on disk (i.e. the git working tree).
We still will be able to read and write flat text files from disc if the user needs to, but our reason for being is to see what kind of good things we could make happen if cut out the middleman and make the IDE's state/history (i.e. undos) and the VCS state/history one and the same. To that end our in-memory representation of the CSTML trees is a reference-immutable btree with efficient copy-writes through deep structural reuse.
Hm, that would very much make it a tough sell for me I must say. In addition to the three (seemingly apt) reasons given by GP, this monolithic approach makes it so much harder to adopt--rather than composing this feature into existing editors, plugin systems, etc. (such as treesitter has done), the editor/IDE needs to be built around this, using it as the core data structure. Even leaving aside my own personal editor preferences (I feel rather bonded with neovim at this point), it means your IDE has to compete on all dimensions of the IDE experience at once, rather than being able to work one a single dimension at a time. As far as user adoption goes, I mean.
Yeah that's a fair take. I think you're reading the situation right in terms of the difficulty of driving adoption. We can't just be a tiny bit better, or just better at one thing. To get people to take migrate into a whole new ecosystem we'll have to push the boundaries in several dimensions, and in a practical sense we have to show the early adopters at least one killer feature that makes it worth it for them to spend time there in the first place.
I would explicitly push back on one idea though, which is that this our approach is monolithic. Yes our tech stack looks foreign from the outside (and it is) but inside it's quite nicely broken down into different layers and libraries with well-differentiated responsibilities. The core of the IDE is so incredibly lightweight that we embed it into our blog posts to parse and syntax highlight our code examples. That gives you a little hint of how we intend to get the tech into the hands of a lot more people. We intend to be able to give them a whole IDE that runs effortlessly in their web browser!
3 replies →