Bootstrapping (or not) a visual designer

I worked the previous few years on a project to create a new form of IDE. The IDE itself was not aimed towards programmers, it was more of a drag and drop form of development. I won't discuss the details or merits of that approach, instead I am going to focus on an interesting consideration we came across in trying to bootstrap such a system to use aspects of itself for its own development, especially when just trying to get to an MVP (minimum viable product) release.

Imagine that you have a form designer and a properties panel and you're not far off. As an example, imagine Visual Studio's Winforms designer was created using Winforms (which some research suggests it is not).

In our system, the notion of a form was very important for the user. We chose to implement the form's properties panel as a form, which is a chicken and egg bootstrapping problem. It's similar in principle to bootstrapping a compiler, but the realities are very different because a compiler is written by programmers for programmers, but in our case our IDE was written by programmers for non-programmers.

Some big problems came out of this decision, which weren't obvious until they happened.

Firstly, the components you expose to the user are initially not interchangeable with the components you need internally, even though they look the same. In a sufficiently advanced system they would be the same, but that only comes about when your system is advanced enough to be able to create large chunks of itself (much more holistically than just an individual entity like a form). Up until that point you must have hard coded behaviour standing in for the bits that your system is not powerful enough to create. This hard coded behaviour was surprisingly divergent, so the code becomes difficult to manage because you are conflating the components you as a developer need and the components your users need. The problems you encounter are all in the code, so development and maintenance and compatibility becomes problematic and time consuming, but the root cause is the spec wants two things to be equal when they are simply not. This is a bootstrapping problem, so it could be solved by keeping the bootstrapping process going on longer, but I don't really want to go there because you could take a short-cut with a native properties panel and still be able to bootstrap correctly later on.

Functionality and scope creep is a problem. The form you expose to the user can be quite simple in an MVP, but your own GUI needs to be complex enough to allow the user to interact with its designer. So if you want a context menu, you need to implement a context menu on your users' form. A context menu on a native panel is easy to implement and doesn't really pose any problems. A context menu on your own representation of a form needs you to implement the notion of a context menu and expose that somehow, which increases the complexity of your requirements and greatly slows you down. In short you are facing problems that need not be there.

A surprising outcome is the increased difficult in debugging the IDE. Looking through a stack trace while a user's form is running results in multiple forms in the stack, one of which is the user's and several of which are your own. This becomes extremely confusing when spending long periods of time paused at a breakpoint trying to visualise your program's state by jumping up and down the stack. This seems like it should be a secondary consideration, but in reality projects that are hard to debug are projects that are slow to develop. Clear separation is good for debugging.

Finally, this approach exposes you to performance problems much sooner than you would otherwise need to address them. Suppose a form take 3 seconds to boot up when the user presses 'run' due to some overhead in some complex routines. That's not great, but it's acceptable because the user doesn't press 'run' very often and they don't really expect or need it to be instantly responsive; a few seconds is fine. Now suppose every selection mouse click in your designer leads to two forms being rendered in your properties panel - suddenly selection takes 6 seconds, and that's a dreadful experience for the user, especially when compared to a completely hard coded panel that would fully render in milliseconds. You can solve this, but you shouldn't have to.

The running trend here is that everything becomes hard long before it needed to become hard. Although this kind of thing is intellectually interesting, it falls into the "being too clever" category and is directly opposed to getting an MVP up and running.