•  06-09-2019
  •  | 
  •  

Pergunta

No momento, a única linguagem totalmente suportado, e o padrão de fato para a manipulação árvore DOM no navegador é JavaScript. Parece que ele tem problemas de design profundas que o tornam um campo minado de bugs e falhas de segurança para o novato.

Você sabe de qualquer iniciativa existente ou prevista a introdução de uma linguagem melhor (redesenhada) de qualquer tipo (não só javascript) para manipulação de árvore DOM e solicitações HTTP em navegadores de próxima geração? Se sim, qual é o roteiro para a sua integração, por exemplo, Firefox, e se não, por que razões (além de interoperabilidade) deve ser JavaScript do idioma suportado apenas na plataforma do navegador?

eu já usei jQuery e eu também li "javascript: as partes boas". Na verdade as sugestões são boas, mas o que eu não sou capaz de entender é: por que apenas javascript? No servidor-side (plataforma de seu-favorito-os), nós podemos manipular uma árvore DOM com cada língua, mesmo fortran. Por que o lado do cliente (a plataforma do navegador) apenas suporte javascript?

Foi útil?

Solução

O problema com javascript não é a própria linguagem - é um perfeitamente bom protótipo e dinâmica linguagem. Se você vem de um fundo OO há um pouco de uma curva de aprendizagem, mas não é culpa do idioma.

A maioria das pessoas assumem que o Javascript é como Java, porque ele tem sintaxe semelhante e um nome semelhante, mas na verdade é muito mais parecido com lisp. É realmente muito bem adaptado à manipulação DOM.

O verdadeiro problema é que ele é compilado pelo navegador, e isso significa que funciona de uma forma muito diferente dependendo do cliente.

Não é só a diferentes DOM real, dependendo do navegador, mas há uma enorme diferença no desempenho e layout.

Editar seguinte esclarecimento em questão

Suponha que várias linguagens interpretadas foram apoiados - você ainda tem os mesmos problemas. Os vários navegadores ainda seria buggy e têm diferentes DOM.

Além disso, você teria que ter um intérprete embutido no navegador ou de algum modo instalado como um plug-in (que você pode verificar antes de servidos da página) para cada idioma. Levou as idades para obter Javascript consistente.

Você não pode usar linguagens compiladas da mesma forma - então você está introduzindo um executável que não pode facilmente ser examinado para o que ele faz. Muitos usuários se optar por não deixá-lo correr.

OK, então o que dizer de uma espécie de sandbox para o código compilado? Soa como Java Applets para mim. Ou ActionScript no Flash. Ou C # no Silverlight.

O que sobre algum tipo de padrão IL? Que tem mais potencial. Desenvolver em qualquer língua que você quer e, em seguida, compilá-lo para IL, que o navegador, em seguida, EIC.

Exceto, Javascript é meio que já que a IL - olhar apenas em GWT . Ele permite que você escrever programas em Java, mas distribuí-los como HTML e JS.

Editar seguinte esclarecimento em questão

Javascript não, ou melhor, é não foi, o único idioma suportado pelos navegadores: de volta na idade das trevas do Internet Explorer você pode escolher entre JavaScript ou VBScript para executar no IE. Tecnicamente IE nem sequer executar JavaScript - ele correu JScript (principalmente para evitar ter que pagar Sun para a palavra java , a Oracle ainda possuem o nome Javascript ).

O problema era que VBScript era de propriedade da Microsoft, mas também que ele apenas não foi muito boa. Enquanto Javascript estava adicionando funcionalidade e recebendo taxa superior ferramentas de depuração em outros navegadores (como o Firebug) VBScript permaneceu IE-only e praticamente un-debuggable (ferramentas de desenvolvimento em IE4 / 5/6 foram nenhum existente). Enquanto isso VBScript também se expandiu para se tornar uma ferramenta de scripting muito poderosa no SO, mas nenhum desses recursos estavam disponíveis no navegador (e quando eles estavam tornaram-se falhas de segurança em massa).

Existem ainda algumas aplicações internas das empresas lá fora, que o uso de VBScript (e alguns contam com essas falhas de segurança), e eles ainda estão correndo IE7 (que só parou IE6 porque MS finalmente matou-off).

Obtendo o Javascript para seu estado atual tem sido um pesadelo e tomou 20 anos. Ele ainda não tem suporte consistente, com recursos de linguagem (especificadas em 1999) ainda faltando alguns navegadores e lotes de calços a ser exigido.

