A esteira do front-end
(polotek.net)- Quanto mais duradouro for um produto, maior tende a ser o custo do tempo e da energia gastos discutindo reescritas do que a escolha do framework de front-end
- Se o produto ainda estiver vivo daqui a 5 anos, isso será um sucesso, mas nesse meio-tempo há grande chance de o framework escolhido ficar obsoleto ou mudar significativamente em uma nova versão com o mesmo nome
- Equipes de produto melhores, em vez de trocar para uma nova ferramenta, entendem profundamente o framework atual e elevam sua proficiência o suficiente para que a ferramenta não impeça o avanço do trabalho
- Para reduzir custos de longo prazo, uma escolha mais próxima da plataforma Web e das tecnologias centrais da Web pode ser uma concessão de negócios mais realista do que abstrações complexas
- A complexidade do ecossistema de front-end dificulta a vida tanto de desenvolvedores iniciantes quanto de equipes de contratação, e desenvolvedores com fundamentos da Web fracos ficam mais vulneráveis à próxima mudança de stack
É difícil sair da esteira por meio de reescritas
- Muitas equipes de front-end acreditam que uma reescrita levará a um estado melhor, mas, em produtos de longa duração, a escolha do framework em si não é a decisão técnica mais importante
- Se um produto durar mais de 5 anos, isso pode ser visto como sucesso, mas, durante esse período, o framework escolhido pode se tornar obsoleto
- A comunidade de front-end sempre girou em torno de mudanças, e é pouco provável que isso mude no curto prazo
- Mesmo frameworks populares que sobrevivem podem mudar completamente por dentro e, sob um novo número de versão, ser na prática reescritos
- O foco da equipe não deve ser perseguir ferramentas novas e brilhantes, mas aprender bem o framework que já usa
- É preciso ter entendimento e proficiência suficientes para que a ferramenta não se torne um obstáculo ao avanço do trabalho
- A expectativa de que trocar para uma ferramenta alternativa resolverá o problema se parece mais com uma armadilha
Quanto mais perto da plataforma Web, menor o custo de longo prazo
- Empresas que querem reduzir o custo de tecnologias de front-end que frequentemente ficam obsoletas podem considerar um caminho mais próximo da plataforma Web
- É preciso reduzir abstrações complexas e reaprender o que a Web realmente consegue fazer
- Isso não significa que essa seja a resposta para todos os problemas nem que seja incondicionalmente melhor
- Pode ser uma concessão de negócios capaz de entregar mais valor e reduzir custos no longo prazo
- Estar próximo das tecnologias centrais da Web torna a equipe menos suscetível, ao contratar engenheiros competentes no futuro, ao argumento de que só será possível trabalhar reescrevendo milhões de linhas de código
- Para engenheiros individualmente, entender profundamente as tecnologias centrais da Web tende a ajudar mais no valor de mercado de longo prazo do que acompanhar continuamente um framework específico
- Pode significar abrir mão de parte da empregabilidade de curto prazo
- É mais favorável à sustentabilidade da carreira do que tentar aprender todas as tecnologias populares
- Conhecer uma tecnologia específica não protege contra realidades como a piora do mercado
Preferências de framework e custos para a equipe
- Engenheiros com forte preferência por um framework devem refletir esse critério nas condições de busca por emprego
- Entrar em uma equipe que já usa um framework específico e depois tentar fazê-la migrar para o framework de sua preferência abala a equipe e aumenta muito os custos
- A complexidade do ecossistema atual de front-end é um peso tanto para desenvolvedores iniciantes quanto para empresas
- Desenvolvedores iniciantes têm dificuldade para aprender habilidades suficientes para conseguir emprego e ficam sobrecarregados por ferramentas complexas
- Empresas sentem até a contratação de desenvolvedores generalistas como mais difícil, e o patamar de entrada para cargos regulares de desenvolvimento também sobe
- Se alguém que está aprendendo o ecossistema tecnológico atual não aprender os fundamentos da Web, poderá ficar em séria desvantagem quando o stack mudar de novo
- A Web é uma plataforma competente e única para entregar software; ela melhorou com o tempo e manteve um alto nível de compatibilidade retroativa
- As ferramentas básicas atuais se tornaram boas o suficiente, mas a camada de frameworks está funcionando contra a plataforma, em vez de abraçá-la
1 comentários
Opiniões no Hacker News
Recentemente trabalhei na troca do sistema de build do código de frontend de yarn para pnpm. Normalmente sou engenheiro de backend, mas também já lidei bastante com JS
O que mais me irrita ao entrar no frontend é que realmente tudo parece deprecated. Se você usou a CLI do apollo em 2022, ela logo vira deprecated e você precisa aprender uma ferramenta totalmente diferente, como graphql-client, com configuração e opções completamente distintas. No fim, mantive o antigo e apenas desliguei a verificação de engine do Node no pnpm para ele parar de reclamar. Quando tento fazer um patch upgrade de alguma dependência, a assinatura de tipos pode quebrar, então também fixo aquilo e deixo um TODO na codebase esperando que alguém conserte algum dia
Quando finalmente consigo fazer rodar, centenas de avisos de deprecated passam rolando durante a instalação e, assim que o build termina, dá vontade de fugir
Acho realmente estranho o quanto o desenvolvimento frontend como um todo aceita breaking changes e deprecated desse jeito. Venho trabalhando há quase 4 anos em um grande projeto Rust e, nesse tempo, houve algumas pequenas breaking changes em bibliotecas de terceiros, mas só uma mudança importante que exigiu alterações grandes na aplicação. Já em JS, parece que em menos de 6 meses você precisa reescrever alguma coisa
O mundo frontend adotou redes sociais, YouTube e até Twitch muito mais ativamente do que outras áreas. Esses influenciadores precisam de material novo o tempo todo para manter a relevância, então vivem empurrando novidades que possam virar conteúdo
Soma-se a isso uma cultura de conferências muito ativa. Conferências de frontend e JS parecem uma grande competição para apresentar o novo tema do momento
O mercado de venda de cursos de frontend também é grande. Criadores de cursos precisam fazer seu chefe aprovar um curso em vídeo de preço promocional limitado de US$ 700 para aprender a nova moda; para isso, precisam afastar a indústria daquilo antigo que todo mundo já conhece. Então empurram fortemente o novo e tornam o antigo deprecated
Um pequeno webapp em JS puro de 5 KLOC que escrevi há 15 anos ainda é usado diariamente por cerca de 10 pessoas sem que uma única linha tenha sido alterada. Na verdade, resistiu melhor do que uma aplicação Win32
Vejo a maior parte do churn no frontend basicamente como uma falha política e organizacional
Quando comecei, na época de JS puro/jQuery, o gerenciamento de dependências era, na prática, copiar arquivos
.jspara o diretóriovendor/. Depois vieram nodejs/npm; no frontend também se usava bower antes do npm, e de repente o conselho padrão passou a ser baixar módulos em vez de fazer as coisas você mesmoMas já naquela época muita gente questionava se fazia sentido não ser dono de milhares de linhas de código oculto e deixá-las nas mãos de voluntários que fazem open source por diversão
Ainda hoje, se você quer manter um projeto por muito tempo, dá para evitar que as partes invisíveis fiquem grandes demais. Dá para tratar pequenos problemas com uma abordagem como: “só preciso de uma função desta biblioteca, então, em vez de depender da biblioteca inteira, vamos copiar apenas essa função para a codebase e adicionar testes”
Por isso, vejo isso não como um problema do JavaScript em si, mas como um problema de pessoas e processos. Há muitos desenvolvedores JS que não passam por esse tipo de problema, mas uma grande parte do ecossistema passa
Todos os dias, milhares de horas-pessoa são gastas corrigindo as consequências de breaking changes “muito importantes”™, como “e se mudássemos MultiselectDropdown para MultiSelectButtonDropdown? E vamos trocar a API por uma completamente nova também!”
Quase não existe uma cultura de entender o custo enorme de quebrar APIs. Depois de trabalhar 10 anos com Go, isso é especialmente frustrante. Go tem uma promessa de retrocompatibilidade, e isso parece influenciar também a atitude de desenvolvedores de bibliotecas Go em relação a compatibilidade e breaking changes. É uma experiência realmente boa ver código escrito há 10 anos compilar e funcionar sem mudanças no Go mais recente
Cheguei a migrar para Flutter para escapar desse inferno JS/web, e combinou bastante comigo; consegui esquecer boa parte da complexidade acidental da stack web. Mas a cultura de “não tem problema quebrar pacotes” está se infiltrando também no ecossistema Dart, o que é muito irritante
Sinceramente, acho muito pior do que frontend. No frontend, ao menos TypeScript e as características da linguagem mantêm o raio de dano em um nível relativamente sane. Em Python, você pode fazer literalmente qualquer coisa, e por isso autores de bibliotecas também fazem literalmente qualquer coisa. Quer mudar a forma de importar módulos? Muda. Quer quebrar todas as suposições sobre o comportamento de classes com metaclasses? Pode. Mesmo que você ache que tipagem estática vá ajudar, nem algo trivial como
Partialfunciona, e também não dá para afirmar estaticamente que dois objetos são do mesmo tipoAcho engraçado ver gente reclamando que bibliotecas mudam. A transição do Python 2 para o 3 foi tão horrível que, no meu emprego anterior, havia um monólito Python de 100 milhões de linhas sem plano algum de upgrade para Python 3. Ir do SqlAlchemy 1 para o 2 é uma migração em 8 etapas e, na prática, uma reescrita completa; se qualquer coisa quebrar, o site cai. Enquanto isso, reclamam que o React adicionou hooks de forma opcional
O estranho é que a internet está cheia de textos sobre a “esteira do frontend”, mas quase não se veem textos reclamando do outro lado
Sobre a afirmação de que “se você é engenheiro, quanto mais profundamente entender as tecnologias essenciais da Web, maior será seu valor de mercado ao longo do tempo”, acho que posso opinar, já que trabalho com front-end há quase 20 anos e passei por várias grandes mudanças de paradigma.
É certamente verdade que conhecer todas as tecnologias essenciais da Web faz de você um engenheiro mais equilibrado. Mas sou cético quanto a isso fazer você parecer mais atraente no mercado de contratação. Não porque esse conhecimento não seja importante, mas porque quem decide contratações geralmente faz correspondência de padrões.
Se você quer maximizar seu “valor de mercado”, ainda precisa ser muito bom em React. Isso é quase o ingresso básico; o restante é ótimo, mas, sem essa base, suas opções diminuem. Talvez o autor quisesse dizer isso e eu tenha interpretado mal.
Porém, em funções como consultoria ou trabalho por contrato, concordo com o comentário original. Ao trabalhar com pessoas de grandes consultorias que contratam ou decidem quem será entrevistado, vê-se que elas praticamente eliminam automaticamente quem ainda não conhece a stack que preferem ou a que o cliente atual usa. Isso não é um problema só de recrutadores não técnicos; arquitetos técnicos também fazem isso. Independentemente do nível de experiência, eles não querem tempo de adaptação à tecnologia em si.
Nessas funções, manter-se atualizado é muito importante. Caso contrário, o gerente de contratação descarta o currículo por falta de buzzwords antes mesmo de um engenheiro avaliar a competência.
Pode ser um caso incomum, mas nunca foi um problema eu não saber React. Chamar isso de “ingresso básico” é forte demais.
Front-end tem um teto de remuneração bastante firme. Depois que você passa de certo nível, nunca mais precisa criar UI.
A maioria das empresas, até as grandes, não se importa muito com os fundamentos essenciais, não os verifica nem contrata com base neles. Contratam com critérios como “manda bem em React” ou “tem muita experiência com Next.js”.
Fundamentos são ótimos quando você está criando algo do zero, mas empresas reais quase nunca fazem isso. Em geral, pegam soluções prontas com ecossistemas grandes e boa documentação. Se você souber trabalhar bem com essas coisas, será contratado com muito mais facilidade, e os fundamentos podem ser aprendidos no processo.
A ideia de que “qualquer framework que você escolher estará obsolete em 5 anos” parece um argumento meio ultrapassado.
Não sou principalmente desenvolvedor front-end, mas não fujo de front-end quando preciso, e venho usando React há cerca de 10 anos. Há uma certa mudança de clima em direção ao Svelte, mas, quando o Svelte ultrapassar o React, provavelmente o Svelte também já terá sido usado em produção por esse mesmo tempo. O Angular também pode perder força algum dia, mas, considerando os períodos do Angular1 e do Angular2+, ele existe há mais tempo que o React.
É verdade que o desenvolvimento front-end se move rápido, mas não é tão ruim assim. Se você escolhe opções entediantes, obtém resultados entediantes.
Angular1 e 2 eram tão diferentes que, tirando o nome, quase não dava para compará-los, e muitos desenvolvedores se queimaram nisso. O próprio Angular também está mudando bastante. Não é tão extremo quanto a passagem do v1 para o Angular2, mas ainda exige uma readaptação considerável. Tudo está migrando para standalone components, nova sintaxe de templates, signals etc.
Com React é parecido. Houve uma grande mudança de paradigma com a chegada de componentes funcionais e hooks. Eram compatíveis, mas muito diferentes entre si.
O mesmo vale para paradigmas mais gerais. No começo era tudo renderização no servidor, depois todos correram para single-page apps, e então voltamos para renderização no servidor, mas desta vez como renderização parcial no servidor com hydration.
É diferente a ponto de poder ser chamado de outro framework, então, embora haja nuances, esse argumento não está completamente morto.
É realmente simples de trabalhar. Fiz um app simples de alocação de ações, e o que mais me surpreendeu foi o tamanho do bundle. Era 9KB com gzip, menor do que qualquer framework que eu conheço. Menor até que o htmx, que em certa medida é quase “anti-JS”.
Frameworks antigos podem continuar rodando por muito tempo. Se ainda existe alguém que conhece aquela stack e pode ser contratado para trabalhar nela quando necessário, então essa stack não é obsolete. “Antiga” ou “legada” pode estar certo. Mas, até chegar o dia em que não reste ninguém para lidar com ela, não é obsolete.
É interessante chamar isso de problema de frontend. Não é um problema de frontend, é o problema de um ecossistema gigantesco no qual novos participantes continuam entrando
Vi a mesma coisa 15 anos atrás, quando Java estava na linha de frente da inovação. Em poucos anos surgiram dezenas de frameworks e vários sistemas de build. A mudança do React 17 para o 18 é muito menor do que ir de Perl 5 para 6, ou de Python 2 para 3
No backend, em vez de “vamos usar um novo framework”, aparece “vamos usar uma nova linguagem”. A moda mais recente é reescrever algo em Rust; antes disso houve Go, Haskell, Scala e F#
Se você acha incômodo migrar código de frontend de React para algo como Svelte, tente reescrever um app em VB 6. Sem falar de coisas como RPC em que os dados ficam dentro do código
Não estou dizendo que a instabilidade das práticas de engenharia não seja um problema. É um grande problema. Só não é exclusivo do frontend
webpack também tem 13 anos, mas a forma de configurá-lo mudou drasticamente mesmo nos últimos anos
Se a configuração do Apache mudasse com a mesma frequência que a desses sistemas, ninguém usaria Apache
No emprego anterior, tivemos duas migrações de banco de dados em dois anos, consumindo no total um ano de tempo de engenharia. Não eram algumas tabelas não essenciais: eram todas as tabelas. Quando algo quebrava ou a direção perguntava por que estava tudo tão lento, culpavam os engenheiros que estavam aprendendo frontend, alegando falta de experiência
Trabalho como desenvolvedor Java há mais de 25 anos, e durante pouco mais dos primeiros 10 anos fiz desenvolvimento full-stack, que era o formato comum nas empresas na época. Hoje é normal haver uma equipe separada de frontend, e muitas vezes três equipes: web, iOS e Android. Para mim, essa mudança aconteceu mais ou menos na época da transição de AngularJS para Angular
Java também mudou rapidamente nos primeiros 10 anos, especialmente nos 3 primeiros. Mas esse período acabou. Java 5 foi uma grande mudança, e Java 8 também trouxe recursos importantes, mas Java 8 é de 2014. Minha equipe só recentemente migrou para Java 11, e agora já saiu o Java 24. Nunca usei recursos do Java 11 e nem sei quais são. Passei 10 anos sem aprender nenhum recurso novo da linguagem
A ferramenta de build é a mesma há 15 anos, e a IDE é a mesma há 20 anos. O framework principal que uso também é o mesmo há 10 anos. Quando fui para meu último emprego, a estrutura da base de código era exatamente igual à da equipe anterior
Criar serviços web em Java é um problema resolvido. É completamente entediante, no bom sentido, como COBOL
O frontend mudou rapidamente no fim dos anos 90 e no começo dos anos 2000, mas continuou mudando rápido desde então. Um projeto pessoal de UI que fiz alguns anos atrás ficou completamente ultrapassado
Se fosse um projeto Java em que trabalhei depois da era EJB, hoje seria possível encontrar um desenvolvedor Java e colocá-lo nele para produzir imediatamente. Mesmo que esse desenvolvedor tenha nascido depois de o projeto ter sido criado. Haveria apenas algumas bibliotecas antigas para aprender
A forma de sair da esteira é simplesmente não usar framework de frontend. Não é escolher outro framework qualquer e reescrever tudo depois
É preciso renderização no lado do servidor, JavaScript só quando necessário, e não separar dentro da empresa as pessoas de backend e frontend
Se um engenheiro consegue escrever SQL para buscar exatamente as colunas necessárias para uma view web com SSR, e também ser responsável por essa view, não é preciso gastar nem 1 segundo pensando em API ou ORM. Basta conhecer SQL e HTML/CSS/JS moderno e puro. A maior parte do trabalho passa a ser transformar views do negócio (SQL) em DOM (HTML), e o ecossistema de programação do lado do servidor fica em segundo plano
Vejo a forma final como SSR de conteúdo web dentro do próprio RDBMS. Algo no estilo do Oracle APEX. Mas a maioria dos engenheiros ainda não está pronta para essa conversa. Eu também não estava quando vi isso pela primeira vez em um ambiente real. Somos apegados demais às formas como sofremos
Ela agravou o problema de complexidade excessiva no frontend. Como há pessoas na equipe de frontend, elas continuam criando trabalho e acrescentando complexidade. Também é um problema haver gente demais que só conhece desenvolvimento web e nada mais
Em um projeto paralelo, defini como uma das restrições iniciais que o site inteiro deveria degradar de forma elegante mesmo com JavaScript desativado. Com isso, toda vez que eu queria adicionar uma funcionalidade que normalmente seria feita em JavaScript, eu perguntava: “dá para fazer isso sem JavaScript?”. Até agora, surpreendentemente, a resposta sempre foi sim
Hoje dá para fazer muita coisa só com seletores CSS sobre controles HTML básicos. Essa base de código ainda não tem uma única linha de JS
Equipes de produto/design podem pressionar para colocar o máximo possível de enfeites em JavaScript, sem considerar usabilidade, desempenho, acessibilidade ou boa engenharia
Eu não sou muito bom em frontend e não tenho designer. Sou muito melhor no backend, mas outras pessoas da equipe têm mais talento do que eu para design de frontend
Ao criar meu primeiro site, li textos como “Svelte é melhor que React” e “solid-js será a próxima grande onda” e achei que isso fosse uma parte importante do desenvolvimento web
Para iniciantes, é melhor ler a MDN e ignorar o resto
As pessoas precisam de tutoriais e walkthroughs, e precisam construir uma compreensão interna de como tudo isso funciona
Frameworks ajudam a abstrair essas partes
Mas talvez não a recente obsessão com Next.js e SSR. Pessoalmente, acho que isso pode acabar sendo um dos fatores de declínio do lado do React
Considerando o quanto JS e CSS puros evoluíram nos últimos anos, e vendo recursos interessantes como animação de
display: nonequase chegando à adoção, a abordagem de gerar HTML por templates no servidor e usar JS apenas onde necessário parece mais válida do que nuncaDigo isso como alguém que vive principalmente de React
Assim como o autor, também trabalho com frontend há 20 anos, de um jeito ou de outro. O ecossistema, o churn, a acrobacia de sincronizar estado entre frontend e backend são realmente insanos
Recentemente comecei um projeto de prova de conceito com Go templates e HTMX, tentando aproximar a sensação de criar UI com “componentes”, como no React. Ainda há muitas arestas, mas existe potencial. Sinceramente, nem tenho certeza ainda se HTMX é necessário. Comecei a gerenciar event listeners diretamente, e acho que prefiro esse caminho
Curiosamente, gerenciar estados complexos de UI baseados em papéis e permissões do usuário é muito mais fácil no servidor. Basta enviar apenas o HTML que o usuário pode ver
Ainda assim, React, Vue etc. têm um impulso enorme. Não sei como poderia começar uma mudança coletiva de mentalidade. Ainda mais considerando que há muitos desenvolvedores que só conhecem frameworks de frontend como forma de criar UI
Não sei quanto à afirmação de que “qualquer framework que você escolher ficará obsoleto em 5 anos”
Uso React profissionalmente há mais de 10 anos
package.json? Qual versão de node/npm a equipe usa?Se você usa versões razoavelmente recentes e bibliotecas populares, deve ter visto se acumularem avisos de deprecated sobre dependências transitivas durante o
npm installPara ser justo, acho que o código do React em si manteve compatibilidade retroativa razoavelmente bem. Não é culpa do React. Mas todos os sistemas de build usados há 5 anos mudaram e quebraram compatibilidade. Eu também tinha esquecido dos métodos de ciclo de vida de componentes
Mesmo um projeto bem mantido como React não consegue escapar da bagunça do seu ecossistema
Nem sempre dá para escolher, mas hoje em dia geralmente opto por importar JS puro sem sistema de build, tratar o máximo possível no backend Python/Django e sair completamente do ecossistema JavaScript. Nunca me arrependi
Você ainda mantém o app no React 15?
Todos os editores WYSIWYG que funcionam no React 16 não têm mais suporte. Se uma vulnerabilidade de segurança for encontrada, ficamos “contando com a sorte”. Ou então não deveríamos usá-los
React 16 ainda é suportado, mas certamente está obsoleto
O contra-argumento é que, se você não adotar um framework, acaba criando um framework próprio que pessoas de fora da equipe não entendem, cuja documentação geralmente é fraca, e no qual é preciso continuar trabalhando para adicionar funcionalidades que frameworks existentes já têm
No frontend existem funcionalidades necessárias em comum e problemas comuns a resolver. Não é melhor começar pelo menos com alguma coisa em vez de partir do nada?
Como ninguém viu o framework interno antes, é impossível encontrar alguém que consiga ser produtivo de imediato. Mesmo com documentação muito boa, leva tempo para aprender e internalizar. Para contratações de longo prazo não é o pior cenário, mas se você precisar temporariamente de mais desenvolvedores, não há saída
Como escrevi em outro lugar, quase todo mundo quer um webapp, ou acha que tem um webapp, mas na realidade geralmente é apenas um site dinâmico. Não é necessário empilhar frameworks para criar um site dinâmico
Isso não é um problema de frontend, é um problema do ecossistema JS. Também acontece no backend
O ambiente JS é uma completa bagunça de dependências que têm dezenas ou centenas de outras dependências. Por exemplo, o grafo de dependências do Platformatic, um framework Node baseado em Fastify, é o seguinte
https://npmgraph.js.org/?q=platformatic#zoom=h
Essas dependências podem ser abandonadas a qualquer momento. Até dependências gigantes como Axios ou Express em algum momento pareceram estar largadas
E cada dependência fica à mercê do que seu mantenedor acha correto. Alguns dias atrás, uma dependência que usamos em produção decidiu que podia deixar de dar suporte a versões do Safari de cerca de 3 anos atrás, embora tenha cerca de 25 milhões de downloads por semana — React tem cerca de 26 milhões — e seja usada em 10 milhões de repositórios no GitHub. Considerando que o Safari tem mais de 50% de participação no mercado móvel dos EUA, isso é realmente insano