Hoje em dia temos muitas opções quando decidimos criar um novo software. Temos que escolher tecnologias em diversas áreas desde a persistência à renderização gráfica.
A escolha não é relevante se o software vai durar menos de um ano. Nesse caso usar a tecnologia com que estiver mais familiarizado é bom o suficiente. Mas se está pensando num software sério que dure 10 anos ou mais, então é bom pesar a escolha.
No passado vimos bastantes tecnologias verem o hype e depois desaparecerem. Claro que não desaparecem por completo; me refiro a não serem relevantes. A relevância não vem só da tecnologia em si, mas da sua adoção: o volume de pessoas que a usa. Existem ferramentas horríveis que são muito relevantes porque muitas pessoas as usam. A relevância é importante porque em algum momento, para um software de 10 anos, vai ser necessário contratar alguém que trabalha com essa tecnologia para manter e evoluir o software.
Além de escolher suas tecnologias ainda há que pensar onde esse software vai rodar. É embarcado em um celular ? Na nuvem ? no navegador ? em uma mistura destes ? Não é simples escolher.
Quando pensamos criar um software para durar 10 anos precisamos pensar se haverá pessoas para programar o software na linguagem escolhida, daqui a 10 anos. Durante a pandemia o COBOL viu uma ascensão porque sistemas escritos nessa linguagem, e deixados a funcionar durante décadas, precisavam agora de manutenção. Mas não há muitos programadores COBOL por ai.
É difícil saber qual linguagem vai estar aqui daqui a 10 anos. Muitas linguagens nem sequer se tornam relevantes. Vide o exemplo do Ceylon. Uma linguagem excelente que foi abandonada. Tendemos a escolher para o futuro linguagens que sempre estiveram aqui, a menos que haja uma melhor. Por isso que C e C++ ainda fazem sucesso, mas Rust está competindo fortemente. Contudo Rust não é a primeira linguagem competindo com C++, já existia o D e muitas outras antes do Rust. Será que o Rust vai ser relevante daqui a 10 anos ou vai ser outro hype como Ruby?
No passado durante as Guerras da Tipagem (Type Wars) a discussão era se as linguagens deveriam ser fortemente tipadas como Java ou fracamente tipadas como Ruby e Javascript. A resposta é que devem ser tipadas. Pelo menos se o seu software é sério para durar 10 anos. Se você está escrevendo um script para mover arquivos, talvez não precisa de tipos … pelo menos não até você tentar mudar esse script um ano depois…
Um comentário à parte. Sempre que “script” é usado significa “descartável”. O problema é que algum momento foi aceite que seria possível escrever softwares sérios, em equipe, com linguagens de script. Ai complica… Não é por acaso que as linguagens tipadas apareceram e estão tomando o lugar das não tipadas.
Softwares sérios são escritos com linguagens tipadas. É claro que você pode escrever com qualquer linguagem, mas o custo não é o mesmo. Ruby, por exemplo, não é tipada, e por isso você tem que escrever testes que testam aquilo que um compilador tipado normalmente testaria. Se usa JavaScript no Node.js, ou até mesmo no navegador, provavelmente tem o mesmo problema. A falta de rigor na compilação levou a comunidade Ruby a criar várias ferramentas de teste unitário e criar uma febre em torno de testar tudo unitariamente. Tudo bem em testar as coisas, mas testar se algo contém um inteiro é, simplesmente, demais.
Aprendemos a lição e as linguagens desde então são tipadas. E mesmo algumas linguagens de script não-tipadas ganharam opções de tipagem, como Groovy ou vão ganhar como Javascript.
Agora que sabemos que temos que usar uma linguagem tipada, qual usar ? Há tantas. O problema é a plataforma em que elas funcionam. Java não funciona no navegador, por exemplo. Existem vantagem em usar uma linguagem para cada plataforma ? Os proponentes de micro serviços acham que sim. Afinal uma das bandeiras de micro serviços é poder programar o serviço na linguagem que mais se adequa à solução. Mas do ponto de vista empresarial e de governança várias linguagens implicam várias pessoas com skills diferentes e isso, trás isolamento e custos. Hoje se ouve falar muito de Front End e Back End e de Dados e as vagas para estas atividades exigem conhecimento de linguagens, ferramentas e plataformas diferentes. Ótimo para os vendedores de tecnologia, horrível para as empresas.
Lá nos anos 50-60 do século passado os projetos de software sempre começavam com a criação de uma linguagem, um compilador, etc. Não havia IDE. De tanto criar linguagens e compiladores as pessoas tiveram a ideia de uma linguagem de uso geral e desde então a linguagem é construida à parte e usada como ferramenta. Contudo, recentemente, a prática de investir em linguagens próprias ao produto voltou, mas de um jeito diferente. A Meta apostou todas as fichas no PHP. Uma tecnologia com vários problemas, mas que tem a sua praticidade. Os problemas começaram a aumentar e a Meta investiu em uma máquina virtual e uma linguagem compatível com PHP para aumentar a performance e corrigir alguns problemas. É um caso de uma linguagem construida depois do produto. Por outro lado temos o Kotlin criado para unificar e simplificar o desenvolvimento de IDE pela JetBrains. Uma história de uma linguagem criada também depois do produto para diminuir custos a longo prazo e ganhar independência de outros vendedores- no caso a Oracle. Afinal, se a linguagem é sua, você decide como evolui-la. Um último exemplo é o Swift. A linguagem que a Apple criou para substituir o Objective-C, uma linguagem que, convenhamos, ninguém alguma vez gostou. Com o Swift, a Apple viu uma explosão de aceitação até ao ponto onde se pede que Swift rode no servidor.
Então qual linguagem escolher ? A resposta está em qual plataforma você precisa. Para o lado do servidor Java é a opção certa. É grátis e tem milhares de bibliotecas para tudo e mais alguma coisa e muito mais está por vir quando os projetos Panama e Valhalla estiverem prontos. Não quer esperar ? Então C#. Mas ai prepare-se para pagar por todos os componentes que você precisa. O paradigma do grátis ainda não chegou com forçar no C# , ou no .NET, mas a linguagem está realmente muito à frente do Java, o problema é a plataforma, que está atrás. Mas e Kotlin ? Kotlin é tipado e funciona no servidor, não apenas JVM mas em tecnologias como node.js e wasm. Aqui o problema é que Kotlin é uma linguagem praticamente universal porque roda em muitas plataformas, mas nem todo o código é portátil. Se você depender de alguma coisas especifica de uma plataforma, não vai funcionar nas outras. Por exemplo, um gerador de relatórios com JasperReports funciona em JVM, mas não em node.js.
E no navegador ? Javascript não é uma opção porque não é tipado. TypeScript é muito popular e é muito provável que esteja aqui em 10 anos. Dart é muito bom também, mas tem menos adoção, exceto pela plataforma Flutter que promete rodar em Android, iOS e Web. Kotlin faz esta mesma promessa.
Uma empresa sempre tem um conjunto de software que utiliza. Alguns fabricados por ela, e alguns de terceiros. Naqueles que são fabricados por ela, temos normalmente o produto em si – aquele software que gera a receita da empresa, mas temos também o site corporativo e talvez algum tipo de blog ou outro software auxiliar.
Para o blog, o WordPress – em PHP – costuma ser uma escolha fácil. Para o site corporativo algum tipo de HTML estático é suficiente. Para o produto, ai sim temos que pensar melhor. Mas esta é uma análise simplista. Esta análise é baseada no conceito – errado – de que o site corporativo e o blog ( ou qualquer outro software adicional) não fazem parte da empresa. Fazem sim. São ativos tão importantes quando o produto. Geram custos e geram receita, ajudam ou atrapalham. E muitas vezes há que existir interação entre eles. Pense um produto de software online. Como você o contrata ? Através de um site. Então quem é o produto ? o que você compra, ou o software que permite a compra ? Claro que são ambos.
Um site tem necessidades diferentes de uma aplicação. Começamos por SEO. Hoje se o SEO do seu site não é bom, você não existe. Mas tecnologia de aplicação como Angular e outras, não conseguiram resolver este problema a contento. A solução sempre passa por produzir conteúdo no servidor. Ora, tecnologia como PHP, JSP ou até ASPX sempre resolveram este problema. Afinal existe uma razão para que o PHP ainda sobrevida como linguagem e plataforma além do Facebook: o ubíquo WordPress.
Ok, então queremos renderização server side para o blog e, claro, para o site. Para a aplicação queremos algo SPA (Single Page Application). Mas espera, tudo isto funciona no navegador. E fora do navegador? E aplicações móveis ? Aqui temos dois mundos : o sempre-online e o algumas-vezes-online. O primeiro podemos resolver com SPA que se adapte ao monitor via CSS. O segundo, podemos resolver com PWA e persistência no navegador ou com uma aplicação embarcada, criada especialmente para ser instalada no aparelho móvel.
Para uma solução embarcada temos o problema da divisão de plataformas. Se você só quer criar aplicações Android, então Java é suficiente. Mas se você quer comprar um Mac para desenvolver para iOS é bom começar a aprender Swift… a não ser que… e se programássemos em uma linguagem e gerássemos aplicações para os dois ? Várias tentativas forem feitas para nos dar essa ferramenta mágica. Atualmente as que estão mais próximas são o Flutter e o Kotlin Jetpack Compose. Ambos prometem Android, iOS e Web a partir do mesmo código fonte.
O problema disto tudo ? Estas tecnologias ainda estarão aqui , daqui a 10 anos ? E mesmo que estejam, como será a evolução ? teremos que passar por problemas de compatibilidade como na migração dos diferentes tipos, sabores e versões de .NET ?
A decisão claro, não é fácil. Neste momento de 2024 com tantas opções de linguagens e plataformas o conceito para o seu software e onde ele precisa estar acessível é muito mais importantes que outrora. Escolher o stack errado pode custar caro no futuro e ter que reescrever tudo de novo.
Se você não tem medo de apostar no futuro e/ou dinheiro para gastar depois, Kotlin pode ser uma boa aposta. Não é a melhor linguagem do mundo, não é a melhor plataforma do mundo, mas é a única que funciona em todas as plataformas. Contrate programadores Kotlin e está garantido – pelo menos enquanto a Jetbains existir e aposta no Kotlin. A linguagem em si está estagnada quando Java ficou no período de adquirição da Sun pela Oracle. Mas embora kotlin permita escrever e portar algumas partes do código é necessário conhecer as outras linguagens com quem ele interage e construir extensões nativas em cada plataforma caso o Kotlin puro não seja suficiente. Por outro lado, soluções que funcionam em uma plataforma, podem não funcionar em outras, como reflection por exemplo.
Se você é mais conservador, então utilize uma linguagem para o servidor , por exemplo, Java e uma para o cliente, como Flutter. Lembrando que estamos pensando que sites e blogs ainda são server side e não são feitos com Flutter ( sim, lembrou bem, por causa do SEO). Se a sua aplicação cliente não precisa de acesso aos sensores do aparelho celular Angular no navegador com PWA e persistência no navegador é uma boa opção. Typescript é uma boa linguagem e hoje em dia há muitas bibliotecas para os mais diversos aspectos. Aplicações offline ainda podem ser construidas com esta tecnologia, com a vantagem de poder usar o mesmo HTML e CSS e usa para o site e blog. Mas neste caso, escolha um design system e o encapsule no Angular. Há muitos design systems prontos de onde escolher.
Enfim, seja qual for a decisão tente nunca escolher a linguagem “própria” da plataforma. Isto vai amarrar o seu produto e empresa a um único vendedor. Claro que nem tudo são rosas no mundo do multiplataforma e estas tecnologias podem desaparecer, mas acho que já está provado que o futuro é escrever uma vez e rodar em qualquer lugar.
A tabela a seguir resume as conclusões.
| Java + Angular/TypeScript | Java + Flutter/Dart | Kotlin Multiplatafroma | |
| Servidor | Sim (Java) | Sim (Java) | Sim |
| Web Server Side | Sim (Java) | Sim (Java) | Sim |
| Web SPA | Sim (Angular) | Sim (Flutter) | Sim |
| Web PWA | Sim (Angular + PWA) | Sim (Flutter) | Sim |
| Offline | Sim (Angular+ Persistência no Browser) | Sim (Flutter) | Sim |
| Embarcado (Android, iOS) | Não1 | Sim (Flutter) | Sim |
Então C#. Mas ai prepare-se para pagar por todos os componentes que você precisa.
Nesse Ponto gostaria de entender que componentes são esses que são pagos?! E sobre a gratuidade do java acaba por exemplo no tão atualmente badalado spring, mas vale ressaltar os projetos que você mencionou e que estão por vir.
Me referia a frameworks como o DevExpress. Para uma aplicação profissional com relatórios, tem que recorrer a isso porque não ha alternativas viáveis gratuitas.Em java tem o JasperReports que é grátis
Em relação ao spring não entendi seu comentário. O Spring é grátis tanto em Java como em .NET.