The problem with something like this is that it's a moving target.

People in 2000 were saying visual editors couldn't match hand-written code, and were right at the time. But I would happily use today's visual editors instead of hand-writing 2000s websites, using only the tools available in 2000, if all I wanted was a 2000-level website.

But so far, every time we've made things more powerful - even if it makes it easier to have a good visual editor - it's also pushed the frontier of what a bespoke experience can give you.

And this is true in many sub-domains as well.

Even things like CSS frameworks.

If you’re doing something trivial, or solving a couple of specific use cases, then a framework full of CSS classes that give you Twitter-looking cards or a no code solution that helps you send an email every time a user clicks a “subscribe” button IS helpful.

But the problem is, once you’ve used the tool for that initial problem, you’re stuck with it. And inevitably, if your thing is successful at all, you will outgrow that tool quickly and need to start making bespoke things to keep up.

I say this not out of gate keeping either - I say this as an overworked full stack software developer who would LOVE to be able to provide a CSS framework or a visual editor to my co-workers and have them produce long term solutions.

But as soon as they find some tool and ask me to help adopt it, it works for them for a couple use cases, and then guess who’s stuck trying to make it work with all the fancy new things we need that then requires extending the tool or working around it entirely?

I also don't think that it will exist, but not because it's technically infeasible. I just don't think it makes sense as a solution.

The complexity of a task depends on the complexity of the problem. That complexity has to live somewhere, and it doesn't matter whether it lives in a GUI or in code.

Just recently I overheard a conversation where some people were complaining about their Zapier integration. Someone had built a data flow for all these tasks, and it was an absolute mess and a maze to wander through. I found myself laughing because it's the same kind of complaint developers often make about code.

Bottom line is that if the UI is complex, the GUI that is used to build it will be complex.

Most of the solutions fall into one of three categories

- they don't give users the amount of control they want because fundamentally, HTML and CSS together couple content and layout in a very programmer way... This is been a huge advantage for them as a user interface language because they create user interfaces that can work on many screen and window dimensions, but if you don't wrap your head around the layout algorithm, you're going to end up surprised.

- they try to give users the level of control over content and layout that users want, and the end result is extremely buggy

- they try to give users the level of control over content and layout that users want, and the end result is incredibly verbose and basically illegible HTML and CSS. This tends to cause problems down the road because it doesn't couple well with other tools and tends to cause problems later if somebody has to debug by hand or they want to move away from the tool used to originally create the page.

It's an extremely non-trivial problem to solve.

I agree with the parent comment, but I also see your point that there is room for innovation. For example, the article mentions flexboxes. Flexboxes have many possible behaviors that a tool could help visualize and decide between.