Esse é um texto longo, onde mostro minha opinião, que certamente não é popular. Esse artigo foi escrito originalmente em 2017, ainda longe do bump dos assuntos de OpenAI e todo esse hype que estamos vivendo em 2023. De qualquer forma, é importante atualizarmos nossas opiniões para que elas fiquem coerentes a atualidade e com o que aprendemos e amadurecemos de lá para cá.

O artigo original ainda pode ser visto aqui e aqui. E a comoção da comunidade front-end pode ser visto aqui.

Embora esse texto tenha dado muita polêmica, acho que na verdade foi mais um choque para aqueles que estavam vivendo na bolha, hermeticamente fechada, do front-end, que realmente não estavam observando as tendências, exceto as de front-end. Uma pena. Muitas discussões maduras e importantes poderiam ter rolado. Mas, só mostrou o quanto o mercado não estava maduro.

Antes de você ler o texto, aqui vem um resumo em forma de disclaimer:

  • Não estou falando que front-ends precisam pedir demissão porque robôs irão tomar o lugar deles. Pelo contrário. Estou dizendo que front-ends precisam resolver problemas diferentes... Problemas que a AI não consegue resolver sozinha e por isso não dá para substituí-los. Substituir um senior de verdade, vai demorar muitos e muitos anos;
  • Estou dizendo que o mercado de front-ends pode estar passando por uma mudança progressiva, pouco perceptível para maioria, que invariavelmente vai impactar a forma que fronts e designers trabalham;
  • Eu estou dizendo que existem muitas camadas de complexidade que ainda serão descobertas e que por isso, uma substituição completa não é factível. Mas, mas, mas existem tarefas, projetos e contextos simples o suficiente para serem feitos do começo ao fim, sem a necessidade da figura de um front-end ou de outras disciplinas;

Aqui vai essa expansão e atualização do texto.

Sobre liderança de times

Muito já se falou sobre topologias de times de tecnologia. Acho que não é um assunto que deveria ser novidade para nenhum profissional que esteja lendo esse texto. Por isso, não vou perder tempo nesse ponto e começar meu rap falando sobre a quebra de liderança.

De qualquer forma, quando falamos sobre a tríade de liderança dos times de tecnologia (aqui, coloco tecnologia como um todo, incluindo design, PMs, dados, devs, etc), certamente Design, Tech Lead e PM fazem parte desse grupo.

Quando falamos sobre desenvolvedores, geralmente há um representante cujo nome muda de empresa para empresa, que vou padronizar aqui como Tech Lead, que é seria o responsável por decidir padrões de tecnologia, direcionamento do time, identificação de oportunidades de evolução técnica e etc... mas também, trabalha muito próximo do PM ou de outros líderes de produto, para antecipar e prever as próximas evoluções que irão impactar o time e o negócio.

As vezes, há uma quebra nesse papel, onde há um líder para front-end e para back-end... Mas isso não vem ao caso.

Mas é importante notar que o mercado tem criado líderes que são mais agnósticos, ou seja, que lideram tanto fronts quanto backs, e talvez até outras especialidades técnicas. Essa é uma tendência que traz muita eficiência para as empresas. Mas, não é uma cadeira fácil.

Essa cadeira acumula muitas responsabilidades que para pessoas técnicas, não são tão comuns assim. Começando por gestão de pessoas, passando por planejamento tático e depois relacionamento com outras áreas não técnicas.

Geralmente é um processo duro, mas gratificante, para quem tenta traçar esse caminho de carreira técnica. Mesmo assim, geralmente, pessoas que vão para essa cadeira, são pessoas que tem uma visão mais holística quando se trata de tecnologia. Isso quer dizer que são pessoas técnicas que conseguem enxergar bem o todo, e não apenas uma parte da construção técnica de software.

É por isso que é uma loucura ter PMs ou pessoas de negócio liderando times técnicos. Não faz sentido. Não há profundidade e especialização suficiente para entender como todos os pontos se conectam, não só com o negócio, mas com todo o arcabouço técnico da empresa e mercado.

