funmachine


Deixe um comentário

An Open Web

Esta força toda que tem surgido em torno do movimento Open Web tem pouco a ver com uma perspetiva puramente técnica de desenvolvimento com tecnologia Web – HTML5 e JS e CSS, etc. É muito mais que isso. Para quem desenvolve para a web no dia a dia, percebe facilmente que ainda estamos muito longe de ter tecnologia completamente agnóstica que corre em qualquer dispositivo de forma nativa. Podemos correr web apps em qualquer browser, que por sua vez existem em qualquer SO, mas ainda estamos muito longe de ter uma integração ideal a nível dos recursos do SO.

Quem tentar criar uma aplicação puramente baseada em tecnologia Web, mas que possa correr, por exemplo, num ambiente desktop, percebe bem a questão….. Não existe forma fácil de, por exemplo, criar uma aplicação chromeless, sem fazer uso dos UIs do browser. Correr em modo Fullscreen não é solução e muito menos correr em frameworks como PhoneGap, que apenas permitem correr uma aplicação web dentro de um rudimentar widget web, com muitas limitações ao nível das funcionalidades suportadas, para não falar na limitação de performance.

Além disso, mais restritivo que desenvolver uma aplicação chromeless é desenvolver uma que faça uso dos recursos do sistema operativo, e apesar de haver grande progressos nessa área (FileSystem API, Local Storage API, etc) ainda estamos longe de ter acesso aos recursos que, por exemplo, as SDK windows, mac, android, iOS nos permitem.

Para mim, frameworks como PhoneGap são uma faca de dois legumes, como o grande treinador dizia… Por um lado prometem desenvolvimento rápido e cross-platform, o que é verdade. Mas por outro, correm a app web em cima de um widget rudimentar, que é disponibilizado pelas SDKs do iOS, do Android, etc., como uma simples view para criar interfaces web simples. Depois os developers passam o seu tempo a tentar otimizar a performance da app…

Por outro lado temos os browsers. Autêntica artilharia pesada. Conseguem alta performance, mas é muito difícil sair do contexto browser, ou seja, é difícil implementar uma aplicação chromeless. É possível integrar apenas os seus layout e render engines? Sim, podemos usar o Gecko, WebKit, etc e embeber num software nosso, mas não é tarefa fácil. Existe um projecto chamado CEF que não é mais que uma API para embeber o Chromium em virtualmente qualquer aplicação. Depois existe uma série de projetos para embeber o Gecko, o motor do Firefox, mas que infelizmente, são sempre abandonados… Por fim existe um projeto chamado Awesomium que é uma framework que permite tirar partido do browser (Chromium/WebKit) para criar aplicações windowless, mas sendo algo comercial e fechado, acabamos sempre sem saber bem em que versão do browser nos podemos basear, nunca temos a certeza que funcionalidades suportam no futuro nem quanto tempo demoram a integrar as evoluções do WebKit (se é que o fazem).

Agora, temos o renascer do gigante. A Mozilla, que tem grande responsabilidade pela web tal como a conhecemos, voltou em força e está atualmente a puxar novamente as fronteiras da web!

A Mozilla está em força com a iniciativa Open Web. Ao longo dos últimos tempos têm tentado estender os web standards para incluir uma série de APIs necessárias para desenvolver aplicações em sistemas móveis que realmente fazem uso nativo do SO. Vejam aqui uma compilação das APIs que estão a ser desenvolvidas.

O primeiro é o projecto Boot To Gecko – B2G , onde estão a desenvolver um sistema operativo mobile baseado no projeto Gecko e que tem como principal novidade as aplicações nativas em aplicações HTML5/JS. Desta forma podemos desenvolver aplicações usando tecnologia HTML5 e JS e ter acesso a um conjunto de recursos do sistema operativo, ou seja, a Mozilla quer tornar a Open Web como uma plataforma para um sistema mobile.

Depois temos a iniciativa Open Web Apps. A Mozilla finalmente vai lançar o seu Web Apps Marketplace, um local onde podemos encontrar, comprar e fazer download de aplicações Web. Um pouco semelhante ao Google Web Apps, mas com a inovação e “passo à frente” que tem sido a bandeira da Mozilla. O funcionamento é muito semelhante às Web Apps Chrome. Temos um MarketPlace onde podemos distribuir  e gerir aplicações Web. O passo à frente nesta iniciativa é o WebRT – Web Run Time:

“Desktop WebRT is a project to build a desktop web application runtime that provides webapps with a native-like look and feel along with platform integration APIs on Windows, Mac, and other desktop platforms.”

A ideia é que ao instalar a Web App existe uma funcionalidade do Firefox que instala a aplicação no sistema operativo nativo e depois podemos correr a aplicação nativamente. Esta ao ser executada corre como se fosse no Firefox, mas num ambiente chromeless.

Estou ansioso por verificar como está plataforma vai desenvolver ao longo do tempo, à muito que ando à procura de uma forma de desenvolver aplicação desktop usando tecnologias Web, principalmente na parte das UIs, com todo o poder dos browsers modernos actuais, e a iniciativa Open Web da Mozilla, particularmente o projecto B2G e WebRT prometem isso mesmo!

Anúncios


Deixe um comentário

Mobile Web Development

Lembro-me de discussões acesas de há uns anos atrás, sobre a guerra Web Apps vs. Native Apps no mundo mobile, e de como a perceção era de que o futuro seria Web App. Podemos discutir e listar todas as vantagens e desvantagens de um conceito sobre o outro e vamos encontrar sem dúvida vários argumentos onde podemos fanaticamente defender o nosso ponto de vista:

Browser:

  1. Um único esforço de desenvolvimento, contra desenvolver para uma série de plataformas (iOS, Android, W7, etc).
  2. Manutenção facilitada, um update no servidor e as mudanças introduzidas estão disponíveis para todos os utilizadores.

Nativa:

  1. Look and Feel nativo, permite fornecer uma experiência de utilização mais standard (e como isto tem importância num iAparelho).
  2. Disponível a partir das AppStores, que são pontos importantes de disseminação das aplicações.
  3. Acesso aos recursos dos dispositivos (acelerómetro, câmara, GPS, etc).
  4. Acesso e utilização Offline.

Esta lista está certamente bastante incompleta mas a ideia também não é espremer as vantagens de uma e outra abordagem.Na minha opinião, a solução Browser tem ganho cada vez mais pontos a favor, devido em grande parte à tecnologia HTML5 que veio preencher uns vazios que até então eram críticos:

  • Com HTML5 podemos ter aplicações offline, usando por exemplo local storage.
  • Podemos obter informações de localização.
  • Podemos criar o look and feel adequado ao dispositivo devido ao CSS3 e HTML5.

No entanto, as aplicações nativas têm tido um grande sucesso, e para mim existem três grandes razões, e que no fundo são as grandes diferenças atuais entre aplicações Browser e Nativas:

  • As AppStores que são um canal de distribuição enorme e massificado.
  • Os recursos do SO disponíveis são maiores e portanto podemos oferecer melhores experiências de utilização e funcionalidades até únicas, que nem sequer podem ser implementadas numa aplicação browser.
  • A aplicação está instalada, facilmente acessível através dos menus de apps dos dispositivos.
