Optando por .NET ao invés de Java

[quote=NickGaspar][quote=sergiotaborda][quote=NickGaspar]Eu prefiro uma plataforma que seja apropriada para servidores (JVM, .NET), e outra para aplicações (Windows 8, iOS).

Todos nós sabemos que fim levou o browser, a última plataforma que tentou encapsular tudo.[/quote]

Como assim ?! O browser tentou e consegui. Ou vc não ouviu falar em HTML 5 ? O Browser é a única plataforma que existe que funciona em todos os aparelhos. Hoje em dia aplicativos android e iphone/ipad são feitos apenas encapsulando o browser. É tudo HTML + javascript.
Não é por acaso que cada vez mais linguagens têm compiladores para js.[/quote]

HTML5 é um formato conhecido por qualquer cliente HTTP, e não apenas browsers.

Mas sobre aplicativos que usam HTML como interface de usuário, o único que me lembro que fez isso foi o facebook, e foi considerado o maior erro da sua história, bastar ver sua reputação na AppStore.[/quote]

Atualmente meu conhecimento é quase todo web e nulo em mobile. Essa do Facebook usar HTML na aplicação mobile um amigo no trabalho tinha me mostrado. Fiquei curioso e fui ver a reputação e na AppStore realmente é ruim :smiley:

Programar interface com HTML e CSS é extremamente prático, mas pelo visto oq matou as aplicações nativas no desktop não foram isso, creio que deva ter sido:

  • Medo de vírus
  • Computador ficando mais lento a medida que instala mais aplicações
  • Aparência feia
  • Necessidade de VMs para rodar (em alguns casos), compromentendo a performance, tamanho do arquivo de instalação e a facilidade de instalação para o usuário leigo

Pelo jeito a própria Microsoft é culpada pelo declínio das apps nativas desktop. A apple não cometeu nenhum desses erros no mobile

É bem diferente. No java o netbeans é minoria comparado ao eclipse. Sim, o netbeans é o visual studio do java e comete os mesmos erros que o visual studio do .net ( produção automática de código). Mas no java vc tem alternativas. Vc não precisa usar o netbeans, nem o eclipse, já agora. Existem muitos outros IDE.

O ponto é o padrão e não a ferramenta. Java se faz na mão. Swing drag-drop é para iniciantes e prototipagem, não é para sistemas reais ( por isso que quase ninguém usa). O Swing é lib de base, é suposto vc criar algum framework em cima dele (vide javaFX). Os juniors de java só começam pelo netbeans se não tiverem aprendido direito e/ou não tiverem um sênior por perto. Enquanto que no .net usar o drag-drop é uma necessidade. Escrever na mão é demasiado complexo (porque o .net não tem layouts como no java e o posicionamento é absoluto).

A curva do C# e do Java são iguais, mas não do IDE e nem nos padrões. E é isso que é importante, não a linguagem.

Quando o cara escolhe .net em vez de java é por dois motivos : 1) não lhe importa a portabilidade e 2) ele acha que a produtividade é maior.
Por quê ele acha que a produtividade é maior ? Porque o protótipo é visível mais cedo. Enquanto o cara do java está montando um framework, o do .net já fez o drag-drop. (Veja, isto é o que as pessoas pensam e fazem, não necessariamente teria que ser assim. O cara de java poderia usar o netbeans para a prototipagem também).

Por outro lado, qual é o equivalente ao EE em .net ? Não ha. (existem formas de fazer as mesmas coisas, mas não da mesma forma padronizada)
E porque não ha, a plataforma .net é muito mais fácil de aprender.

As plataformas em si, são equivalentes, mas a percepção não é. Por exemplo, eu ouço muita gente dizer que um profissional java é mais caro. Por quê ? Porque o profissional java experiente sabe sobre muitos mais assunto que um .net experiente. Isto porque o de java simplesmente teve que ralar mais. Comparando dois sêniors, ele devem saber o mesmo e custar o mesmo, mas comparando plenos e juniors ( que é o que as empresas amam contrantar) os de java sabem muito mais e portanto, querem mais dinheiro. Dito de outra forma, a empresa aceita pagar pouco ao junior drag-drop e pagar pelo IDE, mas não aceita pagar mais ao sênior java para fazer um framework swing.

[quote=victorcosta]- Medo de vírus

  • Computador ficando mais lento a medida que instala mais aplicações
  • Aparência feia
    [/quote]

