O processo de desenvolvimento web pode se dividir em três categorias: design, front-end e back-end. Na minha opinião, a categoria que tem mais processos manuais e repetitivos é sem duvida o front-end.
Pare pra pensar: o core do trabalho do front-end se resume em duas partes:
- implementação do layout: produção da primeira camada de código, onde replicamos o layout criado em algum programa gráfico, para código estático em HTML, CSS e JS.
- integração com API: depois (ou junto, tanto faz) de feito o código estático, a interface é integrada com a API, que geralmente carrega boa parte da lógica, já que essa mesma API é usada para alimentar outras plataformas como mobile, robôs etc.
As outras “responsabilidades” que orbitam em volta do front-end como acessibilidade, SEO, performance, compatibilidade entre browsers, código semântico, entre outras coisas que você pode julgar serem de responsabilidade de um front-end são um mero apetrecho. Elas podem existir ou não em um projeto. Mas um projeto não sobrevive sem o código front-end do layout e sem o conteúdo integrado à interface.
Um observação: acessibilidade é algo que as máquinas podem fazer muito melhor que um ser humano. Embora eu tenha colocado como algo que possa existir ou não em um projeto, é importante demais que você faça um esforço para que todos os seus projetos sejam acessíveis. Eu sei que isso não é a realidade até hoje no mercado e provavelmente nunca será até que esse processo seja automatizado.
Existem uma série de tarefas manuais que nós delegamos para ferramentas criadas afim de economizar parte do nosso tempo evitando a execução de tarefas repetitivas, automatizando o workflow do front-end. Só para citar algumas:
- Pre-processadores CSS: Sass, Less, Stylus
- Task runners: Gulp, Grunt , Make, NPM Scripts
- Scaffolding: Yeoman, Slush
- Dependências/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
Mas mesmo com todas essas ferramentas, o core da responsabilidade de um front-end ainda continua sendo implementar layout original e integrar a interface com o back-end. Você ainda continua replicando o layout que alguém passou dias desenhando e integra o conteúdo que está numa API, que outra pessoa criou. Seu dia se resume em alternar entre as janelas do Sublime / Sketch / Browser / Sublime / API / Browser / Sublime.
“Automation isn’t about being lazy. It’s about being efficient.” — Addy Osmani
Esse processo se torna tedioso e a lista de requisitos para tentar tornar o trabalho de front-end eficiente só aumenta. Toda tarefa mecânica, repetitiva e manual tende a ser automatizada e na minha opinião, em pouco tempo, não vamos precisar de alguém executando o trabalho de front-end de ponta a ponta.
Okay, respira. Isso é a minha opinião. Dado que o front-end é a parte mais operacional de todo o processo, mais cedo ou mais tarde todo o trabalho executado no front-end vai ser automatizado. A parte mais difícil são essas duas tarefas que nós fazemos desde os primórdios. Contudo, elas já podem estar com seus dias contados.
Você pode não ser designer, mas há uma premissa no mundo dos designers que diz que você deve trabalhar sempre com conteúdo real. Isso quer dizer que entregar um layout com texto em Lorem Ipsum Dolor é coisa de designer júnior.
“If your site or application requires data input, enter real and relevant words and type the text, don’t just paste it in from another source.” — Jason Fried
A ideia é que você crie um layout da forma mais fiel possível usando os termos, palavras, nomes, datas etc, a fim de chegar mais perto da experiência do usuário.
Atualmente a maioria dos programas visuais utilizados para criar layouts para web tem alguma feature ou plugin que permite a integração com alguma fonte de dados que contenha o conteúdo real.
Por exemplo o Sketch, que é o programa de criação visual mais querido do momento, conta com plugins que permitem a integração direta entre API e layout. Veja por exemplo o vídeo abaixo demonstrando a utilização do plugin Craft (também disponível para Photoshop):
Ou essa demonstração que usa a API do Stackoverflow:
Em pouco tempo, não vamos precisar de alguém executando o trabalho de front-end de ponta a ponta.
O ponto aqui é: nós só precisamos criar o layout uma vez, usando o programa desejado (Sketch/Photoshop/Figma/Adobe XD etc) e pronto. Não precisamos de uma pessoa para refazer esse layout com HTML/CSS/JS de forma alguma. Isso nos leva para uma segunda discussão: mesmo com o design pronto, usando dados reais de uma API, nós ainda precisamos que ele seja acessível pelos browsers. Como resolvemos isso?
Obs.: E aquele movimento do “Design in the Browser”? Esse é um movimento criado exatamente para evitar o trabalho de produzir duas vezes o mesmo layout. Mas é MUITO melhor fazer um design usando um programa visual do que escrever direto no código. IMHO.
https://tableless.com.br/carreira-de-front-end-vai-morrer/