Чому JavaScript, а не стандартна віртуальна машина браузера?

Чи не було б сенсу підтримувати набір мов (Java, Python, Ruby тощо) за допомогою стандартизованої віртуальної машини, розміщеної в браузері, а не вимагати використання спеціалізованої мови - справді спеціалізованої парадигми - тільки для сценаріїв клієнта?

Щоб уточнити пропозицію, веб-сторінка міститиме байт-код замість будь-якої мови вищого рівня, як JavaScript.

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

Ну так. Безумовно, якби у нас була машина часу, повернення назад і забезпечення багатьох функцій Javascript було розроблено по-різному, було б головним проведенням часу (що, і забезпечення того, щоб люди, які розробили CSS-двигун IE, ніколи не потрапляли в ІТ). Але це не відбудеться, і ми зараз зациклювалися на цьому.

Я підозрюю, що з часом він стане "машинною мовою" для Інтернету, а інші краще розроблені мови та API-файли збираються до нього (і забезпечують різні види роботи двигуна).

Я не думаю, що будь-яка з цих «краще розроблених мов» буде Java, Python або Ruby. Javascript - це, незважаючи на можливість використання в іншому місці, мовою написання веб-додатків. З огляду на такий варіант використання, ми можемо зробити краще, ніж будь-яка з цих мов.

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

1. Google Native Client : технологія запуску нативного коду у браузері.
2. Emscripten : компілятор байт-кодів LLVM для javascript. Дозволяє запускати мови LLVM у веб-переглядачі.
3. Ідея: .NET CLI у браузері, автор Mono: http://tirania.org/blog/archive/2010/May-03.html

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

Відповідаючи на запитання - Ні, це не мало б сенсу.

В даний час найближчими речами, які ми маємо для багатомовної ВМ, є JVM та CLR. Це не зовсім легкі звірі, і не було б сенсу намагатися вставляти щось подібного розміру та складності у браузер.

Давайте розглянемо ідею, що ви могли б написати нову багатомовну програму VM, яка була б кращою за існуючу.

• Ви позаду на стабільність.
• Ви позаду за складністю (спосіб, спосіб, позаду, тому що ви намагаєтесь узагальнити на кількох мовах)
• Ви позаду на усиновлення

Отже, ні, це не має сенсу.

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

Що стосується функціональності, ми, мабуть, тільки справді працюємо з DOM так чи інакше, тому це справді проблема синтаксису та мови idom, і в цей момент є сенс запитати: "Це дійсно того варто?"

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

