The state of frontend development

It’s an exciting time to be a frontend developer.

The amount of frontend tools that have formed in recent years is difficult to fully embrace. There is a thriving ecosystem now where magical things happen daily and everything is evolving at a breakneck speed.

In this series, I intend to overview all of it.

Preprocess all the things!

So many toys to play with. Where to begin? Let’s start with preprocessing.

CSS preprocessing gained a lot of popularity from the Bootstrap framework, starting with Less and later with Sass support. Comparisons between the two seem to result in a tossup. They are far more alike than different.

I admit, when I first heard of Sass, the usefulness of it didn’t really click to me. I had read the most common arguments about large projects with unwieldly stylesheets. But I’ve worked on very large projects with huge stylesheets and it didn’t seem to be a massive problem. My manager at General Electric was especially strict on stylesheet organization, because we needed to be for those large projects.

If, for example, we ever needed to change the color theme, we would just have to search and replace those color codes. It’s that simple!

… and then search and replace the headings in special contexts.

… and search and replace the secondary colors for those areas.

… and don’t forget the many link variations.

Okay, so a lot of searching.

Wait. What did you say? In Sass, I can define a color by being an offset of an existing color? I can darken and lighten with functions? I can setup a color theme to use relative color values and I don’t need to do all of that searching and replacing?

I can set the background color to light or dark depending on whether the text color is light or dark?

Mind blown. I got it.

And that is just one example.

Write HTML faster than writing HTML

Simpler markup languages have popped up to replace the tedious task of writing out HTML. One benefit from this is that it couples well with a common design methodology that has gained momentum — “designing in the browser” — no Photoshop needed. I can see these simpler markup languages being useful for belting out a complex page layout in seconds, not to mention that these HTML preprocessors provide a lot of template-like functionlity.

The still-currently-popular way of belting out HTML is to use Emmet (previously known as ZenCoding) which lets you use short commands in the editor to auto-complete complex HTML. With Emmet, you can build an entire page layout using one line. Emmet is supported by most editing tools.

Template compatibility is where I have the most questions about HTML pre-processors. I wonder how well they work within an existing template system. They would have to allow directives from those template engines to be inserted and not conflict. That will be something I look for when I travel further down that road.

HAML and Jade appear to be the front-runners in this space, though I seem to like the appearance of Slim at a glance. The example on their front page looks, well… slim.

Javascript, shmavascript!

Languages that compile down to Javascript, known as Javascript transpiling, have grown since the days of the Java-based Google Web Toolkit, one of the first major JS transpiling solutions. There are, of course, many of them to choose from nowadays. Each one of these solutions tries to get around the limitations of Javascript or improve upon it.

CoffeeScript has been at the front of the transpiler pack for a while. It’s very easy to use and has a lot of support from various development tools.

Google created the Dart language which leans heavily on JS transpiling, but also works on its own with a plugin / extention.

Microsoft created TypeScript as a superset of Javascript, which may be taking the lead from CoffeeScript.

The growing popularity of these transpilers have heavily inspired the next iteration of the ECMAScript standard, which JavaScript is based on.

Packages, packages everywhere

Package management for frontend development. Who woulda thunk it? Apparently, someone did. I imagine this was started from the build up of Node JS on the server side. Package management has always made sense for server-side development.

Why is it important? With the complexity building in the frontend space, package management turns out to be a necessity now. There are just too many moving parts. Keeping things organized is paramount, especially in a team where the development environment needs to be built and maintained in many places.

NPM - The Node Package Manager, started out providing only back-end modules, but has grown to support front-end development. Node has a huge ecosystem with many available modules.

Browserify - Allows Node modules that were intended for only backend to be used within the browser. It uses the same module system as Node.

Bower - Bower was designed only for front-end packages. It has its own package repository, but can use github repositories as package sources. It can also handle any file types such as images, CSS, javascript, and HTML.

Bower has had some popularity. One mark it used to have over NPM is its handling of duplicate dependencies, but NPM+Browserify has improved quite a lot to the point where many think Bower isn’t necessary.

Some more to consider: Duo, Component, and Ender.

Run Lola run

If, while setting up a project, complex tasks are to be performed, there must to be some process to handle those tasks. Enter task runners, the army ants of Frontend development.

Grunt - Has been around a long while and has a lot of community support. Uses a JSON-like configuration format.

Gulp - A newer task runner which uses Javascript-based configuration and a “streaming” system which allows one task to flow into another task using pipes (similar to piping with unix commands). This streaming system allows for flow control within the build system. The result is slimmer and simpler configuration files.

Project scaffolding

Yeoman is a frontend scaffolding system, which uses the aforementioned tools to define a well-constructed starting point or structure for a project. It allows you to mix and match tools.

Slush is an alternative to Yeoman which uses Gulp itself for the scaffolding portion as well as general task running.

Grid frameworks out the whazoo

Throw a dart in any direction and you’ll invariable land on a solution for making grid layouts.

Mind you, Grid systems aren’t a new thing in frontend development, but there continues to be improvements with Grid systems in recent years. They grew into the frontend UI frameworks that you see today, such as Bootstrap and Foundation, which provide a full toolset to quickly built out mobile-first, grid-based interfaces with all of the fixins.

One particular responsive grid system that I’m enjoying lately is Susy. It seems so simple and flexible. I’m really having a difficult time imagining something improving upon it, although I’m sure something will.

Frontend MVC

Development in this area has excited me to the point where I’ve gone out of my way to create opportunities within projects to work with them.

Popular contenders: AngularJS, Ember, Backbone and React.

The usefulness of these frameworks/libraries is that you can build single-page client applications in the browser while using the backend for authentication, authorization, and data storage, usually provided in the form of a REST API.

Finally, sanity creeps in

Responsive, Mobile-first design is now the norm, which is a breath of fresh air. For years, I had to do a little dancing to convince some clients to consider responsive design, and sometimes they didn’t care very much. Nowadays, mobile devices can make up to half of visitors for some websites. It is now a requirement with every project, and I’m very relieved.

Browser support used to be the pain in every frontend developer’s side, taking up to 1/3rd of the job just to get things working in Internet Explorer 6. Microsoft finally woke up and started taking their browser development seriously to the point where they themselves are pushing companies to stop supporting IE6, and their latest browser is on par or even better in some ways than the competition.

The current bar for browser support, for most companies, is Evergreen browsers, which means the latest browers that automatically update themselves without user intervention.

That is amazing.

I remember talking to one of the IT managers at General Electric explaining why we were still stuck on using IE6 when IE7 had been out and IE8 was in beta. He explained that it was safer to support technology that they were familiar with. It was not for security reasons, because that would make no sense; a newer, updated browser would always be more secure. It was because they knew the web applications they relied on internally would work on IE6. They didn’t want to spend money to rewrite that code.

So many more things

I haven’t even gotten to new editors, like Atomic and Brackets, newer technologies in the browser such as web components or ECMAScript 6 and 7, or CSS naming methodologies (BEM, SMACSS, OOCSS, ATOMIC, etc).

The Frontend Wave^TM is too big to even scratch the surface here. I guess The State of Frontend Development will turn nto a multi-part series, perhaps an ongoing one.