O planejamento de software para essa vida útil é difícil, porque não sabemos o que o futuro nos reserva. Um pouco de contexto: Java foi publicado em 1995, 21 anos atrás. O XmlHttpRequest foi disponibilizado pela primeira vez como uma extensão proprietária para o Internet Explorer 5, publicado em 1999, há 17 anos. Demorou cerca de 5 anos até ficar disponível em todos os principais navegadores. Os 20 anos em que você está tentando olhar para frente são apenas sobre o tempo em que os aplicativos da Web ricos já existiram.
Algumas coisas certamente permaneceram as mesmas desde então. Houve um strong esforço de padronização e a maioria dos navegadores está em conformidade com os vários padrões envolvidos. Um site que funcionava em navegadores há 15 anos ainda funcionaria da mesma forma, desde que funcionasse porque segmentava o subconjunto comum de todos os navegadores, não porque usasse soluções alternativas para cada navegador.
Outras coisas surgiram e desapareceram - com destaque para o Flash. Flash teve uma variedade de problemas que levaram à sua morte. Mais importante ainda, foi controlado por uma única empresa. Em vez de competir dentro da plataforma Flash, houve competição entre o Flash e o HTML5 - e o HTML5 ganhou.
A partir dessa história, podemos reunir algumas dicas:
-
Mantenha a simplicidade: faça o que funciona agora, sem precisar usar nenhuma solução alternativa. Esse comportamento provavelmente ficará disponível por muito tempo no futuro por razões de compatibilidade com versões anteriores.
-
Evite confiar em tecnologias proprietárias e prefira padrões abertos.
O mundo do JavaScript hoje é relativamente volátil, com um alto fluxo de bibliotecas e frameworks. No entanto, quase nenhum deles terá importância em 20 anos - o único “framework” que tenho certeza de que ainda será usado até então é o Vanilla JS .
Se você quiser usar uma biblioteca ou ferramenta porque realmente facilita muito o desenvolvimento, primeiro certifique-se de que ela é baseada nos padrões bem suportados de hoje. Você deve então baixar a biblioteca ou ferramenta e incluí-la no seu código-fonte. Seu repositório de código deve incluir todo o necessário para que o sistema seja executado. Qualquer coisa externa é uma dependência que pode quebrar no futuro. Uma maneira interessante de testar isso é copiar seu código para um pen drive, ir para um novo computador com um sistema operacional diferente, desconectá-lo da Internet e ver se você consegue que seu frontend funcione. Contanto que seu projeto seja composto de HTML simples + CSS + JavaScript e talvez algumas bibliotecas, é provável que você passe.