Executando verificação de segurança...
13

[Front-end] Uma nova tendência ( não tão nova ) está surgindo?

Galera, faz uns bons 15 anos ou um pouco mais que trabalho com Front-end, e talvez tenha sido um dos privilegiados por ter conhecido a versão mais básica da Web e acompanhado toda a evolução até o cenário que temos hoje.

Uma breve introdução

Então eu vim de uma época onde existia uma complexidade enorme na compatibilidade entre browsers, e não existia : media queries, transition e animation no Css, bordas arredondadas, Promises e a API do DOM era despadronizada, algumas bibliotecas como jQuery salvavam a pele para muitos trabalhos, mas para outros ainda era muito dolorido. Fontes customizadas eram um desafio também, poucos conhecem hoje uma biblioteca que caiu em desuso, a Cufon, que transformava os textos html em fontes customizadas, usando uma biblioteca Js que usava um arquivo Flash para funcionar.

Este era o cenário lá atrás...

Além destas limitações técnicas do browser, ainda tínhamos uma preocupação mais high-level, que era a necessidade de abstrair as partes do todo da nossa aplicação, no contexto do Javascript no client. A partir daí veio o boom de soluções de Frameworks que foram evoluindo durante os anos.

A percepção

Mas não é de hoje que sinto que atingimos o extremo desta "frameworkerização".
Tudo parece estar relativamente mais difícil do que precisaria, já me deparei com uma série de projetos mega complexos com relação à sua estrutura, e extremamente acoplados ao framework.

Acho que é sempre válido se perguntar se o que você acredita de fato faz sentido, pode ser apenas uma alucinação ou um viés com relação à sua experiencia de vida. E este sempre foi meu caminho, mas duas coisas me fizeram acreditar que de fato esta visão que eu estava tendo tinha alguma verdade.

  1. Uma série de ferramentas / idéias que eu achava desnecessáriamente complicadas começaram a ser revistas e/ou esquecidas. Nesse bolo está: Rxjs, Redux, Flux, Redux Saga, Lifecycles esquisitos: componentDidMount, shouldComponentUpdate, SPA's estão perdendo a importância para uma série de cenários onde SSR e SSG são suficientes ou simplesmente mais performáticos.
  2. Algumas ferramentas e conceitos estão emergindo no mercado, trazendo como principal diferencial estas duas características que parece terem sido perdidas durante estes anos: Simplicidade e ser Agnóstico. Astro, htmx, Alpine.js, Tailwind são alguns exemplos, onde você pode escolher a sua stack no Front e você pode escolher qualquer outra linguagem/stack no Back e de formas relativamente mais simples, em contraste com o modelo atual, onde o framework que escolhe hoje praticamente dita qual será a linguagem no back-end e adiciona ainda uma série de camadas de complexidade a mais, além de te prender no próprio ecossistema.

A minha dor

Eu já tive algumas oportunidades de reescrever alguns projetos que foram desenvolvidos com os frameworks atuais, para versões sem frameworks, usando algumas alternativas mais leves para resolver problemas de UI, usando também o contexto de Islands popularizado pelo time do Astro, e usando uma das inúmeras soluções de gestão de estados agnósticos independente de frameworks. Em todos os casos ficou claro que ficou mais simples, mais rapido principalmente no quesito performance de carregamento.

Então, minha dor é, primeiramente, ver algo que poderia ser mais fácil, mais simples, tomar proporções super complexas a ponto de precisar de um especialista em um framework para poder utilizar as boas práticas (algumas delas muito questionadas entre a própria comunidade).

Além disso, um papel que precisei desempenhar era o de repassar o conhecimento para as novas pessoas começando no Front-end, e estes frameworks acabavam ficando no caminho do que eu acreditava ser super importante para a formação, que eram os fundamentos, seja da linguagem, seja sobre api do browser, além de tornar mais trabalhoso de fato muitas das coisas que precisavamos fazer.

Alguns conceitos com relação à arquitetura, falando de forma agnóstica para mim sempre foram mais importantes, estas de fato ajudariam um sistema a escalar, corroborando com um dos conceitos cunhados pelo Uncle Bob acerca da arquitetura limpa sobre deixar os detalhes da aplicação nas camadas mais externas da sua solução / arquitetura. Porém a escalabilidade por muitas vezes hoje é uma responsabilidade atribuída ao framework, o que soa estranho para mim.

O valor das tendências (novas?)...

