Ask HN: Why Haven't GUI Front End Editors Caught On?
139 comments
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.
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.
"...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.
> To which I reply, do i really have to include ~500K - 1MB of some framework for this!?!
What framework?
What framework?
.center-the-stuff {
display: flex;
align-items: center;
justify-content: center;
}here's a non-flexbox solution, but the parent element has to have a set height:
.parent {
position: relative;
}
.child {
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
}It's like a magic spell that makes very little sense and is impossible to guess.
If I fire up a reasonable layout system (Xaml for example) which is completely foreign, it's trivial to do there.
I can't understand why html/CSS makes it so hard.
If I fire up a reasonable layout system (Xaml for example) which is completely foreign, it's trivial to do there.
I can't understand why html/CSS makes it so hard.
Because html/css was never intended to be used for layout. It's primarily a content styling system for static documents.
[deleted]
That was so easy with tables.
At the cost of poor performance on the client [1], so you're just pushing any time saved in development onto your user.
The only way around the poor performance of table layouts is to use table-layout: fixed, which then means you lose all responsive layout so you'd need to create a new version for every screen size you wanted to support (and implicitly, not be able to support every size of mobile screen since percentages don't play well with fixed layout. In this case, you haven't saved any time and in fact have created more work for yourself along with a worse version of your site since fewer people will be able to view it properly.
[1] http://www.stubbornella.org/content/2009/03/27/reflows-repai...
The only way around the poor performance of table layouts is to use table-layout: fixed, which then means you lose all responsive layout so you'd need to create a new version for every screen size you wanted to support (and implicitly, not be able to support every size of mobile screen since percentages don't play well with fixed layout. In this case, you haven't saved any time and in fact have created more work for yourself along with a worse version of your site since fewer people will be able to view it properly.
[1] http://www.stubbornella.org/content/2009/03/27/reflows-repai...
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
[1] http://caniuse.com/#feat=flexbox
Fortunately this is not much of an issue because IE is on its well deserved way of dinosaurs and Dodo the bird (my sympathies to those who can't get rid of it because of some dated corporate standards) and Edge doesn't seem to have much impact either. It would fill me with endless joy years back had I known its fate and the success MS will have in next computing platform (mobile). Good riddance!
I am looking forward to the day when I don't have to support ie9
> 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".
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".
Here is the best visual approach ive seen to designing flexbox layouts: http://flexboxgame.com
This is great. Until now, I have been using the "flex box froggy" game for reference. It has been faster for me to recall flex-box CSs rules by scrolling through levels in that game than reading any "real" documentation.
The link you shared above is a big upgrade.
The link you shared above is a big upgrade.
I really like what safari has done with its devtools for the style editor.
Right-click inspect element selects the element you want to modify. Then change CSS properties in a GUI editor. Only problem is persistence.
I love designing and tweaking with devtools iteratively.
A lot of things are done in editors because it gives you a lot of control of logic. Designing assets in visual language like flash makes a lot of sense.
Unity has the same idea. Create your assets visually and assign behaviors to it via code. Their GUI/code fusion is pretty cool.
Writing a public var in a class exposes it in GUI and makes it bindable to other things via click and drag.
Right-click inspect element selects the element you want to modify. Then change CSS properties in a GUI editor. Only problem is persistence.
I love designing and tweaking with devtools iteratively.
A lot of things are done in editors because it gives you a lot of control of logic. Designing assets in visual language like flash makes a lot of sense.
Unity has the same idea. Create your assets visually and assign behaviors to it via code. Their GUI/code fusion is pretty cool.
Writing a public var in a class exposes it in GUI and makes it bindable to other things via click and drag.
Flexbox Game doesn't support Firefox 53 yet, but I can vouch for Flexbox Froggy as well as Flexbox Defense http://www.flexboxdefense.com/
> custom spacing functions
Keep an eye on "Houdini" -- a new browser API draft that exposes the internals of CSS's layout system (and much more): https://www.youtube.com/watch?v=sE3ttkP15f8
Keep an eye on "Houdini" -- a new browser API draft that exposes the internals of CSS's layout system (and much more): https://www.youtube.com/watch?v=sE3ttkP15f8
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.
[deleted]
Sketch is pretty good these days and easier for developers to take the output of vs. Photoshop: https://www.sketchapp.com/
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.
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.
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/
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/
You're confusing cause and effect. There was a movement that posited semantic markup would be good, and we all (mostly) accepted it. CSS's technical shortcomings were very pronounced in the beginning and mostly abated soon after. Achieving the perfect 3-column layout was still hard, as was really centering something, but most other stuff wasn't that far out of reach.
Now there are new problems having to do with bloat, and of course many people use Bootstrap wrongly, but nobody is honestly suggesting you go back to table-driven layout. I'm saying, this is the philosophy that got us here. I'm not saying it works well or that most content is semantically tagged—it isn't.
Your concluding remarks also seem off-base to me. TeX to some extent and LaTeX to a much greater extent put a lot of emphasis on semantic markup. It's just locked up in TeX-land and hard to parse outside of it, so the utility is limited, but every edition of the TeXbook and Guide to LaTeX2e expends great effort encouraging you to introduce semantic macros into your documents so that changing the style does not require extensive rework, as it would a Word document without stylesheets. Even the old Nroff/Troff macros had semantic-ish macros you were supposed to use. And DocBook really could not be further in this direction, where all the styling happens in CSS or XSL, and you have tags like `<computeroutput>` and `<funcprototype>`. I don't see how semantic meaning is an imposition, and anyway, the document authors and the document readers are not the same people.
Now there are new problems having to do with bloat, and of course many people use Bootstrap wrongly, but nobody is honestly suggesting you go back to table-driven layout. I'm saying, this is the philosophy that got us here. I'm not saying it works well or that most content is semantically tagged—it isn't.
Your concluding remarks also seem off-base to me. TeX to some extent and LaTeX to a much greater extent put a lot of emphasis on semantic markup. It's just locked up in TeX-land and hard to parse outside of it, so the utility is limited, but every edition of the TeXbook and Guide to LaTeX2e expends great effort encouraging you to introduce semantic macros into your documents so that changing the style does not require extensive rework, as it would a Word document without stylesheets. Even the old Nroff/Troff macros had semantic-ish macros you were supposed to use. And DocBook really could not be further in this direction, where all the styling happens in CSS or XSL, and you have tags like `<computeroutput>` and `<funcprototype>`. I don't see how semantic meaning is an imposition, and anyway, the document authors and the document readers are not the same people.
> 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://www.xmlmind.com/xmleditor/
https://www.oxygenxml.com/xml_editor/dita_editor_structured_...
I was involved with a technical documentation project around 6 years ago, and the trend was moving to DITA.
http://dita.xml.org/
http://www.xmlmind.com/xmleditor/
https://www.oxygenxml.com/xml_editor/dita_editor_structured_...
A useful metric for document format is "Does GitHub have an HTML viewer for it"? Currently, they display PDF, HTML, and Markdown.
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.
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.
Could not disagree more strongly. A readme or changelog is not a document.
And .org files
Screen readers do expect semantic markup, and it's possible to get by with aria-roles, but why?
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.
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.
I agree. I think the situation created the philosophy which we have today, but the situation has changed. It probably could be done better today, just either nobody's doing it, or it's not gained traction yet.
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.
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.
"Why hasn't X happened?" History explaining why X hasn't happened. "Yeah, but why couldn't it happen?"
Yeah, it totally could happen. Go make it and I promise I'll start using it.
Yeah, it totally could happen. Go make it and I promise I'll start using it.
People have mentioned a few that already exist in this thread; I found another one called Avocode.
It seems like they do exist, and it's just that developers like myself are unaware of them.
It seems like they do exist, and it's just that developers like myself are unaware of them.
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.
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.
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.
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 :)
How was Constructor better than IB? And how did it deal with the issues I mentioned?
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.
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.
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.
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:
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.
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
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.
How can u skip HTML/JS stack for websites? Is your editor only for apps?
We compile the client-side Python code to Javascript using Skulpt (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!).
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!).
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.
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.
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.
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.
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.
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.
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".....
And it was even worse in the days when there was no Firebug and similar tools... I will miss you Firebug (just today I noticed console no longer works in FF 51.0.1, so I guess it's time to switch).
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.
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)
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)
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.
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!
Check out Rails. You could make a static header and footer template for all pages in Dreamweaver or whatever, then for the dynamic parts, the code is very simple. GUI editors can't do this because they don't have a good way to specify what you want to be templated and what you want to be dynamic, and how/when to display those dynamic parts.
Every framework has that though and most have had that since inception. That is not really the point. You want to be able to do the 'cannot do this' points too.
of course, the dynamic nature of modern UIs would have to be a first-class citizen in any competent modern WYSIWYG designer.
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/
[1]https://gomix.com/
Seeing some other comments, I think we're very close to a VB-like solution (maybe something with React + a GUI).
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.
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.
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?
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.
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.
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 :)
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.
I don't think it would work for everyone or every app, but for me it's been a dream come true.
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)?
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.
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.
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.
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.
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.
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.
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.
Well, they sort of have in the form of Wix and Squarespace.
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.
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.
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.
That said, I've seen React GUI editors pop up occasionally.
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.
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.
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.
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.
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.
I often think react seems like the perfect use case for a graphical tool - you could write all the components yourself, so have total confidence in the markup, and just assemble them and add events etc through the gui
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).
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).
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.
There are great answers in these comments that provide good insight. This comment is not one of them.
Do you realize, that guis, and gui designers have been around since before the internet? Do you realize that smart programmers working on their own dime don't use gui designers, not out of desire for job security, but for real technical reasons? Do you think that Richard Stallman and the GNU freaks don't use GUI designers out of desire for job security? That's an insane notion, given that many free software developers don't have traditional jobs by choice.
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/
http://www.bootply.com/
A list of some options:
http://www.cssauthor.com/bootstrap-editors/
https://pinegrow.com/
http://www.bootply.com/
A list of some options:
http://www.cssauthor.com/bootstrap-editors/
> React-friendly one...
How about Structor: https://helmetrex.com
How about Structor: https://helmetrex.com
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.
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.
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...
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...
Haha. Do a google image search for "motif gui" and you'll see the most horrible interfaces made by men.
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.
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.
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.
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.
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.
The closest thing right now I've seen is Webflow and its CMS. You could create a lot of basic web apps with it.
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.
I see using these tools like using photoshop to create a sculpture.
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".
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".
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 - A drag n drop Mac tool for developing React apps. All three platforms.
http://creolabs.com - Design tool for Mac (this guy rewrote UIKit). Only Native ios/android. No Webapp.
https://www.protopie.io - Prototypes for now, simple code export on the way.
http://www.appgyver.io - Data Driven drag/drop webapp. All 3 platforms.
https://creator.ionic.io - GUI tool for Ionic (Angular).All 3 platforms.
https://material.io/stage/ - Google's upcoming tool (From Pixate & Form team). Unknown.
https://polymer-designer.appspot.com/ - A Crude Polymer layout tool, looks like Google abandoned it.
http://www.getnoodl.com/
Prototyping tools like Facebook Origami (http://origami.design/) have refused to spit out code. So I didn't even bother learning it.
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 - A drag n drop Mac tool for developing React apps. All three platforms.
http://creolabs.com - Design tool for Mac (this guy rewrote UIKit). Only Native ios/android. No Webapp.
https://www.protopie.io - Prototypes for now, simple code export on the way.
http://www.appgyver.io - Data Driven drag/drop webapp. All 3 platforms.
https://creator.ionic.io - GUI tool for Ionic (Angular).All 3 platforms.
https://material.io/stage/ - Google's upcoming tool (From Pixate & Form team). Unknown.
https://polymer-designer.appspot.com/ - A Crude Polymer layout tool, looks like Google abandoned it.
http://www.getnoodl.com/
Prototyping tools like Facebook Origami (http://origami.design/) have refused to spit out code. So I didn't even bother learning it.
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.
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.
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.
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. 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/) 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...
- 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. 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/) 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...
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 for an idea of how it works.
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 for an idea of how it works.
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.
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!
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.
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.
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.
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).
(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).
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.
> 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 :)
As a visual thinker, I cannot wrap my head around even simple programming concepts - they seem SO alien to me :)
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.
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.
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.
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.
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.
Then again, for me frontend means native applications, using Android UI Builder, WPF Blend, Qt Creator, iOS UI Builder, Netbeans Matisse.
The most popular CMS, WordPress, is experimenting with this now:
- https://make.wordpress.org/design/2017/02/09/initial-gutenbe...
- https://github.com/WordPress/gutenberg
- Demo: https://wordpress.github.io/gutenberg/
- https://make.wordpress.org/design/2017/02/09/initial-gutenbe...
- https://github.com/WordPress/gutenberg
- Demo: https://wordpress.github.io/gutenberg/
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.
- 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.
I think they're there, you just need to find them. For example, here's a pretty good one: http://h5mag.com/
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.
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.
Like http://maqetta.org and 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
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
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.
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.
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.
Meanwhile designers using WYSIWYG tend to build applications that work just fine in their environment and nowhere else.
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.
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.
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.
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.
[deleted]
Check out bubble.is. It does a fantastic job at both, though it is an integrated solution.
Because then you'd have two problems instead of one.
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.
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.
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
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.
In chip design there's graphical editors available, but most design work is done by writing text in languages such as Verilog and VHDL.
[deleted]
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't provide integration by allowing single documents to be sliced up into smaller components and kept in sync.
So, HN, what's your take on the lack of adoption of GUIs for building frontends?