Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 140 posts

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

#91

Post by benharrison »

jplatte wrote: post #79

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…

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.

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

#92

Post by pjmlp »

Animats wrote: post #51
pjmlp wrote: post #45

Earlier quoted context omitted.

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

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.

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

#93

Post by edwinjm »

intrasight wrote: post #25

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.

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

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

#94

Post by e28eta »

jasoncrawford wrote: post #26

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

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.

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

#95

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

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

#96

Post by mcintyre1994 »

bendecoste wrote: post #90
jasoncrawford wrote: post #26

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

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.

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

#98

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

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

#99

Post by tyoverby »

Animats wrote: post #51
pjmlp wrote: post #45

Earlier quoted context omitted.

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

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

And .org files

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

#100

Post by briantmaurer »

jasondc wrote: post #30
news_to_me wrote: post #28

Earlier quoted context omitted.

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

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.

Post reply on HN