Skip to content

Instantly share code, notes, and snippets.

@psilord
Created October 9, 2023 01:44
Show Gist options
  • Select an option

  • Save psilord/3dc68ba5fbb5d0b6e766c678e7d762cf to your computer and use it in GitHub Desktop.

Select an option

Save psilord/3dc68ba5fbb5d0b6e766c678e7d762cf to your computer and use it in GitHub Desktop.
## Source Centric Editing (No Dispersed UI-Only State)
We found that encoding large amounts of app structure and state in the IDE
itself was both highly convenient and also a strong anti-pattern for
understanding, maintanance, and evolution of the app code. It is trivial for
the IDE interface to cause deviations from standard coding practices (for
example, initializer data held only in an IDE instead of the source code),
for the IDE to produce garbage in its representation when the underlying code
changes, and for the IDE to be poor at telling you when this has happened.
We believe the main problem is that the IDE acts in a readonly manner to the
code. If the user makes changes in the IDE, then ONLY the IDE knows about those
changes. If the user makes changes in the code, then the IDE can only accept
those changes and somehow "merge" them with the knowledge already held in the
IDE. This merging process more often than not simply goes wrong often in
maddening or subtle ways causing a lot of grief.
We want an IDE that understands the code itself in both a reading and writing
manner. The IDE shows an visually editable representation of the actual code.
For example, if a slot on a component is supposed to hold a list, and one
enters that list in the IDE, then the IDE *rewrites* the code (or DSL element
representing that chunk of information) stored in the file to contain that
list. The code ALWAYS holds the most up to date and correct view of the app
and, this is very important, you don't *need* the IDE to make _any_ changes to
the app code or to learn how the app works. The code contains 100% of the
material needed to learn how to app works. If one wished, they could write the
entire app without use of the IDE, but if they suddenly decided to use the
IDE, it will be populated correctly.
One way to implement this behavior is to use Operational Transformation (which
we will explore first, but to which we are not wedded to as a theory) between
the IDE and any other popular code editors (via plugins) to ensure that IDE
changes are correctly synchronized (and vice versa) into the code. The
collaborative real-time editing section must also use this technology so that
people who are simultaneously editing the same file get consistent results. The
IDE is merely another editor entity for a source file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment