• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

djthyrax

AJAX-powered Web apps disappoint power users, Forrester says

18 mensagens neste tópico

Performance issues and complexity hobbling attempts to use rich AJAX apps for daily work

Most power users are disappointed with the performance of Rich Internet Applications (RIAs) based on Asynchronous JavaScript with XML, or AJAX, according to a new research report from Forrester Research Inc.

As a result of the AJAX limitations, the research firm recommended that business users consider emerging next-generation RIA technologies like Adobe AIR from Adobe Systems Inc. and  Microsoft Corp.'s Silverlight tool set.

According to the report, which was released late last week, power users find that AJAX applications are very complex and their reaction time is limited. The reaction time and general speed of user interaction is always limited with AJAX business applications, the report said.

"The local rendering of complex business screens requires serious client CPU time," the report noted.  "A European retailer that wanted to migrate screens from a Visual Basic rich client to AJAX reported initial load times for complex screens of many seconds. Given the nearly instantaneous display of the old client app, this was annoying for power users."

In addition, because most AJAX frameworks tend to keep all real business logic on the server as opposed to local systems, user interactions may require a roundtrip communication between the browser and server for each input field. Some large applications could easily have 50 fields on a single screen.

As a result, AJAX developers told Forrester that they had to reduce real-time input validation compared with traditional rich clients to meet performance requirements. Real time input validation is a top priority for power users, the report said.

Forrester said that as AJAX framework vendors work hard to overcome these barriers, they have encountered additional problems. For example, improvements in bandwidth have not led to expected AJAX performance gains. "Bandwidth has widely improved and people are starting to realize that many AJAX applications have not speeded up accordingly," Forrester noted.

In addition, most corporate desktops run a virus scanner that investigates each line of JavaScript, which slows the rending performance of the browser, the report noted.

The problems likely could be overcome if AJAX vendors and browser companies moved in the same direction to fix them, but Forrester noted that the opposite is actually true. Microsoft is investing in AJAX alternatives like Silverlight while Mozilla lacks the "hundreds" of developers it would need to fix the problems. Meanwhile, Apple's Safari has not been widely adopted for a software vendor to rely on it as the browser of choice.

In the report, Forrester tasks application vendors to concentrate on the needs of power users versus occasional users and to evaluate new rich client platforms as possible alternatives to AJAX. Specifically, mid-sized application vendors evaluating an AJAX framework should also consider the Microsoft and Adobe approaches, the report advised.

Larger vendors should evaluate Adobe and Microsoft's technology seriously, but stick to traditional client technology until the new offerings mature. Large vendors can also consider investing in the Tamarin project - a Mozilla-hosted open source effort that aims to build the next generation JavaScript engine. Tamarin will also contribute to the further development of Firefox.

These companies should also look at the new generation of metadata driven Java clients from niche vendors, the report said. "Using a client-side framework and paying careful attention to detail might allow business application vendors to work around some of the problems," Forrester noted.

"You might have to implement some business logic twice - in the client AJAX framework and in server-side transactions," the report added. "And while browsers might become faster, you should plan to test for both Internet Explorer 7 and Internet Explorer 8 until Internet Explorer 8 becomes mainstream."

For the study, Forrester studied three types of AJAX applications that are replacing traditional client applications: AJAX-driven mash ups, a gradual re-factoring of an HTML page using AJAX and using AJAX to completely replace an enterprise application.

in: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9071039

Ainda gostava de saber o que os gajos beberam antes de escrever o artigo... Srsly, um sistema simples em AJAX tem muito menos consumo de recursos no cliente do que o Flash, mas vá-se lá perceber estes gajos...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Bem escrito esse artigo.

Esta limitação é bem real e todos a conhecemos. Basta comparar a responsividade do gmail com a de um cliente de email tradicional.

Está-se a usar o http juntamente com os nossos browser como plataforma, e eles funcionam, mas a verdade é que não foram feitos, pelo menos inicialmente, para este tipo de uso.

Com a chegada do ipv6 já vai ser possivel controlar a responsividade de uma ligação, as coisas vao melhorar um pouco, mas há custos associados em equipamento de redes, ficamos um pouco à mercê dos ISPs.

O que e pena é ter-se usado o javascript que é uma coisa que está implementada de forma muito diferente de browser para browser. Mas não havia melhor :S

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

