Luca:
This is a very cool idea. I've kind of always wanted to do a plugin for Inkscape that supported d3. However, having done a bit of hacking there, the browser is probably the right place for this kind of work... unless one went down the Electron route.
THE UI
I have been doing work with d3 for a while in the
Jupyter ecosystem. The Jupyter Notebook, a websockety JavaScript SPA that talks to arbitrary backend "kernels", lets you get to the "good stuff" of d3 very rapidly, without thinking too much about that "other part" of data work: the backend! Python, (backend) javascript, haskell, scala and others are all available, and each supports a low-friction way to get stuff out to the front-end. Built with codemirror, backbone, jquery, etc. it can support things like autocomplete (of both the backend language and javascript!). Integrating directly into this environment might be a pretty good idea!
An interesting use of this is
bqplot, a d3-based charting library that uses the
Jupyter "widgets," reactive stateful models, synced between the browser and the backend. There are backends for this in python, julia and haskell, and maybe more! This *really* solves the backend-frontend issue, but hides much of the d3... and only works for python!
For the forthcoming 5.0 release (JupyterLab), a new library is being built called
PhosphorJS, a framework for building IDE-like applications:
demo. It is pretty easy to use d3 in this environment, as you have pretty good low-level access to DOM nodes, but the APIs are deliberately open such to encourage other approaches. Another, indeed frontend, based on Electron (and react) is
nteract, and works with all the underlying stuff.
Core to the mainline 5.0 work is a bunch of stuff related to a reusable IDE (think more atom than codemirror, with command palettes, menus, draggable panels, etc.) called
Phosphide:
demo. This might be a really good place to start, adding the other concepts (generated SVG introspection, etc) as needed, even if the full notebook stuff isn't used. I basically built my own d3-based UI layer for
nbpresent, but I think a lot of things in the "editor" family would benefit from the phosphide opinion.
THE STATE
A great library, also used for nbpresent, is
Baobab. It is an implementation of Om cursors, and supports an immutable, evented tree. Writing UI with d3 with this is awesome, and it supports
history,
computed data, etc. I've also done some work with d3 + baobab + typescript, which is a great way to reduce `function(d){}` fatigue. Whether you make the user deal with this is another story... but it would be a great example for a skeleton...
THE SKELETON
Well, depending on your acceptance of having a backend, either
Yeoman or
Cookiecutter would be good places to start, rather than building an entire new concept. Neither has a web UI today, but either probably could. I've considered in the past using Jupyter widgets to make visual the bootstrapping process, but something bespoke would be cool as well.
THE DOM TRACKING
To get to
Inventing On Principal-level DOM<--> source introspection, it would likely be necessary to introduce some overloaded stuff, perhaps, to the __data__ key that d3 uses... or just go the pre-processor route. Probably the hardest problem you mentioned!