projeto de compiladores - Como usar outra linguagem que não JavaScript no browser? - Stack Overflow em Português
Stack Overflow em Português
Loading…
0
+0
Tour Comece aqui para obter uma visão geral rápida do site
Central de ajuda Respostas detalhadas a qualquer pergunta que você tiver
Meta Discutir o funcionamento e as políticas deste site
Sobre Nós Saiba mais sobre a empresa Stack Overflow
Negócios Saiba mais sobre a contratação de desenvolvedores ou publicação de anúncios conosco
Log-in Registrar-se
comunidade atual
Stack Overflow em Português
ajuda chat
Stack Overflow em Português Meta
suas comunidades
Faça log in ou registre-se para personalizar suas comunidades
mais comunidades stack exchange
Blog da empresa
Stack Overflow em Português é um site de perguntas e respostas para programadores profissionais e entusiastas. Leva apenas um minuto para se inscrever.
Inscreva-se para participar desta comunidade
Qualquer pessoa pode fazer uma pergunta
Qualquer um pode responder
As melhores respostas recebem votos positivos e sobem para os primeiros lugares
Início
Público
Perguntas
Tags
Usuários
Sem resposta
Como usar outra linguagem que não JavaScript no browser?
Faça uma pergunta
Perguntada 7 anos, 9 meses atrás
Ativa 6 anos atrás
Vista 2mil vezes
10
2
Apesar da enorme pluralidade de linguagens de programação em diversos ambientes (desktop, servidor, dispositivos móveis), o browser continua suportando uma e somente uma linguagem: JavaScript. A razão disso me escapa: ainda que exista o problema da compatibilidade (quem faz um site ou web app quer que ele funcione em qualquer browser), nada impede que outras linguagens sejam usadas e "compiladas" para JavaScript. Isso pode ser feito ou no lado do servidor (ex.: Google Web Toolkit) ou cliente (ex.: processing.js). Ainda que me pareça uma "gambiarra", funciona, e interesse nisso não falta (antigamente a plataforma PyPy suportava compilação Python para JavaScript, mas da última vez que chequei essa funcionalidade estava abandonada).
Existe alguma maneira padronizada (ou em processo de padronização, à la HTML5) de se oferecer suporte a outras linguagens de programação no browser, que não dependa da instalação de plugins (ex.: Java, Flash, Silverlight)? De preferência, algo que funcione exclusivamente no lado cliente (como o exemplo do processing.js) sem demandar um programa específico no lado do servidor (e consequentemente um round-trip a ele sempre que um código tenha de ser interpretado).
E se não existe, há algum obstáculo conhecido que inviabilize tal coisa? Em outras palavras, é apenas por falta de interesse dos fornecedores que isso ocorre, ou há algum problema ainda em aberto que impeça tal coisa - seja em caráter privado ou que dependa de consenso entre os diferentes major players (padronizadores, fornecedores de browsers, etc)?
projeto-de-compiladores cross-browser scripting
Compartilhar
Melhore esta pergunta
Seguir
perguntada 8/02/14 às 7:43
mgibsonbrmgibsonbr
81,1mil2121 medalhas de ouro178178 medalhas de prata319319 medalhas de bronze
Adicione um comentário |
5 Respostas 5
Ativos Mais antigo Votos
7
Existem alguns impedimentos técnicos que dificultam a implementação de um ambiente multilinguagem no browser.
A linguagem Javascript possui bindings no Webkit (por exemplo) que é uma das engines web, entre o runtime c++ e a VM javascript (V8 no caso do chrome e JavascriptCore no caso do safari)
Primeiro que qualquer candidato a linguagem alternativa ao Javascript, precisaria ter uma VM também plugada diretamente no Webkit, com os respectivos bindings entre o runtime c++ e o runtime da VM.
O Webkit teria que ser reescrito para suportar (em runtime), duas ou mais VM's alternando-se de acordo com o código do usuário ou desenvolvedor
O projeto Dart da Google, tentou isso(e ainda tenta), sendo possivel usar esse branch do Chrome, chamado Dartium.. Mas ao que parece existem sérios problemas com os garbage collectors devido a duas ou mais VM's terem de ser carregadas em um mesmo processo, dividindo regiões de memória.. degradando consideravelmente a performance.
Uma das limitações é que a lógica DOM está escrita em C++, e a VM da linguagem precisa fazer operações bastante caras a nível de eficiência toda vez que precisa se comunicar com o runtime nativo em c++; Possibilidade: reescrever a lógica DOM, HTML, SVG, etc.. em cada linguagem script.. mas.. não existem muitos ganhos pois essas linguagens tendem a serem menos eficientes do que a C, portanto o ganho na comunicação acaba se perdendo em outros lugares :(
Também existem problemas de compatibilidade:
Imagina, por exemplo, se a partir de 2014 browsers com javascript e dart sejam lançados.. os desenvolvedores precisariam checar se o browser suporta Dart ou outro script pra a partir dai, resolver enviá-lo ou browser.. (mas esse também é um dos motivos pelo qual Dart compila para Javascript.. não havendo problemas nesse caso), mas se a linguagem implementada não tiver esse transpiler.. nada feito
Outra possibilidade seria usar uma IR - Intermediate Representation - de um compilador, onde essa IR fosse tão poderosa que várias linguagems possam ser implementadas em cima dessa representação.
Dois grandes exemplos são o bytecode java, que permitiu várias linguagens distintas funcionarem na JVM, e também mais recentemente o projeto LLVM, com o seu "bitcode" próprio. (outras idéias de nota são o asm.js da mozilla.. mas que não são tão ambiciosas assim quanto uma IR universal)
Com essa idéia seria possivel ter apenas uma VM no browser, implementar o Javascript de forma a produzir essa IR, e deixar assim em aberto para que outros desenvolvedores feras em compiladores possam implementar linguagens distintas para o browser (ou quem quer que embarque essa VM)
Nota: as IR JVM assim como LLVM possui limitações para linguagens dinâmicas por terem sido pensadas para a realidade de linguagens estáticas em seu design.. A LLVM ainda produz um bytecode com alguns elementos não portáveis com instruções para os processadores específicos.. não sendo uma IR "universal".
O projeto da Google o Pnacl, usa uma VM LLVM modificada, com um bytecode propriamente universal.. problemas: LLVM foi feita para compilação AOT, portanto demora pra compilar, pois busca produzir um código final extremamente otimizado, ao contrário das VM JIT's como V8, Dart e Lua que buscam também rapidez ao produzir o código.
Como visto não existe um caminho fácil para essa tão sonhada plataforma, mesmo que haja vontade em perseguir esse caminho, é preciso muito investimento pra bancar uma equipe de alto nível, por no mínimo uns 2 anos, para sair com um resultado aceitável
A melhor pedida agora é ver se o projeto Dart consegue ser embarcado junto ao Chrome, tendo pelo menos uma plataforma dual.. pois para essa plataforma "universal", é preciso de um milagre, vontade e uma boa soma de dinheiro para torná-lo realidade.
Obs: Estou usando IR no sentido de bytecode (retargatável) final, e não no sentido de representação intermediária interna dos compiladores(IR nível 1), como comumente definem a IR a literatura especializada em compiladores
Compartilhar
Melhore esta resposta
Seguir
editada 9/02/14 às 5:32
respondida 9/02/14 às 5:24
ViralataViralata
19133 medalhas de bronze
1
Valeu, era esse tipo de resposta que eu estava procurando. De fato, as linguagens alternativas ou "se compilam" para JavaScript ou são interpretadas em JavaScript, ambas as estratégias com suas desvantagens (ex.: performance ruim). Agora estou entendendo melhor os desafios técnicos que inviabilizam a abertura para mais linguagens.
– mgibsonbr
9/02/14 às 6:33
Adicione um comentário |
5
Como foi citado nessa resposta, os navegadores não itnerpretam, por padrão, outras linguagens internamente. Mas,como alternativa, surgem bibliotecas em outras linguagens feitas em javascript e frameworks que geram javascript.
Um bom exemplo de biblioteca "tradutora" é a Bryton, que permite a utilização da tag <script type="text\python3"> e a programação da página ser feita inteiramente e diretamente na linguagem Python.
Para finalizar, ainda é possível utilizar linguagens que sejam "traduzidas", a partir de frameworks, para javascript. Exemplos disso são o ActionScript 3.0 com o CreateJS e a nova linguagem da Google, a Dart, que lembra bastante a linguagem Java e pretende ser uma alternativa para o JS.
Ou seja, suportado nativamente, hoje, não existe nenhuma outra linguagem que fique do lado do cliente, mas existem diversas formas de se utilizar outras linguagens, com as quais você se sinta mais confortável, do que programar em javascript client-side.
Compartilhar
Melhore esta resposta
Seguir
editada 13/04/17 às 12:59
ComunidadeBot
1
respondida 8/02/14 às 13:08
Felipe AvelarFelipe Avelar
9.55733 medalhas de ouro3333 medalhas de prata5858 medalhas de bronze
2
3
Outra iniciativa interessante é o Emscripten que é um backend de JS para o LLVM. Ele efetivamente permite que o Clang compile C/C++ em JavaScript.
– Guilherme Bernal
8/02/14 às 13:31
Considerando que o Javascript tem desempenho cada vez mais próximo do nativo, por otimizações da engine e por extensões como asm.js, não vai demorar muito para toda grande linguagem de programação ser rotineiramente utilizada neste ambiente.
– epx
9/02/14 às 0:27
Adicione um comentário |
2
O principal motivo é que os navegadores só entendem javascript mesmo. E nem isso eles fazem perfeitamente, cada navegador sempre tem uma peculiaridade específica.
O IE tinha, não sei se ainda tem, o VBScript, pra você programar em Visual Basic. A Google está tentando coisas novas como o NaCl, que permite código C, mas isso ainda é restrito ao Chrome.
A moral da história é que pra termos uma linguagem interpretada no navegador precisamos que ela seja programada nele, e pra que todos os navegadores suportem é necessário haver um esforço de padronização. E apenas o javascript chegou nesse ponto até hoje.
Compartilhar
Melhore esta resposta
Seguir
respondida 8/02/14 às 9:29
C. E. GesserC. E. Gesser
3.7931515 medalhas de prata2727 medalhas de bronze
Adicione um comentário |
2
Dart
Google irá fazer sua linguagem Dart ser interpretada nativamente pelo browser.
Na verdade, já faz! Existe uma versão do Chromium que já roda diretamente scripts escritos em Dart - o Dartium.
A tendência é que a linguagem Dart venha ocupar bastante espaço dentro de alguns anos.
Se os outros browsers vierem a dar suporte ao Dart então seu uso poderá vir a ser tão proeminente quando o JavaScript hoje!
No momento, o Dart é "compilado" para JavaScript, ou seja, você escreve o programa em Dart e o IDE traduz para JavaScript, tornando-o uma solução utilizável desde já.
CSS, HTML, XML, XSLT...
HTML, XML... o "L" é de "Language", ou seja, linguagem. São linguagens de mark-up, não linguagens de programação. Mas, enfim, são linguagens que usamos no browser, sem ser JavaScript.
Do mesmo modo, CSS e XSLT são linguagens de style-sheet que os browsers também lidam.
E estas não são todas as "linguagens" que tanto nós, desenvolvedores, quanto os browsers podem lidar na montagem de páginas e aplicações web, no lado do cliente. Porém, como já disse, não são linguagens de programação.
Outras Linguagens
Um browser é um tipo de software que depende de todo um ecossistema. Nem adianta um gênio bolar um browser revolucionariamente ótimo, ou mesmo trazer o verdadeiro browser que estará sendo efetivamente utilizado daqui a 50 anos... para os dias de hoje. Tal browser seria inútil, pois não há nenhum site nem página na internet preparado para ele.
É como viajar no tempo e levar um aparelho de televisão para 100 ou 200 anos atrás, ou mais: em que tomada ligar o bicho? Que programas ele vai captar, seja por antena, satélite ou cabo? Não há rede elétrica, nem emissoras: o aparelho de televisão, mesmo que seja 3D, LED de última geração, é um traste inútil.
No ponto evolutivo da TI que estamos hoje, o browser, como ele é, tem UMA LINGUAGEM (de programação), e esse linguagem é o JavaScript. E ponto final. Podemos analisar e discutir os eventos históricos, sociais, políticos, econômicos e tecnológicos de como a evolução se deu até chegar neste ponto... porém o fato é este: JavaScript é a linguagem da internet, da web, do client-side, do navegador, do browser. Aparelhos móveis podem ter seus recursos nativos... porém todos irão ter o JavaScript em seus browsers.
Para esse bicho que é o browser, hoje, aceitar, entender e rodar C, Ruby, PHP, Python, Perl, COBOL, Pascal, Basic, LOGO, Ada, Haskell e Fortran... bom... sinceramente... é essa ideia para mim que não faz muito sentido. Poderia até haver algum web standard para fazer essa conexão... mas prover o suporte a uma multidão de linguagens built-in no browser é um contra-senso. Tal browser seria o software mais pesado de todos os tempos!
Mesmo que efetivamente seja estabelecido um standard para "conectar" outras linguagens instaladas no sistema operacional hospedeiro ao browser... então só aqueles que tiverem a linguagem instalada é que poderiam usufruir das mesmas. Nada tão diferente do que já temos hoje, com o Flash (ActionScript), Java, etc. Quer dizer: seja através de um plugin ou um novo standard, o usuário precisará instalar o suporte a essa(s) outra(s) linguagem(ns).
De outro modo, embutir o suporte a elas no browser, como já disse, me parece evidentemente inviável e absurdo, pelo simples fato técnico de extrapolar o já extrapolado escopo de um... browser. É assim que eu entendo.
Compartilhar
Melhore esta resposta
Seguir
editada 9/02/14 às 3:09
respondida 9/02/14 às 0:39
J. BruniJ. Bruni
8.20222 medalhas de ouro1818 medalhas de prata3535 medalhas de bronze
1
1
Embora XSLT às vezes até pareça programação... :-)
– J. Bruni
9/02/14 às 0:43
Adicione um comentário |
0
Hoje estou usando Typescript, que permite programar orientado a objeto, com tipagem e outras vantagens e depois ele compila para javascript garantindo assim compatibilidade com todos os browser de forma simles e sem a necessidade de plugin com flash.
http://www.typescriptlang.org/
Código em Typescript
class Greeter {
    greeting: string;
    constructor(message: string) {
        this.greeting = message;
    }