Da mesma forma como foi revista a priorização sobre SPA vs SSG/SSR, me parece que estão sendo revistas estas complexidades que temos hoje trazidas pelos frameworks mais modernos. O pensamento no alto acoplamento talvez esteja sendo revisto. Talvez o valor de ser agnóstico esteja novamente sendo discutido.

Talvez tenhamos esquecido que o browser, os bundlers, as linguagens ( HTML, JS e CSS ), as ferramentas e a plataforma, como um todo, evoluíram.

Difícil prever o futuro, estas iniciativas estão cada vez mais ganhando tração, talvez elas não sejam definitivamente saídas que substituirão as atuais, mas sob minha perspectiva, estão fazendo um papel mega importante, que é provar, de maneira empírica, que é possível entregar, para um conjunto grande de problemas, uma solução mais simples.

De maneira tímida no meu pequeno mundo é o que eu tenho tentado fazer já faz alguns bons anos, trazendo um pouco do senso crítico tentando não me apaixonar muito pelas coisas que são amplamente divulgadas ou vendidas, um olhar mais cético nestas soluções silver bullet e praticamente averso à complexidades desnecessárias.

Se esse tipo de pensamento tocou seu coração, sempre publico algo nessa linha, então só me seguir lá no medium.

Um abraço!

Carregando publicação patrocinada...
6

Excelente artigo. Cara a evolução da web é uma coisa muita louca, por um lado toda essa complexidade é necessaria, pois estamos usando utilizando tecnologias feitas para lidar com texto em experiencias multi-midias altamente interativas - que obviamente não foram feitas para isto.

Por outro lado é apenas depois de criar essas soluções complexas e bizarras que conseguimos enxerguar com clareza o problema real que estamos resolvendo e propor soluções muito mais simples, mas ai muito vezes é dificil mudar porque já existem milhares de soluções, feitas em cima dessas soluções e por ai vai...E ai o que temos são longos ciclos de tecnologias revolucionárias sendo substituida umas atrás da outra.

No início dos anos 2000, o XML era considerado a maior novidade do mercado, prometendo revolucionar a forma como lidamos com dados na web. O XML e todas as tecnologias adjacentes prometiam uma maneira simples e agnostica de desenvolver aplicações web altamente sofisticadas.

Ao longo do tempo, as complexidades associadas à gestão e escrita de arquivos XML, bem como dos algoritmos necessário para processa-los, acabaram dando lugar a tecnologias mais simples e agnosticas. Como JSON/REST que caracterica o início da "era moderna" do desenvolvimento web a partir do anos 010s e é caracterizada pelos frameworks JavaScript.

É importante notar que ascenção web moderna foi impulsionada justamente pela busca por simplicidade em comparação ao XML/SOAP. Contudo, assim como aconteceu com o XML, essas tecnologias começaram simples mas foram se tornando cada vez mais complexas à medida que cresciam juntamente com as demandas do usuários.

Hoje é ridículo ver a quantidade absurda de arquivos de configuração necessários para um simples frontend - estático. Chegou-se num ponto onde a complexidade superou em muito a época do XML. Algo irônico quando pensamos que a mudança para estas tecnologias ocorreu justamente em busca de simplicidade, mas natural se pensarmos em como a Web continuou evoluindo.

E agora? Parece que a decada de 020 também é um novo ciclo nesta eterna corrida entre gato e rato. A simplicidade e agnosticismo estão voltando à tona com força total através da ferramentas que você citou: Astro, htmx, Alpine.js e Tailwind.

Estou feliz em ver essa tendência rumo à morte do 'desenvolvimento web moderno' tal qual conhecemos hoje. Mas vale lembrar que o processo vai ser longo e doloroso, mas acredito sim que já está em andamento.

Seu texto me lembrou, um pouco este outro aqui, recomendo sua leitura caso não conheça.

https://www.bitecode.dev/p/hype-cycles

1

Nossa cara, eu não tinha visto não! Excelente texto! É bem isso mesmo, muito interessante a maneira como ele expôs o problema.

Muito obrigado pelos seus pontos também, é isso... obrigado pela contribuição, bem rica aqui e me ajudou a ter mais argumentos ainda e ter uma visão mais clara sobre o assunto sobre outras perspectivas.

4

Uma das melhores postagens dos últimos tempos.

É o que eu falo sempre que as pessoas estão complicando muito o que não precisa e estão fazendo isso porque alguém disse que é bom, e elas seguem cegamente.

Levanta pontos importantes. Mas o mais importante é que nem tudo deveria ser web.


Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

4

