when it comes to sites like squarespace and weebly still have a drag + drop configurator don't they? In any case, what you can do with them is pretty limited or won't work as expected if you try to do more complicated things (otherwise FE web developers wouldn't exist).

Xcode's UI editor is extremely good (which can be used for all apple devices, watchOS, macOS etc not just iOS). Android studio is still pretty thin in comparison, I would say you have to do more code with android. Although, you don't actually have to use them at all -- the frameworks will work fine without, it's just down to the developers preference.

I assume the reason why developers don't use GUI editors for web apps is because elements are no where near as complex as iOS/Android elements which for the most part, need to look/feel/behave the same across all apps on their respective OS.

I still use a lot of Delphi (almost for 20 years now). Maintaining a UI with a builder is a real pain. I hate it. Source control is more difficult, accidential changes, complex tools needed, no comments possible, scaling, ...

GUI editors are a disaster. Well, if not done really well. As some mentioned we do still see them in things like mobile and desktop apps or other specialty UIs

• Android
• iOS
• WCF
• swing/gtk

But we generally don't see them on the web

• Frontpage
• codeweaver

But why? Noting the examples I gave come from a time of static web pages. I can only give my thoughts and no evidence.

I think there are three trends which made the gui editor hard to tackle.

• Explosion of frameworks
• Frontend or backend rendering (which programing language controls the web?)
• Components Understand, it is not like this hasn't been seen before. Swing, swt, winform, gtk, qt... They also had the concept of componetization.

So what then? Well, those I listed still exist and probably still have their gui editor. Note these listed also lived through the late 90's which was a time where the future of programming was in "code less editing". Also note these are the main players of graphical interfaces

Jump to the start of the web UI and you, (what I'm going to say will sound harsh, but I think it is accurate imagery), and you have script monkeys (because we all are from time to time) hacking up the web DOM in whatever fashion suits their needs. There was no need for a GUI, they new what they were doing and it was cool.

I believe that the move to trying to componetize the web is still a new approach for the modern web, there are competing approaches and unlike in the desktop age of GUI, these programs are used to doing it by hand (the no code movement is still out there somewhere, but right now things are a moving target and who knows when it will need to be rewritten for the next framework (we have angular, but you can't say it has been around long because it has had many design changes under the same name)).

On the editor side of things, they have been known to make ugly code. It can be hard to version control changes (merge conflicts anyone?). While the code can be edited, the GUI editor may stumble on things you try if you don't stick specifically to its expectations. You aren't removing the code or your need to understand what it is doing (or at least if you don't understand it will be a mysterious black box which doesn't work some times and all you can do is remove and re-add the missing components).

Is the frontend so complicated that we have given up all hope of drag and drop editors?

No, they can actually make the frontend more complicated in multiple ways.

• The code they generate often contains embedded metadata that's dependent on where and when it was generated. This is problematic when you want to keep it under version control, because the generated code is not trivially reproducible and your patches will have lines that don't actually have anything to do with the changes.
• It's unfortunately very typical that you have to reformat the code they generate to make it comply with your project's coding standards (at least, when it's not in some custom language).
• It's not unusual for them to be very picky about the code that is fed in as the initial state of the layout to edit. This means in turn you have to understand how the editor works to be able to edit the code by hand and have it still be editable by the editor afterwards.
• Quite a few either offer too much granularity in control placement, or not enough, so you either end up with controls on a larger grid than you intended, or have trouble making sure everything is lined up correctly.
• They don't work on the command line. Sounds stupid, but this is a huge reason for quite a few people to not want to use them (I'm a good example of such a person, my desktop environment is used as little more than a multiplexer for terminal emulators and a web browser when I'm coding).
• Some of them still don't support scaled relative positioning (which is kind of important for portable UI's).
• They automate what is honestly one of the least difficult parts of coding in many cases. Unless you're dealing with old systems or very poorly designed API's, getting the UI layout to a reasonable state is often exponentially easier than coding the actual behavior of the application and binding the UI to that.

Keep in mind also that the heyday for these things was the late 1990's to the early 2000's, a time when there was an ongoing push to make it so that people who didn't understand computers at a low level could still program by avoiding actually writing code. As that went on though, a lot of the smarter businesses realized that this was a Bad Idea (yes, it's that bad of an idea that it warrants capital letters), both because of the points I mentioned above, and the fact that letting people who don't actually understand computers at a low level do your software development leads to all kinds of long-term issues, and as a result there's been a pretty steady shift away from them for anything that isn't really graphic-design work instead of programming.

For JavaFX desktop apps scene builder is good. I tried bookstrap studio but felt limited using it. In the end writing the code was faster for me.

I have used Qt designer along with pyqt5 to build some small utility apps and it is quite a breeze to use. The powerful signal/slot system allows you to quickly add functionalities to your UI. The only caveat is that the UI is widget-based and not as dynamic as DOM-based ones.

For front-end no-code development Webflow is a big one right now, and it works like a breeze with code that is fine to maintain because of the way it works: you drag & drop HTML elements in, visually, and anything you adjust in the webflow editor is also possible to do with basic CSS properties, making the HTML nor CSS too complicated.

The reason is that frontend development for web is chaotic.

It would be fine if you only had to deal with HTML and CSS, but then you have stuff like Angular that you don't code what it will be shown. You basically code in a code generator.

You have components being shown depending on conditions that will be decided at runtime. Front-end web is all about runtime. You can't always know what to show before running the app.

But I understand you. I miss the GUI editors (even though they usually generated a lot of dirty code)

I think there's a renaissance of gui software right now because that's how trends work. They come and go, but this one is indeed a recurring one for quite some time now.

There are lots of nocode tools, for example Desech Studio will help you visually build html/css instead of writing it by hand.