На каких задачах Java Script действительно лучше других языков?

Гибкое переключение рендеринга с сервера в браузер и назад на уровне каждого UI компонента.

в общем случае — везде, где нужно динамически и асинхронно подгружать исполняемый код.

на практике — для веба в браузере

тут пока речь идёт просто о возможности вызывать джаву из жс и наоборот. Без наказания по перфомансу и удобству, благодаря общему нативному коду в jit-компиляторе, который генерится из любого поддерживаемого языка.

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

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

мне бы какие-нибудь небраузерные применения. На бэкенде.

в браузере было бы интересно, но сейчас джава (точнее, конкретный её вид - Graal) в браузере не работает, и будет нескоро.

На задачах, в которых невозможно применить приличный язык.

на бекенде — как скриптовый язык внутри твоей апликушки. Nashorn под это и был запилен емнип

Вроде nashorn в жабе использовали чтоб пропаривать json без использования сторонних зависимостей.

Если есть хоть какая-то отдалённая вероятность, что этот код будет исполняться в браузере и в нём же придётся его дебажить — у JS нет конкурентов. Лёгкие прослойки ещё более-менее сойдут с сорсмапами, но, скажем, clojurescript — уже не очень.

Ты всегда можешь взять какую-нибудь вундервафлю, которая нагенерит из X яваскрипт и не работать с ним напрямую. Твоя постановка вопроса слегка холиварная.

А причём тут Java в тегах?

Один пример такой задачи уже есть: фронт на ReactJS внутри Java/C++ бэкенда

и о каких свичах ты тут говоришь? пиши два проекта, связанных по REST API. и все дела.

я пришёл к идее, что все языки можно и нужно запускать на JVM.

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

в частности, на джаве с джаваскриптовыми вставками. Или на джаваскрипте с джавовскими вставками.

не инлайновые вставки, а в смысле что ты их можешь без каких-либо проблем из джава-класса позвать код в .js файле и наоборот.

хотя можно и инлайн, но в таком варианте это на порядок сложней, и кейсов уже совсем не вижу

Я бы яваскрипт использовал для скриптования процесса. Для динамитизации, так сказать.

я пришёл к идее, что все языки можно и нужно запускать на JVM.

Эта идея стара. См. Дот.Нет. И, имхо, идея так себе.

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

Имхо, лучше всего так не делать никогда, потому что в этом случае вместо кода у тебя получается малочитабельная каша. Да и на надёжность программы это повлияет не лучшим образом, т. к. большинство труднообнаружимых ошибок появляется как раз на стыке интерфейсов, а языки — тоже интерфейсы.

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

А зачем, если не секрет? Т. е. сама постановка задачи немного школьная: типа препод сказал, что надо понять, вот теперь думаю, как его понять. Но ты, насколько я знаю, не студент. Т. е. задача, видимо, вполне производственная. А на производстве обычно сначала понимают, зачем что-то нужно, а потом уже притягивают это понимание за уши для тупого заказчика.

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

Ты живёшь в каком-то собственном мире :) Чувствую, как последняя звезда потухнет, станет на одного кулинхао больше.

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

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

Баллистику звездолёта рассчитывать в реальном времени.

Парсинг/тестирование сайтов - смотри google puppeteer или Google Chrome Headless mode. Ты можешь пройтись по DOM через document selector и получить оттуда данные в виде сериализованного JSON. Очень удобно, тк селекторы по DOM ты в консоли браузера отладил, пульнул их в свой код, обернул обработку ошибок и работаешь дальше. Не нужно транслировать их в XPath, как это часто делают в том же Selenium.

я копаюсь в этом исключительно из исследовательских соображений.

Понятно. Если говорить об искусстве ради искусства, то задача, наверно, интересная. Своё мнение об её практической пользе я уже высказал. Кроме того, если не только ваша контора, но и Oracle пойдут по такому пути — напихать кучу разных языков, объединённых общей JVM, то вы будете плестись в хвосте у MS, которая эту идею давно успешно воплотила в жизнь в своём .Net. А кому нужен ещё один .Net? Думаю, мало кому. Т. е. java тогда просто растеряет значительную часть поклонников, которые уже не будут видеть принципиальной разницы между java и .Net и разбегутся кто к MS с её более продвинутой в этом плане технологией, кто форкать новую нормальную яву, а кто на вольные пастбища.

Еще вариант - игры, где много скриптов для управления поведением NPC. Движок игры на крестах, например, а для скриптования можно использовать JS. Он простой и его легко освоят всякие там гейм дизайнеры для программирования сценок, квестов и тд

там гейм дизайнеры

===, '1'+1

nobody cares же

Целесообразность, наверно, зависит от того, какие дыры в архитектуре ты хочешь им замазать, или какие нестыковки сгладить.

