Live data from Hacker News

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

news.ycombinator.com

61–70 of 140 posts

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

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

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

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

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

#63

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

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

#65

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…

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

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

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

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

#67
post #53
post #27

Earlier quoted context omitted.

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

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

I am looking forward to the day when I don't have to support ie9

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

#68
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).

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

#69
post #53
post #27

Earlier quoted context omitted.

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

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

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!

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

#70
post #32

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 generat…

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 st…

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 `` and ``. I don't see how semantic meaning is an imposition, and anyway, the document authors and the document readers are not the same people.

Post reply on HN