Serei capaz de codificar o código do navegador do lado do cliente em um idioma de minha escolha? [fechadas]

15

Serei brutalmente honesto: eu odeio escrever código do lado do cliente em JavaScript. Eu não sou fã dessa linguagem, para dizer o mínimo.

Parece bobagem para mim que os navegadores suportem uma linguagem de programação , em vez de uma máquina virtual intermediária (como CIL ou JVM). O último permitiria que os programadores escrevessem em um idioma de sua escolha (até certo ponto), em vez de em um idioma predefinido fixo. Esse idioma pode evoluir mais rapidamente, porque apenas alterações no CIL / JVM / o que exigiria a atualização de todos os principais navegadores. Recursos de idioma podem ser adicionados sem afetar a experiência antiga do navegador.

As enormes economias de esforço que os idiomas intermediários geram são bem conhecidas . Existem iniciativas por aí para promover o "script" do navegador em algo que não seja o JavaScript, e especialmente em uma máquina virtual já projetada, desenvolvida e otimizada? Eles têm algum impulso?

programming-languages browser Roman Starkov
fonte
consulte também: Por que não existem outras linguagens de script do lado do cliente para sites?
mosquito

Respostas:

11

Para responder sua pergunta, sim, estão sendo feitos esforços para descontinuar o Javascript em favor de uma linguagem mais coesa para scripts da Web. O Google tem colocado muita força por trás da linguagem Dart . O Dart possui sua própria VM, que já está incorporada ao Chrome, mas não tenho certeza se os outros navegadores já o adotaram. Há também uma linguagem bastante promissora chamada CoffeeScript .

Há também um projeto muito ambicioso chamado HaXe, que visa unificar toda uma série de plataformas de desenvolvimento com um único idioma.

Acredite, você não está sozinho em não gostar do Javascript, mas receio que isso não aconteça tão cedo - na verdade, parece estar ganhando muito impulso com os aplicativos HTML5 / JS do Windows 8, etc., mas alternativas como as que eu mencionado estão começando a surgir :)

MattDavey
fonte
9
Unificar tudo em um único idioma é exatamente o oposto do que é desejado. Isso só deixa você com a mesma situação que agora, apenas com um idioma diferente em vez de JavaScript. O ponto é que os esforços existentes devem ser baseados: o IL / CLR está bem estabelecido, já possui JITters de alto desempenho para a maioria das plataformas e vários compiladores já compilam vários idiomas nele. Para trazer a web para o século XXI, os navegadores precisam fazer uso disso, em vez de constantemente tentar criar seus próprios itens novos e começar do zero.
Timwi
3
@ Timwi, o CIL é muito pesado e há muita burocracia nele. Não faria sentido anexar um arquivo de bytecode completo e inchado com uma classe dedicada e todos os metadados volumosos a cada onSomethingmanipulador de eventos - analisar e interpretar 10 a 20 caracteres de uma linguagem de script simples é muito mais eficiente.
SK-logic
1
@ SK-logic: Você parece ter uma imagem completamente errada do CIL e do bytecode em geral. Não tenho idéia do que faria você pensar que os metadados binários são "volumosos" em comparação com uma sintaxe de alto nível, como JavaScript. Acima de tudo, não tenho idéia do porquê o "manipulador de eventos onSomething". Os programas C # claramente não são compilados em vários assemblies para cada manipulador de eventos.
Timwi
1
@ Timwi, estou comendo ECMA-335 no café da manhã, então sei muito bem quão volumoso é o CIL. Nós DOM são frequentemente gerados dinamicamente. Não há como adicionar algo a um módulo existente no CIL - você precisa definir um novo módulo. E você não pode adicionar a uma classe - você precisa definir uma nova classe (com os metadados volumosos anexados). E basta comparar o custo da leitura, JIT e execução do CIL com a análise, execução e descarte imediato de uma pequena string de texto. Existem muitos casos em que uma interpretação ad hoc é muito mais eficiente do que qualquer tipo de compilação.
SK-logic
2
@ Timwi, você está propondo usar o bytecode como denominador comum e um formato de comunicação, certo? O que quero dizer é que a especificação atual do CIL é praticamente inútil. ExpandoObject é irrelevante. E sua visão sobre a complexidade da análise é obscurecida. O módulo CIL contém sua própria tabela de referência de montagem, tabela de tokens de metadados e somente classes e métodos. Compare o esforço necessário para ler e JIT todo esse material volumoso com a interpretação de uma sequência de uma linguagem trivial de alto nível. O custo de análise é quase zero aqui. Apenas tente as duas abordagens e compare-se.
SK-logic
5

O próprio Javascript pode ser visto como uma linguagem intermediária, definindo uma máquina virtual na qual outras linguagens podem ser compiladas. Em projetos como o GWT, essa noção já está decolando. Pode não ser o que você projetaria do zero, mas já está se tornando uma realidade que você pode compilar "seu idioma favorito" em Javascript.

