Developers and GUI Tools - Love 'em or Hate 'em?

When it comes to development tools, where is the industry headed? in this Slack chat, members of our Developer Relations team weigh in with their thoughts.

There's a lot of buzz in the industry around so called "low code" or "no code" or "high productivity" solutions. As a rule, these tools rely upon a graphical user interface (GUI) to help build tools without code, sometimes even using drag-and-drop interfaces to build applications. These sorts of tools have a long and somewhat sordid history among developers, which has led them to be somewhat naturally distrustful of them.

Several members of the Progress Developer Relations team decided to have a Slack chat discussion to take a look at the history of these tools and where we think they are going. While (full disclosure) Progress has a new tool in development that falls within this category, we tried to take an honest look from a developer perspective.

TJ VanToll: Hey everyone 👋

This topic is funny to me because when I started my career as a front-end developer, GUI tools like Microsoft FrontPage and Adobe Dreamweaver were serious software used to build serious stuff. But nowadays these tools have fallen out of favor (to say the least), and most front-end tools are now command-line- or terminal-based libraries. With that in mind, our rough agenda for today's discussion is:

• What GUI tools have we enjoyed using over the years?
• What GUI tools have we not enjoyed using?
• Where is the industry heading—more command-line tools, or the resurgence or GUI tools?

Let's start with the first question.

Rob Lauer: Not to date myself, but the first GUI tool I can remember using was the built-in HTML editor that shipped as part of Netscape!

TJ VanToll: OMG Netscape had a built-in HTML editor? Do images exist?

Rob Lauer: Netscape Composer I believe it was called? It eventually became part of a monolithic Netscape distribution. Hey, it could edit tables.

Jen Looper: Rob, is this what you used?

Rob Lauer: Yes!  ❤️

TJ VanToll: Web Page authoring is easy! LOL at the “ABOUT COMPUTERS” link.

Brian Rinaldi: I’ll admit that I started learning development using all the GUI tools from FrontPage then to Dreamweaver and Flash and Director and finally onto ColdFusion Studio. This tells you that: a) yes I am old; and b) I don’t have a problem with GUI tools altogether.

In fact, I would say that I have often struggled with the transition to command-line based development

Jen Looper: I am wondering a bit about the first sentence in TJ's opening statement. Was Dreamweaver considered a serious tool, or was it a way for Adobe to onboard more people into their stack via the frontend?

I remember using Dreamweaver and Flash but the minute you opened up the code to see what was going on, or where bugs were, it was a giant mass of spaghetti. I think this is a chronic issue with these tools. More Dreamweaver than Flash, I suppose.

Rob Lauer: Jen brings up a great point - and the Achilles heal of these GUI tools.

Brian Rinaldi: Jen, agreed. Though this is where I think a distinction has to be made. Some GUI tools are drag and drop while others are more like an IDE with additional tooling in the UI rather than a command line interface. For example, you could use Dreamweaver as a full-on drag-and-drop tool or you could just use it in code mode.

Jen Looper: Flash was something else as well, it was a full studio to author all your animations, tweening, and everything. You kind of had to dive into ActionScript, though, at the end of the day.

Rob Lauer: In defense of these tools - this is how I learned HTML. I dragged-and-dropped a table onto my canvas, then switched to the code view to see what was actually generated. Composer (and...to also date myself...Adobe Pagemill) created very clean HTML that was easy to read and learn from.

Brian Rinaldi: I remember using Flash Builder (for Flex development…and, yes, we’ve already covered that I am old) and it had a drag-and-drop interface which none of us generally used.

Jen Looper: Getting misty eyed over the idea of dragging and dropping tables…

Rob Lauer: > right click > add column. Done!

Jen Looper: Last night I was in this world just a little, helping my daughter set up a web site for a political campaign in our town. We had to choose between Wix, SquareSpace, and Wordpress. Not a hint of code in sight.

TJ VanToll: And did they work well?

Jen Looper: It came down to $$$ - as in, we have none. So Wix and SquareSpace went off the table. Also we both have more experience with Wordpress and, honestly, it gets the job done.

Rob Lauer: So somewhere these tools went wrong. I'm thinking of the .NET 1.1 days with Visual Studio.NET and its drag-and-drop capabilities that would apply absolute positioning to all elements. Awesome for the web…

TJ VanToll: FrontPage is probably the most notorious for generating nonsense.

Rob Lauer: As app complexity ⬆️, code quality ⬇️?