Logo, uma visão holística, completa, ampla do todo, não focada, é importante para trabalhar como líder de tecnologia.

Quebrando os papeis dentro dos times

Quando passamos para o time e para as disciplinas que compõem os times de tecnologia, nós podemos dividir o processo de construção de software, sobretudo softwares que tem a web e mobile como suas principais plataformas, podemos dividir em três categorias macro:

  • design, responsável por criar experiências de uso que abreviam a percepção de valor do usuário;
  • front-end, responsável por construir, absorver e implementar a solução de design e back-end, para que o usuário possa utilizar em diversas plataforma;
  • back-end, responsável por construir, sustentar e evoluir todos processos que realizam e concretizam as ações dos usuários;

A fase de design é a fase mais que se aproxima do planejamento tático e estratégico de produto. Geralmente designers estão mais próximos das decisões e tentam fazer isso de forma alinhada com o negócio e com a gestão de produto.

Por que front-end e back-end?

Quando falamos sobre front-end e back-end, nós estamos falando de dois profissionais que surgiram por uma divisão que faz analogia à estrutura técnica de software.

Existe as ações de software que rodam no client-side, ou seja, todas as ações e processos que são executados no local, no cliente, seja isso um mobile, um browser ou qualquer outro tipo de plataforma que o usuário esteja utilizando.

Geralmente esses processos envolvem ações que o usuário faz utilizando e manipulando a interface do software. É a parte mais funcional do design, e é o que está mais próximo do usuário.

Quando falamos sobre back-end, estamos falando sobre o profissional que tem a responsabilidade de cuidar dos processos e ações que acontecem no servidor. Todas as ações do usuário saem do client-side, manipulando elementos no front-end, e são finalizadas e gravadas no servidor, onde o back-end manipula os processos de server-side finalizar as operações...

Esses resultados serão usados depois em outros processos, projetos, pedaços de software, dados etc pela empresa. Enquanto o resultado do front-end é mais localizado na ponta do usuário, sobretudo no uso do produto, o resultado do back-end pode se espalhar em uma rede maior, que usa e reusa tudo aquilo que resultou da experiência dos usuários.

O trabalho front-end

Quando detalhamos o trabalho dos front-ends, nós podemos separar em dois grandes blocos:

  • Interface: onde há uma integração visual com toda a experiência de uso que designers (ux, ui, writer, research etc) pensaram para a solução, garantindo que haja um impacto claro de comportamento de usuário;
  • Funcional: tudo precisa funcionar conforme o planejado, que consiste integrar a experiência de uso com a stack de server-side, garantindo consistência de uso, experiência, regras e jornadas;

A web é uma plataforma incrível para se trabalhar, mas não evoluiu ou evoluiu muito pouco quando se trata em manipulação de elementos e estados desses elementos quando o usuário utiliza o produto.

Não dá para separar totalmente design de função nesse caso. É por isso que há um profissional que garante que o design, e as ações executadas no client, sejam conectadas com o server-side, seus dados, regras de negócio e etc. O design é função nessa maneira de fazer software.

Nós sempre dividíamos o conceito de client-side em:

  • Informação: onde a informação deveria ser acessível, para garantirmos que essa informação pudesse ser lida, reutilizada e manipulada durante muito tempo no futuro por vários tipos de novas tecnologias. Para tanto, tentávamos manter isso o mais semântico possível usando o HTML como linguagem de marcação padrão;
  • Formatação: a informação precisava ser manipulada para se adaptar visualmente em vários tipos de plataformas e canais que usuários poderiam usar no futuro. Embora hoje o padrão seja desktops e mobiles, estamos começando a ver o surgimento de outras tecnologias e aparelhos que irão precisar ter uma formatação de interface diferente, adaptada para o estilo de consumo específico;
  • Comportamento: a utilização dessa interface muda de plataforma para plataforma. Além disso, cada software pode ter uma experiência de uso totalmente diferente. Isso vai além de adaptar o uso dos elementos de acordo com o tamanho da tela, mas precisa garantir como todos os componentes se comportam em diferentes tipos de "terminais";

