Смогу ли я когда-нибудь кодировать код браузера на выбранном языке? [закрыто]

15

Я буду очень честен: я ненавижу писать код на стороне клиента в JavaScript. Я не фанат этого языка, если не сказать больше.

Мне кажется глупым, что браузеры поддерживают программирование язык , а не промежуточную виртуальную машину (например, CIL или JVM). Последнее позволило бы программистам писать на языке по своему выбору (до некоторой степени), а не на одном фиксированном заранее установленном языке. Этот язык может развиваться быстрее, потому что только изменения в CIL / JVM / что-либо еще потребуют обновления всех основных браузеров. Языковые функции могут быть добавлены без ущерба для старого браузера.

Огромная экономия усилий, которую обеспечивают промежуточные языки, хорошо известна . Существуют ли какие-либо инициативы по продвижению «скриптинга» браузера в чем-то, кроме JavaScript, и особенно в уже спроектированной, разработанной и оптимизированной виртуальной машине? Есть ли у них импульс?

programming-languages browser Роман Старков
источник
см. также: Почему нет других языков сценариев на стороне клиента для веб-сайтов?
комнат

Ответы:

11

Чтобы ответить на ваш вопрос, да, предпринимаются усилия, чтобы отказаться от Javascript в пользу более связного языка для веб-сценариев. Google уделяет большое внимание их языку дартс . У Dart есть собственная виртуальная машина, которая уже встроена в Chrome, но я не уверен, что другие браузеры ее уже приняли. Существует также довольно многообещающий язык, называемый CoffeeScript .

Есть также очень амбициозный проект под названием HaXe, который нацелен на объединение целого ряда платформ разработки с одним языком.

Поверьте мне, вы не одиноки в том, что не любите Javascript, но я боюсь, что он скоро никуда не денется - на самом деле он, похоже, набирает обороты, чем в приложениях Windows 8 HTML5 / JS и т. Д., Но альтернативы, подобные тем, которые я упомянутые начинают прыгать :)

MattDavey
источник
9
Объединение всего в один язык - это полная противоположность желаемому. Это только оставляет вас в той же ситуации, что и сейчас, только с другим языком вместо JavaScript. Дело в том, что существующие усилия должны основываться на: IL / CLR хорошо зарекомендовал себя, уже имеет высокопроизводительные JIT-модули для большинства платформ, и несколько компиляторов уже компилируют в него несколько языков. Чтобы перенести Интернет в 21-й век, браузеры должны использовать это, вместо того, чтобы постоянно пытаться испечь свои новые вещи и начинать с нуля.
Тимви
3
@ Тимви, CIL слишком тяжелый, и в нем слишком много бюрократии. Не имеет смысла прикреплять полный раздутый файл байт-кода с выделенным классом и всеми громоздкими метаданными к каждому onSomethingобработчику событий - разбор и интерпретация 10-20 символов простого языка сценариев гораздо эффективнее.
SK-logic
1
@ SK-logic: у вас, похоже, совершенно неправильная картина CIL и байт-кода в целом. Я понятия не имею, что может заставить вас думать, что двоичные метаданные «громоздки» по сравнению с синтаксисом высокого уровня, таким как JavaScript. Больше всего я понятия не имею, почему «каждый обработчик события onSomething». Программы на C # явно не компилируются в несколько сборок для каждого обработчика событий.
Тимви
1
@ Тимви, я ем ECMA-335 на завтрак, поэтому я слишком хорошо знаю, насколько громоздким является CIL. DOM-узлы часто генерируются динамически. Нет способа добавить что-либо в существующий модуль в CIL - вам нужно определить новый модуль. И вы не можете добавить к классу - вы должны определить новый класс (с присоединенными громоздкими метаданными). И просто сравните стоимость чтения, JIT и выполнения CIL с разбором, выполнением и немедленным отбрасыванием крошечной текстовой строки. Во многих случаях специальная интерпретация является гораздо более эффективной, чем любая компиляция.
SK-logic
2
@ Тимви, вы предлагаете использовать байт-код в качестве общего знаменателя и формата связи, верно? Я хочу сказать, что текущая спецификация CIL в значительной степени бесполезна. ExpandoObject не имеет значения. И ваш взгляд на сложность разбора затуманен. Модуль CIL содержит собственную справочную таблицу сборок, таблицу токенов метаданных и только затем классы и методы. Сравните усилия, необходимые для чтения и JIT всех этих громоздких вещей, с интерпретацией строки тривиального языка высокого уровня. Стоимость разбора здесь практически равна нулю. Просто попробуйте оба подхода и сравните себя.
SK-logic
5

Сам Javascript можно рассматривать как промежуточный язык, определяющий виртуальную машину, в которую могут быть скомпилированы другие языки. В таких проектах, как GWT, это понятие уже исчезает. Это может быть не то, что вы разработали бы с нуля, но уже стало реальностью, что вы можете скомпилировать «свой любимый язык» в Javascript.