Eu acho que não foi nada disso. No mercado corporativo, o que retirou o desktop foi mesmo a facilidade de deploy / atualização e a possibilidade da aplicação ser acessada com facilidade remotamente (parte da sua terceira alternativa).

No caso do mercado de aplicações para usuário, o desktop ainda não está em declínio.
Todos os jogos ainda são apps desktop. Além de IDEs, Players de vídeo, editores de imagens, Office Suites, navegadores…

[quote=ViniGodoy][quote=victorcosta]- Medo de vírus

  • Computador ficando mais lento a medida que instala mais aplicações
  • Aparência feia
    [/quote]

Eu acho que não foi nada disso. No mercado corporativo, o que retirou o desktop foi mesmo a facilidade de deploy / atualização e a possibilidade da aplicação ser acessada com facilidade remotamente (parte da sua terceira alternativa).

No caso do mercado de aplicações para usuário, o desktop ainda não está em declínio.
Todos os jogos ainda são apps desktop. Além de IDEs, Players de vídeo, editores de imagens, Office Suites, navegadores… [/quote]

Mas aí vc tá falando de aplicações que já são nativas naturalmente, pq lidam com arquivos no HD. E mesmo assim mt gente deixou de usar Office local, e usa Google Docs. Slideshare, etc. Existe uma certa decadência de aplicação nativa pra desktop

Agora vê no mobile, uma aplicação que é simplesmente um versão de um site (Facebook) é criticada por usar tecnologias web. Lá aplicações nativas são a preferência, mesmo quando não tem necessidade de usar features que o browser não permite

A única coisa que acho trabalhoso é a configuração de um projeto java. Espero que o play e mentawai ajudem a simplificar isso.

[quote=sergiotaborda][quote=juliocbq]
essa questão de arrastar e colar componentes não tem nada a ver com o .net. Se for assim é igualmente fácil fazer isso com o netbeans(o mesmo profissional citado usando java).
[/quote]

É bem diferente. No java o netbeans é minoria comparado ao eclipse. Sim, o netbeans é o visual studio do java e comete os mesmos erros que o visual studio do .net ( produção automática de código). Mas no java vc tem alternativas. Vc não precisa usar o netbeans, nem o eclipse, já agora. Existem muitos outros IDE.

O ponto é o padrão e não a ferramenta. Java se faz na mão. Swing drag-drop é para iniciantes e prototipagem, não é para sistemas reais ( por isso que quase ninguém usa). O Swing é lib de base, é suposto vc criar algum framework em cima dele (vide javaFX). Os juniors de java só começam pelo netbeans se não tiverem aprendido direito e/ou não tiverem um sênior por perto. Enquanto que no .net usar o drag-drop é uma necessidade. Escrever na mão é demasiado complexo (porque o .net não tem layouts como no java e o posicionamento é absoluto).

A curva do C# e do Java são iguais, mas não do IDE e nem nos padrões. E é isso que é importante, não a linguagem.

Quando o cara escolhe .net em vez de java é por dois motivos : 1) não lhe importa a portabilidade e 2) ele acha que a produtividade é maior.
Por quê ele acha que a produtividade é maior ? Porque o protótipo é visível mais cedo. Enquanto o cara do java está montando um framework, o do .net já fez o drag-drop. (Veja, isto é o que as pessoas pensam e fazem, não necessariamente teria que ser assim. O cara de java poderia usar o netbeans para a prototipagem também).

Por outro lado, qual é o equivalente ao EE em .net ? Não ha. (existem formas de fazer as mesmas coisas, mas não da mesma forma padronizada)
E porque não ha, a plataforma .net é muito mais fácil de aprender.

As plataformas em si, são equivalentes, mas a percepção não é. Por exemplo, eu ouço muita gente dizer que um profissional java é mais caro. Por quê ? Porque o profissional java experiente sabe sobre muitos mais assunto que um .net experiente. Isto porque o de java simplesmente teve que ralar mais. Comparando dois sêniors, ele devem saber o mesmo e custar o mesmo, mas comparando plenos e juniors ( que é o que as empresas amam contrantar) os de java sabem muito mais e portanto, querem mais dinheiro. Dito de outra forma, a empresa aceita pagar pouco ao junior drag-drop e pagar pelo IDE, mas não aceita pagar mais ao sênior java para fazer um framework swing.
[/quote]