Bom, desde que comecei a trabalhar na área (no primeiro estágio em meados de 1999), percebi que as coisas costumam ser cíclicas.

Sempre que há um grande movimento em direção a determinada coisa (seja tecnologia, framework, modo de fazer as coisas, etc), ou seja, quando começa a ser amplamente usado, começam a aparecer também os abusos: o uso errado, e/ou em situações nas quais aquilo não é a melhor solução. As pessoas começam a fazer por moda, por estarem no automático e por não saberem que existem outras formas mais simples. Hoje em dia é pior, aparecem os influencers de plantão que só falam daquilo, e muita gente começa a achar que é a única opção disponível (ou que é "melhor" só porque "é mais novo").

Aí muita gente começa a perceber os problemas e busca alternativas. E não é raro que a alternativa seja alguma coisa antiga, que foi esquecida porque não tinha hype em cima dela, mas que resolve o problema específico de maneira muito melhor. Até aqui não seria problema, mas daí resolvem dar aquela repaginada para parecer algo moderno, dão nomes mais "cool" e isso passa a ser a nova moda. Aí todo mundo começa a adotar pra tudo (até pra casos em que não é a melhor solução) e o loop continua...

Foi assim com SOA, que deu lugar ao REST e hoje muita gente acha que JSON é o único formato existente pra tudo (e que API é só "um site que retorna JSON", sendo que na verdade o termo é bem mais amplo que isso). Já vemos inúmeros casos de abuso por aí, como JSON's gigantes sendo usados só porque "é fácil para humanos lerem", mesmo quando os dados não precisam ser lidos por humanos. Para isso existem outros formatos, como o ProtoBuf, por exemplo (e cada um tem prós e contras, e vc deveria analisar isso em vez de sempre usar a mesma coisa pra tudo).

Foi assim também com os frameworks JS e a onda de SPA's, e agora estão voltando a perceber que SSR é a melhor opção para muitos casos - de novo, não é que um sempre será melhor pra tudo, é caso de olhar os prós e contras e escolher de acordo com a necessidade. CSR e SSR tem seus usos em cada situação, e usar sempre um deles pra tudo é a abordagem errada, na minha opinião. Por isso espero que não ocorra o extremo, de acharem que SPA é a raiz de todos os males e matem de vez, pois aí o ciclo se repetiria de novo...

Como diria um amigo meu: "Você está no ponto A e abre um caminho para o ponto B porque acha que lá é mais bonito. Você percebe que B não é exatamente o que você esperava e deseja voltar ao A. Você tem duas opções: 1) voltar pelo mesmo caminho até A ou 2) Abrir um novo caminho e parar em C achando que está em A. SSR é a segunda opção."

Enfim, eu realmente lamento que nossa área seja assim, tão cíclica e suscetível a modas. O ideal seria que as pessoas soubessem diferentes formas de fazer as coisas (com e sem framework, usando A ou B, etc), analisasse os prós e contras de cada uma e decidisse qual usar baseado em cada caso específico. Senão continuaremos eternamente neste ciclo de aderir à moda, abusar dela, perceber que não serve pra tudo, voltar para o que se usava antes (com nomes novos pra parecer que é algo novo), e isso passa a ser a nova moda, que é abusada, substituída por outra coisa antiga com nome novo, etc...

2

Eu concordo muito com você...acrescentando só na sua visão, talvez não seja algo apenas da nossa área. O Marketing é algo forte e as big techs tem uma grande influência nisso... acho que faz parte mesmo, tudo é uma questão de como vender...

Nós mesmos não estamos livres disso, provavelmente a gente já caiu nessa armadilha sem nem perceber.

O ponto é que a gente acaba sendo uma voz com pouco alcance e há aqueles que compram a nossa briga, dentro da nossa equipe, dentro da empresa que estamos trabalhando e já é algo.

Se vier um novo hype e as pessoas forem para as novas tendências por questões de modismo, pelo menos que seja algo que simplifique né...Pq de complexidade, acho que já deu...

3
2

Texto muito bacana, porém não entendi ao certo onde você quis chegar com base no título.

