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

the "pop up occasionally" part is what has me stumped - if these tools are any good, they must surely be more efficient than hammering out CSS and HTML (or pre-processor languages) by hand. If they aren't, then why, and if they are, what's holding back adoption? I'm a frontend developer myself and the reason I posted the question is because I couldn't give myself a good answer as to why I wasn't using one myself.

I remember dreamweaver, and I have the mental scars to show from using it. However, dreamweaver came about in the time of table-based layout and refused to adapt when the market consensus moved to div- (and later semantic element-) based layouts.

There's no reason that I can see, that you wouldn't be able to name the elements in a document (or ML could be perhaps used to auto-derive names), and beyond that, my understanding is that semantic markup (at least in terms of class/ID names) hasn't proven to be all that important since the advent of the API. Perhaps it's just not been done well enough so far to justify moving over from HTML/CSS, but you'd expect people to be jumping to solve their own issues. I for one find CSS/HTML tweaking to be pretty monotonous when I'm just trying to get to an end result.

This is probably historically true, but I don't see why a WYSIWYG editor for CSS based layouts could not exist?

I'm not a front end developer, and don't really have any desire to become one, and I would like to have a GUI for building fairly standard UIs.

No, we don't "expect (HTML) markup to have meaning". Browsers don't do anything with that semantic information. What we have are generators which use HTML/CSS as an output medium, like Postscript or PDF.

Sites with HTML tables were faster to load, smaller, resized automatically, and never had overlapping text. Most of the claimed benefits of CSS were false. CSS pages tend to pull in, or include, large libraries of styles, Javascript, and other junk. That's where page bloat comes from. See yesterday's article on why the web is so slow despite more bandwidth. Do "view source" on the pages of some major sites. It's disgusting.

There seems to be a programmer mindset that users must write source code which is then compiled to something else. Nroff/Troff, then TeX, then DocBook, for example. (Is DocBook dead? The last update on the DocBook site was three years ago.)[1] This is a terrible thing to impose on users.

[1] http://docbook.org/

intriguing - and how are you finding webflow? Is it just HTML+CSS rearranged in GUI form, or does it take away some of the more boilerplate-y aspects (clearfixes, polyfills, grid layouts etc)?

Seeing some other comments, I think we're very close to a VB-like solution (maybe something with React + a GUI).

this is what's shocking to me - I will confess, I partly started this thread to investigate whether there was an opportunity to start a company around making web front-end development suck less. The fact that we hand-write the most fine-grained basic stuff in 2017 is odd for such a technical industry. Shoot me an email (my address is in my profile) if you'd like to check it out when it's ready!

Completely agree. I wrote code in Delphi 20 years ago, and I was far more productive than I am today.

The secret was to have self-contained components that fit within a rigid layout system. It wasn't easy to make things pretty, but it worked. To write code, you clicked on the component, clicked on an event, and wrote your logic in a little snippet editor. It was all event-driven.

Would love to have something like that for web design today. An opinionated system that forced you to use a limited subset of html and css might be able to pull it off.

(Delphi was a VB-like environment for Borland Pascal. It's still around: https://www.embarcadero.com/products/delphi)

37Signal's new tool GoMix [1] is being billed as an answer to that. I was squarely on that target group, but I gave up on that after a few tries... It was supposed to be simple, but never understood conceptually.

[1]https://gomix.com/

Right, and some open source CMS systems try to provide similar capabilities--widgetized themes in WordPress or Panelizer in Drupal, for example.

But the UIs are complex, and getting good performance is a challenge because of all the layout info stored in the database. They are not something a capable dev team would want to build a product on top of. Fine for empowering content authors though.

"...centering an object horizontally and vertically consistently is still a surprisingly difficult endeavor..." This is so true - even today. Oh wait, someone might state, "but there are frameworks you can simply integrate and they handle that kind of stuff for you, or at least make it easier"...To which I reply, do i really have to include ~500K - 1MB of some framework for this!?! Just silly that centering is an annoying task nowadays.

    .center-the-stuff {
      display: flex;
      align-items: center;
      justify-content: center;
    }

  .parent {
    position: relative;
  }

  .child {
    position: absolute;
    top: 50%;
    left: 50%;
    transform: translate(-50%, -50%);
  }

> What I would really like are more robust layout APIs for both the browser and native apps.

This is what I love about CSS flexbox and grid. Flexbox completely changed how I approach layouts, and I'm excited for grid to hit the big time as well.

The only thing I wish flexbox could do is allow custom spacing functions, so I could write my own alternative to "justify-content: space-around".

Sketch is pretty good these days and easier for developers to take the output of vs. Photoshop: https://www.sketchapp.com/

I wish more tools let me define constraints. Flexbox helps to brute force the layout you want, but it's still pretty annoying. Something like http://gridstylesheets.org/ is a good example of what I want to use more of the time.

Same way you don't drag and drop conversations. UX isn't a product; it's a byproduct of UI. Good UI necessarily produces good UX, not the other way around, no matter what professional "UX engineers" post to Medium.

How can u skip HTML/JS stack for websites? Is your editor only for apps?

The 'withering' of semantic markup is one of the greatest tragedies of the modern web.

totally agree - I remember that war! For simple layouts (even works on email clients) nothing to beat a well designed Table.... it just works :)

