Premissa

O que se segue é uma resposta ao belo artigo de Josh Collinsworth que você pode encontrar aqui.

Decidi estruturar este conteúdo pegando cada citação resumida que ele faz em seu artigo e respondendo a cada uma delas com minha opinião.

Este artigo deve, portanto, ser considerado uma série de ideias que identificam uma opinião pessoal. Das 12 citações relatadas, acabei concordando com ✅ 8 delas, discordando de ❌ 3 e não tendo opinião sobre ? 1.

[TL;DR] Geralmente concordo com a opinião do autor e seu ponto de vista, embora em alguns casos a visão distorcida criada pelo artigo tenha me levado a discordar de algumas afirmações. A análise sobre o preconceito causou, na minha opinião, o mesmo preconceito em relação ao mundo do desenvolvimento por parte do autor.

Sinto que estou vendo uma diminuição generalizada da prática de frontend. Em quase todos os lugares que olho, noto a sua importância minimizada e os seus desafios banalizados.

✅ Concordo plenamente com esta afirmação.

O frontend foi considerado por muito tempo o “irmão mais novo” do backend, e isso é um erro. O frontend é a parte de uma aplicação que o usuário final vê e com a qual interage e, portanto, é fundamental para o sucesso de um produto. Sua importância não pode ser subestimada, mas isso acontece com muita frequência, e eu mesmo às vezes considero meu trabalho como desenvolvedor frontend “inferior” ao que fiz no backend.

Por que isso acontece? Do meu ponto de vista, acredito que seja porque na última década o mundo do desenvolvimento frontend foi invadido por frameworks e bibliotecas que tornaram o trabalho mais simples e acessível a todos. Isto levou a responder a muitos dos problemas que surgiram no passado, fazendo com que o desenvolvimento de frontend se tornasse “mais simples”. Isto levou a uma desvalorização do papel do desenvolvedor frontend, que muitas vezes é visto como um “macaco de código”. Simples, porém, não significa fácil, e muitas vezes o desenvolvedor frontend é chamado a resolver problemas complexos e tomar decisões importantes, justamente porque não se espera mais que ele resolva problemas “simples”, já resolvidos pelo framework, mas sim para enriquecer as experiências do usuário de maneiras novas e inovadoras.

É como se o CSS existisse em algum estado quântico bizarro; de alguma forma, ambos complexos demais para usar, mas simples demais para serem levados a sério, tudo ao mesmo tempo.

✅ Aqui também eu concordo.

CSS é uma das linguagens mais subestimadas e desvalorizadas no mundo do desenvolvimento web. CSS é uma linguagem poderosa e complexa, que permite criar interfaces de usuário complexas e detalhadas. No entanto, a distância da forma normal de escrever código, a sua sintaxe particular e a sua lógica de funcionamento muitas vezes dificultam o seu domínio e utilização. CSS é uma linguagem que requer tempo e dedicação para ser dominada, e o que aconteceu com o movimento CSS-in-JS é um exemplo claro de como a comunidade tentou resolver um problema que não existia criando um novo, ao mesmo tempo que adiciona abstração a uma linguagem já muito complexa.

De muitas maneiras, o CSS tem maior impacto do que qualquer outra linguagem na experiência do usuário, o que muitas vezes influencia diretamente o sucesso. Por que, então, o seu papel é tão menosprezado?

✅ Eu concordo.

Conforme mencionado em resposta à citação anterior, acredito que o problema do CSS se deve à sua lógica de funcionamento e à sua sintaxe particular. O problema é que muitas vezes ela é vista como uma linguagem “secundária” em relação ao JavaScript, quando na realidade é uma linguagem em si, com suas regras e peculiaridades, e requer um tempo de aprendizado comparável ao de uma programação. CSS é uma linguagem poderosa e complexa e seu papel não pode ser subestimado.

Principalmente, ninguém diz que o frontend é menos importante, ou menos real, ou que você não precisa ser tão inteligente para fazê-lo. Mas muitas vezes parece estar implícito.

✅ Concordo parcialmente.

