Boa pedida.
Eu acho AS parecido com Java… Diria que uma mistura de Java com C#. Não posso reclamar: gosto bastante de AS. Com o tempo, parece que pega o jeito do negócio.
[quote=serathiuk]Depende cara. Se fosse for usar “GWT Puro”, você vai se quebrar um pouco, pois ele tem poucos componentes próprios e muita coisa deve ser implementada “na mão”. Ele tem componentes mais básicos(na verdade tudo que o HTML tem nativamente, mais um DatePicker). E você vai ter que manjar de CSS(ou ter alguém na equipe que saiba) para alterar a aparência da aplicação. Mas caso queira coisa mais prontas, você pode utilizar GWT com alguma biblioteca de componentes para o próprio. Eu recomendo o SmartGWT e o Ext-GWT(ou GXT, e não confunda com GWT-EXT. Passe longe do GWT-EXT. hehehe). Com qualquer uma das 2 você vai ter uma riqueza de componentes incrivel, e uma grande facilidade do programação. Vai parecer que está desenvolvendo para desktop. Se você já sabe Java e já trabalhou com Swing ou SWT, vai ser bem fácil de se adaptar.
Já no caso do Adobe Flex, você vai ter que aprender uma nova linguagem, o ActionScript 3, que não é dificil. E também ele tem alguns componentes mais simples e alguns avançados em sua distribuição padrão. Se não me engano a parte de Charts é paga. Mas é muito bom, mas você fica dependendo do plugin da Adobe. Eu não vejo tanto problema nisso, mas tem gente que vê. No caso do GWT, como tudo no final vira Javascript, você não depende de plugin nenhum.
Eu já trabalhei com as 2 ferramentas, e trabalho faz 2 anos com GWT. Eu gosto bastante da framework. Gosto bastante do Flex também. Mas pessoalmente eu escolheria o GWT para um projeto.
Mas se for olhar para o mercado em geral, vale mais a pena se dedicar ao Adobe Flex acredito eu.
Ps e Jabá.: E para o pessoal que reclama que no GWT tem que escrever código para criar telas, tem uma novidade. O UIBinder. È uma forma declarativa de desenvolver as telas, que no fim, fica bem parecido com o que o Flex faz com seus MXML’s. Escrevi um artigo sobre a algum tempo. Quem ficar curioso, dê uma olhada aí: http://serathiuk.com/blog/?p=130[/quote]
Por que passar longe do GWT-Ext?
sem duvidas flex
Porque ele está sem suporte. Como o ExtJS mudou a licença de LGPL para GPLv3/Comercial, eles acharam que era viável manter o GWT-EXT com suporte apenas na última versão LGPL do ExtJS, que era a 2.0.2. O problema é que este tem alguns bugs, como memory-leak, problema de renderização e etc. E não dava para fazer um fork do ExtJS, pois apesar de ser LGPL, ele tem uma licença meio confusa em cima dos CSS e Imagens. Mas o que aconteceu é que não dava para dar manutenção no ExtJS LGPL, e o GWT-EXT é um wrapper para ExtJS. Então ficava impossível dar suporte naquilo. Eu cheguei inclusive fazer umas correções lá(tanto que o ultimo commit do projeto é meu), mas é um ferramenta que não é viável para novos projetos. O próprios criador sugere a utilizar SmartGWT(na verdade o SmartGWT é do mesmo criador). Se não me engano até o forum de suporte saiu ou sairá do ar. E no sistema em que trabalho, estamos migrando do GWT-EXT para o GXT(EXT-GWT), por causa de problemas e do suporte. O GWT-EXT é bem problemático. Tem que fazer muita gambiarra para algumas coisas funcionarem direito. Se for usar alguma biblioteca para GWT, vá de GXT, SmartGWT ou Vaadin.
Minha sugestão: Flex + Java + BlazeDS + Hibernate.
Em todas as circustâncias de aplicações Web?
Não.
Você não vai fazer uma página estática com Flex, né? Eu não recomendaria fazer aplicações web empresariais também (se for usar Java e Flex).
Eu não tenho nenhuma experiência com GWT, mas, pelo que ouvi falar, se vc tiver experiência com Swing, creio que não seja tão difícil mexer com o GWT. O básico do Flex é tranquilo (principalmente se usar o Flex Builder - que, infelizmente, é pago), sendo que o que deve pegar mais é a integração Flex-Java, que pode ser feita com o BlazeDS.
[quote=Andre Brito]Não.
Você não vai fazer uma página estática com Flex, né? Eu não recomendaria fazer aplicações web empresariais também (se for usar Java e Flex).[/quote]
Era isso que eu queria ponderar.
Ainda que surjam algumas dúvidas quando se trata de Aplicativos de grande porte.
Em todas as circustâncias de aplicações Web?[/quote]
Para aplicações web sim.
Para sites não.
[quote=Lucas Emanuel][quote=Andre Brito]Não.
Você não vai fazer uma página estática com Flex, né? Eu não recomendaria fazer aplicações web empresariais também (se for usar Java e Flex).[/quote]
Era isso que eu queria ponderar.
Ainda que surjam algumas dúvidas quando se trata de Aplicativos de grande porte.[/quote]
É que isso depende muito… Pra decidir qual tecnologia usar, você tem que tomar como base diversos fatores na hora de desenvolver um software. É isso que difere os programadores de script kids e afins: a capacidade de escolher uma tecnologia com base em um problema. Não dá pra dizer que usar Flex todas as aplicações empresariais é ruim… Existem casos e casos.
De qualquer forma, tenha uma ideia e faça alguma coisa em Flex. É a melhor maneira de se aprender uma tecnologia. Depois vá fazendo isso com outras tecnologias - defina uma aplicação e construa ela… Aí, quando você tiver que resolver um abacaxi (problema) de verdade, você tem cacife pra falar qual tecnologia é melhor pra resolver o problema.
[quote=Andre Brito][quote=Lucas Emanuel][quote=Andre Brito]Não.
Você não vai fazer uma página estática com Flex, né? Eu não recomendaria fazer aplicações web empresariais também (se for usar Java e Flex).[/quote]
Era isso que eu queria ponderar.
Ainda que surjam algumas dúvidas quando se trata de Aplicativos de grande porte.[/quote]
É que isso depende muito… Pra decidir qual tecnologia usar, você tem que tomar como base diversos fatores na hora de desenvolver um software. É isso que difere os programadores de script kids e afins: a capacidade de escolher uma tecnologia com base em um problema. Não dá pra dizer que usar Flex todas as aplicações empresariais é ruim… Existem casos e casos.
De qualquer forma, tenha uma ideia e faça alguma coisa em Flex. É a melhor maneira de se aprender uma tecnologia. Depois vá fazendo isso com outras tecnologias - defina uma aplicação e construa ela… Aí, quando você tiver que resolver um abacaxi (problema) de verdade, você tem cacife pra falar qual tecnologia é melhor pra resolver o problema.[/quote]
André,
Baseado na tua experiência, qual(is) seria(m) o(s) aspecto(s) negativo(s) de aplicações empresariais em Flex?
Abraço
Baseado em minha experiência… Nó! Gostei disso hein? Uhauhua. Não leve por esse termo… Sou um bebe em desenvolvimento de software, não tenho experiência, mas vou falar algumas coisas (e provavelmente erradas, portanto não siga à risca o que vou falar aqui).
A parte de segurança (principalmente). Aposto 10 mangos como vão vir falar que já devem existir frameworks que fazem trabalho e esse tipo de coisa, mas não vou nem retrucar porque senão vai acabar virando aquele tópico de 10 páginas, só com 3 sendo realmente importantes.
Estou trabalhando com EJB atualmente (usando ICEFaces) - na verdade não é que estou trabalhando, entrei em um projeto que está utilizando, aí dei uma estudada. Mesmo assim, sei que o Flex faz integração com EJB e coisa do tipo… Conheço grande parte dos benefícios do Flex quando se tem o Java no back-end. E eu adoro Flex, de verdade.
Mas assim… Eu achei MUITO mais fácil usar JAAS com JSF. Usando rederOnUserRole, fica muito mais tranquilo de fazer muita coisa. Eu sei que esse não é o único benefício do JAAS, mas eu gostei bastante do que vi. A parte de debug também (quando eu estava trabalhando num projeto usando Flex, eu não conseguia encontrar maneiras de debugar o swf com o servidor de aplicação rodando) parece ser muito mais fácil com os ManagedBeans. E agora, com os Web Beans vindo no JEE6… Acho que vai facilitar mais ainda. Além disso, algumas aplicações rodam em máquinas bem ruins. Usar Flash não acho que seria uma boa ideia, porque poderia exigir mais um tanto dos bixinhos ainda. E asim… imagina que você tem uma lista de fotos. Você passaria blob ou a imagem em si? Se passar o blob, vai ser ruim porque a camada de apresentação não é a responsável por pegar os bytes e fazer a imagem (nunca testei isso no Flash, mas acredito que seja dessa forma). Se você mandar a imagem em si pode ser que ela seja tão grande e cause mais estorvo pro usuário apressadinho. Então eu sei lá…
Ressalvo… Gosto muito do Flex. Muito mesmo. Em meus projetos pessoais (que faço pra minha mãe, pro meu cachorro e pra mim), sempre usei Flex porque é uma agilidade danada. Em uma tarde de sábado você consegue fazer uma aplicação gigantesca e bonita. É fácil de usar praticamente tudo quanto é componente no Flex. Parece que não consegui encontrar motivos pra tirar o Flex da cabeça e aceitar que outras pessoas façam coisas com outra tecnologia, mas as vezes acho que o Flex prende demais (cria uma barreira que só é possível de ser atravessada quando se usa remote ou messaging) o programador, quando está lidando com tecnologias de back-end. Eu ainda espero estudar algum framework (provavelmente o Mate ou o Swiz) pra ver se isso facilita um pouco. E eu espero que facilite, porque vou ter argumentos pra falar que o Flex pode ser usado em aplicações comerciais e empresariais (ou seja lá qual for o nome).
Pronto, falei. Me bombardeiem.
[quote=Andre Brito]
Ressalvo… Gosto muito do Flex. Muito mesmo. Em meus projetos pessoais (que faço pra minha mãe, pro meu cachorro e pra mim), sempre usei Flex porque é uma agilidade danada. Em uma tarde de sábado você consegue fazer uma aplicação gigantesca e bonita. É fácil de usar praticamente tudo quanto é componente no Flex. Parece que não consegui encontrar motivos pra tirar o Flex da cabeça e aceitar que outras pessoas façam coisas com outra tecnologia, mas as vezes acho que o Flex prende demais (cria uma barreira que só é possível de ser atravessada quando se usa remote ou messaging) o programador, quando está lidando com tecnologias de back-end. Eu ainda espero estudar algum framework (provavelmente o Mate ou o Swiz) pra ver se isso facilita um pouco. E eu espero que facilite, porque vou ter argumentos pra falar que o Flex pode ser usado em aplicações comerciais e empresariais (ou seja lá qual for o nome).
Pronto, falei. Me bombardeiem.[/quote]
Opa André,
Como pediu, vamos começar o bombardeio rs.
É impossível fazer uma aplicação gigantesca numa tarde de sábado, o mundo não é tão poético rs. O Flex é realmente bom pra muitas coisas. Menos aplicações empresariais, desde tempo de compilação, bugs na IDE e no framework, até a dificuldade que é otimizar o GC dele. A nossa aplicação antes consumia aqui 250MB de memória. Isso é MUITO. Depois de 2 meses pesquisando, mudando coisas, mexendo com o profiler e uma porção de coisas consegui baixar pra 80MB. Que é bem pouco pelo tamanho da App. Isso em AIR.
O negócio é que tem coisas porcas no Flex que irritam demais. Quer avaliar se o servidor está online? Ele faz a avaliação por HTTP. Jeito porco. Pois tem que ter uma servlet ou um endereço pra analisar. E desde quando isso significa que a aplicação está online? Não, não significa. Usar HTTP pra isso é nojento.
Não tem suporte a threads. Não tem mais nem o que falar sobre isso.
Não tem um viewer decente de imagens. Não abre TIF e uma variedade de formatos, isso em algumas aplicações é muito importante.
Pra voce ter uma idéia do que esse problema significa, estamos quase migrando uma boa parte da aplicação pra C# por isso.
E mais uma série de coisas erradas e básicas, como por ex. a forma de fazer reflection no Flex. Como ele faz? Um método que retorna um XML gigantesco sobre o atributo. Isso é decente? Uma gambiarra monstruosa.
Mas ainda acho ele o menos pior, prefiro lidar com isso do meu lado do que ter o cliente com o browser lento por 3000 gambiarras no JavaScript como o GWT faz. Sem contar que é foda mudar os componentes GWT.
[]'s!
[quote=AUser]
(…)
Mas ainda acho ele o menos pior, prefiro lidar com isso do meu lado do que ter o cliente com o browser lento por 3000 gambiarras no JavaScript como o GWT faz. Sem contar que é foda mudar os componentes GWT.[/quote]
O GWT não faz gambiarra nenhuma de Javascript, do estilo “se for IE faz isso, mas se for Firefox faz aquilo”. Ele gera código especifico para cada browser. E o cliente só carrega aquilo que ele precisa para a aplicação funcionar no browser que ele está usando. O único momento em que ele checa qual browser que o usuário está utilizando, é quando ele vai escolher qual arquivo de Javascript carregar. Falando tecnicamente como a coisa funciona, no seu HTML você carrega o arquivo(que ele gera) suaaplicacao.nocache.js, e esse arquivo escolhe um outro que é correspondente ao seu browser. Se você compilar uma aplicação GWT verá que ele irá gerar além do suaaplicacao.nocache.js, várias arquivos com nomes como ‘95AD117982908B4CBF7FB0EE0623C784.cache.html’, ‘A6394F8C489A122F3601C576AD9926AC.cache.html’ ou ‘3F19506E84F9CCA78C783697475D8FF3.cache.html’. Cada arquivo desse, como já disse, é sua aplicação com código específico para determinado browser. O usuário só vai carregar 1 desses, e não todos. E no caso de sistemas com mais de 1 idioma, ele gera 1 arquivo de cada browser para cada idioma se não me engano.
E sobre a lentidão, trabalho em uma sistema com umas 300 e tantas telas feito em GWT, e não acho que ele é lento não. Mas cada caso é um caso.
O único problema que tive usando GWT, não foi nem relacionado ao GWT em si, mas sim a biblioteca GWT-EXT. Que ela tinha vários problemas de renderização. Já o EXT-GWT(GXT), SmartGWT ou GWT “Puro” não tem esses problemas não.
[quote=serathiuk][quote=AUser]
(…)
Mas ainda acho ele o menos pior, prefiro lidar com isso do meu lado do que ter o cliente com o browser lento por 3000 gambiarras no JavaScript como o GWT faz. Sem contar que é foda mudar os componentes GWT.[/quote]
O GWT não faz gambiarra nenhuma de Javascript, do estilo “se for IE faz isso, mas se for Firefox faz aquilo”. Ele gera código especifico para cada browser. E o cliente só carrega aquilo que ele precisa para a aplicação funcionar no browser que ele está usando. O único momento em que ele checa qual browser que o usuário está utilizando, é quando ele vai escolher qual arquivo de Javascript carregar. Falando tecnicamente como a coisa funciona, no seu HTML você carrega o arquivo(que ele gera) suaaplicacao.nocache.js, e esse arquivo escolhe um outro que é correspondente ao seu browser. Se você compilar uma aplicação GWT verá que ele irá gerar além do suaaplicacao.nocache.js, várias arquivos com nomes como ‘95AD117982908B4CBF7FB0EE0623C784.cache.html’, ‘A6394F8C489A122F3601C576AD9926AC.cache.html’ ou ‘3F19506E84F9CCA78C783697475D8FF3.cache.html’. Cada arquivo desse, como já disse, é sua aplicação com código específico para determinado browser. O usuário só vai carregar 1 desses, e não todos. E no caso de sistemas com mais de 1 idioma, ele gera 1 arquivo de cada browser para cada idioma se não me engano.
E sobre a lentidão, trabalho em uma sistema com umas 300 e tantas telas feito em GWT, e não acho que ele é lento não. Mas cada caso é um caso.
O único problema que tive usando GWT, não foi nem relacionado ao GWT em si, mas sim a biblioteca GWT-EXT. Que ela tinha vários problemas de renderização. Já o EXT-GWT(GXT), SmartGWT ou GWT “Puro” não tem esses problemas não.[/quote]
Opa,
Sobre isso que você citou eu sei, mas você já viu o tamanho do JS que ele gera?
Eu estou trabalhando no jBPM 4.0 e criando uns addons pra ele. Essa é a minha pequena porém traumática experiência com GWT. Acho muito, muito lento.
[]'s!
[quote=AUser]
Opa,
Sobre isso que você citou eu sei, mas você já viu o tamanho do JS que ele gera?
Eu estou trabalhando no jBPM 4.0 e criando uns addons pra ele. Essa é a minha pequena porém traumática experiência com GWT. Acho muito, muito lento.
[]'s![/quote]
Mas você está compilando ele com a opção de ofuscação ligada?
E sobre o tamanho, tinhamos um problema na hora do carregamento, pois o arquivo fica com 4MB de Javascript. Daí o carregamento ficava muito lento(mas o desempenho não). Começamos a utilizar a opção de deflate do webserver, e na hora de baixar, o usuário baixa apenas uns 850KB. E habilitamos para fazer cache desses arquivos. E isso melhorou o problema. Mas está assim porque começamos a desenvolver o sistema com o GWT 1.5 MS1, pois no GWT 2.0 já tem formas de você ir carregando a aplicação sob demanda(RunAsync se não me engano), e não tudo de uma vez quando inicia.
[quote=AUser]Opa André,
Como pediu, vamos começar o bombardeio rs.
É impossível fazer uma aplicação gigantesca numa tarde de sábado, o mundo não é tão poético rs. O Flex é realmente bom pra muitas coisas. Menos aplicações empresariais, desde tempo de compilação, bugs na IDE e no framework, até a dificuldade que é otimizar o GC dele. A nossa aplicação antes consumia aqui 250MB de memória. Isso é MUITO. Depois de 2 meses pesquisando, mudando coisas, mexendo com o profiler e uma porção de coisas consegui baixar pra 80MB. Que é bem pouco pelo tamanho da App. Isso em AIR. [/quote]
É mesmo… Acho que exagerei. Mas em uma tarde dá pra fazer muita coisa. Ainda mais se a pessoa já conhece Flex e tem noção do que está fazendo.
Ah isso sim… Tái um gigante benefício do Flex. O Icefaces também leva dessa do Flex, apesar de ser um framework ‘novo’. E sei lá cara… eu não consegui gostar muito de ficar jogando objetos do jeito que o Flex faz com BlazeDS e Remote, saca? Me incomodei um tanto com isso, sei lá porque. Quem sabe depois de estudar algum framework eu mude minha visão.
[quote=serathiuk][quote=AUser]
Opa,
Sobre isso que você citou eu sei, mas você já viu o tamanho do JS que ele gera?
Eu estou trabalhando no jBPM 4.0 e criando uns addons pra ele. Essa é a minha pequena porém traumática experiência com GWT. Acho muito, muito lento.
[]'s![/quote]
Mas você está compilando ele com a opção de ofuscação ligada?
E sobre o tamanho, tinhamos um problema na hora do carregamento, pois o arquivo fica com 4MB de Javascript. Daí o carregamento ficava muito lento(mas o desempenho não). Começamos a utilizar a opção de deflate do webserver, e na hora de baixar, o usuário baixa apenas uns 850KB. E habilitamos para fazer cache desses arquivos. E isso melhorou o problema. Mas está assim porque começamos a desenvolver o sistema com o GWT 1.5 MS1, pois no GWT 2.0 já tem formas de você ir carregando a aplicação sob demanda(RunAsync se não me engano), e não tudo de uma vez quando inicia.
[/quote]
Interessante.
Vou testar e depois dou um feedback.
[]'s e obrigado!
[quote=Andre Brito][quote=AUser]Opa André,
Como pediu, vamos começar o bombardeio rs.
É impossível fazer uma aplicação gigantesca numa tarde de sábado, o mundo não é tão poético rs. O Flex é realmente bom pra muitas coisas. Menos aplicações empresariais, desde tempo de compilação, bugs na IDE e no framework, até a dificuldade que é otimizar o GC dele. A nossa aplicação antes consumia aqui 250MB de memória. Isso é MUITO. Depois de 2 meses pesquisando, mudando coisas, mexendo com o profiler e uma porção de coisas consegui baixar pra 80MB. Que é bem pouco pelo tamanho da App. Isso em AIR. [/quote]
É mesmo… Acho que exagerei. Mas em uma tarde dá pra fazer muita coisa. Ainda mais se a pessoa já conhece Flex e tem noção do que está fazendo.
Ah isso sim… Tái um gigante benefício do Flex. O Icefaces também leva dessa do Flex, apesar de ser um framework ‘novo’. E sei lá cara… eu não consegui gostar muito de ficar jogando objetos do jeito que o Flex faz com BlazeDS e Remote, saca? Me incomodei um tanto com isso, sei lá porque. Quem sabe depois de estudar algum framework eu mude minha visão.[/quote]
Aí eu discordo, rs. Acho BlazeDS a coisa mais elegante que existe. Realmente o negócio é bonito. Relaxa, com o tempo vai se acostumar! xD
[]'s!!!