A questão de padrões é relacionada com engenharia. Qualquer pessoa que tenha a mínima noção de engenharia de software vai desenvolver corretamente nas duas plataformas com as mesmas duas linguagens. O que distingue um profissional ruim do outro é o nível de conhecimento. Mas concordo com você que os frameworks seguindo a risca esses padrões tornam o trabalho e a soluções criadas bem robustas.

O javafx não é construído em cima do swing. É construído em cima de uma biblioteca gráfica chamada prism, E ela roda sobre java2d em máquinas sem placas de vídeo, sobre opengl em linux com aceleradoras e direct3d em windows com aceleradoras. Possui o próprio sistema de janelas chamado “glass”. Hoje ele é uma alternativa ao swing.

[quote=victorcosta][quote=ViniGodoy][quote=victorcosta]- Medo de vírus

  • Computador ficando mais lento a medida que instala mais aplicações
  • Aparência feia
    [/quote]

Eu acho que não foi nada disso. No mercado corporativo, o que retirou o desktop foi mesmo a facilidade de deploy / atualização e a possibilidade da aplicação ser acessada com facilidade remotamente (parte da sua terceira alternativa).

No caso do mercado de aplicações para usuário, o desktop ainda não está em declínio.
Todos os jogos ainda são apps desktop. Além de IDEs, Players de vídeo, editores de imagens, Office Suites, navegadores… [/quote]

Mas aí vc tá falando de aplicações que já são nativas naturalmente, pq lidam com arquivos no HD. E mesmo assim mt gente deixou de usar Office local, e usa Google Docs. Slideshare, etc. Existe uma certa decadência de aplicação nativa pra desktop

Agora vê no mobile, uma aplicação que é simplesmente um versão de um site (Facebook) é criticada por usar tecnologias web. Lá aplicações nativas são a preferência, mesmo quando não tem necessidade de usar features que o browser não permite[/quote]

A maioria dos serviços estão expostas como webservices. Então creio eu que não há motivos para escrever a aplicação num browser se você pode baixar json ou xml desses serviços. Talvez por estética, mas o sdk do android por exemplo te permite escrever aplicações ricas usando somente xml, que o compilador transforma em código java posteriormente em nativo da dalvik.

[quote=juliocbq][quote=victorcosta][quote=ViniGodoy][quote=victorcosta]- Medo de vírus

  • Computador ficando mais lento a medida que instala mais aplicações
  • Aparência feia
    [/quote]

Eu acho que não foi nada disso. No mercado corporativo, o que retirou o desktop foi mesmo a facilidade de deploy / atualização e a possibilidade da aplicação ser acessada com facilidade remotamente (parte da sua terceira alternativa).

No caso do mercado de aplicações para usuário, o desktop ainda não está em declínio.
Todos os jogos ainda são apps desktop. Além de IDEs, Players de vídeo, editores de imagens, Office Suites, navegadores… [/quote]

Mas aí vc tá falando de aplicações que já são nativas naturalmente, pq lidam com arquivos no HD. E mesmo assim mt gente deixou de usar Office local, e usa Google Docs. Slideshare, etc. Existe uma certa decadência de aplicação nativa pra desktop

Agora vê no mobile, uma aplicação que é simplesmente um versão de um site (Facebook) é criticada por usar tecnologias web. Lá aplicações nativas são a preferência, mesmo quando não tem necessidade de usar features que o browser não permite[/quote]

A maioria dos serviços estão expostas como webservices. Então creio eu que não há motivos para escrever a aplicação num browser se você pode baixar json ou xml desses serviços. Talvez por estética, mas o sdk do android por exemplo te permite escrever aplicações ricas usando somente xml, que o compilador transforma em código java posteriormente em nativo da dalvik.[/quote]

Apps html para android que vejo, é gente que nao quer pagar um programador iOS e outro Android ou que quer lançar rapidamente nas duas plataformas, ai usam estas opções que tem por ae, phoneGap, Titanium e etc, que geram um unico app para todas as plataformas, o que acaba acontecendo é que a experiencia do usuario vira uma porcaria! No android acabamos tendo apps iPhone like, por exemplo é só ver apps que tem um botao voltar na tela, todo android ja tem um botão voltar físico ou virtual(a partir do 3.0+), mas como o app é generico para iOS e android, fica la aquele botão desnecessario na tela!