Para falar a verdade, vejo esse tema muito mais explícito do que o autor diz. Na verdade, muitas vezes me vejo tendo que debater com pessoas que consideram o frontend um trabalho “menor” comparado ao backend, e que acreditam que o desenvolvedor frontend não deve ser um programador, mas um &&&]suporte para aqueles que fazem o trabalho real, o backend. Quando me perguntam qual é a minha função, sempre respondo Full-Stack, porque na minha formação e crescimento existem vários e diferentes elementos, e os dois lados da moeda têm sido importantes e significativos para mim.

Acredito que a comunidade precisa fazer mais para erradicar essa mentalidade. O desenvolvedor frontend é um profissional em todos os aspectos, e seu trabalho é fundamental para o sucesso de um produto.

O desenvolvedor frontend é chamado a resolver problemas complexos, apoiado em ferramentas em constante evolução — o que aumenta muito a carga cognitiva — e a tomar decisões importantes que influenciam diretamente a experiência do usuário, baluarte de um produto de sucesso.

A nossa produção é artística, até certo ponto, e as coisas artísticas têm uma longa e histórica história de serem tragicamente desvalorizadas apenas porque parecem simples e agradáveis.

✅ Eu concordo.

A falta de compreensão das funções e responsabilidades desempenha um papel fundamental em nosso setor. O desenvolvedor frontend é muitas vezes visto como um “artista”, um “criativo”, e seu trabalho é desvalorizado por não ser “técnico” como o do desenvolvedor backend. Isso é um erro em dois aspectos.

Em primeiro lugar, muitas vezes não é o desenvolvedor frontend quem decide o design de um aplicativo, mas o designer (UX, UI, chame como quiser). O desenvolvedor front-end é chamado a traduzir o design em código, e fazê-lo de forma eficiente e de alto desempenho. Isso requer habilidades técnicas e conhecimentos específicos, que vão muito além de simplesmente escrever código.

Em segundo lugar, como já mencionado acima, as responsabilidades de um desenvolvedor front-end geralmente vão muito além de simplesmente escrever código. Se eu modificar o código em meu aplicativo de back-end, os testes automáticos provavelmente notarão quaisquer regressões mais cedo do que eu. Se eu modificar o código em meu aplicativo frontend, é muito provável que a única maneira de perceber qualquer regressão seja testar manualmente o aplicativo ou aguardar um relatório dos clientes finais*. Isso torna o trabalho do desenvolvedor front-end muito mais complexo e exigente do que se imagina. Sem mencionar a quantidade de lógica de negócios e gestão de estado — ambas prontamente despejadas no frontend — que tornam a função cada vez mais integrada ao negócio.

*Nota: Estou bem ciente da existência de testes ponta a ponta, mas sua implementação é muito mais complexa e cara do que os testes automáticos tradicionais, além disso, sua confiabilidade é frequentemente questionada devido às suas condições aleatórias e externas.

A linguagem implica que as interfaces são dissociadas do software, e não uma parte real dele.

? Nenhuma opinião sobre isso.

A referência aqui é ao paradoxo pelo qual em nosso setor parece haver uma diferença entre Desenvolvedor e Engenheiro e que necessariamente deve ser mostrado como algo mais. Não tenho opinião sobre o assunto, mas concordo que hoje em dia a proliferação de títulos e banners nada mais faz do que turvar as águas em relação ao que cada um de nós realmente faz.

Escrever CSS parece ser considerado como fazer anotações em uma reunião, com o sexismo implícito e a desvalorização da importância do anotador na sala.

✅ Eu concordo.

Como já mencionado anteriormente neste artigo, concordo com a desvalorização incorreta do CSS e do mundo frontend em geral. Além disso, nesta parte do artigo é feita referência ao chauvinismo presente no nosso setor e, embora nunca tenha tido uma percepção direta dele, compreendo a sua realidade e gravidade. A nossa indústria ainda é muitas vezes um ambiente hostil para as mulheres e acredito que a comunidade precisa de fazer mais para combater esta mentalidade.