Então, a independência dessas camadas, ou a manipulação independente dessas camadas garante que possamos fazer softwares escaláveis e adaptativos.

Logo, foram criados uma série de frameworks e outras ferramentas que tentam suprir esses gaps nas tecnologias atuais. Talvez, o mais famigerado seja o React, que tenta resolver uma série de problemas da "estrutura fundamental" da tecnologia web, além de propor uma integração mais íntima e fina entre essas camadas.

Mas, embora essas ferramentas tenham trazido um certo ganho de eficiência no momento de desenvolver o front-end, elas não resolveram a forma de trabalho. O front-end ganhou ferramentas melhores, para continuar quebrando as mesmas pedras.

O trabalho do Front-end ainda continuou sendo implementar layout e integrar com APIs de back-end. Só que agora, eles fazem isso amparados com ferramentas mais sofisticadas.

Ou seja, nada disruptivo aconteceu, só inovação ordinária

A diferença entre disrupção e inovação é fácil de entender: inovação melhora o que existe. Disrupção destrói o que existe e cria uma nova realidade.

A Tesla não é disruptiva. Ela é inovadora. Ela seria disruptiva se tivesse feito um teleporter.
Um teleporter criaria um ambiente onde não precisaríamos mais de ônibus, bicicleta, carro, moto, nada desse coisa para se locomover. Ela teria disruptado a forma com que nos movimentamos do ponto A para o B.

Com a Tesla hoje, continuamos tendo que entrar em máquinas com quatro rodas para ir do ponto A para o ponto B... mas fazemos isso com um torque instantâneo absurdo em um carro que dirige sozinho.

Outros aspectos importantes pontos também não evoluíram. Por exemplo acessibilidade, semântica e SEO, continuam essencialmente a mesma coisa. Na verdade, pioraram. Acessibilidade em tempos de código React é uma piada. O mercado de SEO está sofrendo dinâmicas grandes de modelo de negócio de buscadores. E semântica no código só existia para podermos facilitar a extração e leitura dos dados da web por outros meios e plataforma... soluções melhores para resolver esse problema já foram propostos como o bom e velho JSON-LD... Mas em tempos de Web3, sei lá se isso ainda é relevante.

De qualquer forma, são problemas que hoje se tornam irrelevantes quando vemos para onde o mundo digital está sendo direcionado. Semântica, por exemplo, só era usado para SEO e Acessibilidade. Pouquíssima ou nenhuma solução para problemas reais foi feita com impacto relevante e perceptível pelas pessoas.

O front-end automatizou, de certa forma, operações manuais no processo de desenvolvimento

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

Mantive os nomes de ferramentas que já nem mais existem, pra mostrar que o problema não é a abundância de ferramentas que tentam melhorar soluções para problemas corriqueiros do dia a dia.

Mas mesmo com todas essas ferramentas, o core da responsabilidade de um front-end ainda continua sendo implementar layout e integrar a interface com o back-end. O front-end 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 VSCode (vida longa ao Sublime) / Figma (vida longa ao Sketch) / Browser / VSCode / API / Browser / VSCode.

“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. E em computação, uma das primeiras regras é que toda tarefa mecânica, repetitiva e manual tende a ser automatizada.

A conexão da interface de design com a informação que vem do server é uma dessas tarefas que pode ser automatizada ou semi-automatizada.

Isso tem a ver também com a natureza e evolução da disciplina de design.

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 pode (e espero que vá) ser automatizado.

Eu entendo que isso muda de tipo de projeto e produto, obviamente. Mas há um início claro, onde a tendência é que projetos menos complexos sejam totalmente automatizados. Um website, por exemplo, é totalmente factível e executável.

Coisas mais complexas e personalizadas, obviamente, não. Ainda? Sei lá... Mas claramente, não ainda.

Trabalhando com dados reais direto no Design

A disciplina de design é uma outra disciplina que houveram poucas evoluções relevantes nos últimos anos, inclusive sobre forma de trabalho. A galera fala bastante de "Design System", mas qualquer front-end que já criou uma biblioteca simples de elementos de interface já criou um design system rudimentar mesmo sem saber.

