Qual á mais difícil de aprender: GWT ou Flex

São ferramentas diferentes. O GWT gera código javascript para o browser enquanto o Flex gera Flash.

Eu, pessoalmente, prefiro evitar flash sempre que possível. Há quem goste.

Questao de peso do código, o flash pesa mais ne?

É sempre importante pensar no objetivo para escolher… não conheço muito sobre GWT mas o Flex é muito bom, e cada vez vem ganhando mais espaço

Atualmente estou trabalhando com flex e java, já trabalhei com o richfaces, e achei o flex bem mais produtivo, quanto ao gwt não sei te dizer porque nunca usei.
O flex está ganhando mercado, acho que vale a investida.

Sem duvida GWT.

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

E quando se trata de apoio da comunidade e a durabilidade da tecnologia?

Sobre comunidade, o GWT é código aberto e tem total suporte do Google. O Google utiliza muito ele em suas aplicações. Dos produtos do Google que vi que são desenvolvidos em GWT, se destacam o Orkut, Analytics, Sitemap, o gerenciador do Adsense e o Google Wave(inclusive as apps deles utilizam essa tecnologia). O desenvolvimento sempre está ativo e tem uma lista de discussão de suporte onde os próprios desenvolvedores da ferramenta participam. Sobre as bibliotecas de terceiros, o Ext-GWT tem um desenvolvimento crescente e eles dão um bom suporte a ferramenta. O fórum deles são bem esclarecedores, quase tudo que você tem duvida normalmente já está respondido lá ou demora pouco tempo para responderem. O SmartGWT tem um forum bem ativo também. O Adobe Flex tem bastantes foruns sobre o assunto espalhados por aí e tem uma excelente documentação da Adobe. Sobre comunidade e documentação, o Flex ganha bonito do GWT. È bem mais fácil achar artigos e discussões sobre Flex.

Sobre durabilidade da tecnologia, ambas tem grandes empresas por trás, e empresas que acredito que não abandonariam ou fariam uma grande alteração no licenciamento do projeto de uma hora para outra. O GWT está sempre em manutenção e evolução. Tanto que desde que comecei a utilizar, a ferramenta evoluiu muito. Posso dizer a mesma coisa do Flex. Ele começou a evoluir muito desde que leva o nome da Adobe e o código da SDK foi aberto. Acho que com qualquer uma das duas vai estar bem servido. E sobre o GWT, uma coisa interessante, é que desde a primeira versão que utilizei, ele evoluiu, mas não teve alterações que quebrassem compatibilidade. Até mesmo a versão 2.0(que está no Milestone 2), não quebra compatibilidade com versões mais antigas.

Particularmente acho GWT mais fácil de utilizar do que Flex e gosto mais do GWT. E me agrada não precisar de plugins para rodar a aplicação.

Mas vai de fazer os testes básicos e ver o que te agrada mais.

Se a pessoa se aprofundar bem em JavaScript, Ajax e Jquery faria a mesma coisa?

Isso sem dúvidas que sim.

Mas o público alvo do GWT e do Flex é os desenvolvedores que querem desenvolver aplicações de internet rica sem se preocupar com Javascript, e sem se preocupar se no navegador X ou Y o negócio vai funcionar direito. Claro que no caso do desenvolvimento com JQuery você elimina grande parte desse problema, mas ainda sim deve se preocupar com ele.
Já caso do GWT, você programa em Java e quando for “compilar” a aplicação ele gera um código específico para cada navegador, sem nenhum tipo de workaround(e/ou POG).
Já no caso do Flex, é tudo SWF e funciona via plugin, abstraindo o navegador.

Na minha opinião, seria muito mais interessante aprender XHTML, CSS e JS com jQuery BEM do que aprender GWT…

Eu estava pensando nisso também. Mas o JS é bem lerdo para produzir um único componente, não é?

Com GWT a produtividade aumenta??

Concordo. Se for para ter uma ordem de prioridades do que aprender, acho que aprender XHTML, CSS e JS é bem mais vantajoso, pois você entende o que o GWT ou qualquer outra framework baseada em componentes que você pode utilizar vai fazer por “baixo dos panos”. Isso eu acho essencial entender. Mas sobre o que usar em um projeto, eu acho que o GWT é mais produtivo do que um projeto com jQuery. Mais isso vai de cada pessoa e de cada projeto.

