Чому для веб-сайтів немає інших мов сценарію на стороні клієнта? [зачинено]

35

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

web-development javascript browser

— Ерік Паквуд
джерело

1

Дивіться це запитання на "Переповнення стека": stackoverflow.com/questions/2872037/…

— Corey

1

Ваше запитання саме в тому, чому Google зробив GWT .

— поштовх

1

Я вважаю, що суть API DOM полягала у підтримці декількох мов. Справа в тому, що JS насправді добре підходить до виклику. Це нормалізується як нічий бізнес і першокласні функції є величезними в сильно орієнтованій на події парадигмі. Це дійсно зводилося до того, що ніхто не хотів дозволити MS приймати це рішення, і ніхто не придумав кращого, ніж JS. Крім того, Java-аплети були дійсно, ДУЖЕ кульгавими.

— Ерік Реппен

33

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

Мови можна реалізувати і над 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.codeplex.com - це гарний приклад побудови інших мов скриптів поверх Javascript.

— Джим Шуберт

2

Ще один приклад: веб-інструментарій Google ? Java складено на JavaScript

— MarkJ

21

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

Додавання ще однієї "стандартної" мови сприяє всіляким розвагам.

Як вони працюватимуть з іншими мовами?
Чи поділиться DOM?
Чи можуть сценарії, написані в обох, все ще працюють?
Перенесення бібліотек обом

— Джош К
джерело

8

Насправді я думаю, що JavaScript - це мова, яка використовується в Gecko Mozilla. У IE у нас є JScript. Більшість інших браузерів використовують те, що більш-менш відповідає специфікаціям ECMAScript. Ці всі мови для простоти називаються "JavaScript", а насправді вони відрізняються.

— Mchl

1

Ви можете мати кілька мов, які генерують один і той же байт-код. Подивіться на JVM - Groovy, Java, Scala, Clojure, jRuby можна безпосередньо скласти в байт-код JVM. Таким чином, вони матимуть спільний доступ до тих самих DOM-програм, які можуть бути сумісними. Незважаючи на те, що це експоненціально складніше реалізувати з JavaScript VM, оскільки він інтерпретується.

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

21

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

— Майкл Браун
джерело

5

Так, це вже є, клієнтська VBScript ... ух, здригання.

— ocodo

1

+1 Я думаю, що наші голови вибухнуть, якби у нас було підмножина інших мов для запам'ятовування кожного з основних браузерів та їх версій. Гарна відповідь.

— jmort253

4

Це може спричинити загрозу, але ... підтримка браузерів JavaScript [ECMAScript] насправді була дуже послідовною із самого початку. Невідповідним є їх реалізація DOM (та пов'язаних з ними методів). З практичної (та історичної) точки зору важко відокремити обидві, оскільки єдиним реальним використанням JS було маніпулювання DOM у браузері - але зі зростанням сервера JS (такі речі, як NodeJS), це насправді стає дещо важливою відмінністю.

— josh3736

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

— Рятхал

1

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

— Ерік Реппен

6

Браузери повинні бути стандартизованими, щоб те, що ви розробляєте, працювало всюди, у всіх браузерах.

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

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

— Орблінг
джерело

2

Тут важливим моментом є "з гідними двигунами, як у Chrome". Якщо зробити що-небудь навіть м'яке оподаткування, змушує навіть IE8 почати кульгати так, як у нього зламана нога, тоді як останні версії Firefox та Chrome з тих пір, коли я його використовував (це було причиною переключення на інфакт), пропускають разом, не пропускаючи жодного удару.

— Меттью Шарлі

1

@Matthew Scharley: IE, як правило, мляво, бо, мабуть, погіршується з кожною версією. Їм потрібно підняти свою гру, інакше вони будуть поза нею. Єдина причина, що IE має будь-яку затримку, - це через включення в ОС, тепер вони повинні поставити селектор при першому використанні, що значно впало.

— Орлінг

«Це може бути OOP» ... Це в ООП! Спадщина - це не те, що визначає ООП. Об'єкти є.

— KaptajnKold

@KaptajnKold: Напрочуд, це питання дебатів в академічних колах. Я погоджуюсь, що JS здатний використовувати OOP, оскільки в ньому є об'єкти, однак деякі не завжди їх використовують надмірно. Система прототипу багато в чому відрізняється від звичайного аромату OOP, що ще більше видаляє його зі стандартного визначення "мови OOP". Як і у більшості мов, це залежить від того, як ви його використовуєте - коли я ним користуюся, це OOP.

— Увімкнення

3

Замість того, щоб вбудовувати їх у браузери, виробники люблять створювати незграбні плагіни браузера - Java, Flash, Silverlight тощо. Це гарантує узгодженість платформ.

— Кірк Бродхерст
джерело

Ну, справа не в тому, щоб гарантувати узгодженість між платформами, а настільки гарантувати контроль. Як і ви керуєте плагіном, і вам більше не доведеться відповідати нікому.

— поштовх

У порівнянні зі швидкою боротьбою із швидким запуском брудного javascript, "незграбні" плагіни значно кращі. Я звик негативно ставитись до всього завантаження плагіну браузера, але це, безумовно, більш відкрито, ніж "універсально реалізований javascript".

— Milind R

2

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

— davidk01
джерело

Досить багато, що я збирався сказати. Важливою (у цій дискусії) різницею між клієнтською та серверною мовами є те, що браузери повинні реалізувати мову на стороні клієнта.

— поштовх

2

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

Наприклад, Java - надзвичайно чітко визначений стандарт. По суті, все, що вам потрібно зробити, це відкрити DOM браузера як Java API і запустити віртуальну машину 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, який використовує модель на основі подій. Він побудований за допомогою JavaScript 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 на сервері. Дуже круто! Він розроблений з використанням браузера EnvJs на сервері JavaScript.
EnvJs - безголовий браузер, побудований на вершині Rhino.

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

Підсумовуючи це, здається, суперечливість порту інших мов браузера, коли натомість ми можемо перенести цю єдину мову браузера на сервер і усунути цей пробіл більш уніфікованим чином.

— jmort253
джерело

+1 за вказівку на те, що JavaScript не обмежений лише браузером

— Gary Rowe

1

Існує кілька прикладів інструментів, які збиратимуть інші мови в JavaScript, включаючи Haskel, Lisp та Python (напевно, інші). Тож якщо ви хочете працювати на одній з цих мов, ви можете це зробити.

І я думаю, що один з моїх професорів з університету написав схему реалізації в Javascript. Тож якщо вам подобається схема, ви також можете це зробити.

— Захарій К
джерело

0

Люди вирішували відсутність вбудованої різноманітності двома способами: за допомогою плагінів, таких як flash або java аплети, та створення шарів, які користуються javascript як "машинним кодом", наприклад, jquery або Google Toolkit. Якби новий стиль розвитку був досить популярним, люди знайшли би спосіб його втілити.

Будьте в курсі, якщо ви виконаєте .net час роботи в JavaScript, і він коли-небудь стане популярним, певні кола будуть проклинати ваше ім'я в Інтернеті назавжди.

— Карл Білефельдт
джерело

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

— Ерік Реппен