Brief History of Frontend UI Tools and Newest Guy on the Block

My brief history with Front-end UI Tools

Front-end UI development is just writing code rendered in the browser, right? It can even be simplified a step further to say: 1. "Type code" and 2. "See the rendered output." That's it: Rinse, repeat as many times as needed, and you've got yourself the UI you're working on.

But humans are lazy especially software engineers. Pair that with business people happy to pay for an increase in productivity, and you get a tools arms race.

Let's look back at some moments in the history of web UI development.

My UI development memories started in early 2008 when, during a "Web Development 101" course at university, a good friend taught me a trick. At the time, we were having issues with HTML/CSS styling and layouts. (Holy grail layouts were tricky back then, am I right?)

"Colorful markup," he called it. It wasn't then and isn't now a well-established term, so don't think you've missed something.

It works like this: When creating and tweaking layouts, use all possible colors for backgrounds, borders and outlines pink, magenta, yellow, and red. I even use rebeccapurple sometimes. Feels like a good use for it.

Why? What were we doing back then, and why do some of us (slowly raises hand) still do it now?

Short answer: It's a helpful trick to speed up layout development. And, I'll admit, it's also a force of habit. It's hard to get rid of old habits and pick up new tricks (no, I'm not talking about the "using Vim plugins for VSCode" level).

As I was starting to work with Codux, which was new to me, I thought a lot about UI development what I experienced and the history of the tools I encountered.

Behind the simple "type code" step, there are tons of different tools, most of which are shared with other software development areas not specific to web UI development.

In general, IDEs have made colossal progress in the last decades. Still, in my own experience, I started writing HTML tags like <IFRAME WIDTH=100> in Notepad (no pluses). Today, I have an IDE with tons of plugins and even an AI assistant. And we can't say this hasn't impacted front-end development. Of course, it has.

Case in point: I had a friend who was adamant back in 2012 that he had professionally developed HTML and CSS and would not need JS. At least, as long as it wasn't forced on him. Not more than a year later, he was using Grunt for simple templating (I think components weren't popular yet around that time).

CSS preprocessors needed CLI. Then, IDEs helped save some time in our dev cycle by auto-saving files. That was the first time my front-end development involved paid tools (Sublime, I'm looking at you).

File change watchers became the norm. Any UI development piece required at least CLI usage, if not modifying configuration files and so on. Most of the packages.json of front-end projects that I worked on around that time were pure "devDependencies."

Other tools were being developed closer to the "see the rendered output" side of the scale. And if you thought I was going to talk about Figma, you're damn right I am but first, let's address the ancestor of all in-browser tools development tools.

We recently said goodbye to a sweet prince who changed everything Firebug. Firebug and Firebug Lite pioneered a format we've all been using for over a decade and even if you've never used them yourself, screenshots from 2006 would immediately tell you that you're looking at "dev tools."

Of course, Chrome is the most significant player on the market nowadays. Its extensions system is enormous, with built-in dev tools functionality and custom tabs in dev tools. Most big framework players have their dev tools extensions already. But let's give credit to those who were there at the start. Firefox has been on the front lines of tools for web UI development since the beginning and up to today (from recent releases, I'm a fan of their flexbox inspector).

There are also code sandboxes. JSBin of 2012 is a great example. People needed a place to start developing, trying out ideas, and showcasing their code but also be able to inspect it and play with it. As the complexity of front-end development grew, the complexity of sandboxes grew too, up to full-scale "Instant Dev Environments" like StackBlitz.

We can't avoid talking about other types of tools let's call them design-oriented. Like Figma, I don't want to get too much into it, as it isn't a UI development tool. Nevertheless, it's been used as one by some, and it keeps me awake at night.

OK, so we've had a bit of nostalgia; maybe we smiled a bit about something, Googled something new, or just felt appreciative of the evolution of front-end development. But let's go back to the reason why I took you on that journey. Because of "colorful markup," remember?

Despite the evolution of dev tools, nothing has changed enough for me to drop it. Yes, CSS is now much more powerful and, one can say, stable and predictable. IDEs are tremendous and allow autocompletion, popups with documentation, and AI-proposed code.

But all of that was not enough to break my habit of needing to make an effort to keep my mind on the task of layout development. Switching the context between writing code and previewing output was always intact. Whatever was done outside, code always needed to be brought back manually copied from tools and put somewhere. So if I were quick to type, with the help of the toolset behind me (Emmet, Live Templates, multiple cursors), that'd be quicker than any tool that would require me to integrate its "output" back to "my code."

Nothing, that is, until I started using Codux (also when building Codux, but that's a story for another day).

Because of what Codux does for me as a developer it allows me to draft structure quickly, get classes on it, and start bashing together layouts I see it with my own eyes on a preview (it is fully rendered production-grade stuff, with compiled preprocessed CSS, React components, etc.!). I can tweak nearly everything I can do via CSS on a style panel, and after all this working on one screen with no navigation and no complex flow I end up with proper HTML/CSS structure. When I think I'm done, I can commit, push, and start PR from Codux.

While learning React, I needed a simple sandbox environment and I found it without leaving Codux. I just created a new board and started coding, with a preview of rendered output and all the tools mentioned above.

After an initial period of cautiousness, I'm embracing the next step in this evolution and dropping some old habits.

Move aside dev tools and sandboxes. It's time for visual editors to start building the future.

Attribution
Firebug screenshot - https://commons.wikimedia.org/wiki/File:Firebug.png#filelinks
JSBin v1 - https://www.flickr.com/photos/remysharp/4284906136