Muito útil João suas informações. Serve especialmente para nos manter de olhos abertos e enxergar que o leque de opções é muito grande para determinadas soluções. Sou fã de Flex/Java mas tenho absoluta certeza que não são e nunca serão canivetes suíços (servem pra qualquer coisa).
Parabéns pelo trabalho e obrigado por compartilhar e nos abrir os olhos. Marcelo Daniel Em 30 de novembro de 2010 12:27, João Saleiro <[email protected]>escreveu: > Boas, > > depois de várias semanas a trabalhar em dois projectos básicos com HTML (5, > inclusivé), Javascript (jQuery) e CSS, deixo aqui os comentários das > conclusões que retirei enquanto responsável pela equipa - do ponto de vista > do desenvolvimento e tendo o desenvolvimento em Flex como base de > comparacão: > > > - *IDE/apoio ao developer: *A maturidade das ferramentas de > desenvolvimento (Aptana+Dreamweaver) está uns bons pontos abaixo da > maturidade dos IDEs de desenvolvimento em Flex (e naturalmente JAVA). > - *Frameworks: *Existem "n" frameworks de desenvolvimento em JS, que > puxam o JS para um patamar muito interessante, mas ainda assim correspondem > a menos de 1/10 das bibliotecas disponíveis no Flex SDK. Sobra (demasiado) > trabalho para os developers no desenvolvimento de componentes, ferramentas > e > bibliotecas utilitárias. > - *Práticas: > * > - *Copy paste: *Ainda impera muito a prática do copy-paste no mundo > HTML, não sendo fácil encontrar recursos bem documentados. Por outras > palavras, é normal encontrar-se no site de qualquer componente > Javascript o > código "copy paste" simples, directo e intuitivo para colocar a coisa a > funcionar; porém nem sempre disponibilizam directamente a > API/documentacão > que é essencial para quando queremos fazer "algo mais" (exemplo: > http://videojs.com ). > - *OOP não é fantástico: *Frameworks JS conhecidas estão > relativamente bem documentadas. Porém, em vários casos a qualidade do > código > surpreende-me pela negativa - ainda se usa pouca composicão/herancas no > mundo JS. Não é que a qualidade habitual do código seja má; > simplesmente não > é é fantástica... > - *Dores de cabeca: > * > - *Compatibilidades entre diferentes browsers e diferentes > dispositivos*: *Ainda* é terrível. Mesmo tendo cuidado e fazendo > código "by-the-book", há sempre um browser que estraga tudo. Ou um > browser > de dispositivo onde a coisa aparece de forma diferente. E mesmo depois > das > coisas estarem no ar, supostamente estáveis, por vezes ainda aparece a > pessoa x ou y a dizer que aparece não sei quê desformatado... E há o > medo do > futuro: " e se sai um browser/dispositivo novo que me lixa tudo?" > - *Magia negra: *Há alguns comportamentos que parecem > inexplicáveis. E há muitos "brick-walls" que vão surgindo pelo caminho > e que > só desaparecem com a experiência de quem já os enfrentou, ou com muitas > pesquisas no Google. > - *Video: *O suporte de vídeo no HTML5 está muito abaixo da minha > expectativa. Foi o meu maior "letdown". Basicamente, algo que normalmente > nos retira cerca de 20 minutos, retirou-nos cerca de 2 a 3 dias: > - O rendering de vídeo HTML5 de cada browser é ainda muito > susceptível aos parâmetros de encoding. Tivemos que testar vários > cenários > para obter uma boa relacão qualidade/bitrate/compatibilidade com > browser(s). > Um mesmo vídeo MP4 que corre bem no Chrome nem sempre corre bem no > iPhone. > Já agora, recomendo vivamente: http://diveintohtml5.org/video.html . > - Para um vídeo correr em vários/todos os browsers, é preciso > colocar no servidor uma diferente cópia desse vídeo com um encoding > diferente para quase cada browser: Mp4, OGV e/ou WebM. Um vídeo de 20 > MB, > necessitará de pelo menos 60 MB no servidor para as cópias restantes. > Agora > imagine-se que queremos ainda diferentes 3 bitrates para o vídeo. > Multiplicando por "n" vídeos... conseguimos facilmente entupir um > servidor. > - O vídeo em HTML5 nos dispositivos móveis só corre em Full Screen, > mediante um "click". Aparentemente não dá para colocar um pequeno vídeo > a > passar embebido num canto. Porém, no meu Droid 2 com Froyo (suporte a > Flash > Player 10.1) o vídeo aparece nos websites embebido nos locais > correctos, sem > qualquer problema. > - O vídeo em HTML5 nos dispositivos móveis não faz autoplay. Isto é > propositado para gerir melhor a largura de banda (e bateria), mas devia > ser > opcional (não sei se é, mas por defeito o autoplay vem desligado). > - Performance: está uns furos abaixo do Flash Player. O mesmo vídeo > HD, em MP4 corre com fluídez no Flash Player 10.1, mas com menor > fluídez em > HTML5 no mesmo browser. Dá-me a impressão que se perdem cerca de 4 ou 5 > frames por segundo, pois parece haver um género de "stutter". > - *Text layouting: *De longe, e naturalmente, a *MELHOR* > característica do mundo HTML. Isto não é novidade para ninguém, mas ainda > assim é sempre importante realcar que o text layouting de HTML é centenas > de > vezes superior ao text layouting do Flash/Flex. > - *Separacão de "contextos": *O desenvolvimento em HTML+JS+CSS é até > BASTANTE confortável e elegante. > - *Performance: *A performance de JS, para uma linguagem não > previamente compilada, é bastante interessante, andando possivelmente a par > e par com a performance do Flash Player dentro do browser SEM aceleracão > por > hardware, e sem recurso a PixelBender/outros. Porém, nota-se demasiado as > diferencas de performance entre diferentes browsers. > - *Ubiquidade: *No que toca a penetracão, apesar dos impressionantes > 98% do Flash Player (no desktop), o conjunto HTML+JS+CSS é de longe aquele > que dá mais garantias que irá correr em mais browsers e dispositivos. > *Porém* é também o mais fragmentado e problemático: tem comportamentos > diferentes em browsers e dispositivos diferentes, o que em certos tipos de > aplicacão é assustador. O Flash Player continua a ser superior no que toca > a > garantir o mesmo em resultado em qualquer sítio que corra - desde que > corra. > > ***Disclaimer: * > > Isto não é um "rant" nem serve para iniciar um "HTML vs Flash", ou um > debate daqueles acesos, mas sim um conjunto de conclusões que retirei (e que > podem estar erradas - e muitas estarão) e que considerei importantes para > partilhar aqui. Tirei mais conclusões, mas estas são as mais relevantes. Só > queria deixar três pontos claros: > > 1. Se o que se pretende é uma aplicacão web a correr no browser, e que abra > em dispositivos móveis, HTML+CSS+JS é a opcão correcta. Esquecam (por agora) > o Flash Player para este efeito (mas pensem no Air) > 2. Se o que se pretende é mostrar texto, formatar texto, gerir texto, > saltar entre documentos, nem pensar em usar a plataforma Flash. > 3. É uma lufada de ar fresco não termos que esperar 30 segundos em > compilacões sempre que se faz uma alteracão ao código :o) > > João Saleiro > -- > João Saleiro > Chief Technology Officer > Tlm 1: +351 916 077 097 Skype: joao.saleiro Tlm 2: +351 968 203 > 370 Email/MSN: [email protected] <jo%[email protected]> > www.webfuel.pt > > -- > Recebeu esta mensagem porque está inscrito no grupo "Mailing List da > Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos > Grupos do Google. > Para publicar uma mensagem neste grupo, envie um e-mail para > [email protected]. > Para anular a inscrição neste grupo, envie um e-mail para > [email protected] <riapt%[email protected]>. > Para ver mais opções, visite este grupo em > http://groups.google.com/group/riapt?hl=pt-PT. > -- Todas as coisas cooperam para o bem daqueles que amam a Deus. -- Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google. Para publicar uma mensagem neste grupo, envie um e-mail para [email protected]. Para anular a inscrição neste grupo, envie um e-mail para [email protected]. Para ver mais opções, visite este grupo em http://groups.google.com/group/riapt?hl=pt-PT.
<<dir_cima_canto.gif>>
<<dir_meio_canto.gif>>
<<esq.gif>>
<<dir_cima.gif>>
<<dir_baixo.gif>>
<<dir_baixo_canto.gif>>
