The (probable) end of the front-end profession as you know it

A regular and common web development process can be divided into three major categories: design, front-end and back-end. In my opinion, the front-end has the most manual and repetitive processes.

Think about it, the core of the front-end job is summed up in two parts:

• Layout implementation: create the first code of project where we replicate the layout designed in some graphic app, to static HTML, CSS and JS code;
• API integration: after (or at the same time) the static code was made, the interface is integrated using an API, which usually carries a lot of logic, since the same API is used to feed other platforms such as mobile, robots, web version etc;

The other responsibilities that orbit around the front-end like accessibility, SEO, performance, compatibility between browsers, semantic code, among other things that you may judge to be the responsibility of a front-end are a mere preciosity. They may or may not exist in a project. But a project does not survive without the front-end code of the layout and without the content integrated into interface.

Today already we delegate a bunch of repetitive manual tasks to tools to save some time, automating the front-end workflow. Just to cite a few tools soups:

• CSS Preprocessors: Sass, Less, Stylus
• Scaffolding: Yeoman, Slush
• Dependencies / Module Bundles: Bower, NPM, Yarn, Webpack, Duo, RequireJS, Browserify, JSPM, Rollup
• SPA / Libraries / Frameworks: React, Angular, Vue.js, Backbone, EmberJS, todomvc, Polymer, Lodash, Aurelia, MeteorJS
• CSS Frameworks / Libraries: SemanticUI, Bootstrap, Foundation, UiKit, YUI, Susy
• JS Test: Mocha, Jasmine, QUnit, Ava, Tape, Jest
• JS Templates: Underscore, Mustache, Handlebars, DoT, Dust, EJS

But even with all these tools, the core of the responsibility of a front-end remains to implement the original layout and integrate the interface with the back-end. You still continue to replicate the layout that someone spent days designing and integrating content of an API that someone else created. Your day comes down to switching between the windows of Sublime / Sketch / Browser / Sublime / API / Browser / Sublime.

“Automation is not about being lazy. It’s about being efficient. — Addy Osmani

This process becomes tedious and the requirements to try to make efficient front-end work only increases. Every mechanical, repetitive, and manual task tends to be automated and in my opinion, very soon, we will not need someone running end-to-end front-end work.

Okay, breathe. That is my opinion. Since the front-end is the most operational part of the whole process, sooner or later all (or a lot of that) work done on the front-end will be automated, even these two major tasks. However, they may already have their days counted.

Working with real data direct from Design

You may not be a designer, but there is a premise in the world of designers that says you should always work with real content. That means deliver layouts with text using Lorem Ipsum Dolor is something of a junior designer.

“If your site or application requires data input, enter real and relevant words and type the text, do not just paste it in from another source. — Jason Fried

The idea is to create a layout as accurately as possible using the terms, words, names, dates, etc in order to get closer to the user experience.

Currently, most of the visual programs used to create web layouts have some feature or plugin that allows integrate with some data source that contains real content.

For example, Sketch, which is the most beloved visual creation program of the moment, has plugins that allow direct integration between API and layout. See for example the video below demonstrating the use of the Craft plugin:

Watch this demonstration that uses the Stackoverflow API:

The point here is: we just need to create the layout once, using the tool of choice and that’s it. We do not need a person to re-implement this layout with HTML, CSS, and JS manually. This leads to a second discussion: even with the design ready and using real data from an API, we still need it to be accessible by browsers.

How that idea of “Design in the Browser fits here? This proposed process is actually created to avoid the work of producing the same layout twice, but it is much better to make a design using a visual program than to write direct in the code. IMHO.

Beautiful code is not important

The front-end developers always hated code generated by tools like Dreamweaver. They have a reason for it: the code is usually unmaintainable. It was a time where the internet connection was precarious and everything we could do to improve site performance, we did. The code generated by Wysiwyg apps had several problems: it was difficult to humanly read, with poor semantics, it contained useless code and it was often not compatible with all browsers or screen resolutions. All of these made us value clean, semantic, lean and accessible code.

A clean code in the web became a synonymous of good ranking on Google searches, a good cross-browser compatibility, a load performance, better productivity among team members, better maintenance, and so on.

Most of these problems are now solved:

• Browsers have a better compliance with web standards, solving most of the cross-compatibility issues;
• The performance is improved on several fronts: the build process of assets, technologies like HTTP/2 and even the evolution of the internet connection;
• The maintenance and readability of HTML / CSS code is no longer a major concern, since HTML is easily written using few semantic tags and CSS has preprocessors, which help a lot when it comes to setting standards, as well as good practices;
• JS is well advised by frameworks, libraries and a series of good practices that take responsibility for the heavy part of the work, leaving little room for errors from devs;
• And the most important thing for me is that the semantics is no longer in HTML. Since of technologies like JSON-LD, the semantics is no longer tied to the HTML code and this is great;

