Desenvolvimento de aplicativos da Web para longa vida útil (mais de 20 anos)

160

Atualmente, estou desenvolvendo um aplicativo da web para o planejamento de terras do governo. O aplicativo é executado principalmente no navegador, usando o ajax para carregar e salvar dados.

Vou fazer o desenvolvimento inicial e depois me formar (é um trabalho de estudante). Depois disso, o restante da equipe adicionará o recurso ocasional, conforme necessário. Eles sabem como codificar, mas na maioria são especialistas em planejamento de terras.

Considerando o ritmo em que as tecnologias Javascript mudam, como posso escrever um código que ainda funcionará daqui a 20 anos? Especificamente, quais bibliotecas, tecnologias e idéias de design devo usar (ou evitar) para tornar meu código à prova de futuro?

Dan
fonte
94
Comecei a programar no Fortran no final de 1966, então tive tempo de sobra para pensar exatamente sobre esse tipo de problema. Se você encontrar uma resposta até 50% confiável, entre em contato. Enquanto isso, basta pensar no quase-certa obsolescência inevitável como "segurança no emprego" :)
John Forkosh
11
Nada dura para sempre no Software Engineery. HOST apenas nos bancos e porque ninguém se atreve a atualizar esses sistemas críticos. Bem, acho que o programa em execução no Voyager também conta.
LAIV
9
@Laiv Algum tempo atrás, trabalhei em aplicativos de transferência de dinheiro para o Bankers Trust usando as mensagens Swift em execução no Vax / VMS. Alguns anos depois, o Swift eol'ed (no final da vida útil) todo o suporte ao VMS. Rapaz, isso causou alguns problemas ... e me deu mais um contrato na BTCo. Como eu disse acima, "segurança no emprego" :). Enfim, meu argumento é que mesmo aplicativos críticos do mercado financeiro não são imunes à obsolescência.
John Forkosh
102
Que tal "Escreva um código que o próximo desenvolvedor possa entender"? Se e quando o código se tornar obsoleto a ponto de eles precisarem encontrar um programador para atualizá-lo, o melhor cenário é que eles entenderão o que seu código está fazendo (e talvez por que certas decisões foram tomadas).
David Starkey
38
Basta usar HTML simples, sem JS, sem plugins, nada sofisticado. Se funcionar no Lynx, é bom para todos os tempos.
Gaius

Respostas:

132

Planejar software para uma vida útil tão difícil é difícil, porque não sabemos o que o futuro reserva. Um pouco de contexto: o Java foi publicado em 1995, há 21 anos. O XmlHttpRequest ficou disponível como uma extensão proprietária do Internet Explorer 5, publicada em 1999, há 17 anos. Demorou cerca de 5 anos até se tornar disponível nos principais navegadores. Os 20 anos que você está tentando olhar para o futuro são praticamente o tempo em que aplicativos da Web ricos existiram.

Algumas coisas certamente permaneceram as mesmas desde então. Houve um grande esforço de padronização, e a maioria dos navegadores está em conformidade com os vários padrões envolvidos. Um site que funcionou nos navegadores há 15 anos ainda funcionará da mesma forma, desde que funcionasse porque tinha como alvo o subconjunto comum de todos os navegadores, não porque usava soluções alternativas para cada navegador.

Outras coisas vieram e foram - principalmente o Flash. O Flash teve vários problemas que levaram ao seu desaparecimento. Mais importante ainda, era controlado por uma única empresa. Em vez de competição dentro da plataforma Flash, havia competição entre Flash e HTML5 - e o HTML5 venceu.

A partir desta história, podemos reunir algumas pistas:

  • Mantenha as coisas simples: 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 motivos de compatibilidade com versões anteriores.

  • Evite confiar em tecnologias proprietárias e prefira padrões abertos.

O mundo JavaScript hoje é relativamente volátil, com um alto fluxo de bibliotecas e estruturas. No entanto, quase nenhum deles importará em 20 anos - a única “estrutura” que tenho certeza de que ainda será usada até então é o Vanilla JS .

