Почему нет других языков сценариев на стороне клиента для веб-сайтов? [закрыто]

35

Почему сегодня в браузерах есть только поддержка JavaScript и некоторый VBScript? Я знаю, что JavaScript хорош и все, но разве возможность использования другого языка программирования помогает продвигать разные стили разработки?

web-development javascript browser

— Эрик Пэквуд
источник

1

См. Этот вопрос по переполнению стека: stackoverflow.com/questions/2872037/…

— Кори,

1

Твой вопрос точно, почему Google сделал GWT .

— Джоккинг

1

Я считаю, что весь смысл DOM API заключался в обеспечении поддержки нескольких языков. Дело в том, что JS действительно хорошо подходит для этой задачи. Он нормализуется, как будто никто не занимается бизнесом, и первоклассные функции огромны в сильно управляемой событиями парадигме. На самом деле все сводилось к тому, что никто не хотел, чтобы MS принимала это решение, и никто не придумал лучшего, чем JS. Кроме того, Java-апплеты были действительно, ОЧЕНЬ хромыми.

— Эрик Реппен

33

Нет необходимости добавлять suport для нескольких языков, решение будет состоять в том, чтобы стандартизировать общий байт-код, который может использоваться разработчиками языка. Но в настоящее время нет никаких планов для этого (это было предложено).

Языки могут быть реализованы поверх Javascript тоже. Javascript достаточно хорош для того, чтобы на нем могли быть реализованы другие языки. И таких примеров уже много.

— nkassis
источник

3

+1 - для указания на то, что JavaScript является мощным языком, который можно использовать в качестве абстракции для других языков. Было бы интересно написать расширение для Firefox, которое будет работать на клиентской стороне C ++ или Java! <script type="text/cpp" src="test.cpp"></script>,

— jmort253

2

@ jmort253, взгляни на собственный клиент.

— dan_waterworth

Родной клиент, безусловно, интересен, но если Mozilla его не примет, не будет никакой тяги. В последний раз я проверял, что они еще не готовы принять это.

— nkassis

1

Я нашел Gestalt ~ пару лет назад: gestalt.codeplex.com - это хороший пример построения других языков сценариев поверх Javascript.

— Джим Шуберт

2

Другой пример: Google Web Toolkit ? Java скомпилирована в JavaScript

— MarkJ

21

JavaScript является стандартом де-факто и существует с 1996 года. Быть стандартом просто потому, что нет конкуренции, не совсем справедливо, но я не слышал много жалоб на то, почему нет другого языка.

Добавление другого «стандартного» языка продвигает всевозможные забавные мелочи.

Как они будут работать с другими языками?
Будет ли общий доступ к DOM?
Могут ли скрипты, написанные на обоих языках, все еще работать?
Портирование библиотек на оба

— Джош К
источник

8

На самом деле, я думаю, что JavaScript - это язык, используемый в Gecko Mozilla. В IE у нас есть JScript. Большинство других браузеров используют то, что более или менее соответствует спецификациям ECMAScript. Все эти языки для простоты названы «JavaScript», хотя на самом деле они различаются.

— MCHL

1

Вы можете иметь несколько языков, которые генерируют один и тот же байт-код. Посмотрите на JVM - Groovy, Java, Scala, Clojure, jRuby могут быть напрямую скомпилированы в байт-код JVM. Таким образом, они будут использовать один и тот же API-интерфейс DOM и могут стать совместимыми. Хотя это экспоненциально сложнее реализовать с помощью виртуальной машины JavaScript, поскольку она интерпретируется.

— Давид Сергей

21

Подумайте о несоответствиях между браузерами из-за их поддержки только javascript. Теперь подумайте, как было бы, если бы было больше языков.

— Майкл Браун
источник

5

Да, это уже там, на стороне клиента VBScript ... ух, дрожь.

— ocodo

1

+1 Я думаю, что наши головы взорвались бы, если бы у нас было подмножество других языков для запоминания для каждого из основных браузеров и их версий. Хороший ответ.

— jmort253

4

Это может быть придирчиво, но ... поддержка браузерами JavaScript [ECMAScript] на самом деле была очень последовательной с самого начала. Непоследовательна их реализация DOM (и связанных с ним методов). С практической (и исторической) точки зрения трудно разделить их - поскольку единственное реальное использование JS - это манипулирование DOM в браузере - но с ростом JS на стороне сервера (такие вещи, как NodeJS), это на самом деле становится несколько важным различием.

