The best current real-world example to look at would be Apple's Interface Builder for iOS. Why doesn't everyone use IB?
The biggest reasons in my experience are:
* Limited logic. A builder is fine for a simple static layout. How should that layout change depending on the data to be displayed? How should it adapt to different screen dimensions and orientations? Pretty soon you want to write code to control the view.
* Doesn't play well with source control. Even if the GUI builder spits out a text-based format like XML, it's hard to read and understand diffs, and it can be difficult to impossible to merge.
Why don't use tools to make writing HTML/CSS less boilerplate? To some extent we do. We have CSS preprocessors and HTML templating.
In the end, the front end is just code, and no one has yet come up with a graphical form of coding that is superior to text.
I use IB most of the time for iOS layouts. Most of the time it's the fastest, easiest way to lay out a simple interface and get it right.
The other 10% of the time I have to get my hands dirty. This is pretty much par for the course with UI design. Any WYSWIG editor necessarily abstracts functionality in favor of simplicity, and when you need to get deep, you go back to the underlying general purpose language.
There's nothing wrong with that. It's a good workflow. Easy stuff is easy and hard stuff is hard, as nature intended. Fully committing to an IDE editor would mean that easy stuff is easy and hard stuff is impossible.
Back when I did Mac OS 9 development, we used Metrowerks' PowerPlant framework. Constructor, their GUI editor, made laying out user interfaces a joy. It just worked.
When I came back to try iOS development, and saw the sad state of IB, I wondered how things had fallen so far.
Then I tried Android development. Hand rolled XML layout of UI? NOPE.
I too am surprised that no one has developed tools to just do this.
I'm working on a tool to do just this - makes frontend development straight-forward and visual. If you'd like, I can ping you an email when I have something to show - my email address is in my profile if you're interested :)
I agree completely that Interface Builder is best for (mostly) static layouts. Views with dynamic layout based on contents (beyond showing/hiding certain parts) that are not suited to tables/collections are not a good fit for IB. Even then I wouldn't give up on IB, instead drop a custom view subclass in (extra points for IBDesignable), and use IB for what it's good at.
> Doesn't play well with source control. Even if the GUI builder spits out a text-based format like XML, it's hard to read and understand diffs, and it can be difficult to impossible to merge.
I often see people making this claim, and I don't understand it. I think the XML format is very sane.
* It's declarative: the structure matches the view hierarchy, making it easy to audit.
* Custom property values are attributes of the view element, putting all of the view customization in one place.
* Constraints are displayed in a way that matches their implementation: they're added to a single view, and they relate two (or one) views with multipliers and constants. The view id is kind of gross, but it's very searchable.
RE: merging. I also strongly disagree that this is "difficult to impossible". If the changes are to separate parts of the view hierarchy or different ViewControllers, they won't conflict. If you do have two different changes to the same views that need to be merged, isn't it a feature that a human has to look at them? I contend that if you read the xml and understand your view hierarchy, merging is not impossible and is often easy.
> Doesn't play well with source control. Even if the GUI builder spits out a text-based format like XML, it's hard to read and understand diffs, and it can be difficult to impossible to merge.
This is a bit more specific to Apple imho. Android layouts are also XML but much smaller and much more manageable in source control. The underlying xml of storyboard files are hundreds of lines long and often change just from opening the file, even if you don't change anything.
Visual Studio (admittedly on a WinForms codebase, but recent .net and VS) sometimes does something similar if you open a design file without changing anything or while changing something completely unrelated - except it also sometimes changes something like the base font or zoom as part of its random unexplainable changes and if you're not careful to remove everything you didn't want to change you'll ruin your layout.
The biggest reasons in my experience are:
* Limited logic. A builder is fine for a simple static layout. How should that layout change depending on the data to be displayed? How should it adapt to different screen dimensions and orientations? Pretty soon you want to write code to control the view.
* Doesn't play well with source control. Even if the GUI builder spits out a text-based format like XML, it's hard to read and understand diffs, and it can be difficult to impossible to merge.
Why don't use tools to make writing HTML/CSS less boilerplate? To some extent we do. We have CSS preprocessors and HTML templating.
In the end, the front end is just code, and no one has yet come up with a graphical form of coding that is superior to text.