Які мови було б доцільно вводити? (Попередження, наступний суб'єктивний матеріал)

Вводити мову на зразок C не має сенсу, оскільки вона створена для роботи з металом, а в браузері не дуже багато металу.

Вводити мову на зразок Java не має сенсу, оскільки найкраще в цьому - API.

Введення такої мови, як Ruby чи Lisp, не має сенсу, оскільки JavaScript є потужною динамічною мовою, дуже близькою до Scheme.

Нарешті, який виробник браузерів насправді хоче підтримувати інтеграцію DOM для кількох мов? Кожна реалізація матиме свої певні помилки. Ми вже пройшли обстріл, вирішуючи відмінності між MS Javascript та Mozilla Javascript, і тепер ми хочемо помножити цю біль у п’ять-шість разів?

Це не має сенсу.

У Windows ви можете зареєструвати інші мови в хості сценаріїв і мати їх доступними для IE. Наприклад, VBScript підтримується нестандартно (хоча він ніколи не набирав великої популярності, оскільки для більшості цілей навіть гірший, ніж JavaScript).

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

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

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

Я, безумовно, вітаю стандартну незалежну мову VM у браузерах (я вважаю за краще кодувати статично набраною мовою).

(Технічно) Це цілком можливо поступово: спочатку один основний браузер підтримує його, і сервер має можливість або надіслати байтовий код, якщо поточний запит є з сумісного браузера, або перевести код в JavaScript і надіслати звичайний текст JavaScript.

Уже існує кілька експериментальних мов, які компілюються в JavaScript, але наявність визначеного VM (можливо) дозволить досягти кращої продуктивності.

Я визнаю, що "стандартна" частина була б досить складною. Також існують конфлікти між мовними особливостями (наприклад, статичне проти динамічного набору тексту) стосовно бібліотеки (якщо припустити, що нова річ використовує ту саму бібліотеку). Тому я не думаю, що це станеться (незабаром).

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

Якщо у ваших додатках недостатня безпроблемність, тому що на стороні сервера та на стороні клієнта погано спілкуються, то, можливо, ви захочете переглянути спосіб архітектури своїх додатків. Я працював із надзвичайно надійними веб-сайтами та веб-додатками, і жодного разу не сказав: "Хм, я дуже хочу, щоб JavaScript міг би зробити (xyz)". Якби це могло зробити це, то це не був би JavaScript - це був би ActionScript, AIR або Silverlight. Мені це не потрібно, як і більшість розробників. Це хороші технології, але вони намагаються вирішити проблему з технологією, а не ... ну, рішення.

Я не думаю, що стандартна веб-версія VM - це немислиме. Існує декілька способів, як можна витончено та з повною підтримкою ввести новий стандарт VM в Інтернеті, якщо ви гарантуєте, що будь-який формат байтового коду VM можна швидко декомпілювати в javascript і що отриманий результат буде досить ефективно ( Я б навіть пішов настільки далеко, щоб здогадатися, що розумний декомпілятор, ймовірно, генерує краще JavaScript, ніж будь-який JavaScript, який людина може виготовити сама).

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

Ті веб-переглядачі, які в основному підтримують новий стандарт, виграють від збільшення швидкості виконання програм для веб-програм, що базуються на комп'ютері. Крім того, якщо веб-переглядачі базують свої застарілі механізми JavaScript на стандарті web vm (тобто розбирають JavaScript на стандарт веб-версії, а потім запускають його), їм не доведеться керувати двома програмами виконання, але це залежить від постачальника браузера .

Хоча Javascript - єдиний добре підтримуваний сценарій мови, з якого ви можете керувати цією сторінкою безпосередньо, Flash має деякі дуже приємні функції для великих програм. Останнім часом він має JIT, а також може генерувати байтовий код на льоту (ознайомтеся з оцінкою вираження часу виконання, наприклад, коли вони використовують Flash для компіляції математичних виразів, введених користувачем, аж до рідних двійкових). Мова Haxe надає вам статичне введення тексту за допомогою висновку та за допомогою здібностей генерації байт-кодів ви можете реалізувати практично будь-яку систему виконання на ваш вибір.

Швидке оновлення цього старого питання.

Усі, хто підтвердив, що "веб-сторінка буде містити байт-код замість будь-якої мови вищого рівня, наприклад, JavaScript" "не відбудеться".

Червень 2015 року W3C оголосила, що є WebAssembly

новий портативний формат, ефективний для розміру та часу, який підходить для компіляції в Інтернет.

Це все ще експериментально, але вже є деяка прототипна реалізація в Firefox nightly та Chrome Canary, і вже є деяка демонстрація .

Наразі WebAssembly здебільшого розроблений для виробництва C / C ++

у міру розвитку WebAssembly він підтримуватиме більше мов, ніж C / C ++, і ми сподіваємось, що інші компілятори також підтримуватимуть його .

Я дозволяю вам ближче ознайомитися з офіційною сторінкою проекту, це справді захоплююче!

це питання виникає регулярно. моя позиція щодо цього:

А) не трапиться, і Б) вже тут.

пробач, що? дозволь пояснити:

оголошення A

VM - це не просто якийсь універсальний магічний пристрій. більшість VM оптимізовані для певної мови та певних мовних особливостей. візьміть JRE / Java (або LLVM): оптимізовано для статичного набору тексту, і, безумовно, є проблеми і недоліки при впровадженні динамічного введення тексту або інших речей, які Java не підтримувала в першу чергу.