— josh3736

собирался написать в точности такой ответ, у интернета достаточно стандартов, которые не соблюдаются и не поддерживаются. тот факт, что беспорядочный беспорядок, который у нас есть, работает наполовину так же хорошо, как и чудо.

— Ryathal

1

Джош прав. Именно здесь вы подключаетесь к несбывшейся идее отдельного браузера о том, как JS должен отображать и получать доступ к таким вещам, и эти вещи становятся ужасными, но IE наконец-то, по крайней мере, решает давние проблемы с проприетарными API на этом фронте (хотя он продолжает Отстает от последних почти во всем из-за рокового решения MS связать свой браузер с файловым навигатором - ослами).

— Эрик Реппен

6

Браузеры должны быть стандартизированы, чтобы то, что вы разрабатываете, работало везде, во всех браузерах.

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

Javascript - это очень гибкий язык, он обязательный, он функциональный, он может быть ООП (по моде с прототипами) и интерпретироваться. Теперь с приличными двигателями, такими как в Chrome, он вполне способен делать хорошие вещи. Дополнительные языки могли бы просто все вернуть сюда назад, взглянуть на VBScript, только на IE, и поэтому все, что написано на нем, привязано к конкретному браузеру и платформе, кошмар.

— Orbling
источник

2

Важным моментом здесь является «с достойными двигателями, как в Chrome». Если сделать что-либо, даже слегка обременяющее, даже IE8 начнет хромать, как будто у него сломана нога, в то время как последние версии Firefox и Chrome с тех пор, как я использовал его навсегда (именно по этой причине я переключился), пропустили его без промедления.

— Мэтью Шарли

1

@ Мэтью Шарли: IE, как правило, вяло, на самом деле, кажется, с каждой версией становится все хуже. Им нужно улучшить свою игру, иначе они выйдут из нее. Единственная причина, по которой IE удерживается - это включение ОС, теперь они должны включить селектор при первом использовании, который сильно упал.

— Orbling

«это может быть OOP» ... Это в ООП! Наследование не то, что определяет ООП. Объекты есть.

— KaptajnKold

@KaptajnKold: Удивительно, но это вопрос некоторых научных кругов. Я согласен, что JS способен на ООП, в том смысле, что у него есть объекты, которые, однако, не всегда используются некоторыми. Система-прототип также сильно отличается от обычного варианта ООП, что еще больше удаляет его из стандартного определения «язык ООП». Как и в большинстве языков, это зависит от того, как вы используете его - когда я его использую, это ООП.

— Orbling

3

Вместо того, чтобы встраивать их в браузеры, поставщики предпочитают создавать неуклюжие подключаемые модули браузера - Java, Flash, Silverlight и т. Д. Это гарантирует межплатформенную согласованность.

— Кирк Бродхерст
источник

Ну, речь идет не о гарантии межплатформенной согласованности, а о гарантии контроля. Так как у вас есть контроль над плагином, и вы не должны отвечать никому другому.

— Джоккинг

По сравнению с быстрым запуском грязного javascript, «неуклюжие» плагины намного лучше. Раньше я испытывал негативную реакцию по поводу всей загрузки плагинов для браузера, но она определенно более открыта, чем «универсально реализованный javascript».

— Milind R

2

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

— davidk01
источник

Почти то, что я собирался сказать. Важное (в этом обсуждении) различие между языками на стороне клиента и на стороне сервера заключается в том, что браузеры должны реализовывать язык на стороне клиента.

— Джоккинг

2

Здесь приводятся несколько ответов, в которых утверждается, что поддержка нескольких языков сделает для разработчиков веб-браузеров очень неприятным то, что они совместимы со всеми языками. Мне это кажется неправильным.

Java, например, является чрезвычайно четко определенным стандартом. По сути, все, что вам нужно сделать, это представить DOM браузера как API Java и запустить виртуальную машину Java (JVM) внутри вашего веб-браузера. Вы можете указать, что код сценария должен быть либо доставлен в виде скомпилированных и подписанных файлов JAR, либо в виде исходного кода JavaScript. Если браузер обнаруживает JavaScript, он может запустить его через выделенный интерпретатор (как сегодня) или через Rhino поверх JVM. Если он обнаруживает jar-файлы, он создает новый загрузчик классов и изолированную программную среду безопасности, загружает байт-код java в память и выполняет его. Это будет полностью обратно совместимо с существующими веб-страницами и позволит браузеру одним махом поддерживать десятки языков, которые работают на JVM.

