Ask HN: Why Haven't GUI Front End Editors Caught On?

of course, but with a UI you could actually benefit in those areas - for example, integrating something like tota11y or ally.js, and other viewing modes for different screen sizes.

on the backend interfacing side, I suppose that depends on if the UI allowed you to set up fixture data that then flowed into your template tree. I could see that being quite a nice way to visually experiment with structuring your data.

Well, they sort of have in the form of Wix and Squarespace.

There's a huge separation between who designs the frontend and who implements the frontend. To date, none of the frontend editors are good enough to completely replace the need for a programmer to wire up actions. Even back in the Flash days, you needed an ActionScript programmer to make your webapp do anything meaningful.

Since you need a programmer anyway, you might as well use a freeform design tool (Photoshop) to let the designer design whatever the hell he wants without the constraints that a more specialized app might impose. Then, let the programmer take that design and create whatever infrastructure he thinks is necessary without also constraining him to whatever a specialized app might impose.

I've been doing both design and programming a bit lately and I absolutely love apps like Subform, Webflow and Apple's interface builder. But, once I get past the fast iteration mockup phase, the structure of the app or webapp I'm making changes enough that the tools become unwieldy.

What I would really like are more robust layout APIs for both the browser and native apps. In Subform, you can define relative widths and positions both to other components and to the window itself. It's great for taking some of the tediousness out of design, but from a programming perspective, centering an object horizontally and vertically consistently is still a surprisingly difficult endeavor.

My take, as someone who sells a visual web-app creator (see my profile):

If you want it to work well, the UI model of a visual editor has to match up with the data model of the application behind it. Visual Basic worked so well because the objects you manipulated in code were the same components you dragged and dropped onto your window.

We already have way too many (and too complex) representations of application state in a typical web app. I count six:

      Tables in a database
   -> data model in server code
   -> JSON over HTTP
   -> data model in client code
   -> HTML/DOM
   -> visual layout

It's hard enough to make a WYSIWYG editor for the final transformation (HTML -> visual layout). But trying to WYSIWYG the whole "code -> HTML -> layout" flow is basically impossible. This is why I think you won't see a workable GUI editor as long as we stay chained to today's overcomplicated HTML/JS web stack.

What we did with Anvil (https://anvil.works) was to build a simple UI model from the ground up. We avoid HTML and JS, and provide discrete components that can sensibly be dragged and dropped in a GUI editor, and sensibly addressed from code. This means we can bring back 1990s innovations like autocompleting UI code.

But right now it's like having your hand in a cookie jar. As long as you hold onto the full complexity of HTML, JS, Angular/React/etc, you're never going to get that simplicity you want.

I used to really love the idea of GUI front end editors. I tried to use a few different ones for building different apps. They worked great for static UIs. What I learned is that I never actually build static UIs, and I was spending tons of time on the GUI. I dumped each when I realized that building from code was far more productive.