Avançar para o conteúdo principal

Ahah!

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

Comentários

  1. Amen!

    Produtividade de quem desenvolve e de quem utiliza o produto final.

    PJG

    ResponderEliminar
  2. Olá,
    li 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,

    ResponderEliminar
  3. 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). :-)

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

    ResponderEliminar
  4. 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:

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

    ResponderEliminar
  5. Eu cá gosto de applets. :-)

    Não sou fundamentalista, como prova o facto de praticamente não os usar... mas gosto. :-P

    ResponderEliminar
  6. Penso que se esqueceram de dois factores importantes:

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

    ResponderEliminar
  7. "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.

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

    ResponderEliminar
  8. 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.

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

    ResponderEliminar

Enviar um comentário

Mensagens populares deste blogue

[Off-topic] "Novas" tendências de gestão

Afinal as novas tendências de gestão não são de agora. E as suas consequências também já são conhecidas há muito. Vejam esta carta do Senhor Vauban , Engenheiro Militar e Marechal de França, dirigida ao Senhor Losvois, Ministro da Guerra de Luís XIV, datada de 17 de Julho de 1683. "Monsenhor: ... Há alguns trabalhos nos últimos anos que não acabaram e não acabarão nunca, e tudo isso, Monsenhor, porque a confusão que causam as frequentes baixas de preços que surgem nas suas obras só servem para atrair como empreiteiros os miseráveis, malandros ou ignorantes e afugentar aqueles que são capazes de conduzir uma empresa. Digo mais, deste modo eles só atrasam e encarecem as obras consideravelmente porque essas baixas de preços e economias tão procuradas são imaginárias, dado que um empreiteiro que perde, faz o mesmo que um náufrago que se afoga, agarra-se a tudo o que pode; e agarrar-se a tudo, no ofício de empreiteiro, é não pagar aos fornecedores, pagar baixos salários, ter os piores

Conferência Europeia da Comunidade Alfresco

Já foi há quase quinze dias, mas julgo que ainda será relevante abordar a Conferência Europeia da Comunidade Alfresco, que decorreu em Barcelona no dia 22 de Abril. Com uma audiência de mais de 200 pessoas (a sala reservada estava cheia) vindas de vários pontos da Europa, este evento serviu para que muita gente desta comunidade se encontrasse pela primeira vez face a face. A Alfresco Inc. é uma empresa recente, que apostou em criar uma solução de gestão documental de topo de gama usando o modelo open-source . Considerando que a empresa, no seu terceiro ano de actividade, já atingiu o break-even , parece ter sido uma boa aposta. No arranque da conferência esteve John Powell, CEO da empresa, que falou um bocado sobre a excelente evolução da empresa e abordou a "guerra" entre o modelo de negócios proprietário e o modelo de código aberto. Exemplificou este conflito com o Microsoft SharePoint, que ele designou como "a morte da escolha", justificando o epíteto pelo facto

O que é uma POOL ?

Tenho andado a fazer implementações de mecanismos de pooling em Java 2 Enterprise Edition. Como me parece um conceito algo lato tentei a abordagem do dicionário. Alguns mostram que de facto a palavra é usada para muita coisa. A definição mais comum é "piscina". A que mais me agradou foi o que descobri na wikipedia , onde pooling é apresentada como uma técnica para guardar qualquer coisa que já não é necessária em determinado sitio (a que se chama pool ) com o objectivo de a usar quando necessário optimizando assim a utilização de recursos disponíveis. Partindo para a computação, existem vários tipos de pools: Thread Pool - Conjunto de threads livres que se vão adicionando a um fifo quando não necessárias e retirando quando se quiserem usar. Memory Pool - Conjunto de blocos de memória, todos da mesma dimensão, que se alocam inicialmente e usam à medida que necessário garantindo que o tempo de alocação de memória é constante e a fragmentação minima. Connect