Se você deseja usar uma biblioteca ou ferramenta porque realmente facilita muito o desenvolvimento, primeiro verifique se ele foi desenvolvido com base nos padrões bem suportados de hoje. Você deve fazer o download da biblioteca ou ferramenta e incluí-la no seu código-fonte. Seu repositório de código deve incluir tudo o que é necessário para executar o sistema. Qualquer coisa externa é uma dependência que pode se romper no futuro. Uma maneira interessante de testar isso é copiar seu código em um pen drive, acessar um novo computador com um sistema operacional diferente, desconectá-lo da Internet e verificar se você pode fazer com que seu front-end funcione. Contanto que seu projeto consista em HTML + CSS + JavaScript simples e talvez em algumas bibliotecas, você provavelmente será aprovado.

amon
fonte
4
Aplicativos de grande escala não são mantidos no vanilla js, a partir de agora. O ES6 já corrige o problema, mas há uma razão pela qual o fluxo ou o TypeScript estão ganhando popularidade.
Andy
34
@DavidPacker Absolutamente, TypeScript etc. são ótimos e facilitam o desenvolvimento. Mas assim que eu introduzo um processo de compilação, todas as ferramentas necessárias para o processo de compilação se tornam dependências: NodeJS, Gulp, NPM - quem disse que o NPM continuará online em 20 anos? Vou ter que executar meu próprio registro para ter certeza. Isto não é impossível. Mas em algum momento, é melhor deixar de lado as coisas que facilitam o desenvolvimento apenas imediatamente, mas não a longo prazo.
amon
30
@DavidPacker Existem muitas linguagens dinâmicas e, surpreendentemente, muitos sistemas bem-sucedidos foram criados com Smalltalk, Ruby, Perl, Python, mesmo com PHP e JS. Enquanto linguagens de tipo estatico tendem a ser mais sustentáveis, enquanto linguagens dinâmicas tendem a ser melhores para prototipagem rápida, não é impossível escrever JS sustentável. Na ausência de um compilador, a alta habilidade mediana na equipe, a habilidade e a ênfase extra na organização clara do código se tornam ainda mais cruciais. Pessoalmente, acho que os tipos facilitam tudo, mas não são uma bala de prata.
amon
4
Acabei de ler "pegue usb e teste em outra máquina"? Por que não apenas ativar o virtualbox ou usar o modo de navegação anônima (com o ethX desativado).
Kyslik
5
Não tenho certeza de que JS de baunilha será uma coisa certa daqui a 20 anos. Sua história foi difícil e experimental, e recebeu uma boa quantidade de lixo ao longo do caminho, mesmo que tenha surgido como uma linguagem agradável e eficaz (eu pessoalmente prefiro o JavaScript ou o TypeScript). Não é difícil imaginar que os fornecedores possam querer abandonar parte ou todo esse lixo, se isso significa começar a oferecer uma nova linguagem alternativa - como o Google parecia estar propondo com o Dart, por mais que pareça não ter ido a lugar algum - ou descontinuando e eliminando partes de JS.
KRyan
178

O que é ainda mais importante que o seu código que sobrevive por 20 anos é que seus dados sobrevivem por 20 anos. Provavelmente, é isso que vale a pena preservar. Se for fácil trabalhar com seus dados, será fácil criar um sistema alternativo com as novas tecnologias.

  • Portanto, comece com um modelo de dados claro e bem documentado.
  • Use um sistema de banco de dados estabelecido e bem suportado, como Oracle [1] ou SQL Server.
  • Use os recursos básicos, não tente espremer novos e chamativos.
  • Prefira simples ao invés de inteligente .
  • Aceite que a manutenção futura possa custar aspectos como desempenho. Por exemplo, você pode ficar tentado a usar procedimentos armazenados, mas eles podem limitar a manutenção futura se impedirem que alguém migre o sistema para uma solução de armazenamento mais simples.

Depois disso, a aplicação do futuro é mais simples, porque é um invólucro do modelo de dados e pode ser substituída se, em 10 anos, ninguém mais usar Javascript, por exemplo, e você precisar migrar o aplicativo para WASM ou algo assim. Manter as coisas modulares, menos interdependentes, facilita a manutenção futura.


[1] A maioria dos comentários a essa resposta tem uma forte posição contra o uso do Oracle para um banco de dados, citando muitas razões perfeitamente legítimas pelas quais o Oracle é uma dor de trabalhar, possui uma curva de aprendizado acentuada e sobrecarga de instalação. Essas são preocupações totalmente válidas ao escolher o Oracle como um banco de dados, mas, no nosso caso, não estamos procurando um banco de dados de uso geral, mas um onde a principal preocupação seja a manutenção . A Oracle existe desde o final dos anos 70 e provavelmente será suportada por muitos anos, e há um enorme ecossistema de consultores e opções de suporte que podem ajudá-lo a mantê-lo funcionando. Esta é uma bagunça muito cara para muitas empresas? Certo. Mas ele manterá seu banco de dados em funcionamento por 20 anos ? Muito provável.

