um dia desses estava estudando java 2D para fazer desenhos etc… como o html5 para desenhar (que é uma cópia do java 2D) não usei mais applets e fiz tudo no javascript muito rapido e pratico.
o que vcs acham?
HTML5 Fim dos applets, java2D
A
22 Respostas
V
um dia desses estava estudando java 2D para fazer desenhos etc… como o html5 para desenhar (que é uma cópia do java 2D) não usei mais applets e fiz tudo no javascript muito rapido e pratico.
o que vcs acham?
Acho que pra web o HTML 5 vai ser o grande concorrente do flash player, do flex e do Silverlight. Aliás, um concorrente de enorme peso.
Mas o Java 2D nunca concorreu com esses mercados. Applets não foram um ponto dentro da Sun. O Java 2D é legal pra aplicações mesmo, componentes.
E também para fazer jogos em full screen.
F
um dia desses estava estudando java 2D para fazer desenhos etc… como o html5 para desenhar (que é uma cópia do java 2D) não usei mais applets e fiz tudo no javascript muito rapido e pratico.
o que vcs acham?Acho que pra web o HTML 5 vai ser o grande concorrente do flash player, do flex e do Silverlight. Aliás, um concorrente de enorme peso.
Mas o Java 2D nunca concorreu com esses mercados. Applets não foram um ponto dentro da Sun. O Java 2D é legal pra aplicações mesmo, componentes.
E também para fazer jogos em full screen.
Uma duvida Vini, aqueles joguinho web feitos em java usam o que?
Tipo esse aqui que acho bacana: http://www.miniclip.com/games/trials-mountain-heights/br/
V
Usam Java 2D. Ainda assim, são uma parte muito pequena comparado com o que existe em flash…
S
eu acho que por causa do html5 havera muitas mudanças mesmo, mudanças que até nem podemos prever ainda.
M
Algumas coisas que hoje são feitas e Flash ou até mesmo Javascript, tendem ao HTML5. Mas pra ele desbancar de vez o Flash, Silverlight e JavaFX, ele tem de funcionar igual em todos os browsers, o que até agora não conseguiu.
V
Aliás, o eterno problema. O que o pessoal da normatização deveria fazer é criar um navegador de referência. E todos os navegores deveriam funcionar com o layout igual a esse. Esse navegador não precisa ser rápido, nem muito livre de bugs, só precisa ter um comportamento padrão e confiável. Aliás, ele já serviria até de test bed para coisas do próprio padrão.
Seria uma mão na roda na hora que um implementador ficar na dúvida se uma borda deve ou não acompanhar a margem, ou na hora de resolver qualquer ambiguidade causada pela lingua.
Como a Microsoft faz com o driver de referência do DirectX.
A
eu vi um video do adrew muito leagal diz ele que as familias dos navegadores ja se reunirão e estão melhorando essa diferença entre os browsers (tirando fora o IE)
vai da certo pessoal! Html 5 vai pegar mesmo e se o usuario não tiver suporte a ele não vai conseguir ver seus videos etc… dai a tendecia é eles baixar um firefox mais atual o youtube ja tem video como exemplo usando a tag do html 5!
fiquei uma assitindo sua apresentação
http://blog.locaweb.com.br/archives/1387/webcast-html-5-ja-e-uma-realidade/
A
@ViniGodoy vc que é programador de jogos tem um exemplo no video dele fazendo um game no html5 igual o CounterStrike dentre outros que implementa física!
M
vai da certo pessoal! Html 5 vai pegar mesmo e se o usuario não tiver suporte a ele não vai conseguir ver seus videos etc… dai a tendecia é eles baixar um firefox mais atual o youtube ja tem video como exemplo usando a tag do html 5!
O negócio de vídeo e audio é uma das poucas áreas que o navegador HTML5 vai conseguir fazer sem precisar de plugin, assim que escolhererem um codec. Só que a tag video é bem limitada, é quase que só pra pessoa assistir mesmo, enquanto se usar Flash ou Silverlight, tem mais controles e é bem mais flexível.
L
O Html 5 não vai matar o Applet. Este morreu sozinho.
Não gosto da ideia de um browser de referencia. Prefiro a maneira como feita é hoje, onde determinada proposta precisa estar presente em browsers reais para depois ser aceita como padrão.
O conceito de implementação de referência só é interessante para grandes empresas compradoras de middleware, pois dá a segurança de que tudo o que está no pacote não vai ser mudado. Mas é ruim para os desenvolvedores porque o que pode entrar como padrão são especificações demasiamente complicadas e que não foi testada em situações reais.
O Html 5 não precisa fazer tudo o que o Flash faz, basta que o Html 5 atenda a maioria dos projetos de aplicação web. A Abobe, se quiser se manter no mercado, vai inventar novos recursos pro seu plugin; e quem precisar, usa.
Lembrete:
Html 5 não é só e . Tem também Canvas, Web Sockets, Web Workers, Geolocation, armazenamento local, novos tipos de input, novos elementos CSS… Enfim, é muito mais do que Áudio e Vídeo.
V
Não gosto da ideia de um browser de referencia. Prefiro a maneira como feita é hoje, onde determinada proposta precisa estar presente em browsers reais para depois ser aceita como padrão.O conceito de implementação de referência só é interessante para grandes empresas compradoras de middleware, pois dá a segurança de que tudo o que está no pacote não vai ser mudado. Mas é ruim para os desenvolvedores porque o que pode entrar como padrão são especificações demasiamente complicadas e que não foi testada em situações reais.
Por outro lado, existe o inferno que existe hoje. Necessidade de investir em APIs inteiras, que façam o suporte multiplataforma. Acaba que cada browser torna-se uma espécie de “SO” diferente.
Por mim, um padrão deve ser mesmo padrão.
Mais um motivo para o qual fica complicado se cada browser fizer à sua maneira. Vamos torcer para ficar homogêneo o suficiente para que seja agradável de usar.
J
Não gosto da ideia de um browser de referencia. Prefiro a maneira como feita é hoje, onde determinada proposta precisa estar presente em browsers reais para depois ser aceita como padrão.O conceito de implementação de referência só é interessante para grandes empresas compradoras de middleware, pois dá a segurança de que tudo o que está no pacote não vai ser mudado. Mas é ruim para os desenvolvedores porque o que pode entrar como padrão são especificações demasiamente complicadas e que não foi testada em situações reais.
Por outro lado, existe o inferno que existe hoje. Necessidade de investir em APIs inteiras, que façam o suporte multiplataforma. Acaba que cada browser torna-se uma espécie de “SO” diferente.
Por mim, um padrão deve ser mesmo padrão.
Mais um motivo para o qual fica complicado se cada browser fizer à sua maneira. Vamos torcer para ficar homogêneo o suficiente para que seja agradável de usar.
Muito bem citado. A compatibilidade entre alguns browsers com poucos recursos já tornam a vida dos webmasters e designers um inferno, imagina com esses agora.
O interpretador deveria ser padronizado mesmo.
M
É justamente o contrário: pra algumas funções o HTML5 pode substituir o Flash e Silverlight, mas se não tiver todos os recursos, ele vai substituir somente em algumas aplicações e não nas outras. Isso, partindo do princípio que vai conseguir se padronizar entre os browsers, o que acredito que consiga um dia. Se o Flash continuar mais poderoso, automaticamente o mercado dele está garantido.
Sobre a implementação de referencia, não sei se é a melhor forma, ou se é a especificação. Tem muita coisa que não fica na especificação e o pessoal trabalha diferente. Parece até que fazem de propósito.
J
O Html 5 não precisa fazer tudo o que o Flash faz, basta que o Html 5 atenda a maioria dos projetos de aplicação web. A Abobe, se quiser se manter no mercado, vai inventar novos recursos pro seu plugin; e quem precisar, usa.
É justamente o contrário: pra algumas funções o HTML5 pode substituir o Flash e Silverlight, mas se não tiver todos os recursos, ele vai substituir somente em algumas aplicações e não nas outras. Isso, partindo do princípio que vai conseguir se padronizar entre os browsers, o que acredito que consiga um dia. Se o Flash continuar mais poderoso, automaticamente o mercado dele está garantido.
Sobre a implementação de referencia, não sei se é a melhor forma, ou se é a especificação. Tem muita coisa que não fica na especificação e o pessoal trabalha diferente. Parece até que fazem de propósito.
vide microsoft. Até c++ iso eles conseguem modificar para se adequar aos seus outros produtos.
F
Eu to é com medo desse HTML 5 :lol:
Não bastasse agente ter que estudar as linguagens A, B e C, mais os frameworks X, Y e Z, mais javascript, mais CSS, agora vamos ter tambem que saber “programar” em HTML, sim, pq do jeito que ta ja deixou de ser uma simples linguagem de marcação, até jogo da pra fazer com o bixo :shock:
L
Por outro lado, existe o inferno que existe hoje. Necessidade de investir em APIs inteiras, que façam o suporte multiplataforma. Acaba que cada browser torna-se uma espécie de “SO” diferente.Por mim, um padrão deve ser mesmo padrão.
Tome cuidado. A situação atual dos browsers não é resultado do método atual de padronização, era da insistência da Microsoft em forçar uma plataforma proprietária. Qualquer tipo de padronização, havendo os mesmos interesses, resultaria nos problemas de incompatilidade que temos hoje.
Apesar dos browsers primeiro fazerem a sua implementação para depois padronizar, permita fazer duas ressalvas:
:arrow: hoje em dia, nenhum browser propõe coisas à revelia dos outros, existem conversas entre as organizações que criam browsers;
:arrow: as extensões proprietárias são marcadas com tal (ex.: -moz-border-radius e -webkit-border-radius, para os browsers Firefox e Chrome). Havendo consenso nos detalhes de implementação, todos os browsers passarão a implementar uma coisa única como padrão (mesmo exemplo: tornando-se border-radius).
Outra, ser homogêneo não implica ser agradável de usar. EJB 2.1 é implementado homogeneamente em todos os servidores de aplicações, mas não é agradável de usar.
Entendo o que você quis dizer: extensões proprietárias não são agradáveis de usar. Mas se for usado como objetivo de se obter um consenso mais tarde, encaro como ossos do ofício.
Pra finalizar, o modelo de implementação de referência não funciona quando se lida com padrões abertos. No caso do Java, dava certo porque a Sun tinha controle sobre sua licença, quem não respeitasse o padrão era processado. Pronto e acabou.
Nos padrões web, a coisa é diferente; ninguém está pagando por uma licença de uso. Logo, ninguém tem obrigação legal de ser mero copiador da implementação de referência. Como os fabricantes não vão querer se sentir ratos de laboratório, é melhor que suas ideias sirvam de inputs para os futuros padrões.
L
Mas é justamente isso que eu falei! O HTML 5 vai suprir algumas necessidades que o Flash suporta, mas não tudo. Só que quem precisa dessas “algumas” vai acabar usando HTML 5, deixando o Flash apenas para as necessidades mais avançadas.
V
Não é só da MS, embora até o IE6 ela realmente tenha abusado muito disso.
Existem diferenças entre todos os navegadores, em itens que fazem parte do padrão. Principalmente onde o padrão não é 100% claro. Um exemplo clássico é a tag de margin. A bordinha do link considera a margem em alguns navegadores (IE, Opera) e em outros não (Chrome, Safari, Firefox).
Com o tempo o padrão tende a ir cobrindo esses casos, ou os navegadores que são minoria tentam se adequar ao comportamento da maioria, criando um padrão “de facto”.
Nos meus posts anteriores, não falei em momento nenhum de extensões proprietárias. Isso está fora do padrão e ponto. Lógico que nesse caso, o padrão deve exigir algum tipo de marcação especial, para que quem use saiba exatamente que está usando um recurso proprietário, e faça isso por sua conta e risco e não por acidente, como as que você citou. E acho que elas sejam realmente positivas, já que são propostas para a indústria.
Alguns padrões industriais, como o OpenGL, tem o padrão descrito, implementações de referência e possibilidade de extensões proprietárias.
M
Aliás, o eterno problema. O que o pessoal da normatização deveria fazer é criar um navegador de referência. E todos os navegores deveriam funcionar com o layout igual a esse. Esse navegador não precisa ser rápido, nem muito livre de bugs, só precisa ter um comportamento padrão e confiável. Aliás, ele já serviria até de test bed para coisas do próprio padrão.
Compatibilidade entre browsers é de interesse dos desenvolvedores web e é normal estes acharem que se trata de um problema de natureza técnica quando este objetivo não é alcançado, mas não é o caso, empresas que lançam navegadores no mercado buscam diferenciar e não normatizar.
M
Concordo que não é só o IE, embora seja o mais dramático deles. Além do margin, os atributos cellpadding e cellspacing de uma table o bendito IE usa o default 2, sendo que todo mundo é zero.
Mas em Javascript, o Safari é o que mais me dá canseira.
M
Mas é justamente isso que eu falei! O HTML 5 vai suprir algumas necessidades que o Flash suporta, mas não tudo. Só que quem precisa dessas “algumas” vai acabar usando HTML 5, deixando o Flash apenas para as necessidades mais avançadas.
Se uma ou duas funcionalidade do Flash for possível usando HTML5 (digamos, vídeo e jogos), 99% das pessoas poderão abandonar Flash a despeito dos seus recursos mais avançados, porque eles não usam mesmo.
G
Ameaçará as applets falando em design (java 2D). Applets vão muito além disso. Já fiz applet que ficava escutando porta no client para receber dados do server. Mesmo a WebSockets do HTML5 não faria o mesmo pois ele precisa de uma “connection” fulltime com o server para que o server mande dados.
Criado 28 de agosto de 2010
Ultima resposta 1 de set. de 2010
Respostas 22
Participantes 9