O que e pena é ter-se usado o javascript que é uma coisa que está implementada de forma muito diferente de browser para browser. Mas não havia melhor :S

Espera-se mudar isso com o JavaScript 2.0 (que por acaso querem mudar-lhe o nome :)).
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Espera-se mudar isso com o JavaScript 2.0 (que por acaso querem mudar-lhe o nome :)).

Vamos todos fazer figas... uma das razões pelas quais nunca escrevi muito javascript é por me desanimar ao olhar para código em que apenas 30 ou 40% não são bugfixes ou coisas especificas do browser XPTO.

Javascript 2.0 e HTML 5 ... venham eles!

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Em relação ao HTML5, não estou muito ansioso para o receber, estou mais para o XHTML 2.0

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Ajax pode ser lento, mas daí a incentivar-se o uso de Silverlight....

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Infelizmente, no trabalho num dos projectos tivemos a infeliz ideia de ter o BackOffice em AJAX para nas linhas de montagem visualizar estatísticas em tempo real.

Foi um fracasso completo. O PC como é normal numa linha de montagem na indústria está longe de ser topo de gama. No nosso caso era equipada com Windows 98. Mas acho que se fosse na mesma um PC mais recente teria-mos problemas na mesma, se calhar não tão graves, mas acho que continuariam a existir. Perdemos muito tempo a volta disto, depois acabamos por seguir uma outra via que até se revelou melhor e esquecemos o BackOffice, mas gostava de ter experimentado com um Windows mais moderno para saber se o problema também estava relacionado com o SO.

Simplesmente os browsers ainda não têm a capacidade para serem usados como uma aplicação real. O nosso BackOffice funcionava em AJAX e tinha tipo um temporizador que de X em X segundos ia averiguar ao servidor variadas estatísticas. Para além da página ser bastante pesada e demorar algum tempo a carregar, o principal problema era mesmo do tempo de execução. A linha está praticamente a trabalhar 24h sobre 24h. O browser ao fim de algumas horas, simplesmente ficava incrivelmente lento. Experimentamos variadíssimos browsers (que funcionassem em Win98) todos eles sofriam do mesmo problema mais cedo ou mais tarde. Após várias melhorias na página e vários browsers testados o melhor que se conseguiu foi com o k-meleon a durar cerca de 4 a 5 horas, após isso o Windows começava a perder performance até que simplesmente ficava incapaz de se trabalhar.

AJAX é uma tecnologia porreira e veio trazer uma melhoria significativa para aplicações web. Mas os browsers ainda têm de melhorar muito até que se pondere ter aplicações comerciais no mesmo. Ainda é algo muito verde e de pouco confiança. E por experiência pessoal, tão cedo não vou sequer ponderar em fazer uma aplicação novamente em AJAX.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Betovsky, e desactivaram o caching do browser? Limparam as variáveis que deixam de usar? Parecendo que não, é algo que faz toda a diferença. Já passei por situações semelhantes, tanto com AJAX puro e duro como com Flash (como end-user). :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Betovsky, e desactivaram o caching do browser? Limparam as variáveis que deixam de usar? Parecendo que não, é algo que faz toda a diferença. Já passei por situações semelhantes, tanto com AJAX puro e duro como com Flash (como end-user). :)

Não faço a mínima ideia. Apesar de também ter estado nesse projecto eu estava mais encarregue no desenvolvimento de uns terminais. Portanto não sei os detalhes da implementação. Mas presumo que sim, visto que o meu colega esteve à volta de 1 mês a investigar várias documentações para optimizar ao máximo a página... De na altura de falar com ele, acho que o problema devia ser uma memory leak, algo que pelos vistos é muito fácil de fazer em javascript...
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não faço a mínima ideia. Apesar de também ter estado nesse projecto eu estava mais encarregue no desenvolvimento de uns terminais. Portanto não sei os detalhes da implementação. Mas presumo que sim, visto que o meu colega esteve à volta de 1 mês a investigar várias documentações para optimizar ao máximo a página... De na altura de falar com ele, acho que o problema devia ser uma memory leak, algo que pelos vistos é muito fácil de fazer em javascript...

Não é bem bem memory leak no sentido bug. Essa memory que falas pode ser devido a vários factores:

-> Ter o caching do browser enable (na minha opinião, a maior provável)