Avner Shahar-Kashtan
fonte
141
Sinto muito, mas tenho que dizer isso. Se você usa o Oracle, está atirando no pé de todos no que diz respeito a "fácil de trabalhar". Não é fácil trabalhar com o Oracle nem um pouco. Uma grande quantidade de funcionalidades que o SQL Server, PostgreSQL e, provavelmente, até o MySQL simplificam, o Oracle não possui ou dificulta demais. Eu nunca tenho tantos problemas estúpidos com outros bancos de dados quanto eu tenho com o Oracle; mesmo apenas configurando o cliente é uma enorme dor no traseiro. Até mesmo pesquisar no Google é difícil. Se você deseja "fácil de trabalhar", fique longe do Oracle.
jpmc26
4
+1 para manter os dados o mais simples possível. Use SQL padrão para isso, por exemplo, use OUTER JOIN em vez do operador + específico do oracle . Use layouts de tabela simples. Não normalize suas tabelas para o nível máximo absoluto. Decida se algumas tabelas podem ter dados redundantes ou se você realmente deve criar uma nova tabela para que todo valor exista apenas uma vez. Os procedimentos armazenados são específicos do fornecedor ? Se sim, então não os use. Não use o recurso hottst do seu idioma atual de escolha: eu já vi mais programas COBOL sem recursos de OOP do que com eles. E isso é totalmente ok.
some_coder
3
@ jpmc26 Concordo com seus sentimentos sobre a Oracle, mas como eu disse, "fácil de trabalhar" não é necessariamente o principal requisito aqui. Eu prefiro uma plataforma solidamente suportada aqui, mesmo que seja difícil trabalhar com isso. Porque quando amortizado em 20 anos, não é tão ruim.
Avner Shahar-Kashtan
8
De fato, evite a Oracle. O único banco de dados existente hoje que provavelmente não parecerá uma má escolha em 20 anos é o Postgresql.
Joshua
3
Eu gostaria de acrescentar que grandes DBMS de código aberto são preferíveis porque há uma boa chance de que eles não morram. Se a Oracle parar de ganhar dinheiro em 10 anos, em 11 anos ela desaparecerá. O PostreSQL parece ser o melhor cavalo para se apostar.
Shautieh
36

A resposta anterior de amon é ótima, mas há dois pontos adicionais que não foram mencionados:

  • Não se trata apenas de navegadores; dispositivos também importam.

    amon menciona o fato de que um “site que funcionava em navegadores há 15 anos ainda funcionaria da mesma forma” , o que é verdade. No entanto, observe os sites criados não há quinze, mas dez anos atrás, que, quando criados, funcionavam na maioria dos navegadores para a maioria dos usuários. Hoje, grande parte dos usuários não poderá usar esses sites, não porque os navegadores mudaram, mas porque os dispositivos o fizeram. Esses sites pareceriam terríveis em telas pequenas de dispositivos móveis e, eventualmente, não funcionariam se os desenvolvedores decidissem confiar no clickevento JavaScript , sem saber que o tapevento também é importante.

  • Você está se concentrando em um assunto errado.

    As mudanças tecnológicas são uma coisa, mas a mais importante são as mudanças de requisitos . O produto pode precisar ser redimensionado, ou pode ter recursos adicionais, ou pode precisar que seus recursos atuais sejam alterados.

    Não importa o que acontecerá com navegadores, dispositivos ou W3C ou ... o que for.

    Se você escrever seu código de uma maneira que possa ser refatorada , o produto evoluirá com a tecnologia.

    Se você escrever seu código de maneira que ninguém possa entendê-lo e mantê-lo, a tecnologia não importará: qualquer alteração ambiental reduzirá seu aplicativo de qualquer maneira, como uma migração para um sistema operacional diferente ou até mesmo uma coisa simples como o crescimento natural de dados .

    Como exemplo, trabalho no desenvolvimento de software há dez anos. Entre as dezenas e dezenas de projetos, havia apenas dois que decidi mudar por causa da tecnologia , mais precisamente porque o PHP evoluiu muito nos últimos dez anos. Não foi nem a decisão do cliente: ele não se importaria se o site usasse namespaces ou fechamentos de PHP. No entanto, mudanças relacionadas a novos requisitos e escalabilidade, havia muitas!