[quote=sergiotaborda][quote=juliocbq]
essa questão de arrastar e colar componentes não tem nada a ver com o .net. Se for assim é igualmente fácil fazer isso com o netbeans(o mesmo profissional citado usando java).
[/quote]

É bem diferente. No java o netbeans é minoria comparado ao eclipse. Sim, o netbeans é o visual studio do java e comete os mesmos erros que o visual studio do .net ( produção automática de código). Mas no java vc tem alternativas. Vc não precisa usar o netbeans, nem o eclipse, já agora. Existem muitos outros IDE.

[/quote]

O Netbeans não é o Visual Studio do Java. O JDeveloper é o Visual Studio do Java. Quando se trata de recursos drag-and-drop e wizards, o Netbeans é uma criança perto do que faz o JDeveloper. Até a forma de trabalhar, usando os data controls do ADF, geração de componentes, bindings… Vixe, Netbeans não chega nem perto…

Eu diria que o Netbeans está no meio do caminho entre o Eclipse (EDITOR POWER) e o JDeveloper (DRAG-AND-DROP POWER).

[quote=josenaldo][quote=sergiotaborda][quote=juliocbq]
essa questão de arrastar e colar componentes não tem nada a ver com o .net. Se for assim é igualmente fácil fazer isso com o netbeans(o mesmo profissional citado usando java).
[/quote]

É bem diferente. No java o netbeans é minoria comparado ao eclipse. Sim, o netbeans é o visual studio do java e comete os mesmos erros que o visual studio do .net ( produção automática de código). Mas no java vc tem alternativas. Vc não precisa usar o netbeans, nem o eclipse, já agora. Existem muitos outros IDE.

[/quote]

O Netbeans não é o Visual Studio do Java. O JDeveloper é o Visual Studio do Java. Quando se trata de recursos drag-and-drop e wizards, o Netbeans é uma criança perto do que faz o JDeveloper. Até a forma de trabalhar, usando os data controls do ADF, geração de componentes, bindings… Vixe, Netbeans não chega nem perto…

Eu diria que o Netbeans está no meio do caminho entre o Eclipse (EDITOR POWER) e o JDeveloper (DRAG-AND-DROP POWER). [/quote]

Concordo plenamente, o JDeveloper é uma IDE muito fantástica, e forte candidata a se tornar um padrão corporativo. Alguns dos parceiros que temos trabalham com JDeveloper e acham fantástica a produtividade.

[quote=ViniGodoy]
Todos os jogos ainda são apps desktop. Além de IDEs, Players de vídeo, editores de imagens, Office Suites, navegadores… [/quote]
Só acrescentando na lista ,os Emissores de cupom fiscal (PAF-ECF)

Bom tenho olhado os anuncios de vagas no Catho a algumas semanas e embora tenham muitas vagas para .net realmente, para Java sobram. Muitas vagas mesmo.

Quem é nível Senior em Java aqui em SP não fica sem emprego.

Por aqui vejo muita empresa que foi pra .NET e hoje estão migrando pra Java.

Mas o contrario tambem tem acontecido bastante. Mas a causa não é o fato de uma ser melhor que a outra ou a outra que a uma. O problema esta na dificuldade de reconhecer que a falha esta na propria equipe e não nas linguagens.

Mas o contrario tambem tem acontecido bastante. Mas a causa não é o fato de uma ser melhor que a outra ou a outra que a uma. O problema esta na dificuldade de reconhecer que a falha esta na propria equipe e não nas linguagens.[/quote]

É verdade, tem região que o fluxo é o inverso.
Não sei se a falha é da equipe ou da linguagem, acredito que seja mais questão de mercado local ou expectativa frustrada.

não tenho uma fração da experiência e conhecimento que vocês tem, mas vou deixar uma opinião :stuck_out_tongue:
sabemos que Java é uma ferramenta, se a equipe não não se adaptou a ferramenta, se troca a equipe ou a ferramenta??

não tenho uma fração da experiência e conhecimento que vocês tem, mas vou deixar uma opinião :stuck_out_tongue:
sabemos que Java é uma ferramenta, se a equipe não não se adaptou a ferramenta, se troca a equipe ou a ferramenta??[/quote]

Pois é, e o fato das trocas ocorrerem nas duas direções, só mostra que não existe melhor ou pior, mas que cada um tem sua opinião e forma de trabalhar distinta.