Programming as Language

Since pretty much the beginning of time, programming has been considered something akin to alchemy or black magic to anyone who considers himself “not-so-nerdy”. But in reality, programming doesn’t differ all that much from learning a new language: you learn grammar, then you start to speak rudimentary phrases, and once you get a grasp of it, you feel more confident about speaking and eventually you start adding slang, jokes, etc.

Programming is pretty much the same, although there are some additional levels to these languages since you also have to know about different roles such as Backend, Frontend, and UI devs. You see, with programming, there are certain paradigms you have to learn before choosing one way of doing things over another (which may also work, but not as well). And then once you’ve tasted all the flavors of the various programming roles and their specific languages you are able to pick the role you liked the most.

A Brief History of Programming

In a programmer’s world, If you stay with what you know longer than you should, all that programming knowledge you worked hard to obtain will rapidly depreciate in value. This of course is due to the daily-changing, ever-evolving nature of the industry. It wasn’t always like that, however. Early programmers were just that: programmers. The Backend and Frontend concept was around but was nowhere as developed as it is today, since most of the programs ran on a single computer, and it was offline, or connected in a local network. This concept maintained a separation between the user and the data access layer, and was mostly done by the same person or group of people.

But then the world wide web appeared, bringing new concepts along with it. Code was executed on a computer, and then served to another which had to render it in different browsers (the programs that allowed our home computers request and execute these new so-called websites).

Thus the server and client concepts took a new approach, and we had a whole new area of concerns to worry about, including running extraneous code in our computers, and the security breach that implied. That’s when browsers started to develop some standards, which aimed to ensure security and portability between different platforms.

Now programming was divided in two main parts: the business logic, executed on the servers, and the User Interface rendering, executed on the clients. The Frontend-Backend concept made more sense than ever.

The Scene Today

A lot of water has flowed under the bridge since then. Now we have single page apps running mostly client-side, doing tiny AJAX requests that refresh only a portion of a website.

We’ve got tons of frameworks, compilers, transpilers, preprocessors, and postprocessors, JavaScript ate the world, but new editions of its specifications kept coming, year after year, and browsers couldn’t catch up. Only beta, or even alpha versions of ‘evergreen’ browsers were capable of interpreting the latest and greatest versions of this new specification.

Transpilers appeared, letting programmers use the latest improvements in production-ready environments, translating their bleeding-edge code to a more widely adopted version of JavaScript so the non-techie part of the crowd could use their webapp even if they’re not using the last fresh-baked version of their favorite browser.

Taking this into account, the Frontend language and its vast selection of frameworks aimed at specific types of web content had become a world significant enough to demand its own specific role.

And here it is where the fun part begins! Now we know we should split the Frontend part in two, with the Frontend developer working with JavaScript. All the logic will be executed in the “low level” of what is served to the client’s browser. And this wouldn’t be a waste of resources, since in JavaScriptland there’s too much to keep up with, and every day there’s a new way of doing things.

We have even started to use JavaScript-based frameworks on the server side, so the Backend-Frontend line is thinner, and it even makes more sense to separate the UI from the Frontend.

UI Developers

Enough chit-chat, let’s talk about UI developers. We’re a new breed of programmers who love to code.

But at the same time, we’re also very aware of User Experience (UX)- related concepts. Our weapons of choice are Hyper Text Markup Language (HTML) and Cascade Style Sheet (CSS), and we are keen on using both in their full potential. Keeping updated with the constantly changing tides of JavaScript and making good use of the new versions of HTML which makes the language more semantic, and also using all the last additions to CSS selectors, naming conventions, preprocessors, postprocessors, and task runners: to do all of that is nearly a titanic task.

In order to maintain a healthy development environment the Frontend-UI separation was a natural decantation.

This is how we do things at Making Sense, and specialized roles make an impact on the final products delivered. Quality improves with precision, and these clear-cut responsibilities provide an environment in which everyone is a key player, and they feel that way, so developers become highly motivated to be more productive.

What do you need to be (or become) a UI developer?

First of all, love what you do. In this case love to code. That’s always a must. But then again love isn’t responsible of doing all the heavy lifting: you are.

Start by learning the latest and greatest implementations of HTML (which is HTML5 by the time this article is being written) and CSS selectors level 3, keeping an eye on CSS selectors level 4.

Responsive layouts are required knowledge and text hierarchy (as in vertical rhythm) is optional but very welcomed. Any grid system will do the work, but you have to test several of them to know which is best suited for the work you’re intending to do.

CSS preprocessors as Sass, Less or even Stylus form a great knowledge base for keeping up with the agile methodologies being employed in the software development process.

They allow us, the UI devs, to use variables, functions, mixins, and most important of all: divide and conquer our, until now, indomitable code. Here is where the architectural principles appear and we start to divide our code into several files which have specific responsibilities. There’s also Inverted Triangle CSS, Object Oriented CSS, Block Element Modifier naming convention, and CSS modules.

After the preprocessing wave has passed, a new wave comes: the postprocessing one, which takes CSS and generates CSS. However, instead of being a monolithic tool it breaks down to smaller do-one-thing-but-do-it-well modules.

Then we need to run all of this, so it can be browser-friendly. I didn’t mention that Browsers can’t read modular Sass files, or understand mixins. They only speak plain CSS, HTML, and JS, so tasks runners are the new kids on the block. Gulp, Grunt, Broccoli, Mimosa, insert funny name here: there are many of them, and once again the developer is responsible for choosing the one that is best suited for the job. And to do that he must know all of them or at least he must have used more than one. Also you can ask your fellow Frontend developer, who also uses these task runners to transpile between JavaScript versions.

See? The UI is far different from the Frontend, and even further in the distance we can see the Backend or the Databases. We all share the same environment, and may share some of the tools we use on a daily basis, but the way we use them, and what we do with them couldn’t be further apart.

It is really important to be comfortable doing everyday tasks and to excel in whatever you do, you have to be specialized. Once again, do one thing and do it well.

We build up our own toolkit of infallible resources as we go down the path we’ve chosen, and we get better at what we do when we’re glad we’re doing it.

The UI path is stripped from the Frontend responsibilities and because of this the final product we deliver is more robust, all the tools are used in their maximum potential, the tasks are estimated separately, the hierarchy of the different roles is equal, and the developers are happier because they are doing the part they like the most about programming. Epic win!