Apesar de no passado ter a minha opinião bem fincado, atualmente o mundo mobile está tão presente nas nossas vidas que as decisões não podem incidir sobre questões tecnológicas e fanatismos sobre web app contra native app, a verdade é que a questão é puramente de negócio e se queremos lançar uma aplicação mobile no mercado temos que perceber o contexto dessa aplicação. Apesar de um ponto de vista técnico termos que o fazer, não devemos nunca decidir por um dos lados só porque simplesmente “o que um lado nos oferece é suficiente”, ou porque “estou mais à vontade com tecnologias web”. É fundamental perceber o negócio onde a aplicação vai encaixar. Uma questão interessante é apontada neste post, onde é exposto o propósito de utilização. O autor defende que as apps nativas tem uma utilização lean-back ao passo que as browser têm uma utilização lean-forward, ou seja, numa aplicação browser nós estamos essencialmente a pesquisar e navegar em informação ao passo que numa aplicação nativa estamos numa experiência mais imersiva, aproveitando a integração do dispositivo com sensores, câmaras, etc. Para mim faz bastante sentido, apesar de cada vez menos estas diferenças serem sentidas.
Um pequeno exemplo que podemos analisar é uma loja online. Para mim faz tudo o sentido que seja desenvolvido sobre um conceito browser. Primeiro porque, à partida, já deve existir uma plataforma de suporte (a loja online) assente sobre tecnologia web. Depois porque implica um propósito de utilização de pesquisa, navegação por conteúdos. Depois existem uma série de razões de pormenor: não é necessário recursos do dispositivo, a experiência do utilizador também não é à partida o ponto mais essencial e com tecnologia HTML5 e CSS3 já estamos muito (mesmo muito) bem servidos nesse aspeto. No entanto, estará disposto um cliente a perder o potencial de captação que as AppStores, principalmente da Apple e Android, têm para oferecer? São milhares de pessoal que todos os dias pesquisam e navegam à procura de aplicações para os seus telemóveis ou tablets! Neste caso, poderíamos considerar também desenvolver versões nativas! E assim cai por terra a discussão inicial onde tentamos perceber as vantagens de um conceito sobre o outro! Isto leva-me a pensar em arquiteturas mais complexas, APIs e serviços Web onde no fundo temos que esquecer os clientes, podem ser qualquer coisa, browser, nativa, não interessa, o importante é fornecer recursos que estes possam utilizar para alimentar conteúdos e interações.
Concluindo, não penso que qualquer resposta dada esteja errada, seja Browser, Nativa ou as duas, com certeza somos criativos a enumerar argumentos de suporte. A questão não é certamente qual o melhor conceito de um ponto tão purista, a decisão tem que partir com o negócio, o utilizadores e um contexto de utilização em mente, só assim encontramos a melhor resposta. Só os utilizadores irão no futuro dar resposta a esta questão (se é que algum dia vão dar). No entanto é interessante verificar que ao longo destes anos as diferenças entre os conceito browser e nativo são cada vez menores, ainda existem com certeza, mas a linha que os separa é cada vez mais ténue.


Deixe um comentário

HTML5 – Aplicações Offline: AppCache

Antes de começar este artigo, podem fazer download deste projecto. É uma simples aplicação HTML5 que funciona de modo offline e serve para poderem seguir o artigo. No entanto, não precisam de usar o projecto para perceber o que a seguir vamos falar, apenas serve como uma referência e é um ponto de partida para fazerem as vossas aplicações offline.

O que é a AppCache

AppCache é um mecanismo do HTML5 que permite que o programador indique explicitamente ao browser quais os recursos da sua aplicação web que devem ser guardados persistentemente em cache, de forma que a aplicação funcione mesmo sem acesso à internet, isto é, que funcione em modo offline.
O processo para tornar uma aplicação offline é na sua essência bastante simples:

  1. Criar um ficheiro manifest .appcache onde indicamos os recursos que devem ser mantidos na appcache.
  2. Certificarmos que o servidor consegue servir documentos do tipo .appcache
  3. Incluir um ficheiro .appcache em cada página da aplicação, usando o atributo manifest da tag html.

O ficheiro manifest

O ficheiro manifest deve conter então todos os recursos que queremos colocar em cache, segue um exemplo:

CACHE MANIFEST
# ficheiros a colocar em cache
script.js
style.css
img/logo.png

Neste caso indicamos ao browser que script.js, style.css e img/logo.png são recursos que queremos disponíveis offline.
Podemos no entanto indicar outro tipo de regras no ficheiro com os seguintes headers:
CACHE: ficheiros a colocar em cache
NETWORK: ficheiros que nunca devem ficar em cache. O browser lança um erro se tentar carregar estes ficheiros em modo offline.
FALLBACK: Que ficheiro carregar não caso o browser em modo offline não encontre a página na appcache.

Se não indicarmos nenhum header no ficheiro manifest, como o exemplo acima, é considerada uma secção explícita, isto é, o header CACHE.

Vejamos então o seguinte exemplo:
CACHE MANIFEST
CACHE:
script.js
style.css
img/logo.png

NETWORK:
check.php

FALLBACK:
/ /offline.html