Eu atualmente desenvolvo um componente mais rapidamente com GWT do que com jQuery. Mas o problema(pode ser problema para algumas pessoas) em desenvolver um componente para o GWT, seria que o componente ficaria específico ele. Se você quisesse usar em um projeto JSF, você não conseguiria sem quebrar um pouco a cabeça.
Mas nada impede que você implemente um componente com o jQuery e o utilize com o GWT, criando um wrapper para ele. Assim o componente em JS poderia ser usado em outros projetos com outras tecnologias. O SmartGWT funciona assim. Ele não é nada mais que um wrapper para as classes Javascript da biblioteca Smartclient. O finado GWT-EXT também fazia a mesma coisa, mas era um wrapper para o ExtJS. Se ficar interessado por essa parte dos wrappers para componentes JS, dê uma estudada sobre JSNI.

Eu vi nos sites demonstrativos do GWT vários componentes legais. Se aprender somente Xhtml Css e JS com Jquery é possivel fazer os mesmos componentes?

Trabalho a 2 anos com JAVA e a 1 ano com flex 3, a curva de aprendizagem para o flex é muito grande para quem ja sabe java, por isso eu acho que flex é mais fácil.

Isso é possível sim. Mas acredito que tenha que se aprofundar bastante nessas essas tecnologias para desenvolver uns componentes mais complexos. E no caso do jQuery, tem muita coisa pronta por aí para ser usada.

Isso é possível sim. Mas acredito que tenha que se aprofundar bastante nessas essas tecnologias para desenvolver uns componentes mais complexos. E no caso do jQuery, tem muita coisa pronta por aí para ser usada.

Qual que dá mais trabalho de aprender ou usar?

Faz o seguinte: aprende XHTML, CSS e Javascript, depois jQuery. Depois, você entende um pouco do GWT. Nem tudo que tem no GWT você vai usar… Sabendo das coisas que tem nele, quando você precisar você corre atrás… Digo isso porque acho que é muito mais provável que você vá usar mais XHTML, CSS e JS do que os componentes do GWT em si.

Uma boa pedida é o ICEFaces também… Eu achei que ele já montava interfaces bem bonitas, como acontece com o Flex, mas vi que dá pra manter a simplicidade total com ele. Gostei bastante.

Andre Brito:

Faz o seguinte: aprende XHTML, CSS e Javascript, depois jQuery. Depois, você entende um pouco do GWT. Nem tudo que tem no GWT você vai usar… Sabendo das coisas que tem nele, quando você precisar você corre atrás… Digo isso porque acho que é muito mais provável que você vá usar mais XHTML, CSS e JS do que os componentes do GWT em si.

Uma boa pedida é o ICEFaces também… Eu achei que ele já montava interfaces bem bonitas, como acontece com o Flex, mas vi que dá pra manter a simplicidade total com ele. Gostei bastante.

Acho que vou fazer isso mesmo. Xhtml e Css tenho boa base, preciso me aprofundar em JS. Tenho aplicações em Java+Flex, porem unica dificuldade que tive foi ter de aprender AS3. Nunca me dei bem com flash.

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.

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

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.

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).

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?

Para aplicações web sim.
Para sites não.

Lucas Emanuel:

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).

Era isso que eu queria ponderar.

Ainda que surjam algumas dúvidas quando se trata de Aplicativos de grande porte.

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.

Andre Brito:

Lucas Emanuel:

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).

Era isso que eu queria ponderar.

Ainda que surjam algumas dúvidas quando se trata de Aplicativos de grande porte.

É 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.

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.

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.

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!

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.

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.

serathiuk:

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.

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.

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!

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!

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.

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.

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.

serathiuk:

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!

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.

Interessante.

Vou testar e depois dou um feedback.

[]'s e obrigado!

Andre Brito:

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.

É 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.

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!!!

Achava que o flex fosse apropriado para aplicações empresariais… até pq, o que mais chama atenção do flex são os componentes prontos dele.
É possível debugar o código actionscript no eclipse?

rjdiogo,
Sim é possível, inclusive de forma remota: http://fabiophx.blogspot.com/2010/01/debug-em-producao.html

[]s