Como não ficarmos presos ao framework?

[victormiguez]

Fala pessoal, beleza?

Vocês já pararam para pensar como estamos presos aos frameworks? Hoje
conseguimos fazer uma boa separação da lógica de negócio e visualização.
Porém se decidirmos desenvolver uma SPA acabamos ficando presos ao framework
escolhido.

Por exemplo: Se defirmos utilizar React, "automaticamente" cairemos para o
react-router, que deve sempre receber um componente React para fazer a renderização
da tela. E por fim o framework que deveria cuidar apenas da exibição de componentes
agora está envolto por um ecossistema cheio de plugins.
Se levarmos em conta os geradores como create-react-app ou vue-cli o caso
fica ainda pior, pois já estaremos com o "pacote fechado".

O que eu quero dizer é: Pense que temos uma aplicação que seja uma área
administrativa em que os módulos não se conversam, teoricamente não haveria
problema se o módulo /clientes fosse feito com React e /estoque com Vue.
Porém na prática isso fica completamente inviável.

Ou seja, para mim agora o ideal seria que cada um desses plugins fosse agnostico
ao framework utilizado e que sempre que chegarmos na camada de visualização o
componente receba um objeto js puro e cuide da renderização.

Já pensei até na possibilidade de não fazer uma SPA, e cada módulo do projeto
seja um novo app, porém isso adicionaria outras complexidades que tornam isso
inviável.

Acham que faz sentido o que eu quero? Estou criando complexidade onde não existe?

Lembrando que isso não quer dizer que eu queira por em prática essa junção de
frameworks. O que está realmente me incomodando é o fato de que eu estaria
preso ao framework escolhido.

[mikejavier]

Pelo que eu entendi seria mais ou menos ter um "Framework Universal" ???
Mesmo assim ficaria esquisito ter módulos mesmo que nao conversem entre si, feitos com sintaxes diferentes, que seriam renderizados no browser de formas diferentes... isso a nivel de manutenção seria um caos.

Eu tenho esperanças em que chegaremos ao ponto de construir spa com a mesma simplicidade que os FW hj nos permitem porem em vanilla. 🤗

[filipemerker]

Cara, acho bacana o tema. Vou compartilhar minha visão sobre essa questão, mas talvez fique extenso, peço paciência hahah.

TL;DR

1. Certifique-se de que tu não estejas tecnicamente preso ao framework, por culpa de não conhecer a linguagem. Pense bem: essa aplicação precisa mesmo de um framework? Por que? Qual framework? Qual problema essa framework resolve e por que ele é melhor opção para esse caso?
2. Certifique-se de que a interoperabilidade entre componentes é uma necessidade real da aplicação. Pense bem: não existe nenhuma forma de fazer isso usando o ecossistema do meu framework ou descendo ao nível da linguagem? Isso vai agregar valor ao seu sistema? Se você realmente precisar disso, então pesquise as melhores práticas para o seu caso (listo algumas no texto).
3. Seja sempre consistente com o ecossistema que você montou. Isso melhora a performance da sua aplicação, facilita que outros desenvolvedores deem manutenção, e deixa seu código mais profissional, legível e organizado.

O problema técnico

Vocês já pararam para pensar como estamos presos aos frameworks?

Acho que podemos começar a responder essa pergunta desta forma: os desenvolvedores front-end, em geral, não conhecem Javascript.

Muita gente, por culpa de seguir o hype dos frameworks antes de conhecer bem o Javascript, está tecnicamente presa ao framework. Esse é o primeiro problema possível.

Hype Driven Development

Foi assim com o prototypejs, mootools, coffeescript, jQuery, e tantos outros. Especialmente com esse último, inclusive, surgiu um fenômeno chamado "desnevolvedor jQuery". O cara que manjava tudo da documentação da lib, mas nunca leu a spec da linguagem.
Não sabe o que é DOM, não entende property accessors, não sabe o que é um call ou apply, nunca ouviu falar de design patterns, nunca leu nada no MDN, etc.

Foi nessa época que o gênio Eric Wastl criou o Vanillajs, uma zoada com essa galera. Também surgiram iniciativas bacanas como o you might not need jQuery dos Adam Schwartz e Zack Bloom e muitos outros projetos bacanas lembrando o pessoal da importância de conhecer a linguagem.

Quando essa onda das libs baixou, entrou a era dos frameworks. Lá por 2013-14 o Angular bombou e, com ele, se popularizou de uma forma massiva essa ideia de MV* para os devs front-end. Vários outros caras surgiram e bombaram nesse contexto, como Knockout, Ember, Backbone, etc.

Acho que esses caras foram muito importantes para a popularização da ideia de design patterns no desenvolvimento front-end. A partir dali, a maioria das pessoas começou a pensar no front-end em termos de aplicação e não apenas um arquivo de scripts e uma folha de estilos dando vida a um arquivo de marcação.