    greet() {
        return "Hello, " + this.greeting;
    }
}

var greeter = new Greeter("world");

var button = document.createElement('button');
button.textContent = "Say Hello";
button.onclick = function() {
    alert(greeter.greet());
}

document.body.appendChild(button);
Código compilado para Javascript
var Greeter = (function () {
    function Greeter(message) {
        this.greeting = message;
    }
    Greeter.prototype.greet = function () {
        return "Hello, " + this.greeting;
    };
    return Greeter;
})();
var greeter = new Greeter("world");
var button = document.createElement('button');
button.textContent = "Say Hello";
button.onclick = function () {
    alert(greeter.greet());
};
document.body.appendChild(button);
Compartilhar
Melhore esta resposta
Seguir
respondida 17/11/15 às 15:22
p3cp3c
111 medalhas de bronze
2
1
Obrigado pela resposta! Contudo, pelo que eu entendi o Typescript é compilado no servidor e então o JavaScript resultante é enviado para o cliente, certo? Nessa pergunta eu buscava saber o estado do suporte a outras linguagens no próprio browser, sem a necessidade de tradução a JS no lado servidor. Muitos compiladores traduzem X para JavaScript, mas isso é um tantinho diferente de "executar X no browser" rsrs!
– mgibsonbr
17/11/15 às 15:29
1
Na verdade o TypeScript é copilado no próprio editor, não precisa de servidor, dependendo do editor esta compilação fica muito transparente mas o resultado final é o tradicional javascript.
– p3c
18/11/15 às 0:34
Adicione um comentário |
Sua resposta
Obrigado por contribuir com o Stack Overflow em Português!
Certifique-se de responder à pergunta. Entre em detalhes sobre a sua solução e compartilhe o que você descobriu.
Mas evite …
Pedir esclarecimentos ou detalhes sobre outras respostas.
Fazer afirmações baseadas apenas na sua opinião; aponte referências ou experiências anteriores.
Para aprender mais, veja nossas dicas sobre como escrever boas respostas.
Rascunho salvo
Rascunho descartado
Registre-se ou faça log-in
Registre-se usando o Google
Registre-se usando o Facebook
Registre-se usando Email e Senha
Submit
Publicar como convidado
Nome
E-mail
Required, but never shown
Publicar como convidado
Nome
E-mail
Required, but never shown
Publique sua resposta
Descartar
Ao clicar em “Publique sua resposta”, você concorda com os termos de serviço, política de privacidade e política de Cookies
Esta não é a resposta que você está procurando? Pesquise outras perguntas com a tag projeto-de-compiladores cross-browser scripting ou faça sua própria pergunta.
Em destaque no Meta
Reducing the weight of our footer
Que erro cometi ao formular minha pergunta?
Perguntas frequentes que já foram respondidas no SOpt
Vinculado
5
Validar formulários e gerar páginas dinâmicas
0
Escrever codigo VB em arquivo .JS
Relacionado
0
É possível criar um campo data que seja Cross-Browser?
3
CSS cross-browser pelo JavaScript
0
Como usar os colliders no unity?
Feed de perguntas
Assine o RSS
Feed de perguntas
Para assinar este feed RSS, copie e cole esta URL no seu leitor RSS.
Stack Overflow em Português
Tour
Ajuda
Chat
Contato
Feedback
Móvel
Empresa
Stack Overflow
For Teams
Anuncie Conosco
Contrate um desenvolvedor
Developer Jobs
Sobre
Imprensa
Legal
Política de Privacidade
Termos de serviço
Configurações dos Cookies
Política dos Cookies
Stack Exchange
Network
Technology
Culture & recreation
Life & arts
Science
Professional
Negócios
API
Data
Blog
Facebook
Twitter
LinkedIn
Instagram
site design / logo © 2021 Stack Exchange Inc; contribuições de usuários licenciadas sob cc by-sa. rev 2021.11.26.40833
Stack Overflow em Português funciona melhor com o JavaScript ativado
Sua privacidade
Ao clicar em "Aceitar todos os cookies", você concorda que a Stack Exchange pode guardar cookies no seu dispositivo e utilizar essas informações de acordo com a nossa Política de Cookies.