
Ask HN: Why Haven't GUI Front End Editors Caught On? - beaconstudios
WYSIWYG&#x2F;GUI frontend editors have been around for years now, but the standard development process for frontend developers is still to crack out an IDE or text editor and write HTML&#x2F;CSS by hand. For such a technical industry this seems like a strange trend - why wouldn&#x27;t we leverage tools and technology to make building HTML&#x2F;CSS less of a boilerplate activity?<p>It makes sense that it could be related to the widgetisation of frontends, with chunks of HTML appearing in different locations or as embedded JSX, but I see no reason why editors couldn&#x27;t provide integration by allowing single documents to be sliced up into smaller components and kept in sync.<p>So, HN, what&#x27;s your take on the lack of adoption of GUIs for building frontends?
======
lj3
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.

~~~
mxuribe
"...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.

~~~
nip
If you can afford not to support IE9 [1], you don't need a 500K - 1MB
framework to center vertically and horizontally by using flexbox (align-items:
center; justify-content: center) on the parent container.

[1] [http://caniuse.com/#feat=flexbox](http://caniuse.com/#feat=flexbox)

~~~
91bananas
Or you can support it but not give them vertically centered content. Screw em.
If they want it to be 5 years ago, let them be 5 years ago. FIVE!

~~~
salmo
I like to call this degrading gracefully :)

------
fusiongyro
Basically, it's because we expect markup to have meaning. The situation is
pretty different from what it was with a traditional GUI builders because of
the markup hiding back there.

In the bad old days, Dreamweaver had visual tools for this stuff, and it
generated a horrifying mess of nested tables. This was rightly criticized
because it made for a huge amount of markup, the markup was difficult to embed
in a generator, there were lots of ways to destroy the layout if the content
you inserted into it was the wrong size or had the wrong stuff inside it, and
it was hell for web scrapers and screen readers. The generated page had no
semantics and tripped up all these secondary uses. It also tended to be huge,
slow to load, and hard to edit later.

Once CSS grew more powerful, a big fight ensued for semantic markup: keeping
the template semantically meaningful (no tables of images and lack of table
content), easy to generate and fill and easy for scrapers and screen readers,
and doing all the layout in CSS. The mantra became something about hand-coded
HTML always being better than machine-generated.

It probably could be done better today (and with the prevalence of JSON APIs
semantic markup may not matter as much as it used to), but once the philosophy
becomes widespread it becomes difficult to unseat. When you have developers
who are competent at CSS and semantic markup, the sales pitch of moving back
to a visual editor becomes harder.