Таким чином, "загальна багатоцільова VM", яка підтримує багато мовних функцій (оптимізація хвостових викликів, статичне та динамічне введення тексту, foo bar boo, ...), була б колосальною, важкою для впровадження та, ймовірно, важче оптимізувати, щоб отримати хороші показники роботи це. але я не мовний дизайнер чи vm guru, можливо я помиляюся: насправді це досить просто, тільки ніхто ще не мав ідеї? хрм, хрм.

оголошення Б

вже тут: може не бути компілятора байт-коду / vm, але він вам насправді не потрібен. afaik javascript завершується, тому слід мати можливість:

1. створити перекладача з мови X на javascript (наприклад, coffeescript)
2. створити інтерпретатора в javascript, який інтерпретує мову X (наприклад, brainfuck ). так, продуктивність була б безглуздою, але ей, не може мати все.

оголошення C

що? в першу чергу не було точки С !? тому що немає ... ще немає. Google NACL. якщо хтось може це зробити, це Google. як тільки Google змусить його працювати, ваші проблеми вирішуються. тільки, о, це може ніколи не працювати, я не знаю. востаннє, коли я читав про це, були деякі невирішені проблеми безпеки справді хитрого.

Крім того:

• javascript існує там з ~ 1995 = 15 років. все ще реалізація браузера відрізняється сьогодні (хоча принаймні це вже не страшно). тож, якщо ви ще запустили щось нове, у вас може з’явитися версія перехресного браузера близько 2035 року. принаймні робочий підмножина. що відрізняється лише тонко. і потребує сумісності шарів і шарів. Немає сенсу в тому, щоб не намагатися покращити речі.

• також, що з читаним вихідним кодом? я знаю, що багато компаній вважають за краще не обслуговувати свій код як "вид" з відкритим кодом. особисто я дуже щасливий, що можу прочитати джерело, якщо я підозрюю щось рибне чи хочу дізнатися з нього. ура, вихідний код!

Справді. Silverlight ефективно саме це - клієнтська сторона.

У ваших міркуваннях є деякі помилки.

1. Стандартна віртуальна машина у звичайному браузері ніколи не буде стандартною. У нас є 4 браузери, і IE має суперечливі інтереси щодо «стандарту». Три інші розвиваються швидко, але швидкість впровадження нових технологій повільна. Що з браузерами на телефонах, невеликих пристроях, ...

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

3. Як розповідали інші, JS - це не те саме, що AIR / .NET / ... тощо. JS у своєму нинішньому втіленні ідеально відповідає її цілям.

У перспективі Perl і Ruby цілком можуть замінити JavaScript. Однак прийняття цих мов відбувається повільно, і відомо, що вони ніколи не захоплять JS.

Як ви визначаєте найкраще? Найкраще для браузера чи найкраще для розробника? (Плюс ECMAScript відрізняється від Javascript, але це технічність.)

Я вважаю, що JavaScript може бути одночасно потужним та елегантним. На жаль, більшість розробників, яких я зустрічав, трактують це як необхідне зло замість справжньої мови програмування.

Деякі функції, які мені подобаються:

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

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

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

JavaScript - це стандартна віртуальна машина браузера. Наприклад, OCaml і Haskell тепер мають компілятори, які можуть виводити JavaScript. Обмеження - це не JavaScript, мова, обмеження - це об’єкти веб-переглядача, доступні через JavaScript, і модель контролю доступу, яка використовується для забезпечення безпечного запуску JavaScript без шкоди для вашої машини. Поточний контроль доступу настільки поганий, що JavaScript з дозволу безпеки дозволений лише з обмеженим доступом до об'єктів браузера. Проект «Гармонія» намагається це виправити.

Це класна ідея. Чому б не зробити крок далі?

• Напишіть HTML-аналізатор і механізм компонування (всі складні біти в браузері, справді) на тій же мові VM
• Опублікуйте двигун в Інтернеті
• Подайте сторінку із оголошенням, який механізм компонування використовувати та її URL-адресу

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