John Snelson
fonte
5

Essencialmente, não. Você está praticamente preso ao Javascript.

Dito isto, houve esforços no passado para incorporar outros idiomas (applets java, vbscript etc.). Cada um deles nunca ganhou a força que o javascript possui porque o javascript está integrado .

A única maneira de criar o que você está se referindo seria criar uma linguagem de script executada em uma máquina virtual, compilada no lado do cliente e depois executada. Então, cada navegador teria que implementar a máquina virtual em sua própria base de código, para que todo o código fosse executado em todos os navegadores. Então você precisa ter algum tipo de padrão para que todos os navegadores executem os comandos da mesma maneira. Obviamente, como os navegadores são criados de forma independente, provavelmente haveria peculiaridades que os desenvolvedores teriam que ter em mente.

Mas agora acabamos de descrever o Javascript.

Então, no final, suas escolhas são:

  1. acostume-se ao Javascript
  2. tente usar alguma linguagem que seja compilada em Javascript. (Lembre-se de que você ainda deseja verificar o Javascript, que retorna à opção 1.)
  3. use um idioma que exista como um plug-in para o navegador, como actionscript (Flash), ActiveX, applet java, .Net (SilverLight). Isso evita o problema com vários fornecedores / implementações do idioma, mas não integra o idioma.

Basicamente, se você deseja uma linguagem integrada, está preso ao Javascript.

Richard
fonte
2
Outra opção seria usar uma linguagem que compila para javascript e usar isso.
Jetti
@Jetti Você está pensando em CoffeeScript ? É o lema - é "Regra de Ouro", como eles chamam - é "É apenas Javascript" . Mas se você está escrevendo algo que é essencialmente Javascript, não está realmente escrevendo Javascript? É como argumentar que o jQuery não é javascript porque é mais limpo e fácil de usar.
Richard
2
dê uma olhada nesta lista de idiomas que são compilados para javascript
Jetti
@Jetti Talvez eles resolvessem tudo bem. Mas, com a peculiaridade do suporte entre navegadores, eu ficaria nervoso em recomendar qualquer um desses e não em verificar o javascript gerado.
Richard
1
Exceto que o javascript é uma linguagem intermediária absolutamente horrível e muito difícil de executar de forma consistente.
Milind R
4

Na verdade, você não está odiando o javascript, conforme descrito nos padrões da Ecma, mas está odiando a péssima implementação em vários navegadores , com suas peculiaridades, bugs e wtfs. Javascript do lado do servidor é bastante agradável, na verdade. Além disso, o modelo DOM é a causa de 80% da dor do javascript do lado do cliente.

Se você ainda deseja usar outro idioma, pode usar GWT , que basicamente permite escrever Java e compilá-lo em javascript (feio), ou CoffeeScript , que é um açúcar sintático sobre JS, que é compilado em JS.