interface builder ( xcode ), does it well for iOS. You can preview you UI instantly for ipad / iphone in both portait and landscape.

i think the reason the equivalent doesn't exists for web is maybe due to the complexity of css / html, and the various level of browser support, which makes all of it a dark art as soon as you aim for wide device support. Whereas Apple controls everything.

If there was a text-based UI for Photoshop, I doubt it would be better at most things than how Photoshop works now, which involves direct manipulation of an image with essentially real time feedback of each action as you do it.

The OP is also talking about editing the visual side of things, and I think if a well-done editor that also output good CSS and HTML existed, it would be embraced by many.

Of course, I'm someone who enjoys using Xcode's interface builder tools to edit GUIs, rather than laying out controls in code, because I get instant feedback with Xcode's interface builder. As others have mentioned, something similar for Web work seems like it could be very powerful.

Haha. Do a google image search for "motif gui" and you'll see the most horrible interfaces made by men.

Motif, seriously?! A crap-ass, practically committee-built framework that tried to mimic Windows UX without investing in any real UX?! With all the glory of writing hundreds of LOC to achieve small things, casting things into generic Xt pointers, debugging segfaults caused by occasional wrong structure cast etc etc.

HTML stressed rapid results and quick iteration. Surely, it bought many other idiosyncrasies to the table but proposing Motif as HTML killer... In this case we should also declare CORBA a hypothetically better alternative to SOAP and WSDL...

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 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.

> 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.

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.

I'm actively looking into this idea at the moment, and would love to get some feedback from you along the way - I don't have much built right now but I'm happy to give you a discounted account and influence over the product direction if you'd be willing to give me feedback while I iterate? My email address is in my profile if you're interested :)

(this also applies to anyone else who thinks that GUI frontend editing is the way forward - send me an email and I'll let you know when I have something to show you! I won't send you anything else, scout's honour).

Just to be clear, I say that this is the "correct" answer in order to differentiate my answer from the ones that I think are not actually correct.

I often think, and many agree, that the problem is with reactive interfaces supporting both mobile and desktop. Or that the problem is with GUI editors producing disgusting HTML. And indeed these are both problems. But QTDesigner, and friends don't face these problems. Your GTK app isn't going to be a reactive interface, and QT, not using html, isn't at risk of the "disgusting html" problem. And yet these designers aren't terribly popular either.

Yup, the Adobe Flex GUI builder was lovely - right up until you got to the dyanmically generated content or custom components.

Indeed, and our text tools are powerful in the extreme for implementing said changes

I'm a designer too and I've gone from using Illustrator and Photoshop to doing mockups straight in code. It sometimes feels a bit silly to first create a design mockup and then recreate the exact same thing in css. I would much rather create simple unstyled wireframes outlining the basic UX, maybe create a style guide, and do the mockups using HTML and CSS. I also feel that I'm making a lot of similar components such as heros, buttons, carousels, cards with small variations for different projects. I have started to create a repository of often used components that can be easily customized to suit the style of new projects without having to rewrite the entire thing, and it's called http://kitr.io/. The plan now is to add every new component I design and develop to KITR. It would be cool to be able to export to React components and not just plain HTML and CSS, but at least it's possible to copy into any project with some modifications as of now. Do you have any UI components that you feel like you are recreating often?

But you can create a custom control (not as nicely as Delphi has that covered) which can be packaged and documented and then reused. With web, because of CSS this is a problem; shove your custom html control in another page and it suddenly looks bad, not because of a few colors and a bit of alignment (like it would be on the desktop), but because of different framework use, different layouts, clashing css etc. It is a pain compared but he, it is what it is for now.

For niches there are many and many are making big money inside that niche. As generic tool it is much harder. You can turn things around, if possible, but letting your designer use such a tool. Then she is locked inside this constraint to make it look nice. Ours, rightfully, as head design, does not want to do that and I believe many won't though.

> React-friendly one...

How about Structor: https://helmetrex.com