Comments 25
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
Серверный рендеринг поможет таким пользователям быстрее получать контент. Пока картинки будут грузиться, они смогут начать что-то читать:
Можно поподробней, как серверный рендеринг ускоряет получение контента? Ведь если рендерит клиент, кто на клиент идет только минимум необходимых данных. Или речь про то, что в случае клиентского рендеринга нужно загружать скрипты предварительно и это как раз и есть фактор замедления?
Или речь про то, что в случае клиентского рендеринга нужно загружать скрипты предварительно и это как раз и есть фактор замедления?
Да, именно про это речь.
Серверный рендеринг поможет таким пользователям быстрее получать контент
Тут необходимо уточнение, что это справедливо только для первого запроса. При использовании SSR переход по роутам происходит дольше, потому что каждый раз пользователь скачивает готовую разметку, которая может оказаться довольно большой по сравнению с JSON. Попробуйте поставить Slow 3G в Network и походить по страницам, увидите, о чём я говорю.
А вот при клиентском рендеринге, после первой загрузки бандл с библиотеками кэшируется, и при последующих запросах пользователь будет загружать только данные. Если вам очень нужен именно тот самый первый рендер, используйте пререндеринг.
Всё же, SSR в основном используют не для перфоманса на стороне пользователя (по озвученным выше причинам, CSR подходит для этого лучше). Почему вы всё-таки решили выбрать именно его?

Надеюсь что баги таки отловят и исправят, а не превратят в гениальные фичи.
Кстати о птичках: Баг проявляется под всеми доступными мне ОС, и всеми доступными мне браузерами (с самыми актуальными версиями).



разработчики сочли возможным связаться и запросить дополнительную информацию, надеюсь что эта информация поможет им исправить ошибки.
Опасно это в долгосрочной перспективе. Насколько я знаю, и nashorn, и rhino не поддерживаются уже. Не постигнет ли движок яваскрипта в граале та же участь? Что тогда будете делать?
github.com/graalvm/graaljs/blob/master/docs/user/NashornMigrationGuide.md
никто просто так не будет выбрасывать наработки
сдвинулись в стороны graal и truffle, так как реализовывать новые фичи из js мира достаточно ресурсоёмко, реализовывать с помощью truffle оказалось намного проще.
Помню как после этой статьи в 2018 мы обсуждали это на каком-то митапе, и общий настрой был в том что, ты че крейзи, никто не будет запускать богомерзкий джаваскрипт под святой джавой, да ещё и фронтенд какой-то. А вот как оно повернулось.
Жду теперь реализации другой хотелки: мини-приложений (в стиле Amazon Lambda), компилируемых с помощью Native Image
В 2006 существовал JavaScript.
тот пример долгого старта, что там указан, больше похож на запуск с недостаточным количеством памяти — для jvm в таком случае характерно пытаться непрерывно собирать мусор, что практически почти останавливает выполнение любой программы. На это часто напарываются начинающие пользователи JVM. Для пользователя, конечно, было бы удобнее увидеть нормальное сообщение, что не хватает памяти — но это больше вопрос не к graal, а к эргономике JVM.
Ну в случае с GraalVM, таки долгий прогрев имеет место быть. Причём сильно дольше, чем у хотспота.
В профильном чатике телеграмма много экспериментировали на эту тему. В некоторых тестах прогрев получался в разы дольше хотспотовского.
Не будет ли конфликта, когда рендеринг на клиенте будет отличаться от того что нарендерила джава.
Чтобы следить за этим в реакте во время гидрации идет сравнение то, что пришло с сервера с тем, что воссоздал клиент. И, если есть расхождения, в дев моде сообщает об этом.
Новый фронтенд Одноклассников: запуск React в Java. Часть I