Desenvolvimento Web ou Desktop, qual o mais fácil?

…eu sei, “web tá na moda”!
minha pergunta: quando é que o desenvolvimento Web terá as facilidades e usabilidade da boa e velha “aplicação desktop”?!?
… aplicações RIA?!?
será que realmente esta abordagem facilita o desenvolvimento??

passei alguns meses pesquisando sobre “como desenvolver web de forma fácil” …
a verdade é que fui pesquisando… Servlet, JSP, Struts, Spring, Mentaway, VRaptor, JSF, JBoss Seam e o Java EE 6 Annotations! :wink:
e nada achei de desenvolvimento rápido; e nessas horas… lembro-me do “swing”, por exemplo rsrsrsrs

NOTA: como foi dito, sei que “web tá na moda” entao, obviamente, sei que serei mui criticado por expor meu ponto de vista mas, o que mais eu quero é desenvolver sistemas pra web de forma REALMENTE fácil… tem como?!?

valeu a todos!

sinceramente, sou novo no fórum, mas não sabia q existiam tópicos tão escrotos! acho que vc precisa rever teus conceitos… abs

valeu mas, rever meus conceitos?!? …sejá mais claro, por favor; ou seja, voltando à minha pergunta: o que deveria utilizar entao para agiliar o desenvolvimento web?

agradeço a participação

Já tentou Seam?

Ou então tente Rails. Dizem que é bem mais produtivo.

Sempre achei o desenvolvimento web muito pouco produtivo e trabalhoso. Mesmo os componentes novos, parecem que foram feitos do avesso. Esse método de postback é horrível.
Entretanto, não dá para negar que é uma facilidade enorme o deploy. Atualizar um único servidor e não precisar instalar absolutamente nada em lugar nenhum, é uma maravilha.

Josueh,
Entendo seu ponto de vista, mas preciso discordar veementemente.
Quem já teve a oportunidade de participar, profissionalmente, de um projeto desktop (eu já), sabe os problemas enfrentados com implantação, atualizações, configuração de máquina por máquina, etc (pegando um gancho na afirmação do ViniGodoy).

Também já tive a oportunidade de trabalhar com aplicações Web em Java e sei que esta pode ser bastante produtiva, sim, se você fizer da maneira correta. Você citou o VRaptor no seu post: eis aí uma excelente opção pra alcançar bons níveis de produtividade. Até porque, se você fizer uso correto da orientação a objetos, e aplicar conceitos de DDD, as suas classes de domínio serão as mesmas pra aplicações desktop e pra aplicações web, só vai mudar a implementação da camada de visualização (e aqui eu incluo o que muitos chamam de controller, como MBs do JSF, etc).
Concordo que o desenvolvimento Java pra Web ainda é muito verboso e ainda depende de muita configuração XML, mas isso tem mudado e a tendência é que melhore ainda mais.

Agora, se você quer produtividade de verdade, conheça Rails* meu amigo. Após ter trabalhando com desenvolvimento pra desktops (delphi, java/swing) e web (jsp, struts, spring, jsf…) posso dizer que sou muito mais produtivo com Rails do que com qualquer outra dessas ferramentas que citei. Sem contar que a qualidade do código é infinitamente superior (tudo bem, podemos dizer que isso se deve à experiência).

Outra coisa que vale frisar: as aplicações ricas não visam melhorar a produtividade do programador, antes porém, tem como objetivo melhorar a experiência do usuário na web (oferecendo o melhor da experiência desktop, aliado à flexibilidade, liberdade e amplitude da web). Outrossim, posso dizer que, com um pouco de experiência, um bom programador pode alcançar excelentes níveis de produtividade com Flex, por exemplo.

De qualquer forma, um bom programador não depende de ferramentas pra ser produtivo. Produtividade se alcança com experiência e expertise.

Bem, tudo isso é apenas minha opinião.

*Te aconselho a dar uma pesquisada sobre DJango também

Nenhum é facil.

Ambos exisgem grande esforço.