Я б вітав будь-яку мову, окрім JavaScript, як можливої ​​мови сценаріїв.

Приємно - це використовувати інші мови, а не Javascript. Java, мабуть, не дуже підходить між тегом, але такі мови, як Haskell, Clojure, Scala, Ruby, Groovy, були б корисні.

Часом тому я прийшов хрестовий Rubyscript ... http://almaer.com/blog/running-ruby-in-the-browser-via-script-typetextruby та http://code.google.com/p/ruby- в браузері /
Досі експериментальний та триває, але виглядає перспективно.
Для .Net я щойно знайшов: http://www.silverlight.net/learn/dynamic-languages/ Щойно знайшов сайт, але теж виглядає цікаво. Працює навіть з мого Apple Mac .

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

Що стосується безпеки, якщо мова працює всередині JVM (або двигуна .Net для цього питання), VM подбає про безпеку, тому нам не доведеться турбуватися про це - принаймні не більше, ніж нам слід за все, що працює всередині браузера.

Можливо, але для цього нам знадобиться отримати основні браузери для їх підтримки. Підтримка IE була б найскладнішою. JavaScript використовується, тому що це єдине, на що можна розраховувати, коли він буде доступний.

Переважна більшість розробників, з якими я говорив про ECMAScript et et. ін. нарешті визнаю, що проблема - це не сценарій мови, а смішний HTML DOM. Поєднання DOM і мови сценаріїв є загальним джерелом болю і розчарувань щодо ECMAScript. Крім того, не забувайте, IIS може використовувати JScript для сценаріїв на стороні сервера, і такі речі, як Rhino, дозволяють створювати вільні програми в ECMAScript. Спробуйте попрацювати в одному з таких середовищ з ECMAScript деякий час, і подивіться, чи зміниться ваша думка.

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

Старий сайт, але все-таки чудове місце для початку: сайт Дугласа Крокфорда .

Ну, ми вже маємо VBScript, чи не так? Зачекайте, тільки IE підтримує це!
Те саме для вашої гарної ідеї VM. Що робити, якщо я скриптую свою сторінку за допомогою Lua, а у вашому браузері немає аналізатора для перетворення її в байт-код? Звичайно, ми могли б уявити тег сценарію, що приймає файл байт-коду, що навіть було б досить ефективно.
Але досвід показує, що важко донести щось нове до Інтернету: потрібні роки, щоб прийняти кардинальні нові зміни, як це. Скільки браузерів підтримують SVG або CSS3?

Крім того, я не бачу того, що ви знайдете "брудним" у JS. Це може бути некрасиво, якщо закодовано любителями, поширюючи погану практику, скопійовану в іншому місці, але майстри показали, що це може бути і елегантною мовою. Трохи схожий на Perl: часто схожий на заплутану мову, але може бути ідеально читабельним.

Перевірте це http://www.visitmix.com/Labs/Gestalt/ - дозволяє використовувати python або ruby, якщо у користувача встановлено срібло.

Це дуже гарне запитання.

Це не проблема лише у JS, оскільки це у відсутності хороших безкоштовних IDE для розробки більших програм у JS. Я знаю лише одне, що є безкоштовним: Eclipse. Інший хороший - це Visual Studio Microsoft, але не безкоштовний.

Чому це було б безкоштовно? Якщо виробники веб-браузерів хочуть замінити настільні додатки на онлайн-програми (і вони хочуть), вони повинні дати нам, програмістам, хороші інструменти для розробників. Ви не можете зробити 50 000 рядків JavaScript за допомогою простого текстового редактора, JSLint та вбудованого налагоджувача Google Chrome. Якщо ви не макогіст.

Коли Borland зробив IDE для Turbo Pascal 4.0 в 1987 році, це було революцією в програмуванні. З цього часу минуло 24 роки. Соромно, що в 2011 році багато програмістів все ще не використовують завершення коду, перевірку синтаксису та належні налагоджувачі. Можливо, тому, що так мало хороших ІДЕ.

