Компилятор 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. Хмм & hellip;)
На более серьезном замечании: обычно есть три причины для компиляции в ECMAScript:
- повторное использование
- безопасность
- выразительность
Если вы просто хотите повторно использовать существующий код, написанный на другом языке (или существующий код знаний на другом языке), то компиляция / интерпретация на клиенте не имеет особого смысла. Код или кодировщик не ожидают возможности использовать элементы <script> в любом случае. В эту категорию входят такие вещи, как GWT или Volta .
Если (type-) безопасность - ваша цель, то компиляция / интерпретация на клиенте просто не работает: как вы можете гарантировать безопасность, если вы не контролируете компилятор? Вот почему Ur / Web , Ссылки , Flapjax , Haxe , Caja и такие скомпилируйте код на сервер. Они гарантируют безопасность либо за счет статической типизации, либо за счет тесной интеграции, либо за счет того и другого. (Под тесной интеграцией я подразумеваю, что серверная часть, интерфейс и приложение тесно связаны, например, указав структуры данных один раз , а затем сгенерировав соответствующие формы SQL, ECMAScript и HTML из этого единственного источника, чтобы убедиться, что они все совпадают вверх. Должно быть очевидно, почему это требует обработки на сервере.)
Однако те, которые фокусируются на выразительности, ожидают использования в качестве замены для ECMAScript, т. Е. Внутри <script> элементов, и поэтому они часто поставляются с интерпретаторами и / или компиляторами, которые выполняются на клиенте. CoffeeScript, Objective-J и Clamato попадают в эту категорию.