Arseni Mourzenko
fonte
4
A adoção de diferentes tamanhos de tela é um problema geral. O celular é a coisa mais popular no momento, mas se você estiver visualizando este site em uma janela de navegador de tela cheia em uma tela com resolução suficiente, há muito espaço vazio (desperdiçado). Mudar layouts e como as informações são apresentadas para melhor usar os pixels disponíveis nunca realmente aconteceram de maneira inteligente. O celular tornou isso óbvio. Mas pensar na outra direção pode ser mais importante para a questão em questão.
Nulo
9
@ nulo: embora eu concorde com o seu comentário, os sites StackExchange podem não ser a melhor ilustração do seu ponto. Dado os dados a serem exibidos, acredito que os designers / desenvolvedores do StackExchange fizeram um ótimo trabalho ao exibi-los conforme eles precisam ser exibidos, inclusive em monitores grandes. Você não pode ampliar a coluna principal, porque o texto se tornaria muito mais difícil de ler, e você não pode usar várias colunas porque não ficará agradável para perguntas e respostas curtas.
Arseni Mourzenko 13/10
Outro bom exemplo é o evento 'pairar', que costumava ser usado em sistemas de menus. Muitos desses menus falham miseravelmente com dispositivos de toque.
Justas
Você tem 110% (ou mais) de razão sobre os dispositivos, e eu posso fornecer exemplos de décadas mais antigos. No final dos anos 80, trabalhei em aplicativos CICS em execução nos mainframes da IBM e nos terminais síncronos 3270. A região do CICS é análoga aos aplicativos do lado do servidor, enviando dados de tela ao mesmo tempo para os terminais síncronos, que são análogos aos navegadores de dispositivos dedicados. E a programação do CICS foi talvez 80% Cobol, 20% PL / 1. Ambas as línguas são na sua maioria obsoletos hoje em dia, eo aparecimento de estações de trabalho Unix (Sun e Apollo) no início dos anos 1990 CICS praticamente mortos inteiramente
John Forkosh
31

Você não planeja durar 20 anos. Claro e simples. Em vez disso, você muda seus objetivos para a compartimentalização.

O seu banco de dados de aplicativos é independente? Se você tivesse que trocar de banco de dados agora, poderia? A sua linguagem lógica é agnóstica. Se você tivesse que reescrever o aplicativo em um idioma totalmente novo agora, poderia? Você está seguindo boas diretrizes de design, como SRP e DRY?

Eu tenho projetos em execução há mais de 20 anos e posso dizer que as coisas mudam. Como pop-ups. 20 anos atrás, você poderia confiar em um pop-up, hoje você não pode. O XSS não era uma coisa há 20 anos, agora você precisa prestar contas do CORS.

Portanto, o que você faz é garantir que sua lógica esteja bem separada e evitar o uso de QUALQUER tecnologia que prenda você a um fornecedor específico.

Isso pode ser muito complicado às vezes. O .NET, por exemplo, é excelente para expor lógica e método para o adaptador de banco de dados MSSQL que não possui equivalentes em outros adaptadores. O MSSQL pode parecer um bom plano hoje, mas continuará assim por 20 anos? Quem sabe. Um exemplo de como contornar isso para ter uma camada de dados totalmente separada das outras partes do aplicativo. Na pior das hipóteses, você precisará reescrever toda a camada de dados, o restante do seu aplicativo não será afetado.

Em outras palavras, pense nisso como um carro. Seu carro não fará 20 anos. Mas, com pneus novos, novo motor, nova transmissão, novas janelas, novos eletrônicos, etc. Esse mesmo carro pode ficar na estrada por muito tempo.