Джон Снелсон
источник
5

По сути, нет. Вы в значительной степени застряли с Javascript.

Сказав это, в прошлом предпринимались попытки задействовать другие языки (java-апплеты, vbscript и т. Д.). Каждый из них так и не получил той поддержки, которую имеет javascript, потому что javascript интегрирован .

Единственный способ создать то, на что вы ссылаетесь, - это создать язык сценариев, который запускается на виртуальной машине, компилируется на стороне клиента и затем выполняется. Тогда каждый браузер должен будет внедрить виртуальную машину в свою собственную кодовую базу, чтобы весь код выполнялся во всех браузерах. Тогда вам нужно убедиться, что у вас есть какие-то стандарты, чтобы все браузеры выполняли команды одинаково. Конечно, браузеры, создаваемые независимо, вероятно, будут иметь причуды, которые разработчики должны будут учитывать.

Но сейчас мы только что описали Javascript.

Итак, в конце концов, ваш выбор:

  1. привыкнуть к JavaScript
  2. попробуйте использовать какой-то язык, который компилируется в Javascript. (Имейте в виду, что вы все равно захотите проверить Javascript, который возвращает к варианту 1.)
  3. используйте язык, который существует как плагин для браузера, такой как actionscript (Flash), ActiveX, java-апплет, .Net (SilverLight). Это позволяет избежать проблемы с несколькими поставщиками / реализациями языка, но не интегрирует язык.

По сути, если вы хотите интегрированный язык, вы застряли с Javascript.

Ричард
источник
2
Другой вариант - использовать язык, который компилируется в javascript, и использовать его.
Джетти
@Jetti Вы думаете о CoffeeScript ? Это девиз - это «Золотое правило», как они его называют, это «Это просто Javascript» . Но если вы пишете что-то, что по сути является Javascript, разве вы не пишете Javascript? Это все равно что утверждать, что jQuery не является javascript, потому что он чище и проще в использовании.
Ричард
2
взгляните на этот список языков, которые компилируются в javascript
Jetti
@ Джетти Может быть, они бы хорошо сработали. Но, учитывая причудливую кросс-браузерную поддержку, я бы нервничал из-за того, что рекомендую какие-либо из них, а не проверю фактический сгенерированный javascript.
Ричард
1
За исключением того, что javascript является чрезвычайно ужасным промежуточным языком, и его очень трудно выполнять последовательно.
Milind R
4

На самом деле вы не ненавидите JavaScript, как описано в стандартах Ecma, но ненавидите ужасную реализацию в различных браузерах , с их причудами, ошибками и wtfs. Серверный Javascript довольно приятен на самом деле. Также модель DOM является причиной 80% боли JavaScript на стороне клиента.

Если вы все еще хотите использовать другой язык, вы можете использовать GWT , который в основном позволяет писать Java, а затем скомпилировать его в (уродливый) javascript или CoffeeScript , который является синтаксическим сахаром над JS, который компилируется в JS.

