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
Top comments (6)
Chalk up another "this whole part will be automated!" They said that about database development for the last... 30 or so years? Still hasn't happened. People will spend less time doing better work, but in the end, if you think front end work boils down to simply matching DB functions to UI designs, you're... probably not a front end dev. Or haven't been one for very long.
Every attempt to replace front-end development by back-end code until now I have ever witnessed was a complete and utter failure. Yes, transpilers like GWT, emscripten and Web Assembly allow back-end code to run in the browser, but that doesn't invalidate the necessity for someone who can do the maintenance on these - and this individual will invariably have to be sufficient in front-end development.
And even if we replaced all the logic by back-end code, front-end developers have way more experience about the surrounding issues like accessibility and cross-browser-(in)compatibility.
But yes, front-end will change, but it has changed again and again for some time. So I would say that this change is a constant and it's actually the same old front-end development that we're used to never become used to.
I think another scenario will happen. I believe the web design and front-end will merge into one profession.
Take for instance Desech Studio, which is a nocode app for html/css. Right now it's a bit hard to do design in it because you have to position elements with css grid. But imagine being able to drag and drop elements and grids be auto-created. This means you can do the design in Desech Studio, and then you do adjustments to make it more efficient and then do the responsiveness.
You can then integrate it with react, angular, vue and work on the programming while staying sync with Desech Studio for the html/css visual side of the project.
So, either the designers will learn a bit of html/css and javascript programming, or the front-end developers learn a bit of design and ui/ux.
Designing UIs for the web should be as easy as it was with RAD tools of the 90s like PowerBuilder or Visual Basic, with minimal code in the front end. Instead of generating code for the Windows API, they would generate framework code. Or just build the UI from metadata, dinamically (as Salesforce does).
But what happens is that Front End development/engineering is more than just UI as a visual element. Front End is also UI as a logic element. Sure, the templating tasks could be successfully automated, but the logic that glues everything together not so much - for the time being. What make us "human", in a sense, is our ability to use logic as an interface for the world around us. We will need humans to logically bind all those UI elements together in a way that is result-efficient. Creativity also comes in the form of logic manipulation. While two sites may have the same View, the logic behind what achieves the presentation may be quiet different! There is also the security factor to consider. Front End Development has gotten really beefy in the past years. The faster our technology evolves, the more complex human-machine interactions become.
In my humble opinion, I think that the trend is to merge the real-world with the digital one. So what may cease to exist is the screen - which takes away the concept of UI as we know it.
I think we're slowing approaching a day where "write once, run anywhere" is a reality. There are transpilers for all sorts of things, and WASM transpilers are already in the works. Just look at Blazor (github.com/SteveSanderson/Blazor) for a peek at something that could very well be in our future.