Другие преимущества:

JVM извлекла выгоду из десятилетия улучшений производительности. Это сейчас очень быстро, стабильно и зрело. Могу поспорить, что вы увидите значительное улучшение производительности по сравнению с интерпретируемым JavaScript.
Поскольку клиентские приложения становятся все больше и сложнее, преимущества структурированных типизированных языков, таких как Java и Scala, возрастают.
У вас был бы доступ к истинной многопоточности и через Scala, библиотеку коллекций, оптимизированную для многоядерных вычислений.
Вы можете использовать любую из тысяч библиотек Java с открытым исходным кодом внутри браузера.
С помощью таких библиотек, как openGL, браузер может обеспечить доступ к расширенным возможностям графических и графических плат.
Если бы у вас была Java, работающая на стороне клиента и сервера, вы могли бы получить дополнительную выгоду от обмена данными между клиентом и сервером через чрезвычайно сжатую сериализацию двоичного объекта-графа = более быструю загрузку и выполнение веб-страниц.

— Патрик Арнесен
источник

1

Вы уже можете запустить код JVM. Это называется Java-апплет

— Raynos

1

Я считаю, что JavaScript станет еще более распространенным стандартом для Интернета. Мы наблюдаем рост JavaScript на стороне сервера. Вот несколько примеров реализации этого мощного языка на сервере:

Веб-сервер POW SJS - JavaScript на стороне сервера для веб-сервера POW, который работает как расширение Firefox или как приложение XULRunner. SJS играет роль, аналогичную роли PHP в Apache, в том, что он может подключаться к базам данных и генерировать контент на стороне клиента.
NodeJS - JavaScript на стороне сервера, использующий модель на основе событий. Он построен с использованием Google V8 JavaScript Engine . NodeJS рекламируется как инструмент для построения масштабируемых сетевых программ. Веб-сервер "Hello World" может быть написан всего за 6 коротких строк!
Jaxer - сервер JavaScript, который интерпретирует все блоки скриптов runat="server"как серверный JavaScript. Целые веб-приложения могут быть написаны на JavaScript.
Rhino - JavaScript для Java - Mozilla создала эту реализацию JavaScript на стороне сервера, которая работает на Java. По сути, эта концепция похожа на Querces PHP для Java , Jython, JRuby и многих других абстракций других языков, которые работают на JVM. Rhino обычно используется для встраивания JavaScript в Java для предоставления средств сценариев конечным пользователям, но его также можно использовать для перемещения клиентского кода на сервер без необходимости переписывать бизнес-логику на другом языке!
JQuery Claypool - серверная среда JavaScript, использующая возможности JQuery на сервере. Очень круто! Он разработан с использованием серверной JavaScript-реализации EnvJs браузера.
EnvJs - браузер без головы, построенный на Rhino.

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

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

— jmort253
источник

+1 за указание на то, что JavaScript не ограничивается браузером

— Гэри Роу

1

Есть несколько примеров инструментов, которые будут компилировать другие языки в javascript, включая Haskel, Lisp и Python (возможно, другие). Так что если вы хотите работать на одном из этих языков, вы можете сделать это.

И я думаю, что один из моих профессоров из университета написал схему реализации в Javascript. Так что, если вам нравится схема, вы можете сделать это тоже.

— Захари К
источник

0

Люди обходили проблему отсутствия встроенного разнообразия двумя способами: используя плагины, такие как flash или java-апплеты, и создавая слои, которые используют javascript в качестве своего «машинного кода», например jquery или google web toolkit. Если бы новый стиль разработки был достаточно популярен, люди бы нашли способ его внедрить.

Имейте в виду, что если вы создаете среду выполнения .net в javascript, и она когда-нибудь станет популярной, некоторые круги будут проклинать ваше имя в интернете навсегда.

— Карл Билефельдт
источник

Виноваты вебформы и IE. Вы бы меньше разозлились на разработчиков веб-интерфейсов, ткнув их в горячие покер. Не подходит для объединения брендов.

— Эрик Реппен