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

Чи знаєте ви про будь-яку існуючу чи заплановану ініціативу щодо впровадження кращої (переробленої) мови будь-якого типу (не лише JavaScript) для маніпуляції з DOM-деревом та HTTP-запитів у браузерах нового покоління? Якщо так, то яка дорожня карта для її інтеграції в скажімо, Firefox, і якщо ні, то з яких причин (крім сумісності) повинен бути єдиною підтримуваною мовою JavaScript на платформі браузера?

Я вже використовував jQuery, а також читав "javascript: хороші частини". Насправді пропозиції хороші, але те, що я не в змозі зрозуміти, це: чому тільки JavaScript? На стороні сервера (ваша улюблена платформа-os) ми можемо маніпулювати деревом DOM кожною мовою, навіть фортран. Чому клієнтська сторона (платформа браузера) підтримує лише JavaScript?

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

Більшість людей вважають, що Javascript схожий на Java, оскільки він має схожий синтаксис та схожу назву, але насправді це набагато більше нагадує lisp. Це насправді дуже добре підходить для маніпуляцій з DOM.

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

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

Відредагуйте наступне уточнення

Припустимо, було підтримано кілька мов інтерпретації - у вас все-таки проблеми. Різні браузери все ще будуть баггі та мають різні DOM.

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

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

Гаразд, а як же якась пісочниця для складеного коду? Мені звучить як Java аплети. Або ActionScript у Flash. Або C # у Silverlight.

А як щодо якогось стандарту ІЛ? Це має більше потенціалу. Розвивайте будь-якою мовою, а потім компілюйте її до ІЛ, яку браузер потім JIT.

За винятком того, що JavaScript - це вже такий ІЛ - просто подивіться на GWT . Він дозволяє писати програми на Java, але поширювати їх у форматі HTML та JS.

Відредагуйте після подальших роз'яснень

Javascript не є, а точніше, не єдиною мовою, яку підтримують браузери: ще в темні віки Internet Explorer ви можете вибрати між Javascript або VBScript для запуску в IE. Технічно IE навіть не запускав Javascript - він запускав JScript (головним чином, щоб уникнути необхідності платити НД за слово java , Oracle все ще володіє назвою Javascript ).

Проблема полягала в тому, що VBScript був власником Microsoft, а також у тому, що він був не дуже хорошим. У той час як Javascript додавав функціональні можливості та отримував найвищі інструменти налагодження в інших браузерах (наприклад, FireBug), VBScript залишався лише IE і майже не піддавався налагодженню (інструментів розробки в IE4 / 5/6 не було). Тим часом VBScript також розширився і став досить потужним інструментом сценаріїв в ОС, але жодна з цих функцій не була доступна в браузері (а коли вони з’явилися, вони стали масивними дірками в безпеці).

Є ще деякі корпоративні внутрішні додатки, які використовують VBScript (а деякі покладаються на ці отвори в безпеці), і вони все ще працюють IE7 (вони лише зупинили IE6, оскільки MS нарешті знищили його).

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

Додавання іншої мови для інтерпретації в браузерах стикається з двома основними проблемами:

• Змусити всіх постачальників браузерів впровадити новий стандарт мови - те, що вони досі не встигли досягти Javascript протягом 20 років.

• Друга мова потенційно розбавляє підтримку, яку ви вже маєте, дозволяючи (наприклад) IE мати підтримку Javascript другого рівня, але великий VBScript (знову). Я дійсно не хочу писати код різними мовами для різних браузерів.

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

Компілюйте в Javascript

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

(Але я не думаю, що це проблема. Javascript вже добре оптимізований. Машинний код також небезпечний, якщо він написаний від руки, але добре працює як ціль компіляції та мова виконання.)

Стільки варіантів

Існує постійно зростаючий набір мов, які збираються в Javascript. Досить вичерпний список можна знайти тут:

• Список мов, які компілюються в JS на Coffeescript Wiki

Заслуговує на увагу

Я згадаю кілька, які, на мою думку, заслуговують уваги (хоча, без сумніву, нехтуючи деякими дорогоцінними каменями, про які я не знаю):

• Spider з'явився в 2016 році. Він стверджує, що приймає найкращі ідеї Go, Swift, Python, C # і CoffeeScript. Це не безпечно, але має деякі незначні функції безпеки .