coteyr
fonte
2
"Se você tivesse que trocar de banco de dados agora, poderia" Isso é quase impossível de realizar se você fizer algo mais que CRUD em uma linha de cada vez.
Jpmc26
1
Muitos ORMs são independentes de banco de dados. Eu poderia dar qualquer um dos projetos nos quais estou trabalhando com garantia que poderia mudar do SQLLite para o MySql e o Postgre sem nenhum esforço.
coteyr
5
E os ORMs deixam de ser ferramentas muito boas para o trabalho quando você faz mais do que simples CRUD em um único registro de cada vez. É por isso que eu o qualifiquei. Eu tentei. À medida que a complexidade da consulta aumenta, até os melhores ORMs se tornam mais problemáticos do que apenas escrever a consulta e, mesmo que você force sua consulta a eles, rapidamente se vê usando otimizações ou recursos específicos do banco de dados.
Jpmc26
1
Defina "complexo". Esta foi uma operação em massa? Incluiu consultas de janela? Subconsultas? CTEs? Sindicatos? Condições de agrupamento complexas? Matemática complexa em cada linha e os agregados? Quantas uniões em uma única consulta? Que tipos de junções? Quantas linhas foram processadas ao mesmo tempo? É certo que dizer algo sobre uma única linha CRUD (lembre-se, isso significa que uma linha por consulta, não por solicitação da Web ou o que seja.) É um pouco exagerado, mas o caminho para quando o ORM se torna mais problemático do que vale é muito mais curto do que você pensa. E as etapas para fazer com que uma consulta funcione bem são frequentemente específicas do banco de dados.
jpmc26
4
"O banco de dados do seu aplicativo é agnóstico? Se você tivesse que trocar de banco de dados agora, poderia? A sua linguagem lógica é agnóstica. Se você tivesse que reescrever o aplicativo em um idioma totalmente novo agora, poderia?" - Este é um conselho ABSOLUTAMENTE TERRÍVEL! Não se restrinja artificialmente ao que você acha que é o maior denominador comum de linguagens de programação ou bancos de dados - isso forçará você a reinventar a roda constantemente. Em vez disso, tente encontrar a maneira NATURAL de expressar o comportamento desejado na linguagem de programação e no banco de dados de sua escolha.
Fgp 14/10
12

As respostas de @amon e algumas outras são ótimas, mas eu gostaria de sugerir que você olhe para isso de outra perspectiva.

Eu trabalhei com grandes fabricantes e agências governamentais que dependiam de programas ou bases de código usados ​​há mais de 20 anos e todos eles tinham uma coisa em comum: a empresa controlava o hardware. Ter algo em execução e extensível por mais de 20 anos não é difícil quando você controla o que é executado. Os funcionários desses grupos desenvolveram código em máquinas modernas centenas de vezes mais rápidas que as máquinas de implantação ... mas as máquinas de implantação foram congeladas no tempo.

Sua situação é complicada, porque um site significa que você precisa planejar dois ambientes - o servidor e o navegador.

Quando se trata do servidor, você tem duas opções gerais:

  • Confie no sistema operacional para várias funções de suporte que podem ser muito mais rápidas, mas significa que o sistema operacional pode precisar ser "congelado no tempo". Se for esse o caso, convém preparar alguns backups da instalação do SO para o servidor. Se algo travar em 10 anos, você não quer enlouquecer alguém tentando reinstalar o sistema operacional ou reescrever o código para funcionar em um ambiente diferente.

  • Use bibliotecas com versão em um determinado idioma / estrutura, que são mais lentas, mas podem ser empacotadas em um ambiente virtual e provavelmente executadas em diferentes sistemas operacionais ou arquiteturas.

Quando se trata do navegador, você precisa hospedar tudo no servidor (ou seja, não é possível usar uma CDN global para hospedar arquivos). Podemos supor que futuros navegadores ainda executem HTML e Javascript (pelo menos para compatibilidade), mas isso é realmente uma suposição / suposição e você não pode controlar isso.