Клемент Эрреман
источник
9
Я не могу говорить за ромкинов, но я ненавижу сам JavaScript ( в дополнение к проблемам, которые вы упомянули). Он не является объектно-ориентированным, не имеет статической типизации, полезной обработки ошибок и полезных основ современной функциональности. Это также противоречиво и громоздко. И, кстати, самая ненавистная особенность JS - вставка точек с запятой - в стандарте ECMA.
Тимви
1
@Timwi, он основан на функциях, и вы можете написать OO-код, если хотите. Статическая типизация хороша, но если ваш код написан хорошо (небольшие функции, правильная область видимости), это редко проблема. Что касается вставки точек с запятой, я считаю, что это немного раздражает. Это всего лишь один раз укусил меня, потому что у меня был возврат и открытие {объекта в разных строках. Какая «основа современной функциональности», по вашему мнению, отсутствует?
CaffGeek
2
Сам по себе JavaScript не самый лучший язык (если говорить вежливо). Меня не волнуют объектно-ориентированные вещи (чем их меньше - тем лучше), их динамическая система типов (к сожалению, она действительно необходима для такого языка сценариев), но наличие операторов и отсутствие правильных списки и кортежи раздражают. Как для написания на JavaScript, так и для реализации компиляторов, предназначенных для JavaScript.
SK-logic
2
@Timwi: ты видишь, что объектно-ориентированный не является плохой вещью, хотя это не всегда так. Пожалуйста, не рассматривайте ООП как серебряную пулю парадигм развития. Функциональный подход, такой как JS или Scala, тоже великолепен. Вы можете иметь ООП в JS, но главное отличие в том, что это программирование на основе прототипов, а не программирование на основе классов. ООП - это широкое имя, и оно не ограничивается Java / C #. Основанный на прототипах отличается от основанного на классах и хорошо используется, он так же мощный, как и основанный на классах.
Клемент Херреман
2
@ClementHerreman: JavaScript не ограничивается на стороне клиента, но это обсуждение на стороне клиента. JavaScript будет ограничено на базе прототипа, который является недостатком по сравнению с IL , который позволит вам использовать почти любой язык вообще.
Тимви
2

Этот вопрос всплывает время от времени.

Почему у нас нет других языков в тегах сценария вместо просто Javascript

В свое время IE представил VB в качестве альтернативы Javascript. Я думаю, вы уже можете видеть, как это привело бы к адским стандартам, если бы это завоевало популярность ...

Так почему же тогда нет общего стандартного промежуточного языка?

Есть старый подкаст от Брендана Эйха, объясняющий, почему он не видит промежуточный язык байт-кода в ближайшем будущем:

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

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

Основная проблема заключается в том, что хотя промежуточный язык (например, CIL и байт-коды JVM) пытается быть универсальным, в большинстве случаев он оказывается слишком низким уровнем и слишком привязан к исходным языкам высокого уровня, скомпилированным с ними. Например, вы не можете реально реализовать хвостовые рекурсивные функции в JVM - какие другие языковые функции или варианты реализации мы не сможем реализовать, если слишком рано подключимся к низкоуровневой абстракции байт-кода?

Между тем, Javascript - это гибкий язык высокого уровня с развернутой семантикой и множеством различных эффективных реализаций. То, что мы могли бы увидеть в будущем, - это сам Javascript как промежуточный язык - К сожалению, это несколько незрелый язык, и на сегодняшний день немногие языки компилируются в JS.

hugomg
источник
Но этот аргумент применим к JavaScript так же, как и к JVM и CIL, не так ли? :) Единственное, что касается JavaScript, это то, что он уже поддерживается всеми браузерами.
Роман Старков
Суть более тонкая - Javascript описан на более высоком уровне, чем большинство промежуточных языков, поэтому реализации получают больше возможностей при выборе того, что делать. (Конечно, это не все море роз - я просто хотел бы отметить, что мы не первые, кто думает о IL для Интернета и что это не так просто)
hugomg
1

Да. Вы уже можете скомпилировать Dart, Coffeescript и Java в Javascript. У вас есть Emscripten, который является бэкендом компилятора для LLVM для генерации байт-кода Javascript (и я считаю, что LLVM обрабатывает довольно много языков).

Но кроме компиляции в JS, не в короткие сроки. IE6 10 лет и до сих пор пинает. Я надеюсь, что нынешние браузеры (которые не поддерживают другие языки) не будут существовать так долго, но они будут существовать в течение нескольких лет, провоцируя цикличность «мы все равно должны поддерживать браузеры, которые поддерживают только Javascript, поэтому мы должны использовать Javascript "гораздо сложнее, чем, скажем, CSS3 - ваш сайт может работать без CSS3, но попробуйте заставить его работать без сценариев на стороне клиента.

Алекс
источник
0

Возможно, вам просто повезло. Это первый абзац представления на форуме webkit-dev:

Сегодня многие языки компилируются в JavaScript для работы в Интернете. В качестве альтернативы, мы экспериментировали с тем, чтобы разные языковые среды выполнения в WebKit могли работать на веб-страницах вместе с JavaScript ...

Вы можете просмотреть остальную часть сообщения здесь .

pgfearo
источник
0

JavaScript - это душа браузеров, поэтому большинство новых попыток генерируют JavaScript (CoffeeScript - яркий пример).
В GWT вы кодируете свою клиентскую логику на языке программирования Java, а инструментарий генерирует JavaScript.

ClojureScript - интересный проект, если вы занимаетесь написанием кода на Лиспе.

Так что выглядит, несмотря ни на что, JavaScript здесь, чтобы остаться. (Кобол сети может быть?).

Chiron
источник
0

«Любой покупатель может покрасить автомобиль в любой цвет, который ему нужен, если он черный». -- Генри Форд

Уже есть несколько компиляторов, нацеленных на JavaScript, и вы можете выбрать любой язык который компилируется в javascript.

Ваша ссылка, обсуждающая ценность промежуточных языков, обсуждает их в контексте реализации набора компиляторов, а не в предоставлении кода, который будет отправлен по сети и запущен на клиентском компьютере. Javascript может быть не лучшим форматом для этого, но как бы то ни было, он не будет сильно похож на байт-коды CIL или java.

Если вы ненавидите javascript, я предлагаю вам перейти в область Embedded, Scientific или разработки игр, где C, Fortran и C ++ правят рутом. Линейка бизнес-приложений очень активно перемещается в Интернет, а это означает больше Javascript, а не меньше.

Шон Макмиллан
источник