Ferramentas certamente evoluíram e acho que é daqui que os Designers começam a entender que seu trabalho pode ser mais amplificado.

Eu sempre achei que CSS e HTML (e um pouco de javascript) eram e podiam ser incorporadas como ferramentas de interface para designers. Já perdi as contas de quantas brigas separei tanta briga entre designer e front-end por causa de layout que foi implementado errado com visual quebrado e etc.

Logo, eu sempre achei que designers deveriam se apropriar suficientemente da parte de código que possibilita a realização e materialização do seu plano de experiência.

Então, chega o Figma, entregando uma ferramenta cujo diferencial inicial era colaboração, mas que depois evoluiu pra entregar uma ferramenta que realmente resolve os problemas de criação de layouts e experiência, se focando em necessidades reais do dia a dia e com isso aproximando o momento de criação do layout da fase de implementação desse layout. Isso muda o jogo.

Você pode ver os últimos lançamentos de 2023 do Figma aqui. Nesse momento ele lança ferramentas "direcionadas para devs"... mas na verdade, os grandes beneficiários são designers.

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, afim 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):

Craft plugin - JSON - YouTube

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 replicar/refazer esse layout com HTML/CSS/JS.

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? Não resolvemos, oras. A ideia do código bonito e semântico, como eu já disse, era para que pudéssemos manter a informação contida na web fosse facilmente reutilizada...

Web3 é uma visão para a próxima geração da internet, que busca descentralizar o controle e a propriedade dos dados, aplicativos e serviços online. O objetivo principal da Web3 é capacitar os usuários, permitindo-lhes ter maior controle sobre suas informações pessoais e participar ativamente na governança e na economia digital.

  1. Descentralização: A Web3 utiliza tecnologias como blockchain e contratos inteligentes para criar uma infraestrutura descentralizada, eliminando a dependência de intermediários centralizados. Isso reduz a possibilidade de censura, manipulação e controle excessivo por parte de grandes empresas ou governos.
  2. Privacidade e segurança: Com a Web3, os usuários têm maior controle sobre seus dados pessoais. Eles podem optar por compartilhar apenas as informações necessárias e têm a garantia de que seus dados são armazenados de forma segura e criptografada.
  3. Economia peer-to-peer: A Web3 permite a criação de mercados e plataformas peer-to-peer, onde os usuários podem interagir diretamente uns com os outros, sem a necessidade de intermediários. Isso permite uma economia mais justa, onde os criadores de conteúdo e os prestadores de serviços podem ser recompensados de forma mais direta e justa.

Então, atrelar informação ao código já é ruim. A informação precisa fluir, não importa onde ela esteja. Quando falamos sobre informação pública, nos websites que temos hoje na web, podemos usar outras alternativas que facilitam essa integração.

E é aí que entra a oportunidade para todo esse novo hype de serviços e soluções baseadas em inteligências artificiais.

Questão de tempo?

Eu não estou falando que todos os desenvolvedores serão substituídos. Estou falando que boa parte dos desenvolvedores (designers também?) serão substituídos se continuarem a fazer trabalhos operacionais como se fosse 10 anos atrás.

Se um designer consegue, via figma ou qualquer outra ferramenta, se conectar no banco de dados da empresa, criar regras e cenários de interação de experiência de uso direto nessa ferramenta, por que precisamos de front-ends que fazem isso?

Essas ferramentas, como o Figma e qualquer outra coisa, em uma plataforma de desenvolvimento. Assim como eu comentei (previ?) no artigo original.

Projetos como o Fronty, que transforma uma imagem em HTML e CSS... Ou outras ferramentas que tentam converter elementos de design para componentes em React... Isso já facilita fazer aquele Design System maroto...

Computadores evoluem. Se os princípios mudassem não haveria base para a evolução. – Caio Vaccaro

Essa tendência já estava sendo desenhada há tempos. É a coisa mais inteligente a se fazer. Você pode fazer coisas mais importantes do que ficar sentado na frente do computador alternando entre browser, layout, browser, layout.