Jonathan Vanasco
fonte
11
Você também deve considerar a segurança. Um sistema operacional sem suporte de 20 anos provavelmente estará cheio de falhas de segurança. Eu trabalhei para uma empresa e herdei esse problema. Órgão governamental, sistemas operacionais antigos (todos virtualizados há muito tempo, felizmente), mas esse era um problema enorme e a atualização era quase impossível devido à necessidade de reescrever completamente o software (centenas de scripts PHP individuais com código espaguete, cada um dos quais tinha chamadas de banco de dados codificado, usando funções obsoletas que o novo driver não suporta / treme).
Se você seguir a rota do sistema operacional, na melhor das hipóteses, poderá esperar que patches de segurança tenham sido aplicados e que futuros mantenedores possam proteger as coisas na camada de rede. Para planejar que as coisas funcionem dessa maneira a longo prazo (especialmente na ausência de um grande orçamento, pois o OP é um estudante), você basicamente precisa aceitar que seu aplicativo e servidor acabarão ficando inseguros. Por exemplo, em 20 anos, eventualmente existirão explorações conhecidas para a versão SSL no servidor ... mas esse SO pode não ser compatível com as versões openssl em 10 anos. Isso tem tudo a ver com minimizar as compensações.
Jonathan Vanasco 13/10
@FighterJet, você sempre pode executar um firewall em um sistema operacional suportado, então você tem poucos riscos além de SQL injeta, etc, que você deveria ter codificado de qualquer maneira.
Ian
@Ian: eu desejo. Havia um firewall. Mas não escrevi o código, herdei. E sim, havia milhares de vulnerabilidades SQL que eu gostaria de ter corrigido, mas o problema real era que o código dependia de uma versão específica do PHP4 (que foi preterida para sempre e está repleta de falhas de segurança) e uma versão específica do driver do banco de dados (que não funcionava em sistemas operacionais mais recentes), o que nos impedia de atualizar para uma versão mais nova do banco de dados ... o ponto é que depender de algo permanecendo o mesmo nem sempre funciona. Digamos que estou feliz por não trabalhar mais lá.
1
@FighterJet Esse é realmente um bom exemplo do que eu queria falar. Você acabou herdando um código que funciona apenas em uma versão específica do PHP4 e um driver que roda apenas em um sistema operacional específico ... então você não pode atualizar o servidor. Eu não defenderia ninguém fazendo isso, mas acontece. -- muito. FWIW, eu concordo com você, mas queria que minha resposta incentivasse o pensamento em torno desses tipos de cenários, e não fiz uma recomendação.
Jonathan Vanasco 18/10
6

O núcleo da maioria dos aplicativos são os dados. Os dados são para sempre. O código é mais descartável , mutável, maleável. Os dados devem ser preservados, no entanto. Portanto, foque na criação de um modelo de dados realmente sólido. Mantenha o esquema e os dados limpos. Preveja que um novo aplicativo possa ser construído sobre o mesmo banco de dados.

Escolha um banco de dados capaz de impor restrições de integridade. Restrições não impostas tendem a ser violadas com o passar do tempo. Ninguém nota. Faça o máximo uso de recursos, como chaves estrangeiras, restrições exclusivas, restrições de verificação e possivelmente disparadores para validação. Existem alguns truques para abusar de visualizações indexadas para impor restrições de exclusividade entre tabelas.

Talvez você precise aceitar que o aplicativo seja reescrito em algum momento. Se o banco de dados estiver limpo, haverá pouco trabalho de migração. As migrações são extremamente caras em termos de mão-de-obra e defeitos causados.

Do ponto de vista da tecnologia, pode ser uma boa ideia colocar a maior parte do aplicativo no servidor e não em um formulário JavaScript no cliente. Você provavelmente poderá executar o mesmo aplicativo na mesma instância do sistema operacional por um período extremamente longo, graças à virtualização . Isso não é muito bom, mas é uma garantia de que o aplicativo funcionará daqui a 20 anos sem custos de manutenção e hardware caros. Ao fazer isso, você tem pelo menos o fallback seguro e barato de continuar executando o código antigo e funcional.

Além disso, acho que algumas pilhas de tecnologia são mais estáveis ​​que outras . Eu diria que o .NET tem a melhor história possível de compatibilidade com versões anteriores atualmente. A Microsoft está falando sério sobre isso. Java e C / C ++ também são realmente estáveis. O Python provou que é muito instável com as mudanças no Python 3. Na verdade, o JavaScript me parece bastante estável, porque quebrar a Web não é uma opção para qualquer fornecedor de navegador. Você provavelmente não deve confiar em nada experimental ou descolado. ("Funky" sendo definido como "eu sei quando o vejo").

usr
fonte
sobre a história de compatibilidade com versões anteriores do .net - acho que não vi um aplicativo java que solicitasse uma versão mais antiga do java, por outro lado. Isso pode mudar com o Java 9 ou além, mas ainda não o vi acontecer.
eis
É incrivelmente compatível na prática, e instalar uma versão mais antiga lado a lado não é um problema. Observe também que, na minha estimativa, o .NET BCL é 10-100x maior que as classes internas do Java.
usr
compatibilidade com versões anteriores significa que não será necessário instalar também uma versão mais antiga. Mas discordamos da pergunta original, isso não é realmente relevante para o OP.
eis
0