Por isso, acho que são dois lados de uma mesma moeda. Com essa onda, os frameworks evoluiram. Hoje entendemos melhor quais as boas práticas e os design patterns para webapps REST escaláveis, por exemplo, automatizamos tudo com webpack, criamos scaffolds fantásticos como os citados create-react-app ou vue-cli, e muito mais. Isso é ótimo. Mas, por outro lado, TUDO virou webapp. Temos devs overengineering qualquer projeto que botam as mãos, usando angular para carregar conteúdo estático em landing pages, usando routers para fazer SPA sem necessidade nenhuma e coisas que até o diabo duvida.

A solução

Acredito que a solução para o problema de ontem é a mesma para hoje.
É preciso achar um equilíbrio saudável entre fluência na linguagem e no ecossistema da linguagem.

Ser viciado em frameworks e libs é tão prejudicial quanto não usá-los nunca. Acho impossível ser um bom desenvolvedor se tu não fores capaz de descer ao nível da linguagem e ter uma boa noção de lógica de programação.
Mas, por outro lado, os melhores desenvolvedores que eu conheço, nunca fazem trabalho burro. Sabem quando automatizar as coisas, quando utilizar soluções prontas da comunidade. Sabem que não faz sentido descer ao nível de um XMLHttpRequest se tu puderes usar um axios, por exemplo, e sabem que não faz sentido construir uma grande aplicação só com Javascript puro, quando se tem excelentes soluções de frameworks disponíveis.

Frameworks

O que está realmente me incomodando é o fato de que eu estaria
preso ao framework escolhido.

Quanto a esse ponto, que me parece ser o problema central do post do @victormiguez, sobre a interoperabilidade de determinados módulos/serviços e estarmos "presos" a determinados ecossistemas:

Acho que tem muito a ver com uma questão de análise de requisitos e entendimento de negócio do produto que tu está desenvolvendo, saca? Fazer as coisas por um motivo objetivo e não "just because"...

Especificamente sobre a questão da interoperabilidade, vou listar três alternativas (existem muitas mais):

Microservices

Em devOps existe um padrão de arquitetura chamado "microservices". Facebook, Twitter, Spotify, e vários outros grandes produtos digitais usam. Essa arquitetura permite implementar diferentes soluções com diferentes tecnologias dentro de uma mesma aplicação. Dê uma pesquisada.

Interoperability

Também existem cases de aumento de performance MISTURANDO frameworks, como por exemplo, mostra o Dave Smith nessa talk muito bacana. Claro que essas misturas precisam sempre resolver a algum problema específico. Não vejo muito sentido em misturar Vuejs e React, por exemplo.

Compatibility layer

Também existe a possibilidade de se fazer uma cama de compatibilidade ENTRE frameworks, como inferno-compat, ou o preact-compat que fazem com que eles sejam compatíveis com o React ou o ng-react que funciona entre Angular e React.

Por fim...

Soluções existem, mas, como eu disse, é muito uma questão de definições de negócio. O natural é que o desenvolvedor seja consistente com o ecossistema que escolheu. Não tem nenhum motivo para utilizar o director como router da minha aplicação Vue, por exemplo. O vue-router foi pensado desde o começo para funcionar em um ecossistema Vue e, a princípio, nenhum outro componente vai funcionar tão bem quanto ele. O mesmo para react-router ou angular-ui-router. Para fazer componentes mais performáticos, os mantenedores vão sempre adotar soluções que funcionem melhor no SEU ecossistema. Pensar em todos os edge cases seria impraticável.

Por isso, acho que é muito mais um questão de ser consistente com o ecossistema do que de estar "preso" a ele.

Espero ter ajudado de alguma forma, valeu!

[victormiguez]

@mikejavier não seria um "framework universal", mas sim a possibilidade mudar de
framework sem ter que reescrever toda a aplição de uma vez.
Um exemplo: Você tem uma aplicação feita com Angular 1.x que ainda está sendo
mantida e desenvolvida. Então o time decide que a aplicação será atualizada, passando
a utilizar o React. É inviável que você vá reescrevendo os módulos aos poucos e que
os frameworks tenham uma boa interoperabilidade.

[victormiguez]

@filipemerker muito obrigado pela resposta detalhada! Só preciso de um tempo para
processar tudo que você disse, já estou vendo a talk do Dave Smith. Valeu mesmo pelo
conhecimento compartilhado!

[bernardodiasc]

Recomendo esse video @victormiguez --> https://www.youtube.com/watch?v=T1YWB9N166A Browser Framework Fundamentals - Yoshua Wuyts

Ele mostra as características principais de um framework e como fazê-las de modo modular.

[filipemerker]

@victormiguez Legal cara, esse vídeo é muito bom, abre bem a mente para esse tipo de coisa.

Adicionei um too long; didn't read no meu post, aqui que ajuda bem a sintetizar a ideia do texto, da uma lida ali depois! Valeu!