O Github com o seu Copilot já é responsável por 46% do código gerado por programadores de todas as linguagens... em Java, esse número salta para 61%.

O próprio OpenAI lançou a sua própria versão, o OpenAI Codex, que é uma LLM treinada com foco em código. Bom, OpenAi e Github são basicamente da Micro$oft...

O Stack Overflow, refugio seguro de todos os desenvolvedores do mundo, tem visto seu tráfego caindo desde o surgimento do LLMs da vida.

E é engraçado, porque a Stack Overflow agora quer ganhar dinheiro cobrando das empresas que usam seus dados para treinar os modelos de AI. Bom... é um modelo de negócio. Todo mundo hoje em dia conta com uma maneira de vender ~dados~ inteligência para empresas terem vantagens competitivas no mercado...

Mas esses dados são gerados por pessoas... Então, será que as empresas que treinam LLMs, não deveriam pagar as pessoas em vez de apenas a Stack Overflow ou será que a Stack vai repassar parte desse valor para as pessoas que postaram respostas e perguntas? Então, vamos ver como vai dar.

A outra estratégia deles é criar o seu próprio modelo de AI, treinada não apenas com os dados públicos do Stack Overflow, mas também com dados proprietários também... Legal... mas aí vão ter um trabalho insano para ganhar competitividade num mercado que já conta com todo o código que o Github, da Microsoft, tem... e que diga-se de passagem, investiu pesadamente na OpenAI. Além disso, eles vão precisar pagar para as pessoas que geraram esses dados, não é mesmo.

Stack Overflow's second strategy is to develop its own AI models, trained not only on its public data but masses of proprietary information, too.

Veja bem: programadores (e aqui estou incluindo todos os tipos) terão a oportunidade de utilizar essas maravilhas para realmente se livrarem do ruído e se focarem no que realmente importa.

Firstly, it could significantly enhance productivity and efficiency. By automating mundane and repetitive tasks, engineers could focus on more complex challenges and use their skills and expertise to solve more significant problems. This could lead to faster development cycles, shorter time-to-market, and ultimately, a more competitive and innovative industry. -- Hans Christian Reinl, em Revolutionizing Frontend Development: The Role of AI in Design Systems

Conclusão

Mais cedo ou mais tarde a profissão de front-end como nós conhecemos até hoje vai deixar de existir. Não por que a necessidade de trabalhar com client-side vai sumir, pelo contrário. Isso é parte fundamental e essencial, indissociável da maneira com que fazemos software. Humanos precisam de interface.

Mas com certeza a disciplina como conhecemos vai morrer... e se renovar. Responsabilidades, escopo de trabalho, ferramentas, processos de trabalho, relações com outras disciplinas vão mudar drasticamente.

Eu enxergo uma volta às origens, onde parte dos front-ends se tornam uma espécie de Designer, e outra parte se torna e se oficializa como programadores, trabalhando com o pedaço mais pesado de programação. Não necessariamente apenas linguagem back-end, mas muito mais focado em código, do que em visual/interface.

Você que já é velho na área, talvez nem precise se preocupar, porque eu não acho que isso vai acontecer agora, mas você que acabou de começar, é melhor pensar duas vezes no futuro da sua carreira. Tenha uma visão holística. Siga as tendências macros do mercado. Foque-se na sua performance e em como você está resolvendo problemas de negócio por meio do código.

Você não digita código por que é legal. Você digita código para realizar uma solução, que entrega valor para as pessoas, que por sua vez cria resultado para o negócio.

Não há uma data para que essa mudança aconteça. Eu sei que as piadas rolam solta... mas a evolução é progressiva, paciente e constante. O artigo original foi escrito em 2017 e dá para cá o contexto mudou de forma incalculável.

Novamente, os primeiros a sofrerem com essas mudanças serão os ruins e medíocres.

Para ler mais

Devs usando AI para melhorar performance

Outros links sobre evolução dessa automtização que mudará a forma de trabalho dos front-ends

Sobre o cenário das ferramentas de front-end

Dados reais no design

Compartilhe este post