В інтересах продавців веб-браузерів зробити належні (БЕЗКОШТОВНІ) інструменти для програмістів, якщо вони хочуть, щоб ми створили додатки, з якими вони можуть боротися з Windows, Linux, MacOS, iOS, Symbian тощо.

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

Цей "стандартизований VM", про який ви говорите, був би дуже великим і його потрібно було б прийняти всіма основними браузерами, і більшість сайтів все одно просто продовжують використовувати Javascript, оскільки він більше підходить для веб-сайтів, ніж для багатьох інших браузерів.

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

Можливо, ви шукаєте власного клієнта Google.

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

Я думаю, що це не так просто питання. Можна сказати, що ми стикаємося з JS, але чи справді це так погано з jQuery, Prototype, scriptptaculous, MooTools та всіма фантастичними бібліотеками?

Пам'ятайте, що JS легкий , тим більше, що V8, TraceMonkey, SquirrelFish - нові двигуни Javascript, які використовуються в сучасних браузерах.

Це також доведено - так, ми знаємо, що у нього є проблеми, але у нас є багато цих питань, як ранні проблеми безпеки. Зображення, що дозволяє вашому браузеру запускати Ruby-код чи будь-що інше. Пісочниця безпеки повинна бути зроблена для нуля. А ви знаєте що? На цьому Python вже два рази не вдався .

Я думаю, що Javascript буде переглядатися та вдосконалюватися з часом, як HTML і CSS. Процес може бути тривалим, але не все можливо в цьому світі.

Я не думаю, що ви "розумієте прагматичну проблему, що JavaScript - це просто те, з чим ми маємо зараз працювати". Насправді це дуже потужна мова. Ви мали свій аплет Java у браузері роками, а де він зараз?

Так чи інакше, вам не потрібно «бруднитися» для роботи над клієнтом. Наприклад, спробуйте GWT.

... ти маєш на увазі...

Аплікація Java та Java Flash та Adobe AIR тощо.

Загалом, будь-яка рамка RIA може задовольнити ваші потреби; але для кожного з них є ціна, яку потрібно платити за його використання (наприклад, час виконання, доступний у веб-переглядачі та / і пропітераті та / і меншій кількості опцій, ніж чистий робочий стіл) http://en.wikipedia.org/wiki/List_of_rich_internet_application_frameworks

Для розробки Інтернету з будь-яким не веб-мовою ви маєте GWT: розробляйте Java, компілюйте у Javascript

Тому що всі вони мають VM з інтерпретаторами байт-кодів, і байт-код теж різний. {Чакра (IE), Firefox (SpiderMonkey), Safari (SquirrelFish), Opera (Каракан).

Вибачте, я думаю, що Chrome (V8) збирає машинний код IA32.

ну, враховуючи, що всі браузери вже використовують VM, я не думаю, що скласти мову VM для Інтернету буде не так складно.
Я думаю, що це може допомогти з кількох причин:
1. оскільки сервер компілює код, кількість відправлених даних менше, а клієнт не витрачає часу на компіляцію коду.
2. оскільки сервер може складати код під час підготовки та зберігати його, на відміну від клієнта, який намагається забирати якомога менше часу на компіляцію JS, він може зробити кращу оптимізацію коду.
3. компілювати мову в байт-код набагато простіше, ніж трансляція в JS.

як остаточне зауваження (як хтось уже сказав в іншому коментарі), HTML і CSS збираються на більш просту мову, не впевнені, чи вважається він байт-кодом, але ви також можете відправити складені html та css з сервера до клієнта, який би зменшити час розбору та отримання

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

Як я бачу, проблема - це нестійкі та непослідовні реалізації у багатьох браузерах, які ми змушені підтримувати в Інтернеті. Бібліотеки JavaScript, такі як jQuery, проходять довгий шлях до пом’якшення цього брудного почуття.