Como adicionar um idioma alternativo para interpretar em navegadores enfrenta dois grandes problemas:

  • Começar todo o navegador fornecedores para implementar o novo padrão de linguagem -. Algo que eles ainda não conseguiram para Javascript em 20 anos

  • A segunda língua potencialmente dilui o apoio que você já tem, permitindo que (por exemplo) IE ter segundo suporte Javascript taxa, mas grande VBScript (novamente). Eu realmente não quero estar escrevendo código em diferentes idiomas para diferentes browsers.

Ele não deve sered que o Javascript não está 'acabado' - ele ainda está evoluindo para se tornar melhor em novos navegadores. A versão mais recente está anos à frente do de implementações dos navegadores e eles estão trabalhando no próximo.

Outras dicas

Compilar para Javascript

Por enquanto, usando uma linguagem que compila a Javascript parece ser a única maneira realista para chegar a todas as plataformas ao escrever código mais inteligente, e isso provavelmente permanecerá o caso por um longo tempo. Com qualquer nova oferta, haverá sempre alguma razão para que um ou mais fornecedores não vai apressar para enviá-lo.

(Mas eu realmente não acho que este é um problema. Javascript está bem otimizado por agora. Código de máquina também é inseguro se escrito à mão, mas funciona bem como um alvo de compilação e linguagem de execução.)

Tantas opções

Existe uma piscina crescente de idiomas que compilam a Javascript. A lista bastante completa pode ser encontrada aqui:

Notável

Vou citar alguns que eu acho que são dignos de nota (enquanto há dúvida de negligenciar algumas jóias que eu ignoro):

  • Aranha apareceu em 2016. Alega a tomar as melhores idéias de Go, Swift, Python, C # e CoffeeScript. Não é typesafe, mas tem algumas pequenas características de segurança .

  • Elm : Haskell pode ser o linguagem mais inteligente de todos eles e Elm é uma variante de Haskell para JavaScript. É digite-aware altamente e concisa, e as ofertas de Funcional programação Reactive como uma alternativa pura modelos reativas ou spaghetti MVC. Mas pode ser bastante um choque para programadores processuais .

  • Go do Google é destinado a concisão, simplicidade e segurança. código Go pode ser compilado em Javascript por GopherJS .

  • Dart foi a tentativa mais tarde do Google para substituir Javascript. Ele oferece interfaces e classes abstratas através de um C / Java-como sintaxe com digitação opcional.

  • Haxe é como ActionScript do Flash, mas pode alvo vários idiomas para seu código pode ser re-utilizado em programas Java, C, flash, PHP e Javascript. Ele oferece objetos de tipo seguro e dinâmico.

  • Opalang acrescenta açúcar sintático para Javascript para fornecer acesso de banco de dados direta , inteligente continuações, verificação de tipo e ajudar com a separação cliente / servidor. (Amarrado a NodeJS e MongoDB.)

  • GorillaScript , "uma compilação-to- linguagem JavaScript projetado para capacitar o usuário ao tentar evitar alguns erros comuns ". é semelhante ao Coffeescript mas mais abrangente, oferecendo um monte de recursos extras para aumentar a segurança e reduzir os padrões de clichê repetitivas.

  • LiteScript cai em algum lugar inbetween Coffeescript e GorillaScript. Ele oferece sintaxe assíncrona / rendimento para retornos de chamada "inline", e verificar se há erros de digitação variáveis.

  • Microsoft do typescript é um pequeno super conjunto de Javascript que permite que você coloque tipo restrições-on argumentos da função , que pode pegar alguns bugs. Da mesma forma BetterJS permite aplicar restrições, mas em pura Javascript, quer pela inclusão de chamadas extras ou especificando tipos de comentários JSDoc. E agora Facebook ofereceu Fluxo que, adicionalmente, realiza a inferência de tipos.

  • LiveScript é um spin-off de Coffeescript que era popular por sua brevidade, mas faz não parece muito legível para mim. Provavelmente não é o melhor para as equipes.

Como escolher?

Quando escolher uma linguagem alternativa, existem alguns fatores a considerar :

  • Se outros desenvolvedores participar do seu projeto no futuro, quanto tempo vai levar para chegar até a velocidade e aprender esta língua, ou quais são as chances que eles sabem disso já?

  • Será que a linguagem tem muito poucos recursos (código ainda estará cheio de clichê) ou muitos recursos (ele vai levar um longo tempo para dominar, e até lá algum código válido pode ser indecifrável)?

  • Será que ela tem as características que você precisa para seu projeto? (A sua necessidade de projeto tipo de verificação e as interfaces? Será que ela precisa continuações inteligentes para evitar o inferno callback aninhada? Existe uma grande quantidade de reatividade? Poderia precisa para atingir outros ambientes no futuro?)