-> Não ter implementado algo tipo gargabe collector quando vai pedir ao servidor actualizações (e aliado a isso, não ter optado por enviar para o cliente, por exemplo, um objecto JSON com informação para o browser processar mas enviado logo o logo o output directamente que o browser tinha que fazer).

Mas também, mais detalhes só vendo o código...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não é bem bem memory leak no sentido bug. Essa memory que falas pode ser devido a vários factores:

-> Ter o caching do browser enable (na minha opinião, a maior provável)

-> Não ter implementado algo tipo gargabe collector quando vai pedir ao servidor actualizações (e aliado a isso, não ter optado por enviar para o cliente, por exemplo, um objecto JSON com informação para o browser processar mas enviado logo o logo o output directamente que o browser tinha que fazer).

Mas também, mais detalhes só vendo o código...

Não. Eu refiro-me mesmo a memory leak, uma verdadeira memory-leak. Já não tenho a certeza, já foi à 1 ano atrás, mas é daquelas memory-leak em que o processo vai comendo memória até já não haver mais nada para comer, ou seja, daquelas verdadeiras memory-leaks. Daí o Windows passado algum tempo deixar de funcionar em condições, já que a memória já tinha ido toda a vida. Mas tinha a sensação que era algo usual, e pesquisei pelo google e não estava enganado. O que não faltam são páginas a falar de memory-leaks em javascript.

Em relação ao 2º ponto não percebi. Não ter implementado Garbage Collector? Isso não é responsabilidade do browser? Como é que um pedaço de software implementa garbage collector sobre ele próprio? Em relação ao JSON não faço a mínima, como sabes eu sou um pato em webdev e fujo dessa secção como o diabo foge da cruz. Mas todas (acho eu que eram todas, pelo menos eram a maioria, não sei se o meu colega fazia algum manualmente) das transacções entre cliente-servidor era através do AJAXtoolkit para ASP.NET.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Em relação ao 2º ponto não percebi. Não ter implementado Garbage Collector? Isso não é responsabilidade do browser? Como é que um pedaço de software implementa garbage collector sobre ele próprio?

Quando tens um loop "infinito", o browser não te trata dessas variáveis. :) E eu disso "algo tipo garbage colector".
Em relação ao JSON não faço a mínima, como sabes eu sou um pato em webdev e fujo dessa secção como o diabo foge da cruz. Mas todas (acho eu que eram todas, pelo menos eram a maioria, não sei se o meu colega fazia algum manualmente) das transacções entre cliente-servidor era através do AJAXtoolkit para ASP.NET.

JSON é uma notação para descrever objectos em JavaScript (JavaScript Object Notation), e é código JavaScript válido. Um dos erros (na minha opinião) que vejo muito é o pessoal devolver ao cliente o resultado que o user quer ver, e não as informações para o cliente poder processar à sua própria maneira.
0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Tive problemas semelhantes, com uma aplicação AJAX para substituir uma aplicação rica para desktop, os browsers simplesmente não aguentam a quantidade de pedidos e validações necessárias, o firefox começa a consumir memória a torto e a direito, o IE então nem se fala.

A aplicação ficou bastante interessante e tinha a vantagem de usares apenas o browsers, de correres em qualquer PC com qualquer SO e outras vantagens agradáveis como a interface que os utilizadores gostaram, mas a aplicação simplesmente não pode ser executada muito tempo, e apesar de não ter de correr 24/7 tem de estar a funcionar o número de horas de trabalho.

Aplicações simples sim, aplicações mais complexas não acho que compensa. Eu bem me incomodo quando abro o Gmail e o FX bloqueia um segundo, é que param todas as tabs de fazer seja o que for, é frustrante :)

Não sou muito de esperar para ver, comparando com Silverlight que é extremamente mais rápido, se só tivesse de programar para Microsoft não pensava muito, era Silverlight e pronto. Mas pode ser que venham melhorias.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu sei que não está muito relacionado com o tópico, mas essa do HTML 5 e XHTML 2 deixa-me um bocado preocupado... Não sei bem explicar porquê e o que sinto, mas não sei, tenho um bad feeling que isso vai ser uma dor de cabeça no futuro e que não me agrada esse futuro.

Talvez se apenas existisse um novo standard, por exemplo, XHTML 2, acho que ficava mais descansado, mas depois do que li sobre estes standards, não sei não, acho que me vai dores grandes dores de cabeça. Notem que não estou a dizer mal porque vai ter features muito interessantes.

