Има ли други езици освен Objective-J, които се компилират в JavaScript в браузъра?

Objective-J се компилира/трансформира в JavaScript директно в браузъра. (Това е в контраст с правенето на това на сървъра, както GWT прави за Java.) Този подход прилаган ли е за някой език, различен от Objective-J?


person avernet    schedule 09.10.2010    source източник


Отговори (4)



Компилаторът CoffeeScript компилира CoffeeScript в ECMAScript. Тъй като самият компилатор на CoffeeScript е написан на CoffeeScript, той може да се компилира в ECMAScript и по този начин да работи в браузъра. Необходимите части за поддръжка на <script type='text/coffeescript'> елементи вече са включени в стандартния компилатор на CoffeeScript.

Като цяло, всеки език може да бъде компилиран в ECMAScript, всичко, от което се нуждаете, е компилатор. И тъй като всеки език може да бъде компилиран в ECMAScript, всеки компилатор може да бъде компилиран в ECMAScript, всичко, от което се нуждаете, е компилатор за този език компилаторът е написан в.

Това води до комбинаторна експлозия от възможности за компилиране на езици в браузъра.

Например, има един човек, който пише C компилатори, които са насочени към езици от високо ниво за забавление. Той има компилатор, който компилира C в Java, Perl, Common Lisp, Lua или ECMAScript. Така че можете да използвате този компилатор, за да компилирате всеки друг компилатор, написан на C, в ECMAScript. И повечето езици имат някакъв компилатор някъде, който е написан на C.

Clue е написан на C. Clue компилира C в ECMAScript. Следователно, можете да използвате Clue, за да компилирате Clue в ECMAScript. След това можете да стартирате Clue в браузъра, за да компилирате C в ECMAScript в движение. <script type='text/c'>, някой? (Забавна мисъл: node.js е написан на C. Хм …)

По-сериозна бележка: обикновено има три причини за компилиране в ECMAScript:

  1. повторно използване
  2. безопасност
  3. изразителност

Ако просто искате да използвате повторно съществуващ код, написан на различен език (или съществуващо знание на различен език), тогава компилирането/интерпретирането на клиента няма много смисъл. Кодът или програмистът така или иначе не очаква да може да използва <script> елемента. Тази категория включва неща като GWT или Volta.

Ако (тип) безопасността е вашата цел, тогава компилирането/интерпретирането на клиента просто не работи: как можете да гарантирате безопасност, ако не контролирате компилатора? Ето защо Ur/Web, Връзки, Flapjax, Haxe, Caja и такива компилират кода на сървъра. Те гарантират безопасност чрез статично въвеждане или тясна интеграция, или и двете. (Под тясна интеграция имам предвид, че бекендът, фронтендът и приложението са тясно свързани, като например посочвате структури от данни веднъж и след това генерирате съответните SQL, ECMAScript и HTML формуляри от този единствен източник, за да сте сигурни, че всички трябва да е очевидно защо това изисква обработка на сървъра.)

Тези, които се фокусират върху експресивността обаче, очакват да бъдат използвани като заместител на ECMAScript, т.е. вътре в <script> елементи, и затова често идват с интерпретатори и/или компилатори, които работят на клиента. CoffeeScript, Objective-J и Clamato попада в тази категория.

person Jörg W Mittag    schedule 09.10.2010
comment
Леле, това беше... интересно. Пуска два Tylenol. - person UnkwnTech; 09.10.2010
comment
Много готин отговор! И ще трябва да пробвам малко CoffeeScript. - person Jarrod Dixon♦; 09.10.2010

Ето един пример, който компилира език, подобен на Ruby, в javascript - и компилирането може да се извърши в браузъра.

http://jashkenas.github.com/coffee-script/

person Michael Anderson    schedule 09.10.2010

В допълнение към тези списъци тук има индекс: http://altjs.org/, който съдържа:

  • Нови езици
  • Подобрения на JavaScript
  • Портове (Java, C, Ruby и др.)

и още

person Radek    schedule 28.06.2013