O que eu gostaria de acrescentar é pra você começar a publicar em outras plataformas sem ser o Medium já que atualmente tudo no Medium tem paywall e fica bem chato, principalmente pra ler algo, já que o próprio medium barra sua leitura :(

1

Fala @thayto, obrigado pelo feedback. Cara, na verdade não sabia que estavam barrando todos os conteúdos.. abri aqui na anonima e parece que é como o natanael comentou, fechar a janela.

Mas... todos os posts que eu faço no medium são publicados no meu site tb, então lá consegue ver também, zero ads. https://eduardoottaviani.com.br/

Abs

0
2

Cara, gostei muito do seu post. Eu ainda sou iniciante e estou estudando o front-end, mas inevitavelmente tive essa mesma impressão que tudo parece ser mais complexo do que realmente deveria ser.

Quando comecei aprender React, na minha ignorânica, eu me perguntava: Pra quê aprender isso? Qual problema isso resolve? Não era melhor utilizar apenas HTML, CSS, JS?

Hoje eu entendo sobre essa questão de componentização (e etc...) que justifica o uso de uma biblioteca como o React. Porém, a cada nova lib/framework que você decide acoplar, mais problemas surgem em decorrência dessa escolha. E é aí que tudo começa a ficar mais complexo do que realmente deveria.

Tenho notado a ascensão do Astro, e acredito que muitos o aderirão dentro dos próximos anos, incluse eu.

Resumindo, parabéns pelo seu post! Acredito que uma frase que resuma muito bem esse assunto é a do artista Leonard Thiessen:

"A simplicidade é o último grau de sofisticação".

1

Ahhh que comentário bacana! Você mesmo nessa fase de aprendizado inicial já consegue perceber significa pra mim que já tem um olhar mais crítico e tem um ótimo potencial pra ser um programador agnostico. Parabéns.

Eu uso essa frase inclusive na home do meu projeto de componente Js! Só que achava que era do Leonardo Da Vinci, agora não tenho certeza.

Gabriel, concordo com o que você disse, acho que vão ter bibliotecas que talvez resolvam o seu problema de UI com relação à interação do usuario e atualizaçao do html, e voce poderia fazer isso apenas em partes da sua aplicação.

Dessa forma, se o seu site foi feito no magento, wordpress, ruby on rails, laravel, o que for, voce ainda teria um front-end bem organizado utilizando dessas libs para fazer a componentização. Mesmo no mundo node, voce tem template systems pra rodar no servidor: como o pug, nunjucks, handlebars, mustache etc.

Essa é uma maneira de separar a renderização via server side, e as funcionalidades no client, utilizando de tecnicas de componentização que aprendemos com os frameworks e hoje podem ser feitas inclusive sem bibliotecas, utilizando os bundlers pra pegar os arquivos das pastas dos componentes.

React, Angular, Vue, Svelte, Solid e outros, acabam se tornando muito mais Frameworks do que bibliotecas pra mim, pq uma vez que escolhe esse caminho, voce fica preso ao ecossistema... o escopo de uma biblioteca pra mim deveria ser muito menor, então não considero nenhuma destas bibliotecas mais...

Talvez surjam algumas alternativas pra trabalharmos com web components, como o Lit por exemplo, trabalhando na arquitetura Islands.

Obrigado pelo feedback, muito sucesso na sua tragetória!

2
2

Finalmente alguém que sente como eu essa alta complexidade no front (e muitas vezes no back) desnecessárias!
Você deve se expressar como um programador com ideias boas e não por ser capaz de entender a complexidade do framework.

2
0

Fala Luccas33, voce já usou em produção alguma vez? Como faz pra comprovar sua eficácia?

Acho que você me deu uma idéia...

1

Tem um projeto em produção de uso interno da firma.

Sem com eficácia vc quer dizer performance de execução, então eu não testei. O objetivo desse framework não é esse, apesar de que não tem compilação/interpretação, é JS puro. Naturalmente é pra ser leve.
Não fica renderizando os componentes desnecessariamente e vc pode atualizar apenas a parte que desejar. Isso também conta muito.

Mas se vc quis dizer eficaz no desenvolvimento, então sim. A proposta é ser um framework simples com view dinâmica e com separação entre a view e o controller, que facilita o fluxo da aplicação e a organização do código. É conceitualmente eficaz.

Pra provar isto eu teria que escrever uma mesma tela complexa em diversos frameworks para comparar a complexidade/legibilidade. Talvez eu faça qualquer dia com Angular e React.

Tem um CRUD de exemplo no projeto caso você queira conferir. Na minha percepção ficou simples.

De qualquer forma, o objetivo do cleanjs não é ser usado em produção. É uma prova conceitual.

1
1
1
2

nao precisa voltar tanto no tempo

o que ele quis dizer é que frameworks SPA estão sendo substituidos por SSR e até mesmo Sem framework algum (mas claro, com alguma lib de suporte, como o htmx)