Комментарии 30
в пункте 15 я не увидел той магии, о которой было заявлено. в JS объявляются переменные, ну вроде как Java типы… ну а где профит? как данные из Java-сервера передать в клиента? Можешь сделать пример, который будет хотя бы текущую дату из переменной, объявленной в Java модуле на сервере, показывать на странице? или эта тема вообще не связана с клиент-серверным взаимодействием, а просто о том, как можно ноду под граалем запустить?
Эта тема связана не с клиент-серверным взаимодействием, а с тем, что Нода, запущенная на Граале, имеет доступ к джавовским данным.
Генерация статики с использованием React/Babel/Webpack — более сложная и интересная для джавистов задача, поэтому в статье именно она.
Вставить данные при генерации HTML со стороны JS-сервера гораздо проще. Выложил работающий пример на гитхабе.
Всего-то нужно поднять Express и работать с ним так же, как и всегда, цепляя Java по мере необходимости:
const express = require('express')
const app = express()
app.get('/', (req, res) => {
var JavaDate = Java.type("java.util.Date");
var currDate = new JavaDate();
res.send(currDate.toString());
})
app.listen(3000, () => {
console.log("server started")
})Доставить такие данные на JS-клиента можно так же, как всегда — с помощью аяксовых запросов.
Тогда все это похоже на proof of concept с очень ограниченной областью применения.
Сам Пraal — это не proof of concept, а отличная, хорошо работающая вещь. Над которой работают лучшие в мире специалисты по VM, рантаймам, языкам, и так далее.
Примеры использования из этой статьи — это действительно, всего лишь примеры. Если начать разводить здесь «правильную архитектуру» и «лучшие практики»- это будет не статя на хабре, а книга страниц на тысячу триста. Когда напишу такую книжку, сможешь купить ее за пять тысяч рублей :-)
А если говорить философски, мне кажется что органиченность применения — это нормально. Особенно когда ты четко принимаешь эти границы.
Бесшовный интероп — это особый способ оптимизации, в данном случае он оптимизирует несколько вещей: a) объем труда разработчиков на организацию собственного интеропа б) перфоманс интеропного кода при пересечении границы языка
Если у тебя в проекте нет мест, где перфоманс просаживается в этом месте, то все замечательно — проходи мимо, чини что-нибудь другое.
У меня в проектах были и есть такие проблемы (например, как известно, сайты JUG.ru Group создаются статическим генератором).
Примеры использования из этой статьи — это действительно, всего лишь примеры. Если начать разводить здесь «правильную архитектуру» и «лучшие практики»- это будет не статя на хабре, а книга страниц на тысячу триста. Когда напишу такую книжку, сможешь купить ее за пять тысяч рублей :-)
А если говорить философски, мне кажется что органиченность применения — это нормально. Особенно когда ты четко принимаешь эти границы.
Бесшовный интероп — это особый способ оптимизации, в данном случае он оптимизирует несколько вещей: a) объем труда разработчиков на организацию собственного интеропа б) перфоманс интеропного кода при пересечении границы языка
Если у тебя в проекте нет мест, где перфоманс просаживается в этом месте, то все замечательно — проходи мимо, чини что-нибудь другое.
У меня в проектах были и есть такие проблемы (например, как известно, сайты JUG.ru Group создаются статическим генератором).
А в чем профит по сравнению с запуском обычного nodejs и вытягиванием нужных данных из Java-приложения по http? Микросервисы и вот это вот всё.
Ну например в том, что когда-то давно ты обязан был делать микросервисы, а теперь — не обязан.
Например, у микросервисов безумно дорогая стоимость запроса, а вызов через Graal стоит как обычный джавовый метод. То есть твой вопрос можно довести до абсурда таким вопросом: зачем нам писать в языке программирования какие-то функции и методы, давайте вместо каждого метода вызывать REST-сервис?
А еще у микросервисов довольно большая стоимость создания, поддержки итп. То есть это обычные вопросы холивора «монолит против микросервисов».
Есть какая-то минимальная окрестность кода, где вызовы должны быть нативными: это выгодно по перфомансу, по общей стоимости, по чему угодно — в соотетствии со здравым смыслом. И вот уже большие лоскуты соединяются по HTTP. Если когда-то давно переключение контекста языка обязывало начинать медленный интероп (кроме HTTP есть же еще файлы, пайпы, что угодно), то теперь можно не резать на лоскуты то, что должно архитектурно быть единым.
Имхо, это должно особенно понравиться как раз фуллстек-разработчикам. Когда одна команда пишет бэк, и другая — фронт, это одно, ты всегда можешь скинуть заботу по интеграции на кого-то еще. Когда ты пишешь все сам, от базы данных до анимаций во фронте — то ой, уже задумываешься над более оптимальными решениями. Можно парить мозг подрядчику — но крайне невыгодно парить мозги самому себе.
Например, у микросервисов безумно дорогая стоимость запроса, а вызов через Graal стоит как обычный джавовый метод. То есть твой вопрос можно довести до абсурда таким вопросом: зачем нам писать в языке программирования какие-то функции и методы, давайте вместо каждого метода вызывать REST-сервис?
А еще у микросервисов довольно большая стоимость создания, поддержки итп. То есть это обычные вопросы холивора «монолит против микросервисов».
Есть какая-то минимальная окрестность кода, где вызовы должны быть нативными: это выгодно по перфомансу, по общей стоимости, по чему угодно — в соотетствии со здравым смыслом. И вот уже большие лоскуты соединяются по HTTP. Если когда-то давно переключение контекста языка обязывало начинать медленный интероп (кроме HTTP есть же еще файлы, пайпы, что угодно), то теперь можно не резать на лоскуты то, что должно архитектурно быть единым.
Имхо, это должно особенно понравиться как раз фуллстек-разработчикам. Когда одна команда пишет бэк, и другая — фронт, это одно, ты всегда можешь скинуть заботу по интеграции на кого-то еще. Когда ты пишешь все сам, от базы данных до анимаций во фронте — то ой, уже задумываешься над более оптимальными решениями. Можно парить мозг подрядчику — но крайне невыгодно парить мозги самому себе.
Аргумент про стоимость интеропа принят. Про интеграцию не совсем согласен, но вас понял.
Спасибо!
у микросервисов безумно дорогая стоимость запроса
Да ладно. Дороже, чем время программиста, который будет разбираться через год в этих хаках и говнокоде?
Я ещё не видел web проект, где производительность упирается в именно стоимость вызова. Обычно это доли процента.
должно архитектурно быть единым
Правильно, единым, а не вермишель из js и Java кода.
Для java -> js спокойно можно взять GWT и не страдать вообще, особенно учитывая, что есть встроенный jsinterop и обёрнутые через него React и Vue.
Можно. Но этот пост — про Graal. Вести аргументированные дебаты про GWT я сейчас не смогу, это отнимает много времени (а мне еще пост о программе DotNext сегодня выпускать!)
Этот пост про Graal, но тем не менее, мне вот тоже показалось, что местами он слишком узконаправленный. Это взгляд как бы с одной точки зрения, хотя комментарии его конечно уже расширили.
Делать web приложения на Java реально можно сотней методов, и многие из них ничуть не хуже Node вместе со всем окружением.
Мне вот всегда было интереснее немного другое — полноценная и легкая интеграция того же Babel, которая на базе Nashorn делается, но скажем прямо, слегка через одно место. А заодно и всего другого инструментария, который уже наваяли вокруг node, и многое из него — совсем даже не про web, или не совсем про web. Скажем, всякие cli инструменты, или d3 какой-нибудь.
Делать web приложения на Java реально можно сотней методов, и многие из них ничуть не хуже Node вместе со всем окружением.
Мне вот всегда было интереснее немного другое — полноценная и легкая интеграция того же Babel, которая на базе Nashorn делается, но скажем прямо, слегка через одно место. А заодно и всего другого инструментария, который уже наваяли вокруг node, и многое из него — совсем даже не про web, или не совсем про web. Скажем, всякие cli инструменты, или d3 какой-нибудь.
В Граале как минимум три проекта: оптимизирующий джит-компилятор, тулсет для создания языков программирования и клозед-ворлд виртуальная машина. Тема про языки программирования делится на подтемы типа гральжс, трюфельруби, сулонг, итп.
Если писать о каждой из этих тем глубоко и одновременно, то выйдет сочинение с объемами Кнута, это немного неприемлемо для Хабра
Другие темы тоже будут, но попозже. Слона можно съесть по кусочкам.
Если писать о каждой из этих тем глубоко и одновременно, то выйдет сочинение с объемами Кнута, это немного неприемлемо для Хабра
Другие темы тоже будут, но попозже. Слона можно съесть по кусочкам.
А можно взять Clojure и ClojureScript и Reagent. Интеропа между которыми вообще нет. Т.к. это один и тот же язык :)
Очень больно писать на Java веб-интерфейс (по крайней мере до тех пор, пока JVM и OpenJDK не стабилизируются на WebAssembly)
Если нужен Web на Java — есть Vaadin. Сайт на сто миллионов клиентов на нём конечно делать не надо, но внутрикопоративное ПО — очень даже.
PS: demo недоступно, заблокировали наверно вместе с телеграмом
Вопрос как раз в том, что если я не хочу веб на джаве. Джаваскрипт для этого — куда более подходящий инструмент (по крайней мере, пока webassembly вот в этом зачаточном состоянии).
Ой, только не Vaadin. Есть ведь ZK и ейный ZUL, на котором компоненты пишутся гораздо веселей, чем на plain Java, в отличие от.
А кто-нибудь запускал имеющиеся дистрибутивы Graal под той Ubuntu, которая в Windows 10?
Интересный вопрос, надо попробовать.
Я кстати проверил. Если скачать GraalVM для линукса, распаковать его, и запустить, то оно во всяком случае стартует:
graalvm-0.32/bin$ uname -a
4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
graalvm-0.32/bin$ ./java -version
java version «1.8.0_151»
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
GraalVM 0.32 (build 25.71-b01-internal-jvmci-0.40, mixed mode)
Полностью не проверял, но некоторые надежды уже есть.
graalvm-0.32/bin$ uname -a
4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
graalvm-0.32/bin$ ./java -version
java version «1.8.0_151»
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
GraalVM 0.32 (build 25.71-b01-internal-jvmci-0.40, mixed mode)
Полностью не проверял, но некоторые надежды уже есть.
В Node.js надо либо уважать их феншуй по использованию require, либо хакнуть его к чертям вот таким простым кодом
Что здесь происходит? Это столько костылей из-за нежелания написать if(typeof module === 'object') module.exports = validate?
В крайнем случае, при очень сильной ненависти к commonjs, всегда можно объявить функцию глобально явным образом. Вот такой код создаст глобальную функцию validate в любом js-окружении:
(function() {
this.validate = function(target) { /* ... */ };
})();В повседневной практике часто встречаются приложения, состоящие из двух частей: ClojureScript-фронтенд и Clojure-бэкенд. Организация интеропа между ними НЕ требует НИКАКИХ усилий.
Я чего то не понимаю. А почему про котлин никто не вспоминает?) Как раз таки на котлине и удобно писать и под jvm и под js. И не надо изобретать велик на js, можно использовать имеющиеся js фреймворки.
Не очень понятно: это в браузере выполняется? Ведь страница html открывается в браузере. Откуда там Java?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
JavaScript, Java, какая теперь разница?