Achei o meu post anterior um pouco leviano, mas é que não posso explicar meu ponto de vista em poucas palavras. Então, resolvi explicar melhor como vejo a divisão entre os dois modos de se produzir aplicação.

A grande vantagem das aplicações desktop é o fato de serem, na sua maioria, mono-bloco. Você tem apenas um único grande conjunto de binários, não depende de servidores de aplicação e, principalmente, não terá uma rede separando sua lógica de negócios da view. Sua aplicação também é quem desenha integralmente a interface gráfica, não ficando você a mercê de navegadores diferentes.

Devido a isso, as classes de controle tornam-se praticamente triviais. Não há necessidade de frameworks mais elaborados, que tentam minimizar os impactos da rede, ou aumentar a distribuição. Eventos correm rapidamente de um lado para outro, o que aumenta muito a interatividade do usuário. Você também não terá surpresas quando o servidor de aplicação não se comporta da maneira esperada. Nesse sentido, tudo é muito fácil para o programador.

Aliás, aí está a palavra chave das aplicações desktop: interatividade. Mesmo os mais produtivos dos frameworks web não darão ao usuário a mesma experiência interativa que o desktop dá. Em muitos aspectos, ignoramos esse fato por já estarmos acostumados com o “modus operandi” da web, mesmo sendo uma experiência um pouco menos interessante.

Finalmente, dá para citar que essa arquitetura viabiliza aplicações de tempo real e aplicações que exigem muito processamento, como players de vídeo, ou jogos triplo AAA, aplicações de processamento topográfico, que geralmente são difíceis de se ter via rede (seja pelos atrasos da rede, como no caso do vídeo, ou por exigirem muito do servidor, como é o caso dos jogos e a das aplicações matemáticas).

Entretanto, sua aplicação desktop pode tornar-se complexa se você quiser que ela seja uma “rich application”. Suportar plugins, por exemplo, não é uma tarefa tão trivial.

O inferno no desktop está mesmo no deploy e nos testes de ambiente. Obviamente isso foi muito atenuado hoje em dia, com updates automáticos e a internet. Ainda assim, você nunca sabe em que máquina seu aplicativo está rodando (do contrário da web, onde você normalmente conhece exatamente a infra-estrutura de sua aplicação, com exceção do navegador). Fora que se um erro ocorrer numa atualização ou num update, será difícil descobrir que erro foi esse.

Se você usa componentes mais específicos, como por exemplo o hardware de vídeo, pode esperar custos bastantes elevados com testes. Será difícil garantir sua aplicação para um parque gigantesco de hardware. Fora que, os custos com testes também se elevam por você não ter um log unificado. Como na web vários usuários estão rodando a aplicação simultaneamente, mas em um número reduzido de máquinas, é mais fácil gerar logs consistentes, e descobrir o que gerou determinado problema. Fora que, você não precisará que seu usuário lhe envie esses logs, e convence-lo disso pode ser por sí só uma tarefa bastante complexa.

O fato é que, na maioria das aplicações, o ganho de interatividade do desktop não compensará os custos desse deploy. Isso torna a web extremamente viável. As ferramentas para produção na web também são bastante produtivas, e muitas já contemplam soluções para problemas comuns mais completos do que as soluções já vistas em desktops.

Sem falar também no fato que, como a aplicação está na rede, os usuários sentem que ela está sempre disponível. É prático para um gerente saber que ao viajar, poderá acessar os relatórios da empresa na rede de um hotel.

Finalmente, é muito prático fazer backups da infra-estrutura em aplicações web. Uma vez que o ambiente está sob o controle do programador, você pode fazer backups de banco, aumentar a redundância dos servidores ou mesmo melhorar a infra-estrutura do hardware de maneira totalmente transparente.