Jen Looper: Maybe they went wrong with the proliferation of browsers and screen sizes. That’s super hard for these tools to handle.

Rob Lauer: True - yes kids, there was a day when you had to sniff for IE vs Firefox vs Safari vs Chrome

Jen Looper: I remember it well…

TJ VanToll: The only thing that surprises me about the above screenshot is that the tag names are not in all caps.

Brian Rinaldi: Adobe tried to solve the drag-and-drop responsive design thing with Edge Reflow. I think they abandoned it.

Rob Lauer: Adobe seems to have the most storied history, especially with the Macromedia acquisition.

Brian Rinaldi: That’s the thing about full drag-and-drop tools is that we’ve seen so many of them fail over the years. It’s like they eventually reach the upper limit of their capability and once people surpass that in terms of site/app complexity, the tool seems antiquated.

Jen Looper: I think the impetus behind these tools is the need to quickly see what you are building. That has been solved these days with nice, fast hot module reloading (HMR). I just saw a tweet about Gatsby + Sanity.io which allows you to have realtime collaboration and instant previews. The world is getting way fancier.

Brian Rinaldi: Yes, though the toolchain is getting complex.

Jen Looper: For sure!!

Using webpack for my "hello world" app pic.twitter.com/MmnXTl0ebw

— Tomasz Łakomy (@tlakomy) February 20, 2018

TJ VanToll: The only modern example I can think of a drag-and-drop tool that’s really good and generally liked is storyboards in Xcode. I think it shows you can do drag-and-drop, but that it’s really hard and you have to throw a lot of engineering muscle at the problem to get it right.

Rob Lauer: So do the best tools get you 80% of the way? Or are the best tools those that are very focused on specific tasks?

Jen Looper: TJ, you are obliged to use these tools to build an Apple Watch app, for the Storyboard composition, last time I was working with this stack. That works fine, but you are really locked into Xcode, then, if you want to release that app.

TJ VanToll: Ah good point. Lock in is another common downfall of these tools.

Jen Looper: Maybe that plays into Rob’s question. I think lock-in is a problem for a diverse developer base.

Rob Lauer: The "enterprise" doesn't seem to have a problem with lock-in though. Maybe we need to differentiate between types of developers. cough "citizen developer" cough

Jen Looper: True, true!

Brian Rinaldi: I’d answer Rob’s question by saying that, in my experience, the best tools recognize the limits of drag-and-drop and let you go beyond that when you need to or are ready.

TJ VanToll: Agreed. Flash meets that criterion, as does Xcode.

Rob Lauer: I think you are right as well.

Jen Looper: Ideally, you can easily access your code and it’s readable. Honestly Wordpress does that.

Rob Lauer: So the best tool will get me 80% of the way, then let me take over. But is it a one-way street? Many times generated code, that is subsequently edited, cannot be re-edited in the original tool

Jen Looper: 😱

Brian Rinaldi: I agree, though I think that round-tripping usually a problem with the full drag and drop interface tools.

To bring up another Adobe example, Flash Catalyst was going to be a way to design Flex/Flash application interfaces using drag and drop. Everyone wanted it until they actually got it. The lack of round-tripping killed it out the gate (they eventually added it, but I think in the end it was too limited or too late).

Rob Lauer: Let me propose one successful implementation of this - albeit a somewhat limited one, and very self-serving considering this group 🙂. That would be NativeScript Playground. It provides drag-and-drop UI components, with code generation, but the "canvas" is your editor and your UI is reflected on the device. Maybe a bit outside of the scope of what we are talking about though.

Brian Rinaldi: NativeScript? Tell me more! 😉

Jen Looper: I really like that the code is right in front of you in NativeScript Playground, it’s the focus, not backgrounded.

Rob Lauer: So what GUI tools, in the past/present, were/are at least commercially successful? Dreamweaver? Xcode? Android Studio?

Brian Rinaldi: Dreamweaver is still around.

Rob Lauer:

Initial release: December 1997; 21 years ago

Jen Looper: I see Dreamweaver is still around and I kind of want to try it again.

TJ VanToll: Interestingly, a lot of these tools don’t make money directly, but try to help suck you into their ecosystem, as Jen mentioned earlier. Xcode and Android Studio for example are free at least.

Rob Lauer: Excellent point.

TJ VanToll: NativeScript Playground is free too 😉

Brian Rinaldi: I think that gets at your final question, TJ:

Where is the industry heading—more command-line tools, or the resurgence or GUI tools?

