Tip:
Highlight text to annotate it
X
HTML5 - Inside the Brackets com Jonathan Stark
Olá, sou Jonathan Stark e este é Inside the Brackets.
Este mês, "HTML5 versus Nativo, quem vai ganhar?"
Cada lado tem argumentos válidos, mas ambos têm fãs irracionais
o que torna difícil avaliar as questões,
deixar o exagero de lado
e decidir o que é melhor para seu próximo projeto.
Assim, vamos apresentar nossos convidados.
Dan Bricklin é da Software Garden Inc.
e pai da planilha eletrônica,
Drew Crawford é proprietário da DrewCrawfordApps,
Dave Methvin é presidente da JQuery Foundation
e Mike Richmond
é arquiteto no Open Source Technology Center, na Intel.
Drew, começando com você. Você escreveu em um blog
sobre HTML5 e por que aplicativos móveis ou da web eram lentos. - Isso.
O que o levou a isso? -Eu basicamente me enchi
de tantas discussões que eram mais banalidades
e que não tinham base em fatos.
E, claro, o desenvolvimento nativo é grande parte do meu trabalho.
Conversei muito com clientes
e outras pessoas. E eu queria algo
que fosse mais definitivo e usasse linguagem mais técnica
e acrescentasse mais números e fatos à discussão.
E qual era seu ponto chave? -Aplicativos móveis da web são lentos
e continuarão assim por algum tempo.
O que você acha disso? -Acho que ele provou
que eles são mais lentos para muitas coisas, não tudo.
Mas o Drew acrescentou alguns números
para dizer que se você busca comparar velocidades,
quando se importa com a velocidade para certas coisas,
eis alguns números. Não digamos apenas - isto é rápido,
isto é lento, mas o quanto você precisa que seja rápido.
Se seu carro atinge 150 milhas por hora e o limite na área é 35
isso não importa. Mas se você precisa dirigir a 150 milhas por hora
isso é importante.
Você precisa saber quando isso de fato importa.
Há uma grande diferença em velocidades.
Além disso, deve haver outras coisas que você não esteja medindo,
como o garbage collection. E você deve considerar isso.
Dave, gostaria de saber de você.
Estamos falando de preocupações chave para desenvolvedores.
Como as pessoas decidem por onde seguir?
Acho que a questão é que o HTML5 é rápido o bastante,
é a escolha preferida,
pois é de fato mais rápido para o desenvolvimento também
e trata de questões de portabilidade.
Portanto, em vez de apenas escolher uma plataforma,
você tem uma série de plataformas e, potencialmente, a capacidade
de usar qualquer web browser de qualquer plataforma,
o que você não tem ao usar o desenvolvimento nativo.
Qual seria um exemplo em que você diria
que devemos usar um aplicativo nativo?
Acho que um aplicativo nativo seria a escolha correta
se você precisar usar
um recurso específico da plataforma não facilmente disponível
atravé de HTML. E pode ser um sensor especial,
você pode precisar integração total
com um dispositivo como a câmera. E você não vai conseguir isso
no momento se usar HTML5.
Mike, como a Intel vê tudo isso?
Vemos a web, que abriu os braços para o HTML5,
como uma plataforma incrível
para uma ampla gama de experiências.
O que houve nos últimos anos
é que facilidades estão sendo acrescentadas ao padrão,
permitindo a construção de aplicativos e não só websites -
um desenvolvimento bastante interessante.
Tentamos descobrir como oferecer novas capacidades
mais rapidamente ao usuário.
Drew, vou ser o advogado do diabo um minuto:
Existem tipos de aplicativos onde você acredita que o HTML5 possa ser superior ?
Qualquer coisa em que o tempo de mercado seja o principal,
onde consumidores não tenham muita escolha,
talvez você esteja em um novo mercado e talvez não haja um software
que de fato concorra
com o que você está produzindo.
Dan, existem aplicativos
que lhe permita abrir mão do HTML5? -Sim, fiz isso com meu aplicativo.
Tenho o Note Taker HD, para escrita,
que dá ou não um zoom da escrita
e renderização em cima de PDFs,
e você tem de usar o hardware,
você fica doido para fazer isso.
Tive de me valer de C para isso, mas ele só é executado no iPad.
As pessoas me perguntam: por que não Android?
Bem, não tenho tempo para colocá-lo no Android,
Claro que existem muitos aplicativos
onde a velocidade para determinados controles importa.
E o HTML simplesmente não é o ideal.
Então você precisa entender o que é fácil programar
naquele sistema e o que não é.
E o que é mais importante para o seu aplicativo.
O que fará dele um sucesso ou fracasso?
E isso significa
que você tem de seguir por este ou por aquele caminho.
Drew, se você considerar nosso público,
como saber em qual dos lados se está?
Eu diria que se você vai trabalhar com a web
você deve ter muita clareza sobre por que os clientes vão escolher
uma experiência da web e não outras disponíveis.
Você deve ter algo que o oriente
que lhe diga - certo, talvez eu esteja trabalhando em uma rede social
e portanto é importante chegar ao mercado com rapidez
e atraia usuários. E se você não tiver isso claro,
que com o atual estado de desempenho
e o estado atual do hardware móvel
que o nativo seja o melhor.
É dificil para mim imaginar um desesnvolvedor de aplicativos
para o qual prazos e tempo de comercialização não importem.
Há sempre pressão para se concluir um aplicativo.
Desenvolvedores precisam fazer seus aplicativos funcionarem,
e trabalhar para torná-los mais rápidos.
Ou seja, se os principais recursos não estiverem ali,
ninguém se importará se são rápidos, ninguém vai fazer o bechmarking deles
se ninguém de fato os usar.
Há milhões de desenvolvedores da web
que usam parte de sua criatividade e ideias,
colocam isso num aplicativo e o oferece a seus consumidores.
E se alguém vai se perguntar:
"Será que eu deveria fazer um aplicativo nativo?"
isso, para mim, é meio ridículo.
Porque eles não vão fazer desenvolvimentos nativos,
eles são desenvolvedores da web.
Você acha que construir primeiro um aplicativo nativo é uma otimização prematura?
Acho que é como no desktop - você faz um website
ou cria um aplicativo, um aplicativo nativo, que precisa ser executado-
um aplicativo executado no desktop.
Viemos de uma época em que tudo era nativo
e só usávamos a web um pouquinho,
para um momento em que usamos a web para tudo o que podemos.
Comece com HTML5. Se não for adequado, comece a pensar
e você vai descobrir que se não conseguir programá-lo,
você vai contratrar alguém como o Drew, que é como a coisa meio que funciona,
porque você não tem programadores que sabem como programar de forma nativa.
Não é algo que se aprenda em alguns minutos.
O problema para desenvolvedores
é que eles veem essas contorvérsias e, em muitos casos,
as circunstâncias dos aplicativos controversos,
coisas como Facebook ou LinkedIn, não se aplicam aos aplicatvos
que eles estão criando.
Portanto, minha sugestão aos desenvolvedores
é que eles precisam entender do que se trata seu aplicativo.
E um filtro realmente bom para isso é algum aplicativo seu
que pode ter sido feito com um website e um bookmark
quando era assim que se faziam as coisas
Se a resposta é sim, então as tecnologias da web são fáceis.
E então você usa um segundo filtro.
Você pode ir a um website como jQMGallery.com
que tem como amostra aplicativos jQuery
e há uma centena de aplicativos ali
que são todos diferentes, mas como que se enquadram a um padrão.
E se olhar para eles, se verificar as capturas de tela,
pode-se dizer: "uau, sim, é isso que estou tentando fazer." Exato.
Exato. Isso se parece com meu aplicativo?
E em caso afirmativo, é bem capaz que eu consiga escrever com isso também.
E há inúmeros aplicativos que se encaixam nessa categoria.
Se você está tentando fazer algo, por outro lado,
que você nunca viu ninguém fazer antes,
e parece ser algo no qual você terá de levar
o hardware ao limite
certo, então você deve estar fazendo desenvolvimento nativo.
As pessoas precisam perceber que a maioria dos aplicativos não é tão exigente,
e que a maioria não é assim tão excepcional.
E talvez isso seja ruim. Mas você é pago para criar algo
e você deve usar a tecnologia certa para isso.
Não acho que isso seja verdade. A maioria dos aplicativos é excepcional.
Se verificar muitos dos demos de aplicativos de HTML5
sobre o qual você falava,
e você os comparar com aplicativos nativos,
há diferenças muito claras em coisas como rolagem.
A rolagem é tranquila? Se o usuário está reorganizando uma lista,
o item da lista muda quando pressionado?
Coisas assim, detalhes como este são muito importantes.
Se você verificar estudos na web,
coisas como a rapidez com que consigo fazer uma compra,
a rapidez com que uma página é carregada, isso é importante.
100 milisegundos, 50 milisegundos.
E isso cria dinheiro. Se você consegue levar a Amazon
de 100 milisegundos a 50 milisegundos
você pode ganhar muito dinheiro. -Para alguém em uma fábrica
ou um vendedor que precise conseguir usar o que há de mais recente
para conseguir dizer a seu cliente sobre seu produto,
esses são aplicativos não muito complexos.
E a diferença entre um resposta em 10 segundos
e uma em 1 segundo não importa tanto
quanto 10 segundos versus não ter informação alguma. -Claro.
Portanto, é preciso pensar.
Principalmente na área de empresa para empresa,
ou de empresa para funcionário, a área BTE.
É diferente do que você tem falado,
que é o aplicativo ser sua loja de frente,
o aplicativo ter de ser criado assim.
Nem todo aplicativo precisa ser assim.
Você realmente se importa quando você está no controle
o quanto parece bom ou se é criado em uma fração de segundo diferente,
se tem a informação correta? -Claro.
Acho que alguns desenvolvedores acham que precisam usar código nativo
para acessar as capacidades do dispositivo.
Há quem ache que se precisa usar código nativo
se você vai usar uma câmera ou um acelerômetro.
Todas essas coisas estão sendo acrescentadas às engines web modernos
ou podem ser acessadas por aplicativos híbridos,
quando se tem apenas um pouco de código nativo
para acessar o dispositivo que você quer. Você coloca aquilo
no todo do seu aplicativo que usa tecnologias da web
e tudo certo. Portanto, não creio que sejam as capacidades do dispositivo
que separem o desenvolvimento nativo do desenvolvimento
de aplicativos baseados na web. Não mais.
Acho que a coisa se resume a - seu aplicativo está fazendo algo
com conjuntos de dados que tenha uma escala tão grande
que você mesmo precisa gerenciar a memória,
você não pode depender do garbage collection automático
construido nos browsers, você está fazendo algo na tela
onde sua ideia sobre como a coisa deveria ser feita é muito melhor
do que as pessoas escrevendo as engines dos browser,
que são pagos para basicamente competir com outros caras
sobre a rapidez da execução?
E acho que ainda há questões envolvendo aplicativos
onde se tem muitos dados
e se faz a rolagem por uma lista de fato muito longa.
Portanto, é padrão para a web. E se você não pode entregar a experiência
que está tentando entregar, ou o que seus usuários esperam
ou atender às necessidades do seu negócio,
então, certo, talvez passe para desenvolvimento híbrido e então talvez para nativo.
Quero mudar um pouco de assunto.
Você tocou em APIs de dispositivo chegando ao browser.
Minha experiência com isso
é que ainda há muita fragmentação.
Imagino qual o papel da Intel com toda a fragmentação,
e como HTML entra nisso.
APIs de dispositivos são desenvolvimentos relativamente novos no W3C.
Por um tempo houve uma resistência
para se acrescentar acesso de dispositivos em web browsers
por receio de que sabendo qual hardware estava em um dispositivo,
juntamente com cookies e histórico,
permitiria-se aos sites comerciais identificar consumidores
e segui-los pela web.
Depois de alguns anos de debate,
o W3C descobriu que se poderia distinguir entre browsers
que tenham uma UI, quando se vai de site para site,
e web runtimes baseados na mesma tecnologia
mas que não têm UI para consumidores navegarem,
e que você poderia permitir APIs em web runtimes
ou em execuções de aplicativos, que não se pode permitir em browsers.
E quando aquela decisão foi tomada
e se estabeleceu um grupo de trabalho de aplicativos de sistema para aquelas APIs,
houve muito progresso
na padronização daquelas APIs de dispositivo.
Portanto, RTC, câmera, acelerômetro.
Câmera, acelerômetro. -Orientação é algo importante.
Orientação, calendarização. -DRM
Isso nos leva ao próximo tópico - monetização.
O que podem dizer sobre monetização
e como isso se encaixa no mundo do HTML5 versus lojas de aplicativos?
Se você pode evitar pagar uma taxa a uma loja de aplicativos
isso é melhor. A loja, claro,
oferece um grande mecanismo de distribuição
e um lugar onde as pessoas sabem que podem achar seus aplicativos.
Mas, por outro lado, principalmente se você tem algo
que é mais do que um modelo de assinatura,
se a Apple quiser uma boa fatia dessa receita
só porque alguém baixou aquele aplicativozinho,
isso é um problema.
Basicamente, eles estão entre você e seu cliente para sempre.
E essa não é uma relação que muitas empresas desejam ter.
Drew, o que você acha de tudo isso?
Qual a última vez que você digitou os dados de seu cartão em um aplicativo?
Não sei se eu já tive a escolha, como usuário,
de digitar detalhes de meu cartão de crédito em um aplicativo
ou apenas usar o sistema de compras do iTunes
- sempre quiz fazer isso longe do teclado
e tirar meu cartão de crédito.
Outra coisa para se pensar
é que hoje vivemos em um mercado global.
As lojas de aplicativos fazem negócios no Chade, por exemplo.
Você não vai processar pagamentos no Chade.
É muito difícil. Não se conseguem as permissões,
não se consegue abrir um negócio.
Esses são desafios para os negócios
que a loja de aplicativos solucionou. E acho que seria de se esperar
isso de uma multinacional.
Isso é importante.
O que você acha, Dan? -A Apple não é tão cara
se você só está vendendo algo, sem assinatura.
Os 30% deles, comparados a antigamente,
quando se tinha caixas de software e você tinha de pagar aos distribuidores
você está pagando menos com isso.
Você tem uma porcentagem maior
de um número menor, vezes mais unidades.
Mas, ter apenas um lugar, ou a loja de aplicativos da Apple
ou outra loja,
isso é muito limitante de várias formas.
Porque você está a seu bel prazer. Nem todo mundo pode viver assim.
É bom que isso exista, mas não deve ser a única coisa.
Na área de B2B e B2E, a área de negócio para funcionário,
você não se preocupa da mesma forma com monetização.
Você quer que seu aplicativo seja livre
e é através de algo mais que você ganha seu dinheiro.
Isso é importnte. E você precisa distinguir
entre esas coisas distintas.
A loja de aplicativos é maravilhosa para os consumidores,
mas os consumidores têm muitas necessidades distintas.
E a Apple tem suas necessidades, atrás das quais eles vão.
E é algo lucrativo, uma necessidade importante.
Mas não é tudo. E precisamos de tudo.
Acho que às vezes a questão sobre qual tecnologia usar
para criar um aplicativo se vê às voltas com esta questão
sobre as lojas de aplicativos serem ou não boas.
Se você sabe que deseja estar em uma loja de aplicativos,
isso não significa que você tenha de fazer desenvolvimento nativo.
Todas as opções que se tem para monetização
continuam disponíveis para você.
Se você está usando tecnologia da web para criar seu aplicativo.
Misturar essas duas questões deixa os desenvolvedores confusos -
a questão econômica de como se é pago
e a outra questão econômica
sobre qual é a forma mais eficaz de entregar seu aplicativo,
ou criá-lo, para começar.
Certo, nosso tempo está chegando ao final.
Mas gostaria que vocês
deixassem algo para pensarmos. Por isso, brevemente,
queremos que os expectadores identifiquem sua situação
nessa discussão que tivemos hoje
para que eles possam escolher
qual a melhor abordagem no caso deles, especificamente.
Poderíamos ouvir vocês sobre
que tipo de coisa as pessoas precisam considerar?
Você tem de considerar o que você está criando
e para quê - isso meio que define tudo o mais.
E que recursos você tem para criar o que está criando.
O que eles podem fazer, quais as ferramentas que se vai usar
para construir ou que ferrametnas pode usar para construir.
Você não tem um único martelo, não tem uma única chave de fenda.
Pessoas de verdade que estão construindo coisas - carpinteiros, engenheiros
têm todo um conjunto de ferramentas. Não se tem uma única lente na câmera,
mas uma lente para zoom, ou várias lentes.
Você tem de escolher a ferramenta certa. -Drew?
Acho importante entender seus usuários -
quais suas expectativas, que outras alternativas eles têm.
Portanto, pense fora da caixa
sobre opções que seus usuários terão
e tente quantificar prós e contras
considerando a experiência do usuário.
Dave? -Acho que o Drew falou da questão
de se usar uma loja de aplicativos, como uma vantagem,
e de ser capaz de usar isso, ter vantagem da cauda longa.
E se há uma tecnologia que ajuda de fato a cauda longa
é o HTML5; pode-se usar a mesma tecnologia
por vários dispositivos sem muito esforço.
Isso é positivo. E não apenas para os desenvolvedores,
mas para o usuário final. -Acho que as pessoas se surpreenderiam
ao ver quantos aplicativos elas usam hoje
que são criados usando-se tecnologias da web.
Eles vem de lojas de aplicativos
portanto, para se estar nessa loja
eles têm de ser um pacote, um pacote nativo
e são construídos com tecnologias da web.
A maioria dos desenvolvedores sabe usar tecnologias da web
para fazer o trabalho que estão tentando fazer.
Apenas os aplicativos que exigem mais
requerem programação nativa. -Ótimo, legal.
Bem, nosso tempo acabou.
Gostaria de agradecer nossos convidados pela discussão animada.
Se há uma coisa para pensarmos hoje
é que não é fácil ser um desenvolvedor de aplicativos.
Você conta com tempo e recusos limitados
e precisa tomar decisões o tempo todo
sobre como ter o equilíbrio perfeito
entre coisas chave que diferenciam seus aplicativos.
Espero que tenham achado a discussão útil
e saibam fazer as escolhas para vocês e seus aplicativos.
Obrigado por participarem de Inside the Brackets
e não deixem de acompanhar nossos novos encontros nos próximos meses
onde vamos explorar ferramentas e recursos do HTML5
assim como o papel do HTML5 nas empresas.
Até a próxima.