Гибкое переключение рендеринга с сервера в браузер и назад на уровне каждого UI компонента.

Clojure+ClojureScript и какой-нибудь Rum.

Работа с DOM. Для других языков API не завезли, вот тебе и вся клёвость.

Я бы сказал, что

(а) в тех задачах, где язык со статической типизацией будет ограничивать твои возможности (напр., один и тот же алгоритм придётся переписывать дважды для разных иерархий типов) — см. тж. inline fun <reified T> в Kotlin (https://kotlinlang.org/docs/reference/inline-functions.html) — и

(б) там, где решение нужно будет модифицировать без перекомпиляции (в т. ч. заниматься прототипированием) или где часть задач ты делегируешь индусам, неспособным изучить Java (ср. Mozilla и XUL/XBL).

Да, ещё

(в) представь, что у тебя есть некий ресурс, предоставляющий внешним пользователям «песочницу» для исполнения их кода, — напр., ты запилил курс для Coursera или Stepik и хочешь убедиться, что алгоритм твоих студентов работает за O(n * log(n)), а не за O(n^n).

Для других языков API не завезли, вот тебе и вся клёвость

Вообще-то везде есть библиотеки для работы с DOM, а уж в Java вообще XML во все поля.

какие задачи лучше всего делать на «языке JS» просто потому, что он клёвый?

Никакие, ибо ничего «клёвого» в js нет. Он скучный и нудный, просто до зубовного скрежета.

Где везде? Речь о реализации DOM в браузерах, а не просто работе с абстрактным деревом.

Речь о реализации DOM в браузерах

И каким боком это относится к js как к языку?

а не просто работе с абстрактным деревом

А оно и не абстрактное, оно обычно отражает конкретную предметную область. С каких таких щей документ в браузере имеет «настоящую» DOM, а документ в файле имеет «абстрактную» DOM?

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

Все языки одинаковое говно, для практических задач их выбирают, исходя из среды выполнения/инфраструктуры/библиотек, а не самого языка, привыкнуть к любому можно

этот юзернейм просто такой толстый что даже тонкий. типа wrap around. хотя просто глупый.

(в) представь, что у тебя есть некий ресурс, предоставляющий внешним пользователям «песочницу» для исполнения их кода, — напр., ты запилил курс для Coursera или Stepik и хочешь убедиться, что алгоритм твоих студентов работает за O(n * log(n)), а не за O(n^n).

Тут скорее о платформе, чем о самом языке.

про «клевый» ничего не скажу, но разве _реальные_ потребности в реальных ситуациях не важнее?

может быть вас на каким-то мысли натолкнет.

уже сказали про единый клиент-серверный язык это же две причины, одна понятно - ментальная нагрузка. Другая когда вам банально нужно делать одну и ту же работу и там и там. Пример - валидация. Клиенту на ЖС нужно чтобы помочь пользователю заполнить форму/подготовить связку структур данных, а серверу - из-за того, что он не может доверять клиенту и вынужден сам валидировать. Для валидации можно велосипедить декларативное на что-то на хешмапах с правилами и пр, но тогда 1.придется писать два интерпретатора на двух языках. 2. оно будет с подводными камнями (к примеру даже правило «регулярка» - не исключено, что потребует и регулярок отлаживать два комплекта). Т.е. наверное для валидации удобнее использовать именно _единый код_. правда этот пример плох тем что на сервере у вас нет того dom, но если отвязать код от dom смысл уже может и появится.

второй очевидный пример - сторонние библиотеки, которые уже написаны, но не вашем основном языке. т.е. самая лучшая библиотека решающая эту задачу - она на ЖС например. а у вас жава, а жавовская, предположим, не дотягивает немного. либо вообще только ЖС такие библиотеки есть, к примеру что-то для фронтенда понадобилось - те же CSS-lint вроде сейчас только на жс идут. (правда бывает и обратная ситуация css валидатор w3c был на java именно).

дальше про жс уже не скажу. третье это гибриды. положим у вас веб-портал с конца 90х на перл + пхп. натурально гибрид (описываю реальную ситуацию), но на костылях (SSI,exec,прегенерация), т.к. рантайм у них не общий. тут было бы удобнее уже отлаженный код из языка A буквально вызывать из языка Б, т.е. сделать гибрид «нормальный». т.е. проще говоря, зачем вообще разбираться и переписывать какой-то существущий коде, который работает, хорошо бы просто вызывать его как раньше и всё.

почти такая же ситуация, но _миграция_ при наличии не кодовых ассетов - положим что у вас часть проекта на A часть на B, и второго давно больше. и есть, к примеру html шаблоны, но в B нет 100% совместимого template engine, т.е. было бы хорошо либу на языке A запустить в рантайме B и там же скормить ей старые шаблоны. (вместо шаблонов может быть-то другое, но на ум как-то не приходит.)

• Программист Вася зачем-то пишет одновременно на жабе и жабаскрипте, жабаскрипт захардкожен.
  • Вася любит писать на жабе, но жабаскрипт даёт какие-то невъебенные преимущества.
    • На жабаскрипте есть хорошие, годные библиотеки, которых нет на жабе. Что там у них есть, разве что действительно реакт можно натянуть.
  • Вася любит писать на жабаскрипте, но жаба даёт какие-то невъебенные преимущества.
    • На жабе есть хорошие, годные библиотеки, которых нет на жабаскрипте. Заметка на полях: BigDecimal из жабы в жабаскрипт портировали/переписали, если так можно, то нужно ли вообще мешать языки?
    • На жабе сишечке есть хороший, годный перформанс и Вася хочет ускорить своё поделие.
• Программист Вася пишет программу на жабе, которая умеет в себе выполнять скрипты на жабаскрипте, жабаскрипт незахардкожен. Куча вариантов.
  • Макросы в офисных программах.
  • Скрипты в играх. Можно писать расширения для игр.
  • Модификация вебсайтов. greasemonkey для пользователей, через админку cms для админа сайта. Какую нибудь подсветку старых багов в багтрекере зафигачить на скорую руку.
  • Линуксоадминам polkit конфигурировать, лол.

ЗЫ: Напишите уже макскому, гугл грозит отключить старую гуглокапчу, пускай обновляется.

про «клевый» имел в виду, сложно представить как жавист говорит «ну к черту, надоел контроль типов, надоел интеллисенс, скучно! сделаю-ка файл на жс.» тем более если задача на 20 строк, то жавист извернется сделает это на жаве, даже если в жс это удобнее, а если на 20000 строк то тем более на жаве сделает.

Почему я это спрашиваю: мне нужно написать небольшую работу, где нужно свичнуться в JS и сделать какую-то задачу, и потом вернуться назад.

1. Тузла для тестов REST JSON API. Ну сам понимаешь жысон для js очень нативный потому, удобнее делать именно так. Пример: https://github.com/wayerr/jsterest

2. Скриптование всякой херни. Отчёты там и прочия байда, всё что не большое но с упоротой логикой, и не используется повторно. Примеры есть но closed source, увы.

Ещё из разряда идиотских идей: допустим у нас есть гуй на жабе, tensorflow на питоне и проприетарный libspotify с анальным drm и заголовочным файлом на сях. Мы этот зоопарк хотим собрать вместе и поэтому пишем glue code на жабаскрипте.

Ой, на многих! Запутывание потенциального противника, создание развлекательных видео на эту тему, коллекционирование импотентных рантаймов, втаптывание в грязь самооценки, скатывание веба в задницу...

gjs gnome во все поля

Года два назад я бы сказал тебе, что Java+Nashorn очень удобны для девопса. Т.е. некое подобие Ansible, Ant или даже Gradle, но на JS с возможностью вызовы всего этого из Java и обратно. Руководствовался тем, что все знают JS и не надо изучать всякие груви и прочий XML-ый треш. И даже полтора года потратил на ресерч и разработку такого инструмента.

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

Я бы добавил, что перенос существующих ЯП на JVM не менее плохая идея, но это уже совсем другая история.

если не только ваша контора, но и Oracle пойдут по такому пути

так это именно оракловский проект и есть.

работа у меня с этим напрямую никак не связана. То есть, это помогает работе, но не более.

про .NET ты не совсем прав (совсем неправ). В JVM такая идея была воплощена ещё раньше, чем в .NET.

Смысл не в интеропе между несколькими языками, а именно в интеропе меджу JavaScript и другими языками. Всё дело в джаваскрипте.

Насколько понимаю, JavaScript на .NET CLR так никогда и не стал официальным языком, а в Java он официальный JVM-язык уже давно. Начиная с Java 7 есть встроенный компилятор JS, а в Java 11 он просто становится гораздо лучше. И вот эту идею я и хочу растащить по всему свету.

А при попытке нагуглить официальность JS на JVM, вылезают лишь сторонние проекты и биндинги (node js to java, ringojs, nashorm, etc). Если уже так давно, то почему так тихо?

Насколько понимаю, JavaScript на .NET CLR так никогда и не стал официальным языком, а в Java он официальный JVM-язык уже давно. Начиная с Java 7 есть встроенный компилятор JS

Этого не знал. Последний раз писал ещё на java 2.

Но я поясню, почему считаю такие идеи пагубными.

Java машина изначально была заточена на язык Java, а язык Java на java-машину. В результате получалось что-то монолитное, красивое, более-менее компактное и продуманное, хоть и довольно тормозное на больших проектах.

Теперь ты пишешь компилятор js для jvm. Потом компилятор vbs для jvm. Потом компилятор python для jvm. Пока этим занимаются какие-то левые фирмы или энтузиасты, можно не обращать внимания. В конце концов, не нравится — никто не заставляет пользоваться. Но что произойдёт, когда этим всерьёз начнёт заниматься контора, отвечающая за стандарты языка и за jvm? Они увидят, что в js какие-то вещи не очень эффективно (скажем, в сравнении с другими вещами, потому что эффективность виртуальной машины с автоматическим сборщиком мусора вообще сомнительна — это не камень в твой огород, а факт, но у явы есть и достоинства) и появится соблазн добавить новые «фичи» в jvm, чтобы откомпилированный js-код работал быстрее и ел меньше памяти. Потом команда, занимающаяся jvm-python'ом, скажет, что им бы тоже хотелось добавить в jvm разные питоновские фичи. И т. д. И что получится в результате? Что-то громоздкое, неуправляемое, дырявое и совсем уж неэффективное, в сравнении с чем будет казаться, что прежняя ява просто летала быстрее си.

Я, конечно, немного утрирую. Судя по успеху технологии .net, всё не так плохо. Но думаю, что большая доля правды в моих словах есть. С другой стороны, поддержка только js — ещё не поддержка всего, чего только можно. Но это уже маленький шажок в этом направлении. Я против громоздких комбайнов там, где без них можно обойтись.

Кстати, в своё время, когда java была ещё Sun'овской, Microsoft накатала в Sun длинную телегу с перечислением того, что они должны добавить в яву, чтоб сделать её более юзабельной для windows-пользователей. Sun послала Microsoft лесом. Тогда Microsoft создала свой Visual J++, несовместимый с java, но называемый ими так же. Sun подала в суд на Microsoft и выиграла его. Microsoft могла бы продолжить развивать технологию под другим названием, но, видимо поняв, что в этом случае она обрекает себя вечно дышать в спину Sun, плюнула на это, и создала свой Dot.Net, базирующийся на истинно микрософтовских принципах (налепить в кучу побольше всего, скрестив ежа с ужом, чтоб можно было одно и то же сделать и так, и этак, и разэтак, а что потом никто ничего понять не сможет — дело десятое). У микрософтовских принципов нашлось немало почитателей, и дот.нет серьёзно потеснил яву. Я думаю, что если Oracle не остановится на поддержке js в jvm и пойдёт дальше по микрософтовскому пути, то потеряет свою нишу и обречёт себя вечно дышать в спину Microsoft.

Как-то так. Длинновато получилось, но короче я не умею.

Но что произойдёт, когда этим всерьёз начнёт заниматься контора, отвечающая за стандарты языка и за jvm?

Ты прав. Именно это и происходит, и эта компания называется Oracle.

Они увидят, что в js какие-то вещи не очень эффективно ... и появится соблазн добавить новые «фичи» в jvm,

Поэтому в течение следующих нескольких лет Java/JVM переведут с C2 на Graal, а Graal изначально делался (вместе с Truffle) как запускатор высокодинамических языков под JVM. Именно поэтому, когда Twitter переехал на Graal (им пофиг, что это пока не продакшен), на их огромных полудинамических ынтерпрайзных поделках для Scala оно дало +10% производительности.

Ну а я собственно и занимаюсь тем, что сейчас изучаю Graal, и ищу ему методы применения в реальном мире.

Nashorn это и есть официальная - часть OpenJDK. А до этого был Rhino. И это не просто «биндинги», это целиком JS виртуалка, реализованная на Java.

А ещё был (но загнулся в альфе) такой же официальный Project Avatar, типа Node.js на Java. А сейчас как Node.js уже сможет работать Graal.

Graal быстрее v8?

Не знаю точно, спрошу/измерю. Скорей всего, перфоманс в большинстве типичных случаев примерно такой же, с точностью до пары процентов.

Graal изначально делался (вместе с Truffle) как запускатор высокодинамических языков под JVM. Именно поэтому, когда Twitter переехал на Graal (им пофиг, что это пока не продакшен), на их огромных полудинамических ынтерпрайзных поделках для Scala оно дало +10% производительности.

Да, я начал читать статью на хабре. Правда, у меня в этот момент компилировался почти сутки webkitgtk, и в какой-то момент всё встало, поэтому поубивал лишние процессы, включая браузеры. Но дочитаю.

я собственно и занимаюсь тем, что сейчас изучаю Graal, и ищу ему методы применения в реальном мире.

Если он на 10% эффективнее и почти без багов, как написано в статье, то зачем для него что-то искать? оно само его найдёт. :-)

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