Clement Herreman
fonte
9
Eu não posso falar por romkyns, mas eu odeio em si JavaScript ( além dos problemas que você mencionou). Ele não é orientado a objetos, não possui tipagem estática, nenhum tratamento útil de erros e nenhuma estrutura útil de funcionalidades modernas. Também é inconsistente e pesado. E, a propósito, o recurso mais odiado do JS, inserção de ponto e vírgula, está no padrão ECMA.
Timwi
1
@ Timwi, é baseado em funções e você pode escrever código OO, se quiser. A digitação estática é boa, mas se o seu código for bem escrito (pequenas funções, escopo adequado), raramente será um problema. Quanto à inserção de ponto e vírgula, acho que isso é um aborrecimento leve. Só me mordeu uma vez, porque tive o retorno e a abertura {de um objeto em linhas diferentes. Que "estrutura de funcionalidade moderna" você acha que está faltando?
CaffGeek
2
O JavaScript em si não é a melhor linguagem existente (por assim dizer). Eu não me importo com coisas orientadas a objetos (quanto menos, melhor), com seu sistema de tipos dinâmicos (é realmente necessário para uma linguagem de script desse tipo, infelizmente), mas com a presença de declarações e a falta de listas e tuplas é irritante. Tanto para escrever em JavaScript quanto para implementar compiladores direcionados para JavaScript.
SK-logic
2
@ Timwi: você está vendo que não é orientado a objetos como uma coisa ruim, embora nem sempre seja o caso. Por favor, não veja OOP como a bala de prata dos paradigmas de desenvolvimento. Abordagem funcional, como JS ou Scala, também são ótimas. Você pode ter OOP em JS, mas a principal diferença é que é a programação baseada em protótipo, em vez da programação baseada em classe. OOP é um nome amplo e não se limita a Java / C #. O protótipo é diferente do baseado em classe e, bem usado, é tão poderoso quanto o baseado em classe.
Clement Herreman
2
@ClementHerreman: JavaScript não se limita ao lado do cliente, mas esta discussão é sobre o lado do cliente. O JavaScript é limitado ao protótipo, que é uma desvantagem em comparação com o IL, que permitiria o uso de praticamente qualquer idioma.
Timwi
2

Esta pergunta aparece de tempos em tempos.

Por que não temos outros idiomas em tags de script em vez de apenas Javascript

No dia em que o IE introduziu o VB como uma alternativa ao Javascript. Eu acho que você já pode ver como isso levaria a padrões infernais se pegasse ...

Então, por que não uma linguagem intermediária padrão comum então?

Existe um podcast antigo de Brendan Eich explicando por que ele não vê uma linguagem de bytecode intermediária em um futuro próximo:

http://www.aminutewithbrendan.com/pages/20101122

http://news.ycombinator.com/item?id=1893686

O problema básico é que, enquanto a linguagem intermediária (como CIL e os bytecodes da JVM) tenta ser genérica, na maioria das vezes eles se revelam com um nível muito baixo e muito vinculados às linguagens originais de alto nível que foram compiladas para eles. Por exemplo, você não pode realmente implementar funções recursivas de cauda na JVM - que outros recursos de idioma ou opções de implementação não conseguiremos implementar se associarmos a uma abstração de código de byte de baixo nível cedo demais?

Enquanto isso, o Javascript é uma linguagem flexível de alto nível, com semântica estabelecida e várias implementações diferentes, eficientes. O que poderemos ver no futuro é o próprio Javascript como uma linguagem intermediária - infelizmente isso é um tanto imaturo e poucas linguagens compilam no JS a partir de hoje.

hugomg
fonte
Mas esse argumento se aplica ao JavaScript tanto quanto à JVM e CIL, não é? :) A única coisa que vale para o JavaScript é que ele já é suportado por todos os navegadores.
Roman Starkov
O ponto é mais sutil - o Javascript é descrito em um nível superior ao da maioria das linguagens intermediárias, para que as implementações tenham mais espaço para escolher o que fazer. (Claro, isso não é tudo um mar de rosas - Eu só queria salientar que não somos os primeiros a pensar em uma IL para a web e que não é assim tão simples)
hugomg
1

Sim. Você já pode compilar Dart, Coffeescript e Java para Javascript. Você tem o Emscripten, que é um back-end do compilador para o LLVM para gerar bytecode Javascript (e o LLVM lida com várias linguagens, acredito).

Mas, além de compilar para JS, não em um curto espaço de tempo. O IE6 tem 10 anos e ainda está chutando. Espero que os navegadores atuais (que não oferecem suporte a outros idiomas) não sobrevivam por muito tempo, mas permanecerão por alguns anos, provocando o ciclo de "mordida de cauda" de "ainda precisamos dar suporte a navegadores compatíveis apenas com Javascript, portanto, precisamos usar o Javascript ", de uma maneira muito mais difícil do que dizer CSS3 - seu site pode funcionar sem CSS3, mas tente fazê-lo sem scripts do lado do cliente.

alex
fonte
0

Você pode apenas estar com sorte. Este é o parágrafo de abertura de uma submissão no fórum webkit-dev:

Hoje, muitos idiomas compilam o JavaScript para rodar na web. Como alternativa, tentamos permitir que diferentes tempos de execução de idiomas no WebKit sejam executados em páginas da Web ao lado de JavaScript ...

Você pode ver o restante da mensagem aqui .

pgfearo
fonte
0

O JavaScript é a alma dos navegadores, é por isso que a maioria das novas tentativas está gerando JavaScript (o CoffeeScript é um exemplo claro).
No GWT, você codifica sua lógica do lado do cliente na linguagem de programação Java e o kit de ferramentas gera JavaScript.

ClojureScript é um projeto interessante se você estiver na codificação Lisp.

Portanto, parece que não importa o que, o JavaScript está aqui para ficar. (COBOL da web, talvez?).

Quíron
fonte
0

"Qualquer cliente pode ter um carro pintado da cor que quiser, desde que seja preto". -- Henry Ford

Já existem vários compiladores direcionados ao javascript, e você pode escolher qualquer idioma que seja compilado para javascript.

Seu link que discute o valor das linguagens intermediárias as discute no contexto da implementação de um conjunto de compiladores, não no fornecimento de código que será enviado por uma rede e executado em uma máquina cliente. O Javascript pode não ser o melhor formato para isso, mas, seja o que for, não será muito parecido com CIL ou bytecodes java.

Se você odeia javascript, sugiro que você mude para o espaço Embedded, Scientific ou de desenvolvimento de jogos, onde C, Fortran e C ++ dominam. Os aplicativos de linha de negócios estão mudando muito para a Web, e isso significa mais Javascript, não menos.

Sean McMillan
fonte