Neste caso, acontece o seguinte:

  • script.js, style.css e img/logo.png são enviados para a appcache, e dessa forma, disponíveis offline.
  • O script check.php não fica em appcache, deve ser sempre carregado da rede.
  • Caso o browser não consiga carregar a página em modo offline, é mostrada a página offline.html. A “/” antes de offline faz com que qualquer URL pattern corresponda ao procurar o ficheiro offline.html.

Criar ficheiro appcache para uma aplicação estática é trivial, mas a maior parte das vezes queremos que estes sejam dinâmicos, ou seja, dependendo da página que estamos a servir, os recursos que queremos offline podem variar, e podem ser tantos (p.e. a pasta de imagens) que se torna demorado escrever este ficheiros à mão. Para isso existem algumas ferramentas que criam ficheiros .appcache de forma automática. Por exemplo, esta ferramenta cria o ficheiro manifest baseado na página que estámos a visualizar no browser.

Adicionar o ficheiro manifest

Depois de criar o ficheiro manifest precisamos incluir em cada página que quisermos servir. Isto é importante, não podemos simplesmente incluir o manifest na nossa “Home Page” e não incluir nas restantes, pois nesse caso apenas a “Home Page” ficava em cache.
Para incluir o ficheiro manifest numa página, inserimos o seguinte na tag html da página:
<html manifest=”app.appcache”>

Servir ficheiros manifest

Agora precisamos por fim certificar que o nosso servidor consegue servir estes ficheiros com extensão .appcache. Uma forma simples de o fazer é criar um ficheiro .htaccess e adicionar a seguinte linha:

AddType text/cache-manifest .appcache

E é isto, agora o nosso servidor Apache consegue servir ficheiros .appcache. Atenção que se não se certificarem que os ficheiros .appcache estão a ser servidos, a nossa aplicação nunca vai funcionar offline.

Testar aplicações offline pode tornar-se frustrante porque assim que o browser coloca recursos em cache, eles não voltam a ser carregar do servidor, mesmo em modo online.
Existem apenas três caso em que browser tenta carregar novamente recursos que estão em cache:

  1. O utilizador limpou a cache.
  2. O ficheiro manifest foi alterado.
  3. A cache foi alterada via javascript.

Portanto, já testar alterações nos ficheiros em cache existe uma solução simples, alterar o ficheiro manifest! Basta uma pequena alteração como adicionar/editar um comentário.

 

 

AppCache Debug

Existem algumas formas para fazer debug da appcache:
No chrome, utilizar o “Resources Panel”, lá encontram informação sobre o estado da Application Cache.

No chrome, navegar até chrome://appcache-internals/, podemos então ver quais as aplicações que estão a utilizar appcache e até remover da cache.

No entanto fazer debug da appcache não é fácil, os recursos são muito limitado.
Existem também problemas com a appcache em si. Tem uma API muito limitada que não permite fazer muito, não existe forma, por exemplo, de saber se determinado recurso que estamos a trabalhar está em cache ou não, assim como não existe forma de limpar a cache programaticamente.
A appcache tem uma natureza transacional, isto é, ou está completamente carregada ou completamente vazia, desta forma é impossível parar o download e resumir, não existe controlo sobre o estado do download do recursos.
Outro problema é o facto de se utilizar um ficheiro manifest por página, sendo impossível criar grupos de recursos para colocar em appcache. (Existem alguns hacks no entanto, usando iframes)

Existe ainda muito mais para falar sobre appcache, como alterar a cache com javascript ou detectar suporte appcache nos browsers, mas para já ficamos por esta introdução base. Assim que houver mais assuntos para falar este artigos será actualizado!

Para testarem um exemplo podem fazer download deste projecto.


2 comentários

HTML 5 – As novas tags

Mais um artigo da colecção HTML5, desta vez sobre as principais tags HTML5.

HTML5 – Introdução

HTML5 – As novas tags

O DocType

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