O futuro ...

Jeff Walker escreveu uma série instigantes de posts sobre "o problema Javascript", inclusive porque ele não pensa typescript , nem Dart nem Coffeescript oferecer soluções adequadas. Ele sugere algumas características desejáveis ??para uma linguagem aprimorada em a conclusão .

deve ser JavaScript do idioma suportado apenas na plataforma do navegador?

Sim e não. Há uma alternativa lá fora chamado Dart pelo Google que faz compilação de JavaScript e, assim como jQuery que tenta fazer a manipulação DOM um pouco mais fácil. Pode ser divertido de experiência, check-out.

Veja também

É verdade que o Javascript estava em um ponto notoriamente difícil de lidar, mas a comunidade de desenvolvimento web tem percorreu um longo caminho desde então. Em vez disso, gostaria de encorajá-lo a ter um olhar para jQuery . É fácil e abstrai todos os vários problemas.

E realmente não há alternativas que trabalho através da placa. Flash vem à mente, mas isso também é ECMAScript e é provavelmente mais matam para a maioria das coisas.

prazo curto, eu uso coisas como jQuery para esconder as incompatibilidades navegador. A longo prazo, tecnologias como o Silverlight ou Adobe AIR pode fazer este um campo minado muito diferente (mas ainda um campo minado) no futuro.

Doug Crockford deu uma palestra no Google detalhando a partes boas e ruins de JavaScript e seu futuro. Ele realmente não mudou muito em tudo desde 1999 - o que pode ser dito ser uma coisa boa (praticamente todos os navegadores pode executar o mesmo código, desde que você está ciente de suas limitações) e Doug mostra onde as peças boas eram em sua maioria mal-entendidos que acabam por ser muito poderosa.

Para DOM manipuluation, olhada JQuery como uma biblioteca do lado do cliente que substitui a maior parte da API DOM terrível com operações que são uma dor para escrever em pedaços muito elegantes de código que são mais fáceis de escrever.

Se você está pensando que o JavaScript tem problemas profundos, eu recomendo o livro de Doug Crockford, JavaScript : The Good Parts . (Ou Google para "Crockford JavaScript" para encontrar várias apresentações de vídeo que ele fez.) Crockford esboça um subconjunto seguro e conjunto de práticas, e enumera especificamente algumas partes da linguagem de evitar.

Estou desconhecem os planos para substituir JavaScript como de facto meios de manipular o DOM. Então, melhor aprender a usá-lo de forma segura e bem.

Em termos de lado do cliente Javascript é a única maneira de manipular o DOM. Em termos de lado do servidor, há uma infinidade de maneiras.

Internet Explorer suporta linguagens de script conectáveis, embora o único incluído de forma confiável com o IE além JScript é VBScript.

Tanto quanto eu tenho visto, parece haver uma espécie geral de viés em direção linguagens dinâmicas no navegador, e JavaScript parece preencher esta necessidade de forma adequada o suficiente para que os efeitos de rede fazem qualquer outra língua um non-starter. A linguagem é realmente muito poderoso, embora a sua implementação em navegadores deixa muito a desejar.

Se você está disposto a restringir seus clientes / visitantes para navegadores específicos, e possivelmente disposto a obrigá-los a instalar um plug-in, você pode olhar para MS Silverlight - uma visão legível está em wikipedia . Com o Silverlight 2, você pode correr, do lado do cliente, o código que você escreveu em C #, IronPython, IronRuby, VB.NET, etc; a livre luar clone do Silverlight, a partir do projeto Mono, promete trazer a mesma funcionalidade para Linux .

Na prática, a maioria dos desenvolvedores de aplicações web e sites preferem para alcançar um público mais vasto do que o Silverlight (e, eventualmente, do luar) atualmente pode oferecer - o que significa degola com Javascript, ou possivelmente o Flash (que usa uma linguagem de programação semelhante, Actionscript).

Assim, ganhando substancial mindshare, adopção e tração para qualquer outra coisa que está provando ser uma luta difícil, mesmo para Microsoft com seus grandes grupos de engenheiros e orçamentos de marketing e um projeto de software livre no lado (possivelmente para aliviar as preocupações sobre lock-in proprietário) - o que pode ajudar a explicar por que há muito pouco interesse, por exemplo, por parte da Fundação Mozilla, na empurrando para essa meta a. "Além de interoperabilidade", você diz: mas claramente a questão da interoperabilidade é o biggie aqui, dado que observamos wrt o progresso do Silverlight ...