I know that even giving all the responsibility to frameworks, libraries, and tools, a developer has a good chance of writing bad code. We always make mistakes, some more, some less, there is no silver bullet.

Try to understand one thing: beautiful code is not so important anymore in a world where a tool can generate a good piece of code.The tools that help us today to build assets can be used by tools to automatically create HTML/CSS/JS code from layouts produced in programs such as Sketch. See this plugin example that is no longer updated since 2015 and already tried to automate the code export in Sketch. The guy was trying to make HTML code from the layout drawn in Sketch version 3. Today the Sketch is currently in the version 42, and in version 43, Sketch is opening the code of its files in JSON format. Which brings us to the next subject.

Design Automation

*“We have a new file format which is more compact, and enables more powerful integrations for third-party developers. — *Sketch Team

Sketch will become a development platform. Opening the code of your files, anyone will be able to read these files and from there create anything. How long for someone to create a plugin that reads the Sketch file in JSON format and automatically generates HTML, CSS, and JS from a Sketch layout?

“Computers evolve. If the principles changed there would be no basis for evolution. — Caio Vaccaro

Okay, but wait: even before this new Sketch file format, there were already some tools you might not have known as Teleport, which turns any website into an Sketch artboard. Also, UIPad converts Sketch layout to HTML,CSS, and React! Take a look:

This trend was already drawn a long time ago. It’s the smart way to go. You can do more important things than sitting in front of the computer switching between browser, layout, browser, layout.

We have a design that integrates with the API, pulling real content on interface. We have a design tool that exports layout to HTML, CSS, andJS code ready to be used, but we’re still using code as it used. There is one more step that can be improved.

WebAssembly (Wasm)

Another important point, which has nothing defined yet, but which can start to make sense. All that story of WebAssembly, which is a new binary (bytecode, actually) format created by Google, Microsoft, Mozilla, and several others.

The code format of WebAssembly can be decoded much faster than JavaScript is parsed. This really brings to the Web the experience of native apps, specially on the mobile.

The cool thing is that other languages ​​can be compiled for WebAssembly. Today the project is a little more focused on C / C++, but other languages ​​will certainly be covered. The main goal of WebAssembly is performance.

One concern that comes up in the air is that it smells of monopoly. Remember Flash? Whether he wanted it or not it was an alternative to creating something native on the Web. But the grace is that:

• WebAssembly does not replace JavaScript. Everything has backward compatibility, everything will run in the same universe as JS and security will have the same restrictions as JS;
• It is not just a company or group that is behind Wasm, but several like Firefox, Chromium, Edge and Webkit;
• To run WebAssembly you won’t need to run third-party plugins, since the browser engines will be fully compatible;

Do you understand why searching for a clean code (as we know it today) does not make that much sense anymore? Your website/product bytecode will be generated by a Sketch-like tool.

Conclusion

This article is opinionated and full of guesses from my own. All of these can become true, or not. IMHO, sooner or later the front-end profession as we know will no longer exist.

I don’t know if this will really happen, but until yesterday automated cars and trucks were just movie stuff.

Further reading

Actual data in design

• 3 Easy Steps for Working with Realistic Data in Sketch Using JSON
• Designing with Data
• Prototype with real data in Framer, from JSON to multi-device and internet of things
• Adobe XD: Designing with Real Data

About not using fake text in layouts

• Lorem Ipsum is Killing Your Designs
• Why designers should never use fake text
• Stop using Lorem Ipsum!
• “Getting Real design tip: Just say no to Lorem Ipsum

WebAssembly

• FAQ do site WebAssembly
• WebAssembly — a web compilada
• Google, Microsoft, Mozilla And Others Team Up To Launch WebAssembly, A New Binary Format For The Web
• WebAssembly e o futuro da Web
• From asm.js to webassembly
• The Web is getting its bytecode: WebAssembly

About the Front-end Tools Scenario

• front-end.directory
• Using front-end build tools
• A Collection Of Best Front End Frameworks
• GitHub: Front-end JavaScript frameworks
• Front-End Tooling Trends for 2017
• Updated List: The 67 Very Best Front End Web Developer Tools
• The most popular JavaScript front-end tools
• Top 10 Templating Engines for JavaScript To Improve and Simplify Your Workflow 2017
• Automating Front-end Workflow
• Javascript State of the Union 2015, parte 3
• Slides — Javascript State of the Union 2015
• The State of Front-End Tooling 2016 — Results
• Front-end Roles and Responsibilities