Isto é o doctype! Deve ser sempre a primeira linha de qualquer documento HTML e serve para indicar ao browser qual a versão do HTML em que o documento está escrito. Existem dezenas de doctypes, que podem fazer o browser “entender” o HTML de diferentes formas. Daí, é importante usar um doctype que faça o browser correr num modo standard. Por exemplo, o doctype acima – XHML 1.0 Strict – contem todos os elementos e atributos HTML, mas NÃO INCLUI elementos de apresentação ou obsoletos (como tag font). Frames também não são permitidos e o HTML tem que ser escrito como um XML válido.
Não existe nenhum problema em continuar a usar este tipo de DocType, mas porque não usar o novo DocType HTML5 que é mais pequeno, legível e faz os todos os browsers recentes correr em modo standard:

<!DOCTYPE HTML>

O elemento Header

Supõe que precisas criar um cabeçalho e algumas secções para uma página HTML:

</pre>
<div id="header">
<h1>O meu Site</h1>
 Não tenho a certeza o que escrever aqui...</div>
<pre>

Não existe nenhum problema em continuar a usar esta estrutura, é HTML5 válido de qualquer forma. Mas uma novidade do HTML5 é que fornece alguns elementos adicionais para usar como cabeçalhos e secções em páginas Web.

Vamos então começar por analisar o cabeçalho (a div com id header). Apesar de comum, está estrutura não representa nada, o browser não faz ideia que isto se trata de uma secção “header”, nos enquanto “programadores” é que reconhecemos este padrão como uma estrutura de cabeçalho. O HTML5 define um elemento <header>, na nossa página podíamos reescrever da seguinte forma:

<header>
<h1>O meu Site</h1>

 Não tenho a certeza o que escrever aqui...</header>

Navegação

Na génese dos documentos HTML está a navegação, afinal é por existir navegação numa página web que podemos navegar de umas páginas para outras, de documento em documento. Tipicamente, referimos a navegação de um website como um “menu”. A estrutura mais comum para criar um menu é recorrendo a listas HTML:

</pre>
<ul>
	<li><a href="#">Home</a></li>
	<li><a href="#">Blog</a></li>
	<li><a href="#">Acerca</a></li>
	<li><a href="#">Contactos</a></li>
</ul>
<pre>

Utilizar listas é válido, mas traz um problema, não existe forma de saber que determinada lista se refere ao menu do website. Imagem uma pessoa com dificuldades visuais, que usa um software text-to-speech para “ler” uma página web. O software carrega a página HTML e “lê” o site, permitindo que a pessoa ouça o que está escrito. Se não identificarmos o menu explicitamente, o software não tem forma conveniente de saber que existe um menu principal onde a pessoa pode navegar para diferentes secção do site. Se existir uma forma de identificar o menu de navegação do site, o software pode facilmente apresentar à pessoa quais os links disponíveis para navegar:

<nav>
<ul>
	<li><a href="#">Home</a></li>
	<li><a href="#">Blog</a></li>
	<li><a href="#">Acerca</a></li>
	<li><a href="#">Contactos</a></li>
</ul>
</nav>

Secções

O elemento <section> pode ser visto como um contentor para uma parte significativa de uma página web, da mesma forma que num livro, um capítulo engloba uma secção significativa do livro.
Usar o elemento <section> é uma forma eficiente de organizar e separar o conteúdo numa página Web. Por exemplo, em vez de criar uma lista de artigos independentes numa página web, ou englobar numa tag <div> sem qualquer significado, podemos usar o elemento <section>.

<section>
<div>
<h1>Title</h1>

Lorem Ipsum si dolore... ... ...</div>
</section>

Como podemos começar a perceber, tags como <nav>, <section> não têm por objectivo fornecer nenhumas funcionalidades novas, trata-se mais de permitir dar significado ao conteúdo que escrevemos.

Hgroup

O elemento <hgroup> representa o cabeçalho de uma secção. É utilizado para agrupar os vários elementos <h> (h1… … h6) que eventualmente fazem parte do cabeçalho.

<hgroup>
<h1>Lorem ipsum si dolore</h1>
<h2>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec molestie. Sed aliquam sem ut arcu.</h2>
</hgroup>

Artigos

</pre>
<div>28 de Março de 2012
<h2>  <a href="#"> Nova Entrada </a></h2>
 Lorem ipsum si dolore... ... ..</div>
<pre>