Hoje, acho que não cabe mais comparar as duas. Ambas estão ocupando nichos diferentes e, realmente, a web está dominando o mercado de aplicações corporativas, a olhos vistos. O desktop, fica restrito a aplicações de processamento pesado, que exijam muito do hardware, que tenham um requisito de tempo real, ou que devam interagir com algum tipo de hardware específico, como uma webcam (e talvez algum outro caso que eu tenha esquecido).

Pegando o gancho aqui… se estamos escolhendo entre web (entenda-se html via browser) e desktop (entenda-se AWT,Swing,SWT , JFaces ou algum outro toolkit gráfico ) não estamos apenas escolhendo formas de visualização. Web por definição existe o uso de HTTP. Ora, desktop só será alternativa a HTML se o programa tb tiver cmunicação com o AS. Portanto, essa ideia de que aplicações desktop não dependente de servidores de aplicação não é verdadeira e não é interessante para o trade-off. Para escolher, temos que partir da mesma base. Portanto a pergunta seria : visualização em browser ou em desktop ? Em browser vc não precisa desenhar o ciente a menos que queira RIA. Na ausencia de RIA web é muito mais simples. E pode ser a unica alternativa ( por exemplo, e-comerce com dektop é estranho). Na presença de RIA desktop é mais fácil. Sobretudo swing.

O problema é portanto a distribuição. Aplicações web , po definição, não são destribuidas porque é o browser que acessa o site por um endereço pubico. (aplicações web são publicadas, não distribuídas)
Distribuir aplicações desktop pode ser complexo. Mas , mais uma vez, o trade-off só existe se pudermos distribuir via web. Se o usuario não tem internet e precisa usar o sistema o problema da distibuição é igual para ambas as alternativas.
Felizmente existe o JWS. Pode não ser perfeito, existem alguns macetes, mas permite que uma aplicaçõa desktop seja servida como uma aplicação web seria. O problema de ir de máquina em máquina atualizar o software não se coloca mais.

Uma outra opção pouco conhecida/usada é utilizar um Applet. Um Applet permite que uma aplicação com interface desktop seja servida via web, sem usar jws. Atualmente (java 7) não ha mais destinção entre applet e jws do lado do cliente. Vc servir um applet que abre numa janela fora do browser e ela se mantém assim mesmo quando o browser é fechado. A diferença essencial é que com jsw vc não precisa usar o browser nunca (tlv da primeira vez que instala,mas só. Outra opção é instalar por email mandando o arquio jnlp como anexo).

Em ambiente distribuido os desafios de uma aplicação desktop são muitos mais que as aplicações web. Por esta razão é muito mais complexo fazer aplicações desktop distribuidas que web. Mesmo que usando ajax,desktop é mais dificil. Uma opção que veio facilitar é o REST e ai vc pode usar o desktop como um tipo especial (especializado) de browser.

Sergio, até concordo que se você impor as limitações de uma arquitetura à outra, você vai ter os cenários que pintou. Mas a grande questão do meu post era mostrar que, efetivamente, desktop e web atendem a propósitos diferentes.

Se você tem uma aplicação desktop para ser front-end de um servidor de aplicação remoto, provavelmente você está fazendo uma grande besteira. Até pq, vc terá toda a limitação da web, sem nenhuma facilidade do browser. Inteligentíssimo, não?

Da mesma forma, não faz sentido falar em sistema web “sem rede”. Camada de controle complexa, previsão para distribuição, post back, para uma aplicação que está integralmente em uma máquina só? Ou que no máximo vai acessar um BD externo?

bem, Java Web Starter ao meu ver é uma boa (e por que nao, ótima) solução para aplicações em intranet;
seguindo o sergio: deploy pode se “resumir” na criação de um jnlp, por exemplo;

voltando ao RIA, sei que sua abordagem não tem nada haver com produtividade mas, dá pra pelo menos “pensar” em desenvolver uma aplicação web HOJE somente com os componentes básicos do html ?!?
entao, me refiro à desenvolvimento fácil utilizando componentes ricos…

eh, rails tá crescento mas… espero que o Java EE cresca mais ainda! (prefiro programar em Java! rsrsrsrs)