Rob Lauer: There is a lot of pendulum swinging in tech. CLI was shunned for years, now in the last 7-8 years it's seen a resurgence. Now maybe it's time for GUI tools to take over again..?

TJ VanToll: My thought—for the front-end world specifically, things have gotten increasingly complex over the last decade, which I think will make devs more willing to use a tool that hides some of this complexity.

npm install... pic.twitter.com/c0YCG9Rk9f

— Glen Arrowsmith (@garrows) November 21, 2018

Brian Rinaldi: It seems like there is a divergence. Most developers I encounter (granted, I’m in the JavaScript and front-end dev space mainly) are moving towards a command-line-based stack of tools. However, the industry seems to be moving towards supplying more GUI tools under the “high productivity” or “low code/no code” tooling umbrellas.

The latter seem to be specifically targeting large enterprises.

Jen Looper: I am thinking about this post by Chris Coyier that I recently read about this new industry split between those who are ‘UX Engineers’ and those who are ‘JS Engineers’. Maybe the former are more likely to use GUI tools, and the latter command-line tools.

The UX Engineers I know, however, seem to use Sketch for the most part.

Rob Lauer: Ionic has had a well-received (I assume) GUI tool for years, first called Codiqa, then Creator, now Ionic Studio. I definitely see some advantages with it if you are a hybrid developer. However, IIRC you are limited in how you lay out your elements (stack only), which to me is a deal-killer. There is also no backend integration built-in.

Jen Looper: Do tools like InVision allow you to see code?

Rob Lauer: I don't think so, but this brings up the realm of design tools -> code generation. Like going from Sketch to NativeScript or React Native Talk about ugly code generated...

Brian Rinaldi: Those solutions are definitely being worked on.

Jen Looper: It’s been done in the community, I haven’t personally tried it.

Rob Lauer: The problem with these tools is generally you are getting absolute positioning of your elements. This leads to a lot of extra code and unnecessary complexity.

Jen Looper: Looking at Sketch, it has a code export - I think for things like SVG generation, this could be super useful.

Rob Lauer: BuilderX is another example - super awesome design interface, but the exported code is jammed with absolute elements. Maybe it's me, but I spend 50% of my time doing pixel-tweaking in my layouts.

Brian Rinaldi: Jen and I both worked at Sun Life and I remember there being a wide range of applications within the company. Some were incredibly complex. Others solved smaller business problems, down to the simple “app” built in Access or (yikes!) Domino that often only had a couple of users. So I can kind of understand where these tools, even from a no-code/citizen developer standpoint, have a place within a large enterprise. It’s not like you need a single tool to solve all your problems.

Jen Looper: I think these tools can shine when they help with small pieces of the UI, like an SVG or a canvas element. When you expect that, in one drag, a few drops, and a click, that you have a fully responsive web site, that’s where the trouble starts

Rob Lauer: So the "best" GUI tool will be one that makes me, as a developer more productive, leveraging my existing enterprise data stores/services, doesn't get in my way when i want to edit code, and lets me back into a design canvas when i want to add additional functionality. Something like that 🙂

TJ VanToll: So there you have it. GUI tools are the best and also the worst! Any closing words?

Jen Looper: Moonshot, Rob! I think we should just go back to that Netscape composer

TJ VanToll: 🙂 Simpler times.

Jen Looper: I think these tools did help onboard a lot of new people into the industry back in the day, and helped pushed the concept of 'good UI and UX' forward.

Brian Rinaldi: I’d say, development, even just web development, today is way bigger and more complex than when I started, which means there is room for a whole range of solutions because there are just so many apps needed and being created. Devs should use whatever makes them most productive in what they have to build.

Rob Lauer: Let me just end this with saying here at Progress we are working on a new tool that I think legitimately scratches all of these itches!

TJ VanToll: Spoiler alert!

TJ VanToll: Well there you have it. Feel free to continue the conversation in the comments with the tools you’ve enjoyed (and not enjoyed) using over the years. Oh, and if you’re interested in testing the super-secret tools we’ve been working on here at Progress, here are the details:

Soon we'll be launching a new tool to help you make web and mobile apps with Angular. You can add custom chat bots and connect to enterprise infrastructure, authentication, and other data sources without writing any code. Oh, and you'll always have full control and the ability to modify the Angular source code. Interested? Come build amazing apps with us. Join the invite list!

Rob Lauer: Adobe, if you're listening, bring back Pagemill!