Em relação a div com a class “entrada”, podemos perceber esta estrutura como um artigo numa página, um grupo de elementos que em conjunto formam um artigo num website, por exemplo, uma lista de posts num blog, ou uma lista de notícias, ou até mesmo um único post ou notícia numa página de um website.

Mais uma vez, não existe problema algum em utilizar esta estrutura, é HTML5 válido! Mas o HTML5 introduz um novo elemento que permite organizar de uma forma mais clara um artigo numa página:

<article>
<h4>28 de Março de 2012</h4>

Lorem ipsum si dolore ... ... ...</article>

A tag <article> permite organizar um artigo numa página.

Datas e Hora

O elemento <time> permite facilmente identificar datas dentro de documentos HTML5:

<time datetime=”2012-03-28″ pubdate=””>28 de Março de 2012 </time>

Existem três componentes da tag <time>:

●      Machine-readable timestamp

●      Componente de texto Human-readable

●      Uma flag opcional pubdate

O timestamp pode indicar a data (como no exemplo) mas também podemos adicionar a hora, desta forma:

<time datetime=”2012-03-28T13:32:56″ pubdate=””>28 de Março de 2012</time>

O componente de texto pode ser qualquer coisa, não precisa de indicar uma data específica, pode ser algo como: “Á 5 minutos” ou até mesmo nada! A flag pubdate pode significar uma de duas, se a tag <time> está dentro de uma tag <article> indica que o artigo foi publicado naquela data e hora. Se a tag <time> não está dentro de uma tag <article> significa que o documento foi publicado na data e hora especificado na tag.

Footers

Imaginem o seguinte rodapé:

</pre>
<div>
<div id="FooterTwo">© 2012 HTML5 - Basic Tags</div>
<div id="FooterTree">HTML5, para MTM - <a href="http://www.epb.pt">EPB</a></div>
</div>
<pre>

Tipicamente encontramos este tipo de rodapés em página HTML, mas mais uma vez o HTML5 define um elemento específico para rodapés <footer>:

<footer>
<div>
<div id="FooterTwo">© 2012 HTML5 - Basic Tags</div>
<div id="FooterTree">HTML5, para MTM - <a href="http://www.epb.pt">EPB</a></div>
</div>
</footer>

Normalmente o footer contem informações sobre quem é o autor do web site, links para documentos relacionados, informações de copyright, etc.
O tipo de elementos que podemos inserir dentro de um footer não é definido à partida, pode fazer sentido criar um footer como o de cima, ou então, em casos de footers com mais conteúdos, podemos por exemplo criar secção <nav> dentro do elemento <footer>.

Aside

O objectivo deste elemento é designar conteúdo que está relacionado mas não faz parte do conteúdo principal da página. Podemos ver o <aside> como as notas que por vezes aparecem nos livros ou website: referências para artigos relacionados, curiosidades sobre o conteúdo, etc. Todo isso está relacionado com o conteúdo, apesar de não fazer parte do mesmo.

<article>
Lorem ipsum si dolore... ...
<aside>
<h1>lorem ipsum</h1>
Lorem ipsum si dolore... ... ...</aside></article>

Dialog

O elemento <dialog> permite identificar conversações numa página web, pode portanto, ser particularmente interessante para criar comentários e respostas a comentários.
Dentro do <dialog> temos ainda disponíveis os seguintes elementos:

  • <dt> para identificar o autor
  • <dd> para identificar o texto em si

Abel SoaresAqui está um conversa usando o elemento dialogJonh SmithParece interessante

Figure

Inserir imagens numa página web é uma tarefa rotineira para qualquer pessoa que desenvolve aplicações web.
Mais complicado é identificar a imagem e o texto associado a esta.
O HTML5 define o elemento <figure> que nos permite inserir imagens e conteúdos associados neste elemento.

<figure>
<legend>Figure 12. Using the FIGURE element </legend>
 <img src="“figure_element.jpg”" alt="“The" width="“240”/" height="“140”" border="“0”" /></figure>

Associado ou elemento <figure> temos o elemento <legend>. Como o próprio nome indica é um elemento html onde podemos definir a legenda da imagem.

HTML5 – Introdução

HTML5 – As novas tags