Como se o trabalho quase impossível de oferecer suporte a todos os dispositivos, sistemas operacionais, tamanhos de tela, navegadores, preferências do usuário e interfaces possíveis no passado, presente e futuro fosse tão simples que nós mesmos inventamos toda a complexidade, só porque estávamos entediados.

✅ Concordo com o significado intrínseco desta afirmação.

A complexidade do mundo de hoje torna o papel do desenvolvedor frontend ainda mais complexo do que nunca, e quando piadas frontend e punchlines se tornam preconceitos, é fácil cair em a armadilha de desvalorizar o trabalho dos trabalhadores frontend.

Sim, como grupo, ficamos entusiasmados com coisas novas. Mas por que isso não nos torna curiosos, ou adaptáveis, ou curiosos? Por que não recebemos o crédito pela nossa alegria de aprender, em vez de sermos denegridos por nos recusarmos a permanecer no mesmo lugar?

❌ Concordo menos com este.

Embora seja verdade que a evolução do mundo frontend — como já mencionado anteriormente — tenha levado a uma proliferação de ideias, ferramentas e metodologias, a Síndrome do Objeto Brilhante é um problema real e generalizado, especialmente em a comunidade front-end. Isso não significa que você não deva ser curioso ou adaptável, mas que muitas vezes você cai na armadilha de adotar novas tecnologias sem entender completamente os prós e contras, e sem avaliar se elas são realmente necessárias ou não.

Se as nossas competências são valiosas como fita adesiva sobre as fissuras das deficiências organizacionais, porque não são valiosas durante o planeamento e a tomada de decisões que levaram a esses defeitos, quando poderíamos potencialmente evitá-los?

✅ Concordo totalmente.

Exatamente como um Arquiteto de Software (ou Tech Lead, ou quem está no comando da arquitetura) deve envolver todos os membros da equipe nas escolhas arquiteturais — apesar de ter a última palavra e, em última análise, a responsabilidade sobre eles -, também a decisão O processo de criação que leva à criação de um aplicativo ou parte dele deve envolver todos os membros da equipe, incluindo desenvolvedores front-end. Aqueles que já fazem isso há tempo suficiente podem encontrar lacunas na experiência do usuário ou no design que outros não perceberiam, e envolvê-los no processo de tomada de decisão pode levar a uma melhor experiência do usuário e a um produto de sucesso.

As ferramentas de front-end se comercializam como se o front-end fosse algo que ninguém quer fazer e ninguém deveria se preocupar mais do que o necessário.

❌ Você pode ver claramente a frustração aumentando à medida que a postagem se desenvolve, mas neste caso só posso discordar.

O marketing — como Josh define — das ferramentas frontend nunca banalizou ou tentou simplificar os desafios dos desenvolvedores, exceto por algumas raras exceções. Essas ferramentas visam cada vez mais tornar o trabalho do desenvolvedor frontend mais simples e eficiente, mas nunca banal, e é certo que o rumo continue o mesmo. A promessa nunca é fazer do desenvolvedor frontend um macaco de código, mas permitir que ele se concentre no que é realmente importante: a criação de uma experiência de usuário bem-sucedida e o impacto nos negócios e no mundo ao seu redor. O mesmo vale para o mundo backend, onde as ferramentas evoluíram para permitir que os desenvolvedores se concentrem no produto, em vez de em escolhas técnicas ou problemas de configuração.

Finalmente, lembremos que o mundo das relações com desenvolvedores se desenvolveu de forma estruturada nos últimos anos, e quaisquer erros de algumas empresas não devem ser considerados a norma.

Parece que ninguém mais pensa no frontend como uma parte crítica do produto; eles só pensam nisso como a bela caixa em que o produto chega.

❌ Aqui também, infelizmente, discordo de Josh.

O frontend é uma parte fundamental de um produto e sua importância não pode ser subestimada, mas isso não significa que você necessariamente tenha que se entregar à complexidade e à abstração. O desenvolvimento frontend já é complexo o suficiente para não exigir design supersofisticado ou arquiteturas obscuras, e exatamente como no mundo backend, a padronização, se feita com pleno conhecimento dos fatos, permite não adicionar carga cognitiva desnecessária e focar em outros aspectos do produto.