Pergunta

Com o aumento do poder das estruturas JavaScript como YUI, JQuery e Prototype, e ferramentas de depuração como Firebug, criar um aplicativo inteiramente em JavaScript do lado do navegador parece uma ótima maneira de criar aplicativos simples, como jogos de quebra-cabeça e calculadoras especializadas.

Existe alguma desvantagem nisso além de expor seu código-fonte?Como você deve lidar com o armazenamento de dados para esse tipo de programa?

Editar:sim, Gears e cookies podem ser usados ​​para armazenamento local, mas você não pode acessar facilmente arquivos e outros objetos que o usuário já possui.Você também não pode salvar dados em um arquivo para um usuário sem que ele invoque algum recurso do navegador, como imprimir em PDF ou salvar a página como um arquivo.

Foi útil?

Solução

Escrevi vários aplicativos em JS incluindo uma planilha.

Parte de cima:

  • ótima linguagem
  • ciclo curto de execução de código e revisão
  • A manipulação de DOM é ótima para design de UI
  • clientes em todos os computadores (e telefones)

Desvantagem:

  • diferenças entre navegadores (especialmente IE)
  • escalabilidade de base de código (sem suporte intrínseco para namespaces e classes)
  • não há bons depuradores (especialmente, novamente, para o IE)
  • desempenho (embora tenha havido grande progresso com FireFox e Safari)
  • Você também precisa escrever algum código de servidor.

Conclusão:Vá em frente.Eu fiz.

Outras dicas

Outra opção para desenvolver aplicativos ou jogos simples de desktop em JavaScript é AdobeAIR.Você pode criar o código do seu aplicativo em HTML + JavaScript ou usando Flash/Flex ou uma combinação de ambos.Tem a vantagem de ser multiplataforma (na verdade, multiplataforma, Linux, OS X e Windows).Não apenas Windows e OS X).

Caramba, pode ser a única vez em sua carreira como desenvolvedor que você pode escrever uma página da web e direcionar APENAS UM navegador.

SproutCore é uma estrutura de aplicação totalmente hospedada em JavaScript, emprestando conceitos particularmente do Cocoa (como KVO) e Ruby on Rails (como usar um gerador CLI para seus modelos, visualizações e controladores).Inclui Prototype, mas cria muitas coisas, como controles sofisticados.Isso é Fotos a demonstração é indiscutivelmente impressionante (especialmente no Safari 3.1).

Greg já indicou o Gears para você;além disso, o HTML 5 virá com meios padronizados de armazenamento local.O Safari 3.1 vem com uma implementação onde você tem um banco de dados SQLite por site com tamanho máximo configurável pelo usuário, bem como um navegador de banco de dados integrado com consulta SQL.Infelizmente, levará muito tempo até que possamos esperar amplo suporte ao navegador.Até então, o Gears é de fato uma alternativa (mas não para o Safari…ainda!).Para um armazenamento mais simples, é claro que sempre há cookies.

A desvantagem disso seria que você está à mercê deles com o js habilitado.Não tenho certeza se isso é um grande problema agora.Praticamente todos os navegadores suportam js e o habilitam por padrão.

É claro que a outra desvantagem seria o desempenho.Você está novamente à mercê do cliente que cuida de todo o trabalho intensivo.Isso também pode não ser um grande problema e depende do tipo de aplicativo que você está criando.

Nunca usei o Gears, mas parece que vale a pena tentar.O plano de backup seria executar algum script do lado do servidor através do ajax que despejasse seus dados em algum lugar.

Não totalmente do lado do cliente, mas tudo bem.

Nihilógico (não é meu site) faz muitas coisas com Javascript.Eles ainda têm vários jogos que eles fizeram em Javascript.

Também vi um jogo roguelike bacana feito em Javascript.Infelizmente não me lembro como se chamava...