As outras respostas fazem sentido. No entanto, acho que os comentários sobre a tecnologia do cliente acabaram complicando as coisas. Trabalho como desenvolvedor há 16 anos. Na minha experiência, contanto que você mantenha seu código de cliente intuitivo, tudo bem. Portanto, nenhum "hacks" com frames / iframes, etc. Use apenas funções bem definidas nos navegadores.

Você sempre pode usar modos de compatibilidade nos navegadores para mantê-los funcionando.

Para provar meu argumento, há apenas alguns meses, corrigi um bug do milênio no código javascript de um cliente que está executando seu aplicativo da web há 17 anos. Ainda funciona em máquinas recentes, banco de dados recente, sistema operacional recente.

Conclusão: mantenha-o simples e limpo e você ficará bem.

Jonathan van de Veen
fonte
1
Quadros e iframes estão muito bem definidos na especificação HTML. O que os torna inadequados?
curiousdannii
3
@curiousdannii: Não é tanto o uso de iframes (os quadros não são mais suportados no HTML5), como o uso de quadros e iframes para carregar conteúdo de forma assíncrona por meio de scripts, etc. Ele pode funcionar muito bem agora, mas sempre estar sujeito a alterações de segurança.
Jonathan van de Veen
-2

Alguns axiomas:

  • A verdade sobrevive. Nesse contexto, seriam algoritmos e modelos de dados - o que representa verdadeiramente o "o quê" e o "como" do seu espaço problemático. Embora haja sempre o potencial de aprimoramento e aprimoramento, ou uma evolução do problema em si.
  • Idiomas evoluem. Isso é verdade tanto para linguagens de computador quanto para linguagens naturais.
  • Toda tecnologia é vulnerável à obsolescência. Pode levar mais tempo para algumas tecnologias do que para outras

As tecnologias e padrões mais estáveis ​​(os menos vulneráveis ​​à obsolescência) tendem a ser aqueles que não são proprietários e foram amplamente adotados. Quanto maior a adoção, maior a inércia contra quase qualquer forma de mudança. Os "padrões" proprietários são sempre vulneráveis ​​às fortunas e aos caprichos de seus proprietários e às forças competitivas.

Vinte anos é muito tempo na indústria de computadores. Cinco anos é um objetivo mais realista. Dentro de cinco anos, todo o problema que seu aplicativo deve resolver pode ser completamente redefinido.

Alguns exemplos para ilustrar:

C e C ++ já existem há muito tempo. Eles têm implementações em praticamente todas as plataformas. O C ++ continua a evoluir, mas os recursos "universais" (disponíveis em todas as plataformas) têm praticamente a garantia de nunca serem preteridos.

O flash quase se tornou um padrão universal, mas é proprietário. As decisões corporativas de não suportá-lo em plataformas móveis populares basicamente o condenaram em todos os lugares - se você é autor da Web, deseja que seu conteúdo esteja disponível em todas as plataformas; você não quer perder o principal mercado móvel que se tornou.

WinTel (Windows / x86), apesar de ser proprietário da Microsoft e da Intel, tendo começado em uma plataforma abaixo do ideal (16 bits interno / 8 bits externo 8088 versus o contemporâneo Apple Macintosh 32 bits interno / 16 bits externo 68000) e erosão para a Apple no mercado consumidor continua sendo uma opção de fato para plataformas de negócios. Durante todo esse tempo (25 anos), o compromisso com a compatibilidade com versões anteriores impediu o desenvolvimento futuro e inspirou considerável confiança de que o que funcionou na caixa antiga ainda funcionará na nova.

Pensamentos finais

JavaScript pode não ser a melhor opção para implementar a lógica de negócios. Por razões de integridade e segurança dos dados, a lógica de negócios deve ser executada no servidor, para que o JavaScript do cliente seja limitado ao comportamento da interface do usuário. Mesmo no servidor, o JavaScript pode não ser a melhor opção. Embora seja mais fácil trabalhar com outras pilhas (Java ou C #) para pequenos projetos, falta a formalidade que pode ajudá-lo a escrever soluções melhores e mais organizadas quando as coisas ficam mais complexas.

Zenilogix
fonte