1 Comentário

HTML 5 – Introdução

Vou tentar escrever vários artigos sobre features HTML5 que acho particularmente interessantes e creio que no fim teremos um guia bastante completo sobre HTML5.

HTML5 – Introdução

HTML5 – As novas tags

Para já, segue uma pequena introdução ao HTML5, começando por simplesmente responder à questão “mas afinal, o que é o HTML5?”.

O HTML5 não pode ser visto como uma única tecnologia nem uma simples evolução do HTML4.  Como podemos ler em HTML5 Rocks: “HMTL5 is not a single thing or a monolithic technology. It is a collection of features, technologies, and APIs that brings the power of the desktop and the vibrancy of multimedia experience to the web—while amplifying the web’s core strengths of interactivity and connectivity.”
O HTML5 fornece novas funcionalidades necessárias para o desenvolvimento de aplicações web modernas e a sua especificação tem sido um esforço de standardizar muitas funcionalidades suportadas por vários browsers, que os web developers têm usado há muito tempo mas que ainda não tiveram a oportunidade de ser standardizadas.
Um browser recente é tudo o que é necessário para começar a desfrutar das vantagens deste novo conjunto de funcionalidades que vieram para ficar e revolucionar a forma como vemos as aplicações web. Caso não tenham a certeza se o vosso browser suporta determinada funcionalidade HTML5, existem vários sites que podem consultar para verificar a compatibilidade do browser, por exemplo findmebyip.com ou caniuse.com Aplicações que antes exigiam o poder e funcionalidades avançadas encontradas nas plataformas desktop estão agora disponíveis em ambiente web, graças à nova versão do HTML, CSS3 e um conjunto de APIs Javascript que fazem parte do “pack” HTML5, abrindo portas a uma nova geração de web apps que conseguem alta performance gráfica e de animação, trabalhar offline e levar a colaboração entre utilizadores a um outro nível.
Nesta série de artigos sobre HTML5 optei por fazer a divisão entre as várias tecnologias que compõem o HTML5: as novas tags HTML, o CSS3 e as APIs Javascript. O próximo artigo é então sobre as principais tags HTML5.


Deixe um comentário

Optimizar o DOM: Não usar o DOM

O DOM é uma API independente da linguagem e que serve fundamental para trabalhar com XML e HTML. Apesar de ser uma API agnóstica, as arquiteturas dos browsers implementam uma interface em Javascript e dividiram a implementação DOM e Javascript em dois módulos diferentes. Por exemplo, o Chrome usa o WebCore como motor para renderizar páginas e DOM (do WebKit), mas usa o seu próprio motor Javascript (V8).

Em aplicações Web com interfaces interativas é comum o o uso (e abuso) de Javascript, nomeadamente no acesso e escrita do DOM. No entanto, a arquitetura de DOM e implementação Javascript separadas tem um custo: a performance. A verdade é que como o Javascript tem que comunicar com um módulo diferente (implementação DOM) cada vez que quer ler e ou escrever no DOM a performance acaba por se degradar.

Não podemos fazer nada em relação a isto a não ser otimizar o nosso código Javascript de forma a fazer o menos pedidos possíveis de escrita e leitura DOM. Vejamos um exemplo simples: queremos uma função que imprima os 150 primeiros algarismos num qualquer elemento do DOM. Uma versão poderia ser:

function print150()
{
  for(var i = 0; i < 150; i++)
  {
    document.getElementById('elem').innerHTML += i;
  }
}

À partida este código é inofensivo, mas em termos da performance a nível do DOM, este código é um serial killer. Ao longo do ciclo estamos constantemente a aceder e escrever no DOM, e como já percebemos, o acesso ao DOM é custoso. Por isso uma versão optimizada e com maior performance será calcular a string a imprimir e depois com  um único acesso imprimir o resultado:

function print150()
{
  var toPrint;
  for(var i = 0; i <150; i++)
  {
    toPrint+=i.toString();
  }
  document.getElementById('elem').innerHTML = toPrint;
}

Esta versão faz uso da regra de ouro ao programar o DOM se queremos eficiência: usar o DOM levemente, e ficar o mais possível no ECMAScript.