Se você deseja escrever um aplicativo JavaScript independente, consulte XULrunner.É sobre isso que o Firefox foi criado, mas também foi criado para que você possa distribuí-lo como um tempo de execução de aplicativo.Você escreverá parte da interface em JavaScript e usará JavaScript para seu código.

Engrenagens pode fornecer o armazenamento de dados persistente do lado do cliente que você precisa.No entanto, não existe uma maneira muito boa de não expor seu código-fonte.Você poderia ofuscá-lo, mas isso só ajuda um pouco.

Eu fiz aplicativos simples como este para coisas como um Solucionador de Sudoku.

Você pode ter problemas de desempenho, pois está completamente à mercê do intérprete Javascript do cliente.O Gears seria uma ótima forma de armazenamento de dados, mas não acho que tenha penetrado tanto no mercado.Você poderia simplesmente usar cookies se não for muito exigente com esse tipo de coisa.

Estou com ScottKoon aqui, Adobe AIR é ótimo.Na verdade, só criei um widget muito legal (imho) até agora, mas fiz isso usando jQuery e Prototype.js, que funcionaram de maneiras maravilhosas porque não precisei aprender um modelo de evento totalmente novo.Adobe AIR é muito bom, o consumo de memória não é tão ruim, a atualização para uma nova versão é integrada ao AIR, então é quase automática e o melhor de tudo é multiplataforma...eles até têm uma versão alfa para Linux , mas já funciona muito bem no meu Eee.

Jogos independentes no GWT:

  1. http://gpokr.com/
  2. http://kdice.com/

Em relação ao salvamento de arquivos de um aplicativo javascript:

Estou muito entusiasmado com as possibilidades dos aplicativos do lado do cliente.O Flash 10 introduziu a capacidade de criar arquivos para salvar diretamente no navegador.Achei super legal, então criei um componente javascript + flash para envolver o recurso de salvamento.No momento só funciona para criar arquivos baseados em texto (vcard, ical, xml, html, css, etc.)

  1. Página inicial do download
  2. Código-fonte e documentação no Github
  3. Veja-o em uso no Starter para jQuery

Pretendo adicionar suporte para arquivos que não sejam de texto em breve, mas isso é um começo.

Meus feeds RSS me serviram bem - descobri aquele Javascript roguelike!

É chamado As Tumbas de Asciiroth.

Dado que você escreverá algum código de servidor de qualquer maneira, faz sentido manter o armazenamento no servidor para muitos domínios (livros de endereços, pontuações de pôquer, configuração de GUI, etc.). Se você entrar no Webkit ou Gears, provavelmente também poderá mantê-lo em seu servidor.

A vantagem de mantê-lo em seu servidor é dupla:

  1. Você pode integrá-lo simplesmente como uma camada de modelo em uma estrutura MVC típica e,
  2. Os usuários obtêm uma visão consistente sem ficarem presos ao navegador/PC ou em um ambiente nada ideal (Internet Cafés).

O código do servidor para lidar com isso também pode ser bastante trivial, principalmente se for escrito com essa tarefa em mente, portanto não representa um grande fardo cognitivo.

Vá com qooxdoo.Eles lançaram recentemente o 1.0, embora a maioria dos usuários diga que ele estava pronto para o 1.0 há pelo menos duas versões.

Comparei qooxdoo com YUI e ext, e acho que qooxdoo é o caminho a seguir para programadores - YUI não é tão polido quanto qooxdoo, do ponto de vista de um programador e ext tem um modelo de licenciamento não tão amigável.

Alguns dos pontos fortes (para mim) do qooxdoo são:

  • código extremamente limpo
  • o melhor modelo de programação OO que já vi entre os frameworks Javascript
  • uma biblioteca de widgets de UI extremamente rica

Ele também possui um executor de testes para testes de unidade, um gerador e leitor de documentos de API, um recurso de registro e vários recursos úteis para depuração, agrupados em algo chamado Inspetor.

A única desvantagem é que não existem temas prontos (algo como skins) para qooxdoo.Mas criar seu próprio tema é bastante fácil.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top