Hi all, I'm the author of the article. Thanks very much for linking it here.

It's very easy to fall back on entrenched opinions and unhelpful developer-vs-designer stereotypes, and see any call for a visual tool to be one to remove or demote code from the process altogether. That is absolutely not what the article states or is about.

I'm adamantly against canned solutions that make things easier for designers but harder for developers; rather, I want something that merges the power of code-centric tools with the speed and approachability of visual tools.

Basically: Visual Studio Code + DevTools + Codepen + a browser rendering engine + the stuff we use Gulp / Grunt / Browsersync / Sass etc for on the command-line, but bundled into something useful for non-developers - with added GUI deliciousness that would obey good code rules.

Rather than just 'draw anywhere' and getting all that FrontPage-y style rule nightmare, it might be more 'define a grid, then draw a div into a grid cell, then either create or apply a class,' etc.

Interaction is definitely supposed to be part of this (something I did not go into depth with in the article) - defining states for sure, as well as animation.

One use context is creating a component library / pattern library that will be consumed by several different user types. For instance, Material.io or the Salesforce Lightning Design System, IBM's Carbon Design System, etc, intended for producing web applications.

Designers need a style guide, front-end developers or 'designer-devs' want to see live examples with code snippets, other kinds of developers might want to know about data sources and where the variables are used in a particular component.

A visual tool should make it very easy to both create and edit such components, and maybe add a bit of metadata like 'this component is recommended for use as the nav' and 'it has these dependencies' - so you can more easily export it into something like Clearleft's Fractal tool, etc. In the long run, such metadata might let an opinionated tool automatically snap things into place / recommended source order to guide beginners, but always modifiable by developers.

And similarly, being able to open a library of components, see a 'molecule' like a nav bar, then drill down to atomic components like ULs, buttons, see what the data placeholders are, etc - preferably also with some human-readable annotations.

(Obviously I am handwaving the complexity of actually doing something like this, but conceptually, it _ought_ to be doable.)

By its nature, I would want this kind of tool to promote understanding of CSS inheritance and modularity, so that it would lend itself to creating reusable symbol-objects, much as we are used to in Adobe apps and Sketch, and previsualize the changes to the cascade, or get warnings that "x other classes depend on this, are you sure?"

For instance, InDesign style palettes can roughly map onto text and object styles - your basic H1-H6, standard HTML styled elements. The missing part in Adobe is scoped/modified or additive styles, but that's just a conceptual step forward. In a code context, an "H1, but inside a product grid" style can decompose to BEM classes, and the app or tool should make this clear as we already do with Inspector computed views.

So just to clarify, what this really should do is help visual designers make the leap into becoming hybrid designer-developers (and vice versa) but if someone simply wants to use it to sketch things out freehand, regardless of end use or code quality, it should help them do that, albeit in an opinionated way under the covers.

As I allude to in the article, we don't ask visual designers to write raw PostScript. We depend on the tools we use to author it correctly when we draw boxes or type text into our documents; the Web has added robustness. I'm not that worried about it producing spaghetti code.

Any visual tool should produce at least well-structured, readable code; lean towards making sure it's standards-compliant / uses best practices; but also is flexible enough to let you author it in any way that is suitable for your needs, so you're not trapped in canned layouts or overly-prescriptive boundaries.