~~~
Animats
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/](http://docbook.org/)

~~~
pjmlp
> Is DocBook dead?

I was involved with a technical documentation project around 6 years ago, and
the trend was moving to DITA.

[http://dita.xml.org/](http://dita.xml.org/)

[http://www.xmlmind.com/xmleditor/](http://www.xmlmind.com/xmleditor/)

[https://www.oxygenxml.com/xml_editor/dita_editor_structured_...](https://www.oxygenxml.com/xml_editor/dita_editor_structured_editing.html)

~~~
Animats
A useful metric for document format is "Does GitHub have an HTML viewer for
it"? Currently, they display PDF, HTML, and Markdown.

~~~
pjmlp
The reality is that Github is irrelevant for the majority of enterprise
customers.

Companies that see software development as a cost center, and rely on
consulting companies to provide value to their actual business processes.

At most, their IT departments or vendor management departments, might know
that Github is where some open source packages they leech are stored.

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

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

~~~
beaconstudios
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 :)

------
meredydd
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](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.

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

~~~
meredydd
We compile the client-side Python code to Javascript using Skulpt
([http://skulpt.org](http://skulpt.org)), and we render the visual components
in HTML, but you interact with them entirely in Python.

This creates a much less "leaky" abstraction than building a new framework
directly on top of HTML/JS. It also lets us offer things like blocking I/O
operations (no more callback hell!).

------
drabiega
Visual editors work great when the thing will always look the way you've
designed it. But that's not how the web works. Especially now that mobile web
browsing is a common thing, your site will be viewed on all sorts of devices
with different resolutions / aspect ratios / etc.

When you add that factor in it shouldn't be hard to see why a visual editor is
not sufficient. Visual editors are just not a great way to specify the type of
logic that decides how your interface will look and behave at radically
different sizes and shapes.

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

~~~
syrrim
The equivalent does sortof exist. You can of course preview your layout in the
browser, and chrome (and possibly others) allows you to change the dimensions
to reflect mobile devices. You can also link the source code in dev tools to a
file, and edit the page live.

------
smilesnd
In my experience frontend editors that designers use generate horrible code.
Just as it is turtles all the way down. For frontend editors it is tables all
the way down. My first web job was modifying CMS. Someone would tell me put a
green box here with inputs for this and that. Then it would go to a designer
to change the fonts, and get rid of the square corners. Then the guy would
want it moved 5px to the left so it would come back to me. The gut wrenching
horrors that would follow still give me nightmares till this day. Everything
the designer touch would be placed in a table inside another table inside
another table all surrounded by a table. This wasn't just the case with
"designers" tools either. I believe windows web forms did a similar thing. It
is difficult to generate human readable code that stays up to date with the
latest trends. That is reliable enough to work across the spectrum that is the
web covering everything from multiple os, web browsers, screen sizes, pixels,
and etc. The few that have try were either brave or foolish to believe that
they could take on a beast such as frontend, and still be around to tell tales
of taming the beast.

~~~
scarface74
Yes those were the bad old days when we used nested tables for layout with
rows and columns. We are much more sophisticated now. We use nested divs with
classes like "row" and "col-md-6".....

------
RcouF1uZ4gsC
In terms of easily cranking out a CRUD app, the current state of the art in
web front-end development is a long ways behind Visual Basic 4 which was
released in 1995.

~~~
ccleve
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](https://www.embarcadero.com/products/delphi))

~~~
therealmarv
Delphi is also the first thing which comes into my mind when I think of that.
I was also much more productive in that old days with GUI stuff. I also don't
understand why there is no good RAD existing nowadays... I think the biggest
reason is because there are no real solid non changing standards (like the
Windows API and VCL in Delphi) and all this stuff HTML5+CSS3+ES6 have much
more possibilities how stuff is created and interlinked to eachother in
comparison to a Windows window system.

------
mariusasdf
I'm a designer, and consider HTML/CSS/JS to be as good a design tool as any,
perhaps even better than any CAD app. I use Sketch, Illustrator and Photoshop
as needed for icons, illustrations and photos.

Also, code is a really handy tool for design (generation/automation).

I believe in using the right tool for whatever "material" I'm working with.
For (responsive) web apps, that tool is HTML/CSS/JS.

Most designer's have their own preferences. I don't believe any current or
future wysiwyg app can meet all needs.

~~~
bearfjellstad
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/](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?

------
drdaeman
There was a time when they were popular. Then, such tools were declared
"uncool" (not without good reasons - the markup wasn't particularly good) by
semantic markup movement, around the time of tables-vs-divs wars.

Semantics had withered away since then. No one cared, and it eventually got
replaced with a bunch of <div>s on the DOM side and JS-virtual-DOM-all-the-way
on how it's generated and managed. Editors haven't caught up, but I'm sure
they will.

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

------
increment_i
I've found I really enjoy using webflow (a YC alumnus I believe) for
responsive front end design. I literally design all my templates and
components in their app now, export the raw HTML/CSS, and add any templating
or client logic if needed. It's fun as hell. I also find looking at the
generated CSS files helps me internalize CSS stuff I wouldn't otherwise have
time to dig into. I know some folks look at me aghast for not hand coding my
front end and I couldn't honestly care less.

I don't think it would work for everyone or every app, but for me it's been a
dream come true.

~~~
beaconstudios
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)?

------
wvenable
In addition to all the good points made here (designs are static, different
devices, etc) it's also because WYSIWYG editors just are plain inefficient.
It's faster and easier to work with text. The best tools and technology work
on text (copy/paste, git, sass, etc). Most people use HTML/CSS IDEs the
provide the same level of power as programming language IDEs.

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

~~~
wvenable
There is no exclusively visual side of things for web design. Sure you do the
initial design in Photoshop but once you need to add interactivity it's no
longer purely visual. You've sliced it up and you can't put it back together.

Xcode works because even on mobile/desktop there is more separation between
design and functionality than the web. The web is both more primitive and more
flexible.

------
brudgers
GUI front editors are always catching on with new users and pragmatists...I
mean for many people WordPress is a GUI editor for making web sties and blogs
at a high level of abstraction of widgets and themes.

Wordpress also highlights the tradeoffs anything that abstracts over the
underlying code...doing something specific means both knowing significant
technical details of WordPress and some non-trivial amount of CSS, HTML,
Javascript, and PhP _and_ the specific implementation details of the site in
question. If the site is leveraging a significant portion of WordPress's
capability then the overhead that comes with using WordPress may be a valuable
tradeoff. Likewise if the person maintaining the site has a business doing
WordPress sites then they can bring WordPress expertise to bear.

But for a general professional programming practitioner, the more universal
tools of programming languages are applicable in more situations...knowing
HTML and CSS is useful when working with WordPress and the more expertise a
person has with the general tools, the less advantage there is to using
WordPress.

Going down the stack from WordPress is possible. But it's still pretty much
the case that if I'm using a GUI editor on the happy path, I don't care that
it's using React. Using or not using React only matters when I'm off the happy
path and have to figure out what the GUI did.

The last problem with front-end development in particular is that committing
to a tool is risky, in two years there's a reasonable chance that the
underlying technology of the tool will be out of the mainstream: e.g. Angular
(one) today.

Good luck.

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

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

------
minimaxir
GUI editors worked because website content was 100% static back then. In 2017,
dynamic templating/MVC paradigms, along with CSS3 shenanigans, make GUIs
difficult and certainly not accessible for non-technical users which would be
the primary market.

That said, I've seen React GUI editors pop up occasionally.

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

~~~
robin_reala
Because front-end development isn’t visual development, it’s interface
development.

What you’re building can be accessed visually on a variety of screen sizes,
through a screen reader, a screen magnifier, a braille display, through print
outs and a multitude of other different ways.

Conversely in the other direction, you’re also building application interfaces
that let back-end systems feed data into the interface, and that‘s not
something you’d want to use a visual editor for either.

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

------
GFischer
I've seen a few bootstrap-based ones and I have tried a few, like PineGrow and
Bootply, and I think they help. I'm hoping for a React-friendly one.

[https://pinegrow.com/](https://pinegrow.com/)

[http://www.bootply.com/](http://www.bootply.com/)

A list of some options:

[http://www.cssauthor.com/bootstrap-
editors/](http://www.cssauthor.com/bootstrap-editors/)

~~~
moflome
> React-friendly one...

How about Structor: [https://helmetrex.com](https://helmetrex.com)

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

------
intrasight
The software industry largely decided to use HTML for the front end, it also
largely gave up the 20 years of R&D on GUI design tools for existing
semantically rich front-end frameworks. If Motif were FOSS or if CMU hadn't
handed license rights to Andrew WM to IBM, we'd have probably avoided this
whole mess that is HTML.

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

~~~
intrasight
That like looking at Windows 3.1 screenshots and saying Windows 10 is
horrible. Obviously thing would have evolved and improved. My point is that it
was encumbered by licensing issues and therefore wasn't adopted.

------
tigershark
My point of view as a WPF developer is that I permanently switched the xaml
files to be opened with the plain xml editor rather than with the normal
design view. If I need to design something really specific, in the very
unlikely case that I don't do it with Inkscape, I use expression blend just to
iterate quickly over that very specific graphical element. For all the rest I
just write xaml. There is auto-completion, most of the time I don't even need
it, and if I had to use the designer view to compose my guis I would spend
much more time for nothing. And after that I had to manually edit the awful
design that is spit out by The wysiwyg editor. So I really can't imagine
myself now using one gui editor as I have done multiple times in the past.

------
jonshariat
I have been thinking the same thing for a while now. I know exactly what
vision youre getting at. I think most people, especially programmers, don't
see it.

The closest thing right now I've seen is Webflow and its CMS. You could create
a lot of basic web apps with it.

------
conductr
I've tried to use some of these mentioned GUIs. For me, the learning curve is
fairly steep. Beyond creating something very simple I always find myself
spinning my wheels very soon. I know what I need, so it's much easier to jump
into the IDE and just do it. Also. At some point even your HTML is going to be
made live. Either through turning it into the template or inline code or etc.
it just doesn't really blend with my workflow. I prefer to sketch out things
on paper then just go straight to IDE seems to be quickest way to keep the
iterations going and then push to prod with least amount of friction.

I see using these tools like using photoshop to create a sculpture.

~~~
benharrison
I completely agree with the learning curve. I often think it's just as hard,
if not harder, to learn a new tool than it is to learn a new programming
concept. You have to re-train your brain to think the way the creators of the
tool approach problem solving (assuming their approach is actually good). If
you're not already like-minded, then this is incredibly counterproductive.

There's so much flexibility that allows for creativity when you just
understand the code. In fact, I've been doing what I consider to be "designing
in the browser" for years. Which is using Photoshop to get started, pick
colors, etc, then utilizing developer tools for much of the refinement during
the implementation phase. This is the closest thing I've ever found to a good
"GUI editor".

------
redindian75
Here are some GUI Tools which are showing promise. (not affiliated with any of
them)

Here were my basic needs:

* Ability to be understood by a non coder (not necessarily web novice).

* Simple Reusable Components - Drag & Drop tools to create simple CRUD apps

* Code Generation - Have enough scaffolded code generated to hand off to a coder to wire it up. (from Elance etc)

* Work on at least 2 of 3 platforms - WebApp (JS, React or Vue), iOS & Android

* Have ability to create simple logics - If/Then or Show/Hide or even JSON digestion

Here are the tools:

[https://neonto.com/reactstudio](https://neonto.com/reactstudio) \- A drag n
drop Mac tool for developing React apps. All three platforms.

[http://creolabs.com](http://creolabs.com) \- Design tool for Mac (this guy
rewrote UIKit). Only Native ios/android. No Webapp.

[https://www.protopie.io](https://www.protopie.io) \- Prototypes for now,
simple code export on the way.

[http://www.appgyver.io](http://www.appgyver.io) \- Data Driven drag/drop
webapp. All 3 platforms.

[https://creator.ionic.io](https://creator.ionic.io) \- GUI tool for Ionic
(Angular).All 3 platforms.

[https://material.io/stage/](https://material.io/stage/) \- Google's upcoming
tool (From Pixate & Form team). Unknown.

[https://polymer-designer.appspot.com/](https://polymer-designer.appspot.com/)
\- A Crude Polymer layout tool, looks like Google abandoned it.

[http://www.getnoodl.com/](http://www.getnoodl.com/)

Prototyping tools like Facebook Origami
([http://origami.design/](http://origami.design/)) have refused to spit out
code. So I didn't even bother learning it.

------
jplatte
Hm, it might have to do with the way CSS works.. When I'm developing gtk+
Applications, I always do the UI in glade. It works wonderfully, even if I
still have to do some stuff in code (UI elements that are added in response to
the user doing something). And even for that there seems to be an alternative,
namely GtkBuilder templates – haven't tried that yet and Glade doesn't seem to
be able to create them, but might be able to edit them once you have manually
written the first few lines of XML.

~~~
benharrison
Good point. I've never actually worked with gtk+, but I have worked with
windows forms development for desktop apps. I thought it was a really good
approach for building a windows desktop applications, but I create all web-
based UIs in a code editor.

I suppose if there was only one browser to target, then we might actually see
more use of a GUI editor. Kind of how FrontPage was for IE a long time ago.

------
redindian75
Simple, job security. It would put lot of FrontEnd Coders out of work - not
all, but many of them. So it is in everyone's best interest to keep coders
coding, designers designing and have as little overlap as possible. Silos
keeps the wheels turning.

So there has been a collective badmouthing about how WYSIWYG tools create a
codular mess, and then they proceed to create similar codular mess by hand
(pull this library, glue, pull that library, glue..etc). After Bootstrap,
webdesign is dead. Every single website look the same. If not literally, then
same blocks re-arranged (Hero Image, Sticky Nav, Round Profile Pictures,
Contact Map, Footer).

I remember Dreamweaver in late 90s, it democratized webdesign, as a design
student, I was able to pretty much draw and create as simple or complex I
want. In 1998 Dreamweaver promoted "Roundtrip HTML" to quell the backlash -
but dev sentiment killed a lot of momentum it had (They still badmouth it).
Semantic Markup, Tables... unmaintainable, and then proceed to have the same
convoluted polluted code. Was it perfect? NO... but it was not FrontPage or
Word>HTML. It is 2017, and with the technologies available today, there should
be multiple tools to cater to UX tooling.

For most designers, learning to code kills the spark of creativity, and puts
you in a templatized mindset (Hero Image, Logo on top left etc).

~~~
strickjb9
I'm not sure if this is a troll post. The "un"adoption of GUI frontend tools
has nothing to do with job security. At best, it is a poor conspiracy theory.

There are great answers in these comments that provide good insight. This
comment is not one of them.

------
dustingetz
Frontend development involves I/O (server data fetching), which has
implications

\- it is async \- it can fail \- it is slow

TLDR you need a programmer to hand-orchestrate the I/O.

REST (HATEOAS) link abstraction permits a general solution to data-driven user
interfaces (this is why web browsers are a generic user interface for simple
html-only applications), but they are slow due to the way the data fetching is
handled - see former facebook manager Pete Hunt's quote here (2014) which
predates GraphQL
[https://news.ycombinator.com/item?id=7601774](https://news.ycombinator.com/item?id=7601774).
Essentially we are talking about the object/relational impedance mismatch,
which has performance implications and generally requires hand optimizing by a
programmer (tweak the backend queries to batch a lot of stuff and minimize
database round trips; tweak the frontend to do as few network requests as
possible..this causes the backend-for-frontend pattern (anti-pattern) where
you get N backends each hand coded... you can't abstract over this and also
have good performance.
[http://samnewman.io/patterns/architectural/bff/](http://samnewman.io/patterns/architectural/bff/))
So you need programmers to figure out the right perf compromises and write the
same shitty glue code over and over.

BUT if you have a graph oriented database with something like GraphQL to query
it from the frontend, it's pretty easy to imagine abstracting over this stuff
in a way that doesn't require hand-tuned performance e.g. Relay and Netflix
Falcor, just needs one generic backend, and this paves the way for generic
CRUD app word processor that outputs performant apps. If you abstract over
I/O, the actual user logic code isn't async, there's exactly one place doing
I/O (the generic runtime) so user code can't fail, data fetching is
automatically batched properly so user code isn't slow. Don't need a
programmer anymore, what you need is more like a business analyst who can
write excel formulas.

My startup is building exactly this, it's called Hyperfiddle, email me
directly if you'd like to talk about this or be on our mailing list when we
launch this year. You can read a little more about it in this transcript of my
LambdaConf talk last summer:
[https://docs.google.com/document/d/1hb9qB_d9jlDUpgTSBcFELGhK...](https://docs.google.com/document/d/1hb9qB_d9jlDUpgTSBcFELGhKuWVecVzgGCcOeR9UueE/edit#heading=h.up2n5n7x3shf)

------
tyingq
WYSIWYG seems to work well for HTML/CSS if you're working in a specific, fixed
domain.

Wix.com, for example, does a nice job with this. If you play around with it,
though, you can see why it would be difficult to extend it for general purpose
use on any type of website. See
[https://www.youtube.com/watch?v=UgkkiKdPibg](https://www.youtube.com/watch?v=UgkkiKdPibg)
for an idea of how it works.

------
jdauriemma
WYSIWYG editors have a hard enough time generating valid, sensible markup and
styles for consumption by typical end users. But many end users are not
typical - some have visual and/or auditory impairments. In many jurisdictions,
website creators are legally required to comply with accessibility (a11y)
principles. This adds another layer of abstraction on top of the already
complex task of building a valid and functional UI.

------
brandmeyer
I agree with the other's regarding the dynamic nature of the content. In
addition, the widgets themselves haven't changed all that much for desktop
GUI's. WxWidgets, Win32, Gtk, and Qt have mostly the same basic set of
controls today that they had 15 years ago. Just imagine the extra R&D churn it
would consume if you also had to update your GUI editor every time you changed
a web UI control!

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

------
startupdiscuss
Good question.

One way to think about this is: why don't you or I use a GUI to build a front
end.

I tried to use one for Bootstrap, and it was hard to get the everything to
line up right. I wasn't sure how things would act when the screen changed, or
how to change that.

Then when I went into the CSS it was laid out in an unfamiliar fashion.

These problems seem very solvable, but I don't know why they persist.

~~~
beaconstudios
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).

------
anigbrowl
Most programmers are not very good at visual thinking IME. I have a bet with
myself that by 2025 natural language processing will be good enough (combined
with other UI tools) for designers to explain what they want directly to the
computer and a great many programmers are going to be sitting around wondering
what the hell happened.

~~~
redindian75
> Most programmers are not very good at visual thinking IME.

As a visual thinker, I cannot wrap my head around even simple programming
concepts - they seem SO alien to me :)

------
ilaksh
Having used many great visual dev tools over the years but also generally
mainly focusing on code, especially in the HTML world, and having had many
discussions on this topic over the years, I can promise you that it is a
cultural/social failure rather than a technical issue.

It comes down to this: programmers write code. If you build your UI or
whatever graphically without writing code, then you are not a programmer --
you are a user. The last thing any programmer wants to be is a lowly user. So
programmers have a natural motivation to not make these tools better or try to
use them. And it becomes part of the culture to not use visual tools, and
naturally having rarely used them and never trying to improve them and the
fact that they diminish their job towards more user-like behaviors,
programmers often do not find them useful.

------
oneeyedpigeon
HTML isn't WYSIWYG. Every 'front end html GUI editor' I've seen has tried its
best to sweep that fact under the carpet rather than embrace it.

HTML is very easy to edit, in fact, if you need precise results, it's easier
to edit html by hand than it is to wrestle with a WYSIWYG editor, trying to
get it to do what you want.

CSS really doesn't suit itself to our current understanding of GUI editors.
It's not even clear how editing specificity of a selector, to take just one
example, should work in a WYSIWYG environment.

We haven't got good visual editors for html/CSS for many of the same reasons
that we don't have good visual editors for C.

------
andrei_says_
I do both design and development and in my experience it comes to abstraction
level, control and code quality.

Any GUI editor I've tried sooner or later comes down to editing CSS/ HTML via
dialogs which is less efficient than editing text files and requires similar
expertise. I'd rather know CSS / HTML than be an expert in my way around a
certain GUI.

Front-end code structure matters a lot for maintainability and there is no
standardization to account for that.

Autogenerated code is not great.

So, once I am done with basic UX prototyping on paper, I usually move to
handcrafted code and fill in detail as I know/discover more, testing along the
way.

------
pjmlp
On the projects where I am tasked with fronted development, the WYSIWYG
editors have surely caught on.

Then again, for me frontend means native applications, using Android UI
Builder, WPF Blend, Qt Creator, iOS UI Builder, Netbeans Matisse.

------
gmays
The most popular CMS, WordPress, is experimenting with this now:

\- [https://make.wordpress.org/design/2017/02/09/initial-
gutenbe...](https://make.wordpress.org/design/2017/02/09/initial-gutenberg-
prototype-editor-testing/)

\-
[https://github.com/WordPress/gutenberg](https://github.com/WordPress/gutenberg)

\- Demo:
[https://wordpress.github.io/gutenberg/](https://wordpress.github.io/gutenberg/)

------
miguelrochefort
Creating UI by hand is ridiculous. It doesn't scale.

\- All companies think they solve a unique problem, and believe that justifies
creating a custom UI.

\- All brands want as much exposure to users, which demands custom UI themes
and styles.

\- All devices have access to different I/O components, which implies
completely different user interfaces.

\- All users have different preferences and needs.

You can't design a one-size-fits-all UI taking all of the above considerations
into account. You need to operate at a higher level of abstraction than
"pixels on a screen".

The solution has been in front of us for decades. It's semantics.

------
mmjaa
I think they're there, you just need to find them. For example, here's a
pretty good one: [http://h5mag.com/](http://h5mag.com/)

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

------
jkmcf
I still miss Sun's DevGuide. It's hard to find anything on it these days. It
was so easy to create a GUI and I haven't found anything similar.

------
elchief
Like [http://maqetta.org](http://maqetta.org) and
[https://www.sencha.com/products/architect/](https://www.sencha.com/products/architect/)

It seems like once a GUI library gets mature enough to get a graphical editor,
some new library comes along that the herd moves to and the old one dies a
slow death

------
postscapes1
If Webflow could bump up its CMS abilities just a notch or two, and include a
better template/design component it would be a knockout imho...

On this same note I would kill for someone to add this type of interface to
Airtable.... An untapped market with most current solutions (knack, caspio,
etc) not even close on graphic and layout possibilities.

------
Retric
The real issue is a huge WYSIWYG : HTML mismatch. You want HTML that looks
different on different screens, handles blind users, and gracefully degrades
to still work on IE 6, early iOS, etc.

Meanwhile designers using WYSIWYG tend to build applications that work just
fine in their environment and nowhere else.

~~~
tluyben2
You want that but in reality, how often does it happen for popular sites? The
small startup sites no one will ever visit are ready for the handicapped, slow
connections, work on every browser and mobile while my banks, airlines and
others I need and/or visit daily barely work for normal users on high powered
desktops. And the bad apps they have. Oh boy. They would benefit from a more
generic bootstrap/react based wysiwyg component approach.

------
praptak
Same reason markup/markdown is better for docs than Microsoft Word.

WYSIWYG development just sucks. It's not diffable nor mergeable. Quick setup
is simple, but complex refactorings are plain impossible. Also there's always
at least this one thing the editor fights you on.

------
jmcmahon443
Yo man, everyone's got their brew. It's just how much of it you can remember
and copy into the next batch each time.

------
george_ciobanu
Check out bubble.is. It does a fantastic job at both, though it is an
integrated solution.

------
jinglebells
Because then you'd have two problems instead of one.

------
ericls
What about UX? How you drag and drop that?

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

------
timthelion
The correct answer to this is that the structure of the interface changes over
time, and is influenced by the code. If you were to try to implement, say, the
interface to HN, then you would create a top bar with some links, a body
section, and then a bottom bar with some links. But the interesting part, all
the posts, couldn't be drawn in the gui editor, because, well, they are
programically generated. You could create some sort of post template, that
would then be able to be injected into the "body section" but really, all the
interesting parts of the interface end up being dynamic, and the static parts
are trivial to design in code too.

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

------
droithomme
If these things produced good backend code, were faster to work with than
text, produced code compatible on all browsers, and could do what I want them
to do I'm sure I'd continue to use them rather than quickly find them
unsuitable for my particular purposes.

In chip design there's graphical editors available, but most design work is
done by writing text in languages such as Verilog and VHDL.