• В'яз : Haskell може бути найрозумнішою мовою з усіх, а Elm - це варіант Haskell для Javascript. Це дуже чітко і стисло, і пропонує функціональне реактивне програмування як чудова альтернатива реактивним шаблонам або MVC-спагетті. Але це може бути досить шоком для процедурних програмістів .

• Google's Go спрямований на стислість, простоту та безпеку. Код Go може бути скомпільований у Javascript GopherJS .

• Пізніше Дарт був спробою Google замінити Javascript. Він пропонує інтерфейси та абстрактні класи через синтаксис, схожий на C / Java, з необов'язковим набором тексту.

• Haxe схожий на ActionScript Flash, але він може орієнтуватися на кілька мов, щоб ваш код можна було повторно використовувати в програмах Java, C, Flash, PHP та Javascript. Він пропонує безпечні та динамічні об'єкти.

• Opalang додає синтаксичний цукор до Javascript, щоб забезпечити прямий доступ до бази даних , інтелектуальне продовження, перевірку типу та допомогу в розділенні клієнт / сервер. (Зв'язано з NodeJS та MongoDB.)

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

• LiteScript потрапляє десь між Coffeescript і GorillaScript. Він пропонує синтаксис асинхронізації / вихідних даних для "вбудованих" зворотних зворотних дзвінків, а також перевірку змін на друку.

• TypeScript Microsoft - це невеликий набір Javascript, який дозволяє розміщувати обмеження типу на аргументи функції, які можуть назбирати кілька помилок. Аналогічно BetterJS дозволяє застосовувати обмеження, але в чистому Javascript, або додаючи додаткові дзвінки, або вказуючи типи в коментарях JSDoc. А тепер Facebook запропонував Flow, який додатково виконує виведення типу.

• LiveScript - це відкат від Coffeescript, який був популярний своєю стислістю, але не виглядає для мене дуже читабельним. Напевно, не найкращий для команд.

Як вибрати?

При виборі альтернативного мови, є деякі чинники , які необхідно враховувати :

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

• Чи є в мові занадто мало функцій (код все ще буде наповнений панеллю котла) або занадто багато функцій (освоєння знадобиться тривалий час, і до цього деякий дійсний код може бути нерозбірливим)?

• Чи є у нього функції, необхідні для вашого проекту? (Чи потрібен вашому проекту перевірка типу та інтерфейси? Чи потрібні його розумні продовження, щоб уникнути вкладеного пекельного зворотного дзвінка? Чи є багато реактивності? Можливо, в майбутньому це потрібно орієнтувати на інші середовища?)

Майбутнє...

Джефф Уокер написав цикл публікацій в блогах про "проблему Javascript", включаючи те, чому він вважає, що ні TypeScript , ні Dart, ні Coffeescript не пропонують адекватних рішень. У висновку він пропонує деякі бажані особливості для вдосконаленої мови .

має бути JavaScript єдиною підтримуваною мовою на платформі браузера?

Так і ні. Там є альтернатива під назвою Dart від Google, яка компілює JavaScript і подібно до jQuery намагається трохи спростити маніпуляції з DOM. Можливо, буде цікаво експериментувати, перевірити це.

• З Google див . Мова dart
• Від Microsoft див. Мову TypeScript

Дивитися також

• В'яз
• Кал

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

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

За короткий термін я використовую такі речі, як jQuery, щоб приховати несумісність браузера. В довгостроковій перспективі такі технології, як Silverlight або Adobe AIR, можуть зробити це мінним полем (але все-таки мінним полем) зовсім іншим.

Дуг Крокфорд виступив з Google де детально про погані та хороші частини JavaScript та його майбутнє. Насправді він майже не змінився з 1999 року - що можна сказати, що це добре (майже всі браузери можуть використовувати той самий код, якщо ви знаєте про їх обмеження), і Даг показує, де хороші частини в основному були непорозуміння, які виявляються дуже сильними.

Для маніпуляції DOM дивіться на JQuery як на клієнтську бібліотеку, яка замінює більшість жахливих API DOM на операції, які боляче писати на досить елегантні біти коду, які простіше написати.

Якщо ви думаєте, що у JavaScript є глибокі проблеми, я рекомендую книгу Дуга Крокфорда, JavaScript: хороші частини . (Або Google для "Crockford JavaScript", щоб знайти кілька відеопрезентацій, які він зробив.) Crockford накреслює безпечний підмножина та набір практик, а конкретно перераховує деякі частини мови, яких слід уникати.

Мені невідомо про плани замінити JavaScript як фактичний засіб маніпулювання DOM. Тож найкраще навчитися користуватися ним безпечно та добре.

З точки зору клієнта, Javascript - єдиний спосіб маніпулювати DOM. У плані сервера існує безліч способів.

Internet Explorer підтримує підключувані мови сценаріїв, хоча єдиний з надійно включених до IE крім JScript - це VBScript.

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

Якщо ви готові обмежити своїх клієнтів / відвідувачів певними браузерами і, можливо, готові вимагати, щоб вони встановили плагін, ви можете подивитися на MS Silverlight - читаний огляд є у вікіпедії . За допомогою Silverlight 2 ви можете запускати на стороні клієнта код, який ви написали на C #, IronPython, IronRuby, VB.NET тощо; безкоштовний клон Moonlight Silverlight від проекту Mono обіцяє принести таку ж функціональність в Linux.

На практиці більшість розробників веб-додатків та сайтів вважають за краще охопити широку аудиторію, ніж наразі Silverlight (і, зрештою, Moonlight), яка може надавати - що означає дотримуватися Javascript або, можливо, Flash (що використовує аналогічну мову програмування, Actionscript).

Таким чином, здобуття значної рішучості, прийняття та притягнення до чого-небудь іншого виявляється непростою боротьбою навіть для Microsoft зі своїми великими групами інженерів та маркетингових бюджетів та проектом вільного програмного забезпечення на стороні (щоб, можливо, полегшити занепокоєння щодо власного блокування ) - що може допомогти пояснити, чому зацікавлення Фонду Mozilla дуже мало, наприклад, з боку Фонду Mozilla. "Окрім інтероперабельності", ви говорите: але очевидно, що питання інтероперабельності тут є великим, враховуючи те, що ми спостерігаємо за прогресом wrt Silverlight ...

Як вже було сказано, у вас є Flash (ActionScript, що є похідною мовою Javascript) та Silverlight / Moonlight (IronPython, IronRuby, JScript, VBScript, C #), які можуть працювати в браузері через плагіни (перший з них набагато більше всюдисущий) .

Також є інша альтернатива, якщо вам подобається Ruby: HotRuby , це реалізація рубіну в javascript, яка буде працювати в браузері. Він ще не дуже зрілий, але ви можете поглянути на це.

Одне, що я не бачив згадуваного (о, я бачу, як Alcides згадував HotRuby, коли я писав, а Носредна згадував GWT та Script #), і я хотів би викинути там є ряд реалізацій [вставте мову] -on- JavaScript (наприклад, перекладачі, які дозволяють конвертувати Ruby , Python , C # , Java , Obj-J / Cappuccino [подібний до Obj-C / какао] або переробку [для Canvas] в JavaScript або на клієнті, або перед розгортанням [та деякі з яких також представлені різні бібліотеки абстракцій]). Звичайно, є ефективність роботи, якщо вона перекладається на клієнта, але якщо вам зручніше іншою мовою, це дозволить вам отримати деяку гнучкість.

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

Ні. JavaScript це, але він буде розвиватися. Наступна версія - "Гармонія JavaScript", і ви можете дізнатися більше, якщо ви це зробите з Google.

Час від часу хтось пропонує вставити інтерпретатор байтового коду в браузери поряд з JavaScript. Напевно, не станеться, принаймні на деякий час.

Я випадково люблю JavaScript. Але є й інші рішення, включаючи GWT, який компілює Java в JavaScript і Script #, який компілює C # в JavaScript.

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

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

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

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

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

Я не думаю, що незабаром Javascript буде замінено. Зовсім інший підхід до багатих клієнтів, можливо, ви захочете дослідити Flex, який є Flash-технологією.

Можливо, щось на зразок haxe (див. Haxe.org) могло б вам допомогти. Це мова, яка здається більш чистою, ніж JavaScript, і її можна скласти до JavaScript, тому її можна запустити всередині браузера.

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

Багато людей розуміють, що Javascript - не найкраща і найкрасивіша мова. Однак зараз його підтримують браузери, і тому ввести іншу мову буде надзвичайно важко. Нам просто не потрібна інша війна в браузері.

Це пояснює, чому я не знаю жодних планів переходу на іншу мову на стороні клієнта.

Але я думаю, що Javascript не так вже й погано, якщо ви почнете думати про модель DOM і як би з нею працювати. Багато речей, які зіпсуються з JS, є результатом того, як працює модель DOM.