[ Razor Pages >=? Java Server Pages/Faces ]

Na minha opinião você só aprende tecnologia legada a fundo quando a empresa pede para você manter algo legado, ou quando tem uma vaga de emprego com esse requisito como critério eliminador.

De qualquer forma, você precisa saber um pouco sobre as tecnologias antigas, para saber conversar e comparar com as novas. Seu objetivo é emprego? Dê uma estudada no que está pedindo para poder falar com o entrevistador. Só se aprofunde quando achar necessário.

Uma coisa interessante sobre isso: Legado, apesar da demonização da palavra, é o objetivo final de todo sistema. Sistema legado é um sistema de sucesso, que está sendo usado por muitos anos e gerou muito valor a empresa e ainda continua gerando, e provavelmente levou ela a outro patamar pela automatização que o sistema trouxe. Manter um sistema legado é uma tarefa de alto valor que pode ser muito interessante se tu aplicar práticas corretas de engenharia de software, mesmo que a tecnologia não seja a mais recente.

Pensava que tecnologia legada é mantida pelo mercado há tempo, como razor que nasceu desde o .net framework, assim como jsp que vive desde os primórdios do Java.

Mas nao sei se vale a pena aprender jsp, com spring.

Exatamente.
Já atuei em sistemas legados que estão no ar há mais de 20 anos e continuam tendo alguma evolução.

Bem, se for seguir esse raciocínio, então vc considera que React (lançado em 2013, ou seja, há 10 anos) e Node (lançado em 2009) são “tecnologia legada”? Só pra citar duas coisas que ainda estão na moda. Afinal, 10 anos na nossa área já pode ser considerado “muito tempo atrás”, dada a velocidade com que as coisas mudam.

Falando de linguagens em si, a maioria das mais usadas hoje em dia foram criadas há mais de 10 anos. Só pra ficar em alguns exemplos, temos Rust (2013), TypeScript (2012), C# (2000), Java (1995), JavaScript (1995), Python (1991), C++ (1983) e C (1972). Todas ainda são amplamente usadas. O fato de serem antigas as torna “legado”? Claro que até hoje continuam saindo versões novas, mas ainda tem muito projeto que não atualizou (tem bastante coisa em Java <= 11, por exemplo).

As pessoas tem que parar com esse pensamento de que algo é ruim só porque é velho, ou que algo é bom só porque é novo. Existem casos e casos, tem coisa velha que ficou ultrapassada porque surgiu algo melhor, mas tem coisa antiga que continua funcionando muito bem. Assim como tem coisa nova que merece atenção, mas tem novidades que são só mais do mesmo ou até pioram o que já existia.

Por fim, não tenho estatísticas confiáveis, mas eu diria que tem muito projeto antigo que ainda precisa de manutenção. Muitas vezes eles não são atualizados porque sairia tão caro que não vale a pena: imagine um sistema com milhares/milhões de linhas de código, que evoluiu por vários anos, com trocentas regras de negócio e tratamentos de erros que foram ocorrendo ao longo do tempo. Muitos desses detalhes foram feitos por pessoas que nem trabalham mais lá, são aquelas famosas linhas “misteriosas” que funcionam e todo mundo tem medo de mexer. O risco e o custo de mudar tudo pra uma tecnologia da moda, só porque “X é antigo então é ruim, muda pra Y que é bom porque é novo”, é enorme. Só fanboys irresponsáveis bancariam tal mudança sem uma boa justificativa, o mais adequado é ser pragmático e manter o que funciona. Reescrever tudo não é nada simples.