Eu só não sei da onde que vc acha que o Moonlight implementa as mesmas coisas que o Silverlight…
A solucão da Microsoft vai bem alem de um plugin rodando codigo .net…
+1
A unity agora tem um projeto para o android, e imagino que isso vai bombar muito o c# com mono na plataforma.
Vale a pena ler sobre.
http://unity3d.com/unity/coming-soon/android
e para quem não conhece a unity
[quote=juliocbq]O objetivo do jfx seria rodar neles, não competir. Acabei de saber que o mono vai compilar para android também, então provavelmente o silverlight vai estar no android.
http://www.go-mono.com/monodroid/[/quote]
O Mono/C# seria compilado, como bem você disse. Na aplicação alvo, não existe mais a plataforma .Net, apenas o binário Android normal. O Silverlight é uma criatura diferente, deveria haver um plugin para o browser do Android que interpretasse os bytecodes típicos do Silverlight. Não acho que a criação de um compilador usando Mono implica uma criação fácil para um plugin Silverlight.
O JavaFX competiria com o Android. A ideia original era haver um JavaFX Mobile (possivelmente um sistema operacional), cujos detalhes nunca foram defiidos, mas que seria um substituto (ou uma alternativa) ao J2ME. E mesmo que o JavaFX fosse para rodar num dispositivo via browser, competiria sim com Android; uma vez que um desenvolvedor crie um programa para Android, ele não vê beneficio em portá-lo para uma outra linguagem/plataforma visando os mesmos dispositivos.
Heheh a mesma "solução " adotada para iPhone…
o Miguel está até dando solucoes a lá microsoft 
Remenda e lança como SUPER NOVIDADE !
[quote=Leonardo3001][quote=Jesuino Master][quote=Leonardo3001]Há rumores de que o iOS da Apple e o Android da Google sejam utilizados em Set Top Boxes… então mais uma vez, é um lugar onde o JavaFX está atrasadíssimo.
E com relação a Javascript… me desculpe, mas onde existe netbook, smartphone, tablet e set top box não existe IE 6, nem IE 7. Ao contrário, só existe o que há de mais avançado pra Web, como HTML 5, CSS 3 e JS 1.7.
[/quote]
JavaFX também pode ter o runtime portável para rodar sobre essas plataformas. E é exatamente essa uma das questões para torná-lo OpenSource.
HTML5, CSS 3 e JS são ótimos para criação de aplicações ricas, mas nem tudo é perfeito, não se gera processamento. Em grandes animações navegadores tradicionais, sem aceleração de hardware engasgam, sem dizer questões como de codecs proprietários, compatibilidade de navegador etc. IMHO, a coisa vai ser perfeita com a idéia da Google de fazer o “navegador SO”. Em outras palavras, querendo ou não, Flash estará ai por mais alguns anos…
[/quote]
Ser Open Source e ter o runtume portável não garantirá o sucesso do JavaFX. A aceleração de hardware é importante, mas está sendo superestimado nesta discussão; é uma característica importante, mas não é determinante para o sucesso da plataforma. Além do mais, não é algo exclusivo do JavaFX, o Safari tem aceleração de hardware, as aplicações nativas para iPhone/iPad e Android também tem.
[quote=fddo]Set Top Box eu não sei, mas a com certeza a Sony e talvez a LG, estarão utilizando Android em algumas series de suas TV. Se javafx rodaria no android, ai eu não sei, alias se alguém souber me avise… ehehehehe
[/quote]
Set top box separado ou interatividade integrado na TV, não importa, a ideia original é a mesma: o Android e o iOS comeriam as fatias de mercado que o JavaFX não teve fôlego para conseguir.
Como assim? Programar em Java e C++ é mais fácil? Até entendo quando um programador Swing ache Java mais fácil, mas C++ é também o mais fácil?
Primeiro que eu não faria “programação desktop” em JS, usaria Javascript para a parte dinâmica, CSS para apresentação e HTML para a estrutura. Segundo que documentação e livros para Javascript tem aos montes (recomendo o livro de Javascript de David Flanagan e a documentão da api do JQuery, ótima), sem falar de vários outros de CSS e HTML.
[/quote]
A parte de aceleração não foi muito clara acredito. Digo que navegadores sem aceleração de hardware engasgam em animações/aplicações pesadas com HTML5/CSS3/JS. Olhe o teste no meiobit:
Com certeza, isso vai melhorar, ninguém duvida, mas ainda há um caminho a trilhar.
É muito bonito ver demos de HTML5 rodando perfeitamente com códigos criados por profissionais, mas quando a coisa pega e cai no mercado, nem sempre a qualidade é o principal alvo… Só estou tentando desmistificar esse lado bala de prata dessas tecnologias, problemas também devem ser reconhecidos…
O Android TV também tem muita propaganda, mas existem outros poréns por trás dele. Um exemplo é a padronização. Aqui no Brasil o padrão é o Ginga(http://www.ginga.org.br/). Set top Box são fabricados para o Midleware brasileiro, não li nada de Android na documentação do Ginga até hoje. Não estou criando Flame, nem quero desrespeitar o poderoso Android, só estou falando que nem tudo é tão lindo como está no vídeo da Google sobre o Android TV…
Ser OpenSource não é garantir o sucesso. Se tivesse uma forma absoluta de garantir o sucesso a Oracle já tinha feito há muito tempo. Ser OpenSource é para quebrar algumas barreiras impostas a essa plataforma, mas também há, como o Chun está mostrando, problemas. Nada é sucesso absoluto, só acredito, e as 500 pessoas que assinaram a petição, que ter o código aberto irá ajudar a plataforma a possivelmente ganhar mercados e a popularização. A portabilidade do runtime não é definitivo, mas com certeza é um passo super importante. Um exemplo é o Flash, quando foi informado que ele rodaria sobre o Android, foi um ponto a mais para a plataforma da Adobe.
Vou dar um exemplo bem legal: se o desenvolvedor fizer uma aplicação e souber que pode vender para quem tem Android, Symbian, Maemo e BlackBerry, ele vai desenvolver. Mas a empresa responsável não está conseguindo, ou não se importa, em portar para plataforma X, Y e Z. Se fosse código aberto poderiam haver grupos interessados em portar, e assim, popularizar a plataforma. NO caso JavaFX: Fácil desenvolvimento, compatibilidade com Java (você pode usar o GDATA do Google para criar apps usando os serviços deles, por exemplo), mas ainda faltam boas ferramentas e componentes de interface melhores, O QUE PODERIA ser feito pela comunidade, se fosse código código aberto.
Mesmo sem ser código aberto temos muitas ações de terceiros, algumas que até eu participo, no entanto, muito dos trabalhos são meio que hacks, pois não temos o código, mas precisamos de componentes pra construir aplicações…
Desculpem os parágrafos desconexos, é que escrevi essa resposta “aos poucos”.
[Opinião pessoal]
Gosto muito de Javascript e dessas bibliotecas alto nível, como o JQuery, mas prefiro programar com uma linguagem de GUI, como Java Swing, JavaFX, etc.
[/Opinião pessoal]
[quote=Leonardo3001][quote=juliocbq]O objetivo do jfx seria rodar neles, não competir. Acabei de saber que o mono vai compilar para android também, então provavelmente o silverlight vai estar no android.
http://www.go-mono.com/monodroid/[/quote]
O Mono/C# seria compilado, como bem você disse. Na aplicação alvo, não existe mais a plataforma .Net, apenas o binário Android normal. O Silverlight é uma criatura diferente, deveria haver um plugin para o browser do Android que interpretasse os bytecodes típicos do Silverlight. Não acho que a criação de um compilador usando Mono implica uma criação fácil para um plugin Silverlight.
O JavaFX competiria com o Android. A ideia original era haver um JavaFX Mobile (possivelmente um sistema operacional), cujos detalhes nunca foram defiidos, mas que seria um substituto (ou uma alternativa) ao J2ME. E mesmo que o JavaFX fosse para rodar num dispositivo via browser, competiria sim com Android; uma vez que um desenvolvedor crie um programa para Android, ele não vê beneficio em portá-lo para uma outra linguagem/plataforma visando os mesmos dispositivos.
[/quote]
Eu imagino que javafx não se transforme em plataforma não, apesar de ter visto mesmo algo sobre isso se não me engano no site da sun. O jfx mesmo sem ser uma vm já é interessante de usar em um smartphone, até porque a linguagem não é difícil.
Revivendo esse tópico.
JavaFX virou open source e será parte do Java 8.