Se acharem que esta discussão tem pano para mangas, criem novo tópico...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu acredito que resolverá muitos problemas. O HTML4 foi feito numa altura que era por coisas a funcionar à bruta a torto e a direito, sem alguma vez pensar em standards. Hoje as coisas são feitas com muito mais rigor tecnico.

O djthyrax é que pôs as coisas de uma forma um pouco esquisita.

Ninguem vai ter que escolher entre XHTML ou HTML.

XHTML é simplesmente um conjunto de restrições extra que garantem que o html seja xml válido. Mas o formato sintático do html continua intacto.

Hoje em dia qualquer aplicação que veja a luz do dia devia fazer output de XHTML váliso, idealmente toda a web seria em xhtml válido, não sendo, o browser deiva dar um aviso de segurança antes de mostrar a página.

Dessa forma podia separar-se o desenvolvimento do parsing do html de outras coisas como indexação de páginas web.

Por exemplo, se desenvolvermos um motor de busca, o indexador tem estar apetrechado de mecanismos de segurança para evitar erros devido a html mal formado.

Mas, para afugentar os fantasmas... nazgulled, isto vai ser projectado e implementado numa fase em que as tecnologias web, apesar de estarem em bom ritmo de desenvolvimento estão estáveis. Vão ser considerados todos os erros do passado, etc. Não há nada a temer, antes pelo contrario, há é usar os benificios da tecnologia :)

Afinal de contas, tirando o atom e o rss, a web tem sido assim mistura de tecnologias postas juntas de qualquer maneira, pois ainda estamos nos primordios da internet.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Eu sei disso e eu nunca disse que não iriam resolver muitos problemas. Simplesmente faz-me alguma confusão...

Eu sou um gajo muito picuinhas e gosta de ter tudo bem feito ao pormenor, seja em PHP, XHTML, CSS, JavaScript (principais linguagens que uso em desenvolvimento de sites). Para teres uma ideia, um script que ando a fazer há uns tempos, já não sei do mesmo sitio há uns meses e porquê? Porque ultimamente só tenho melhorado pequenos pormenores no código e apenas isso, não tenho realmente avançado com o código e com as implementações de funcionalidades que faltam, mas feito melhoramentos. Isto porque tamos sempre a aprender e cada dia que passo descubro uma maneira nova e melhor de fazer as coisas, então, perco tempo a mudar o código e a melhora-lo em vez de finalmente acabar o raio do script.

Isto para a dizer que quando chegar o XHTML 2.0 (porque o HTML 5 não me interessa e não tenciono fazer sites em HTML 5) com as novas funcionalidades que eles estão a implementar, vai-me dar vontade de modificar tudo que fiz até hoje adoptando estes novos standards, que foram pensados para ser melhor, suponho eu. E como tal, eu queria usa-los, para o meu código continuar a ser moderno e actualizado com os standards. E isso vai dar muitas dores de cabeça e vai criar muita confusão, pelo menos a mim.

Fiz-me entender ou nem por isso?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

[off]

Naz já percebi que fazes os sites por conta própria e sozinho. Há uns anos também tive problemas desses. Estava sempre a alterar, a melhorar, cheguei a ter um projecto durante 2 anos.. e nunca o lançei.. Isto é só um aconselho; tenta arranjar uma lista de objectivos com prioridades, e no final se sobrar tempo vais melhorar o que já está feito. Cumprimentos.

[/off]

Li há uns tempos um artigo que dizia que as tecnologias/arquitecturas web estão a evoluir muito mais rápido que os browsers. Nada mais verdade.

Também já pensei muitas vezes em substituir back-offices complexos por aplicações AJAX.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

[off]

Naz já percebi que fazes os sites por conta própria e sozinho. Há uns anos também tive problemas desses. Estava sempre a alterar, a melhorar, cheguei a ter um projecto durante 2 anos.. e nunca o lançei.. Isto é só um aconselho; tenta arranjar uma lista de objectivos com prioridades, e no final se sobrar tempo vais melhorar o que já está feito. Cumprimentos.

[/off]

Mas eu já tenho uma lista, só que quando descubro algo novo que me atraia, não resisto em adaptar o meu código para ficar melhor. Não consigo evitar que queres... devo ter algum problema lol. E claro que faço sozinho, só faço isto como part-time, ainda sou estudante, não estou no mercado de trabalho, talvez um dia... :)

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora