Não consigo descrever como fiquei satisfeito ao ler a última newsletter do Javalobby ("Why is the default answer always a web app?"). Nela, o David Van Couvering questiona a criação sistemática de um "multi-tiered HTML/CSS/JavaScript monster" como resposta a qualquer problema. Em vez disso, ele defende Java Web Start, Swing, e Rich Internet Applications.
Como eu concordo com ele...
Aqui há mais de um ano, quando a Sun anunciou que ia "libertar" o Java, comecei a escrever um artigo cujo título era "Ajax Nonsense, Open Source Java and the return of the Applet". O Sérgio Ferreira convenceu-me que não valia a pena insistir porque AJAX era o que os clientes queriam e por isso não havia nada a fazer. E, como eu tinha mais que fazer, o artigo nunca foi acabado.
Entretanto, a Sun lançou o projecto JavaFX, que mais não é do que o Retorno do Applet. ;-)
E a malta começa a questionar-se, finalmente, se não será demasiado pouco aquilo que se consegue fazer hoje em dia com as arquitecturas aplicacionais baseadas em HTML, Javascript e requests HTTP avulsos - a base do AJAX.
Até que enfim que começamos a repensar a produtividade do que andamos a construir! :-)
Como eu concordo com ele...
Aqui há mais de um ano, quando a Sun anunciou que ia "libertar" o Java, comecei a escrever um artigo cujo título era "Ajax Nonsense, Open Source Java and the return of the Applet". O Sérgio Ferreira convenceu-me que não valia a pena insistir porque AJAX era o que os clientes queriam e por isso não havia nada a fazer. E, como eu tinha mais que fazer, o artigo nunca foi acabado.
Entretanto, a Sun lançou o projecto JavaFX, que mais não é do que o Retorno do Applet. ;-)
E a malta começa a questionar-se, finalmente, se não será demasiado pouco aquilo que se consegue fazer hoje em dia com as arquitecturas aplicacionais baseadas em HTML, Javascript e requests HTTP avulsos - a base do AJAX.
Até que enfim que começamos a repensar a produtividade do que andamos a construir! :-)
Amen!
ResponderEliminarProdutividade de quem desenvolve e de quem utiliza o produto final.
PJG
Olá,
ResponderEliminarli com agrado a mensagem, e a propósito falou-se no JavaFX. Já ouvi falar do Java FX mas na verdade sei muito pouco ou praticamente nada sobre ele. Achei curioso dizer que “o projecto JavaFX, que mais não é do que o Retorno do Applet. ;-) “ não entendi muito bem quando falas “em retorno do Applet”. Em boa verdade os meus conhecimentos e experiencia de Java sao pequenos, tenho feito (com algum entusiaismo) algumas Applets e uns programitas Desktop....nada mais, até pq a realidade do meu local de trabalho baseia-se em Microsoft. Por favor, fala-me um pouco do JavaFX e a analogia com as Applets....e o campo de trabalho possivel com o JavaFX. Estou curioso para perceber o que me será possivel fazer com esta recente tecnologia da SUN.
Obrigado,
Luis Goncalves,
O JavaFX é um projecto da Sun para posicionar a Plataforma Java como concorrente do Flash (e depois, quando a Microsoft o anunciou, do Silverlight). A tecnologia base já existe desde 1997. Trata-se de embeber aplicações de Java em páginas HTML e a isso sempre se chamou "applets". Daí eu dizer que o JavaFX é o "Retorno do Applet" (em inglês impressiona mais). :-)
ResponderEliminarA utilização dos Applets de Java nunca foi muito bem sucedida. Para além de alguns problemas técnicos aborrecidos com a tecnologia a malta queixava-se que tinha que fazer download do Java Runtime Environment, que era muito pesado e que afinal era tecnologia proprietária, porque a Sun levou 10 anos a "libertar" o Java. A Microsoft tentou fazer o mesmo com o ActiveX e falhou ainda mais rotundamente. Quem ganhou com tudo isto foi a Macromedia, com o Flash, que era muito menos ambicioso e acabou por ficar com o "mercado" da interactividade avançada nas páginas web.
Embora o JavaFX tenha uma grande novidade que é a utilização de uma linguagem de scripting para fazer animações interactivas (à semelhança do Actionscript do Flash) a verdade é que o projecto é mais vasto. A ambição da Sun, com o JavaFX, é resolver as queixas dos utilizadores que impediram que os applets se tornassem "a" tecnologia preferencial para a criação de páginas web com grande interactividade. As melhorias previstas incluem uma forte redução do tamanho do JRE que é necessário instalar, novos mecanismos para facilitar a sua instalação e muitas outras adaptações.
A minha teoria, quando a Sun decidiu reposicionar o Java como software livre, era que isso era uma excelente oportunidade para se voltar a ter uma plataforma potente para criar interactividade na web. E de facto a Sun, com o JavaFX está a ir por esse caminho.
Resta saber se ainda vai a tempo. Porque o mercado pode achar que os Applets "já eram". O efeito da moda é tramado. Veremos.
O artigo original está cheio de incorrecoes e falsas assuncoes, que como na maioria dos artigos de opiniao servem apenas para validar o ponto de vista do autor, ainda que este possa ser correcto. Vou apontar algumas dessas lacunas:
ResponderEliminar1)HTTP/HTML is a static, document-oriented protocol and markup.
Está certo para HTML/markup mas nao para HTTP/protocol. Reparem nesta definicao de HTTP feita pelos insuspeitos tipos da IETF:
"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred."
Se isto é um "static, document-oriented protocol" vou ali e já venho...
2)But today there is Java (write once, run anywhere) and Java Web Start (auto-upgrade to all your client machines). They are mature and battle tested.
Primeiro, "write once, run anywhere" era um "wishful thinking" e depois uma "catch phrase" que nunca foi verdadeira. Basta ver a necessidade que houve de subdividir Java em ME, SE e EE. E o obvio falhanco que foram a Applets. Nao quer dizer, no entanto, que nao venha ainda a ser verdade. Mas nao o é agora.
Segundo, dizer que Java Web Start é maduro e testado em batalha é, enfim, optimismo a mais.
3)Dando de barato que o meu entendimento de ingles é tao bom como o frances dos ingleses, creio bem que nao percebo a seguinte frase:
"There is no reason why the server should be responsible for composing the UI for your application. It can be a server, not a UIer."
Por um lado, se e que percebi alguma coisa, existem varias opcoes de RIA/Ajax cujo UI é desenhado no cliente, nao no servidor. Claro que pelo menos um "overhead" inicial tem que vir do servidor, mas e usando Java Web Start? Same-o...
E uma vez que vejo que estao a pensar que "pois mas o Web Start só faz isso uma vez inicialmente e depois so faz actualizacoes parciais", lembro que ha plataformas RIA que fazem precisamente isso, e a prova e que trabalham "offline" qd e preciso.
Dito isto, e para o Fernando nao pensar que estou a implicar com ele, a opiniao geral quer dele quer do autor original é, no geral, tambem a minha:
a) If your application is only going to run on the local network, there is absolutely no need to create a multi-tiered HTML/CSS/JavaScript monster.
Tirando a parte do monstro, nao podia estar mais de acordo...
b)(...)none of that is needed when you have a small number of users, so why create complexity when it's not required?
Esta nao tem monstro, concordo totalmente.
c)Now, if you're building an application to be accessible over the Internet, or if you need to scale, it's a different story.
Correcto e afirmativo, como agente dizia noutras guerras.
Mas para estragar a pintura o autor logo a seguir contradiz-se a ele proprio, senao quanto a letra pelo menos quanto ao espirito do artigo.
i) But even then you can use Java and Java Web Start, and your client application can talk to the middle/web tier using a service API.
Ou seja, o autor comeca por criticar o facto de se escolher uma arquitectura nao apropriada a um objectivo concreto so porque esta na moda, para concluir aconselhando o uso de uma arquitectura nao apropriada a um outro objectivo concreto, so porque é a que ele gosta...
Basicamente, acaba por proclamar um fundamentalismo em detrimento de outro fundamentalismo. E isso é, enfim, ser fundamentalista...
Eu cá gosto de applets. :-)
ResponderEliminarNão sou fundamentalista, como prova o facto de praticamente não os usar... mas gosto. :-P
Penso que se esqueceram de dois factores importantes:
ResponderEliminar- O primeiro é uma das razões que sempre vi apontadas para se passar para aplicações web em vez de java ou outras que requeiram runtimes, que tem a ver com gestão de configuração. É verdade que Java Web Start ajuda, mas há imensos problemas de gestão de diferentes runtimes em ambientes heterógeneos e as aplicações web vieram remover essa questão. Basta ter um browser e funciona, não precisa de permissões específicas.
- O outro ponto, que me parece sempre esquecido, é a acessíbilidade. Hoje em dia, se se faz uma página com cuidado é simples de usar um screen reader para a ler. Mas experimentem usar um screen reader numa java applet e vão ver a bela miséria que vai sair.
E isto é válido tanto para a Internet como para intranets: os utilizadores com necessidades especiais não podem ser negligenciados e representam uma percentagem considerável da população.
"Basta ter um browser e funciona"... no início. Isso é uma enorme falácia, porque a maior parte das vezes fazem-se as aplicações para um ou dois browsers e espera-se que ninguém se lembre de testar dos outros. A verdade é que dá muito mais trabalho fazer aplicações para web do que em GUI tradicional. E o problema da gestão da configuração é grandemente exagerado, como prova, por exemplo, a aplicação das declarações IRS da DGCI que toda a gente usa.
ResponderEliminarPraticamente todos os browsers têm o flash player instalado e ninguém se queixa dos problemas dos runtimes. A Sun está a apostar em conseguir fazer o mesmo com a versão light do Java Plugin para o JavaFX e acho muito bem. A Microsoft idem, com o Silverlight.
Quanto à questão da acessibilidade, parece-me que não se aplica. Isto é: as aplicações GUI com alta interactividade são necessárias - sempre o foram - e isto não entra em conflito com a acessibilidade aos sites. É que uma coisa é um site do Estado que tem que estar acessível a todo o tipo de públicos e outra coisa é uma aplicação "data-intensive" onde a produtividade do utilizador é mais prioritária que a acessibilidade.
Eu quando falei dos problemas de configuração eram em ambientes intranet. Já vi suficientes parques informáticos com utilizadores com restrições imensas nas suas máquinas e com incapacidade de centralizar a gestão dos sistemas. Lembro-me concretamente de andar a mudar Oracle Forms para JSF exactamente por estes problemas.
ResponderEliminarAs aplicações só não funcionam em todos os browsers por falta de conhecimento e falta de vontade. Não é assim tão difícil.
Discordo que seja mais fácil desenvolver GUIs tradicionais do que páginas web, a natureza declarativa da web facilita o desenho de interfaces. O Java FX vai neste sentido mas é, manifestamente, uma tecnologia que não convenceu nada até agora. Eu ainda passei uns bons meses a desenvolver applets e não era sempre pêra doce.
A noção que GUIs tradicionais são mais simples faz também com que não se veja que para fazer uma aplicação dessas são necessários conhecimentos distintos, como seja threading, do que são necessários numa comum aplicação web.
Em relação a acessibilidade, não estamos a falar apenas de aplicações altamente interactivas. Estávamos a falar de um modelo diferente de desenvolvimento de aplicações e dum ponto de vista generalista. E se se generaliza a tecnologia - e numa empresa é normal haver uma escolha de pilha tecnológica - a maioria das aplicações, altamente interactivas ou não, mais ou menos ricas, são feitas dessa foram. E a acessibilidade é importante não só na web como no local de trabalho, especialmente quando há possibilidades igualmente produtivas que dão mais hipóteses.