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

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

Какая версия GraalVM используется? CE или EE?
CE
Что удалось сделать

  • Запустить JavaScript на сервере в Java мире Одноклассников.
  • Сделать изоморфный код для UI.
  • Использовать современный стек, который знают все фронтендеры.
  • Создать общую платформу и единый подход для написания UI.
  • Начать плавный переход, не усложнив при этом эксплуатацию и не замедлив серверный рендеринг.



И ни слова о том, насколько ускорился или замедлился фронтенд непосредственно на «фронте», то есть в браузерах у посетителей. В итоге ожидаем (но не факт) тормозные «Одноклассники». Хотя, впрочем, целевая аудитория ресурса достаточно нетороплива, так что на производительность можно и забить. Действительно, зачем.
Это вторая часть статьи. Большинство про Java в первой. Также тут есть пример с получением текста через Java.
Очень порадовал момент, когда увидел в архитектуре MobX, приходит свет в наш мир, да простят меня redux адепты! которые утверждают что большие проекты можно строить только на redux, добавил в копилку еще один проект на который можно ссылаться. Спасибо!

Вы бросили достойный вызов легаси. Могу пожелать терпения и удачи.


В рамках эксперимента, нашей команде была поставлена обратная задача — запустить java(апплет) приложение в браузере (разумеется никак апплет, а как js приложение. В апплете более 5тыс классов, свой LookAndFeel, Swing и прочие вещи. В это трудно поверить, но с помощью CheerpJ и 2 напильников нам удалось за 2 дня достичь успеха в этом деле.


По проделанной Вами работы, хочется понять в целом — это разумно js под граалем запускать?

Уже больше года развиваем это решение. Пока кажется разумным

Подход к миграции очень похож на Frankenstein migration (https://youtu.be/CaP5eAylYpI)
Скажите, вы опирались как-то на это выступление или сами тоже пришли к подобному способу миграции?

Мы придумали все за год до этого выступления, опираясь только на свою ситуацию, Я, когда слушал его на холи, был весьма удивлен. ))
А что удивительного? Такое в той или иной степени было возможно давно. Ну наверное неполноценно, но два javascript движка были практически всегда — сначала Rhino, потом Nashorn. И я похожие вещи, только поменьше масштабом, не только видел, но и делал.

Ну т.е. идея-то давно носилась в воздухе. У оракла даже был другой проект по запуску Node в JVM (успешно заглох).
Удивительно было, что я как раз доклад про это готовил, а Денис всю концепцию почти моими словами рассказал ) Я даже расстроился немного тогда.
Согласен, что сама идея не нова. Вопрос в реализации.
И разница в том, что у нас это уже работающая история на огромном проекте.
Тут скорее не про всю миграцию, а про миграцию фронтенда через инкапсуляцию «модных» технологий внутрь веб-компонентов. Именно об этом Денис рассказывал на Holy/JS, и часть про миграцию компонентов — очень похожа на эту концепцию.
Насколько я понимаю, речь ведь так или иначе о том, чтобы на бэкенде запустить некий javascript код, который что-то сделает, вместо того чтобы этим грузить браузер? Ну, или сделать так, чтобы этот код выполнялся где попало, где удобнее прямо сейчас?
Не хочется повторять задачу тут.
Рекомендую ознакомиться с первой частью, где об этом подробно описано
habr.com/ru/company/odnoklassniki/blog/480808
По смыслу да. У него были только веб-компоненты и клиент. А у нас еще и сервер.
Например, для календаря в атрибутах всего лишь выделенная дата, а в store уже матрица с полной информацией за месяц. Очевидно, что ее бессмысленно передавать с сервера.

Вроде бы, считается хорошей практикой хранить нормализованные данные в сторе, а вычисляемые значения считать селекторами (термин из мира redux — но наверняка в modx что-то подобное есть) на лету.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий