Как стать автором
Обновить

Комментарии 24

хочется спросить насколько GraalVM опенсорсный
как-то так
github.com/oracle/graal

отсюда берется CE версия
для EE имеются закрытые дополнения касающиеся отдельных оптимизаций, но и сама EE платная для продакшена

описание как собрать свою версию
github.com/oracle/graal/blob/master/vm/README.md#example-build-the-base-graalvm-ce-image
ОООО, разработчики знают толк в извращениях.
С любопытством жду продолжения

ЗЫ интересно, получается, это свой серверный рендеринг, но внутри JVM. Любопытно. В копилку пункт по использованию graalvm
Серверный рендеринг поможет таким пользователям быстрее получать контент. Пока картинки будут грузиться, они смогут начать что-то читать:


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


Да, именно про это речь.
Теперь понятно происхождение уже трех фантомных сообщений в переписке на ОК, и очень «логичное» поведение окна отправки ответного подарка (после отправки ответного подарка из ленты оповещений, закрывая окно отправки подарка (там имеется крестик) ты закрываешь и ленту оповещений (имеющую отдельный крестик)) причем разработчики считают такое поведение интерфейса абсолютно нормальным. Причем если в окне отправки ответного подарка открыть окно общения с техподдержкой, и закрыть её, то лента оповещений не закрывается.
Короче говоря как на КДПВ (О сколько нам открытий чудных, готовит просвещенья дух)!
image

Надеюсь что баги таки отловят и исправят, а не превратят в гениальные фичи.
Таки это разработчики ОК увидели описание бага и решили вместо его исправления заминусовать сообщение и в карму камень кинуть? Или это хейтеры Одноклассников? Ну бог всем судья и rm -rf /
Кстати о птичках: Баг проявляется под всеми доступными мне ОС, и всеми доступными мне браузерами (с самыми актуальными версиями).
В отличии от молчаливых господ минусующих, думающих что заминусовав описание ошибки они волшебным образом её исправят
Это не те баги что вы ищете, это фичи - деплойте их в продакшн
image

Это не те баги что мы ищем! Это фичи! Деплоим их в продакшн!
image

Немедленно!
image

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

Опасно это в долгосрочной перспективе. Насколько я знаю, и nashorn, и rhino не поддерживаются уже. Не постигнет ли движок яваскрипта в граале та же участь? Что тогда будете делать?

НЛО прилетело и опубликовало эту надпись здесь
По поводу Nashorn:

github.com/graalvm/graaljs/blob/master/docs/user/NashornMigrationGuide.md

никто просто так не будет выбрасывать наработки
сдвинулись в стороны graal и truffle, так как реализовывать новые фичи из js мира достаточно ресурсоёмко, реализовывать с помощью truffle оказалось намного проще.

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


Жду теперь реализации другой хотелки: мини-приложений (в стиле Amazon Lambda), компилируемых с помощью Native Image

Подход запуска js, но только в asp.net, использую лет 5. В основном для быстрых кастомизаций. А вот использование для рендеринга не знаю. Ваш подход напоминает Asp.net WebForms ). Фича ssr в том, что почти один и тот же код используется и на клиенте и в шаблонизаторе. Как реализовано у вас, я не понял. Если клиентский код и серверный код генерации html разный, то как по мне зря потрачено время

Об это подробно будет во второй части. Она готовится к публикации

Спасибо, ждем )

В 2006 существовал JavaScript.

Интересно было бы почитать про сравнение производительности, такого решения. Насколько я помню (https://github.com/graalvm/graaljs/issues/74), во многих кейсах компилируемый graal имеет намного более долгий старт, да и производительность слабее v8.
этот тикет оставлят неясное впечатлениие. насколько я понял прочитанное, разработчики graal не признали проблем с его производительностью.
тот пример долгого старта, что там указан, больше похож на запуск с недостаточным количеством памяти — для jvm в таком случае характерно пытаться непрерывно собирать мусор, что практически почти останавливает выполнение любой программы. На это часто напарываются начинающие пользователи JVM. Для пользователя, конечно, было бы удобнее увидеть нормальное сообщение, что не хватает памяти — но это больше вопрос не к graal, а к эргономике JVM.

Ну в случае с GraalVM, таки долгий прогрев имеет место быть. Причём сильно дольше, чем у хотспота.


В профильном чатике телеграмма много экспериментировали на эту тему. В некоторых тестах прогрев получался в разы дольше хотспотовского.

Тем не менее, если вы используете в проде, есть ли метрики в сравнении v8?
Очень интересно было бы почитать. Технология очень интересна.
НЛО прилетело и опубликовало эту надпись здесь
Не будет ли конфликта, когда рендеринг на клиенте будет отличаться от того что нарендерила джава.


Чтобы следить за этим в реакте во время гидрации идет сравнение то, что пришло с сервера с тем, что воссоздал клиент. И, если есть расхождения, в дев моде сообщает об этом.
Да и java тоже не будет вечна)
Интересно посмотреть, как оно деплоится, жду подробностей в следующей части ;)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.