Como já disse, você tem Flash (ActionScript, que é uma língua derivada do Javascript) e Silverlight / luar (IronPython, IronRuby, JScript, VBScript, C #) que pode ser executado no navegador via plugins (a primeira sendo muito mais onipresente).

Há também uma outra alternativa se você gosta de Ruby: HotRuby , é uma implementação de rubi em javascript que a vontade executado no navegador. Não é muito maduro ainda, mas você pode ter um olhar para ele.

Uma coisa que eu não vi mencionado (oh, eu vejo Alcides mencionado HotRuby enquanto eu estava escrevendo e Nosredna mencionado GWT e Script #) e gostaria de jogar lá fora é que há um número de implementações de [língua] -on-JavaScript (por exemplo, tradutores que permitem converter rubi , Python , C # , Java , obj-J / Cappuccino [semelhante ao obj-C / cacau] ou Processamento [para lona] a JavaScript quer no cliente ou antes da implantação [e alguns dos quais também apresentam várias bibliotecas de captação]). Claro que há uma sobrecarga de desempenho, se ele está sendo traduzido no cliente, mas se você está mais confortável com outra linguagem que permitirá que você alguma flexibilidade.

Pessoalmente, porém, eu recomendo aprender a amar JavaScript. É um excelente, linguagem poderosa, e muito elegante, uma vez que você começa a conhecê-lo. Eu estou enfrentando o dilema oposto, mastigando o bocado para ter uma solução JavaScript / DOM que atenda todas as minhas necessidades do lado do servidor capaz. / Opinião não solicitada

No. JavaScript é isso, mas vai evoluir. A próxima versão é "JavaScript Harmony", e você pode aprender mais se você Google isso.

Agora, e então alguém sugere colocar um intérprete de código de byte para os navegadores ao lado de JavaScript. Provavelmente não vai acontecer, pelo menos por algum tempo.

Acontece que eu amo JavaScript. Mas há outras soluções, incluindo GWT, que compila Java para JavaScript e Script #, que compila C # para JavaScript.

Jquery (ainda javascript mas) ele realmente vai ajudá-lo a que eles têm suporte para quase todos os navegadores e não é realmente tão difícil de aprender:)

O JavaScript é a linguagem de Inglês da web. Inglês historicamente espalhar porque tinha uma marinha forte conquistando vários países. Isto é comparável a grandes empresas que conquistaram a web com JavaScript. É uma linguagem derrotado junto de várias fontes europeias (grego, latim, línguas germânicas, Francês mesmo alguns chineses e palavras indígenas). JavaScript emprestado um monte de conceitos ao longo dos anos a partir de outras línguas (estrutural, OO, funcionais). Inglês é falado em lugares diferentes, com pequenas variações no dialeto e sotaque, que podem processar a compreensão difícil. Assim como JavaScript tem diferentes navegadores interpretação um pouco diferente.

Apesar de Inglês é fácil de aprender, inicialmente, tem pronúncia muito inconsistente e mais exceções do que regras. Assim como JavaScript é sempre lá para oferecer uma surpresa.

Apesar das diferentes sotaques, JavaScript é a língua franca da web. Assim como você pode não ser Inglês e escrever aqui em Inglês, cada navegador tem um certo grau de compreensão Inglês. IE6 é como o cara que diz em seu currículo que ele é fluente, mas só fui a um curso de duas semanas de Inglês como língua estrangeira.

Tem havido tentativas de suplantar Inglês como os mundos de língua principal, por exemplo, Esperanto. Mas todos eles falharam, porque a maioria das pessoas na terra falar um pouco de Inglês. Da mesma forma, será difícil introduzir melhores alternativas para JavaScript.

Eu não acho Javascript será substituído em breve. Para uma abordagem completamente diferente para clientes ricos, você pode querer investigar Flex, que é uma tecnologia baseada em Flash.

Talvez algo como haxe (veja haxe.org) poderia ajudá-lo. É uma linguagem que parece mais limpo do que JavaScript e pode ser compilado até JavaScript, para que ele possa ser executado dentro de um navegador.

Eu sei que isto não é uma resposta directa à sua pergunta, mas eu pensei que poderia ser interessante para você, no entanto.

Muitas pessoas entendem que o Javascript não é melhor e mais bonita linguagem nunca. No entanto, é atualmente suportada por navegadores e, assim, será extremamente difícil introduzir um idioma diferente. Nós simplesmente não precisa de outra guerra browser.

Isso explica por que eu saiba não tem planos de mudar para uma linguagem do lado do cliente diferente.

Mas eu acho que o Javascript não é tão ruim se você começar a pensar sobre o modelo DOM e como o faria um trabalho com ele. Muitas coisas que são confuso com JS são o resultado dos trabalhos modelo modo DOM.

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