Чи зможу я коли-небудь кодувати код браузера на стороні клієнта мовою, яку я вибрав? [зачинено]

Я буду жорстоко чесним: ненавиджу писати клієнтський код у JavaScript. Я, принаймні, не шанувальник цієї мови.

Мені здається дурним, що браузери підтримують мову програмування , а не проміжну віртуальну машину (наприклад, CIL або JVM). Останнє дозволить програмістам писати мовою, яку вони вибирають (певною мірою), а не однією фіксованою наперед заданою мовою. Ця мова могла розвиватися швидше, тому що лише зміни в CIL / JVM / що б потребували оновлення кожного головного браузера. Мовні функції можна додати, не впливаючи на стару роботу браузера.

Масові заощадження зусиль, які приносять проміжні язики , добре відомі . Чи існують якісь ініціативи щодо просування браузера «сценаріїв» у чомусь іншому, ніж JavaScript, і особливо у вже розробленій, розробленій та оптимізованій віртуальній машині? Чи мають вони імпульс?

Щоб відповісти на ваше запитання, так, докладаються зусилля для знецінення Javascript на користь більш згуртованої мови для веб-сценаріїв. Google поклав велику тягу за їхньою мовою Dart . У Dart є свій власний VM, який вже вбудований у Chrome, але я не впевнений, що інші браузери його ще прийняли. Існує також досить перспективна мова під назвою CoffeeScript .

Є також дуже амбітний на вигляд проект під назвою HaXe, який має на меті об'єднати цілу низку платформ розвитку з єдиною мовою ..

Повірте, ти не любиш Javascript, але боюся, що він нікуди не піде - насправді, здається, він набирає багато обертів, що стосується програм Windows 8 HTML5 / JS тощо., Але альтернативи, як ті, які я згадані починають весняно починати :)

Сам Javascript можна розглядати як проміжну мову, що визначає віртуальну машину, на яку можна компілювати інші мови. У таких проектах, як GWT, це поняття вже знімається. Це може бути не те, що ви створили б з нуля, але це вже стає реальністю, що ви можете скласти "свою улюблену мову" в Javascript.

По суті, ні. Ви в значній мірі застрягли з Javascript.

Сказавши це, в минулому докладалися зусилля щодо залучення інших мов на борт (java-аплети, vbscript тощо). Кожна з них ніколи не отримувала тяги, яку має JavaScript, оскільки JavaScript інтегрований .

Єдиний спосіб побудувати те, про що ви посилаєтесь, - це створити мову сценаріїв, яка працює на віртуальній машині, складена клієнтською стороною і потім виконується. Тоді кожен браузер повинен був би реалізувати віртуальну машину у власну кодову базу, щоб весь код працював у всіх браузерах. Тоді вам доведеться переконатись у наявності якихось стандартів, щоб усі браузери виконували команди однаково. Зрозуміло, що веб-переглядачі, створені незалежно, мабуть, мали би бути примхи, які розробники повинні мати на увазі.

Але зараз ми тільки що описали Javascript.

Отже, нарешті, ваш вибір:

1. звикнути до Javascript
2. спробуйте скористатися якоюсь мовою, яка компілюється до Javascript. (Майте на увазі, що ви все ще хочете перевірити Javascript, що повертається до параметра 1.)
3. використовувати мову, яка існує як плагін до браузера, наприклад ,criptcript (Flash), ActiveX, аплет java, .Net (SilverLight). Це дозволяє уникнути проблеми з декількома постачальниками / реалізаціями мови, але не інтегрує мову.

По суті, якщо ви хочете інтегрувати мову, ви застрягли з Javascript.

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

Якщо ви все ще хочете використовувати іншу мову, ви можете використовувати GWT , який в основному дозволяє вам писати Java, а потім компілювати її в (потворний) javascript або CoffeeScript , який є синтаксичним цукром над JS, який компілюється в JS.

Це питання час від часу виникає.

Чому ми не маємо інших мов у тегах сценарію замість Javascript

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

То чому б тоді не було загальної стандартної мови проміжних?

Є старий подкаст від Брендана Ейха, який пояснює, чому він не бачить мову проміжного байт-коду найближчим часом:

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

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

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

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

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

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

Можливо, вам просто пощастить. Це вступний пункт подання на форумі webkit-dev:

Сьогодні багато мов збираються в JavaScript для запуску в Інтернеті. Як альтернатива, ми експериментували з тим, щоб дозволити різному мовному виконанню в WebKit запускати веб-сторінки поряд з JavaScript ...

Решту повідомлення ви можете переглянути тут .

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

ClojureScript - цікавий проект, якщо ви кодуєте Lisp.

Отже, незважаючи ні на що, JavaScript тут залишається. (COBOL в Інтернеті, можливо?).

"Будь-який клієнт може мати автомобіль, пофарбований у будь-який колір, якого він хоче, якщо він є чорним". - Генрі Форд

Уже є низка компіляторів, націлених на javascript, і ви можете вибрати будь-яку мову, що компілюється в javascript.

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

Якщо ви ненавидите javascript, я пропоную вам перейти в простір для вбудованих, наукових чи ігрових розробок, де C, Fortran і C ++ керують переходом. Лінійка ділових додатків дуже сильно рухається до Інтернету, а це означає більше Javascript, а не менше.