Да, обсуждали сходство в комментах к моему посту. Непонятен только вес рантайма для сервер-сайд режима. Если он весит мегабайты как Vaadin, то это не имеет особого смысла. Королев специально сделан так чтобы весить минимально.
Если речь о тестах проверяющих сам Королев, то нет, не до конца. Работает через раз. Выглядит так будто сервер проглатывает события. Я бы грешил на сам Королев, но есть тесты производительности/корректности, которые работают по реальному "накликаному" логу событий и там 100% детерминизм даже под дикой нагрузкой (т.е. события таки не проглатываются). Возможно проблема в Sauce Connect Proxy. Надо садиться и дебажить, а времени особо нет.
Действительно. Судя по этой статье разработчики Blazor идут по очень похожему пути что я с королевым.
However, the design of the Blazor framework is smart and flexible enough to run the application separate from rendering process. For example, we can run Blazor in a web worker thread separately from UI thread.
Я делал такое на Scala.js в 2014 https://medium.com/@yelbota/-18195d44f574 Потом мне в голову пришла идея, что то что крутится в веб-воркере может крутиться на сервере. Я совместил это с идеями React/Redux так и получился Korolev.
Running .NET code inside web browsers is made possible by WebAssembly (abbreviated wasm). WebAssembly is an open web standard and supported in web browsers without plugins. WebAssembly is a compact bytecode format optimized for fast download and maximum execution speed.
Вес клиентской части все же достаточно большой, не смотря на то что компоненты управляются с сервера. Королев не грузит ничего дополнительного, если сам программист этого не захотел. 6 Кбайт несжатого JS достаточно для работы.
Из этой статьи не очевидно как реализовать подобное Королеву. Судя по документации ReactDOMServer это и не предполагается. Чтобы работало как в Королеве нужен метод который будет рендерить в список событий для отправки по веб-сокету. При чем он должен выдавать только изменения. Опять же на стороне клиента должен быть механизм, который такие списки будет обрабатывать.
Во-первых, на сколько я понимаю, React не позволяет обрабатывать события на сервере, а предлагает только рендер начального состояния. Во-вторых React 16 вышел на год позже Королева. Хотя в любом случае изобретение не мое. Ниже в комментариях есть ссылка на проект с подобной философией для языка Erlang.
Подобная идея давно имеет реализация в erlang n2o (можно сделать интерактивное приложение без знаний js)
Да, n2o один из источников вдохновения. При всей нелюбви к Максу Сохацкому лично, надо отдать ему должное: в своей работе он воплощает то каким софт должен быть на мой взгляд. В Королеве несколько другой подход к работке.
Вообще не понимаю почему нельзя совмещать для скажем «JS-анимаций» и набором «фиксированных» библиотек для «интерактивности».
Можно. В Королеве для этого предлагается использовать веб-компоненты.
В такой постановке это ни о чём не говорит. Может у вас на каждый клик там два байта обновлений;
На каждый клик сравнение двух версий виртуального DOM. 1 млн. CCU это чудовищно много. Такие показатели бывают только у супер-разрекламированных онлайн-игр на запуске. Представим что нормальный сервак держит 10000 CCU. Если уж у вашего сервиса такая популярность, то купить 100 серверов не большая проблема.
Ну и к чему тогда у вас там сарказм про глупых фронтэндеров
Это не сарказм, а реальное положение дел. В начале пилит Вася, потом к нему присоединяются Петя с Колей, потом Вася увольняется и пошло-поехало. К сожалению разработка выстроена не всегда грамотно. Особенно в стартапах.
У вас тоже — оп, и стало два.
Использовать Королев и Реакт совместно довольно проблемно.
Проблем с этим нет — просто платите за это полностью вы. Виртуальные сервера в облаках не бесплатны.
Кто-то должен платить. По вашему будет лучше, если заплатить пользователь? Почему мы продолжаем делать веб на PHP, Ruby, Python, а не перейдем, на пример на Rust чтобы платить еще меньше?
Проблем с этим нет — просто платите за это полностью вы. Виртуальные сервера в облаках не бесплатны. «Тупой» тонкий слой бэка, собирающий что-то там из базы или из нижележащих сервисов, и бэк, который рисует всем их DOM — это совсем разные вычислительные нагрузки.
Надо замерять. Невозможно сравнить Королев и условный веб-сервер собирающий JSON. Синтетические тесты показывают, что тот самый дохлый макбук 2013 года прекрасно держит 500 одновременных пользователей, которые раз в секунду что-нибудь кликают.
Следующий нюанс — работа с БД напрямую. Для маленьких приложений, это может быть и сработает. Но такой фокус не пройдет в более сложном приложении. Как пример, банковский софт, где что бы отдать небольшой JSON к клиенту, происходит сборка онного с разных микросервисов или баз данных плюс куча куч проверок и обработок.
О том и разговор. Можно ходить к БД на прямую, к очереди напрямую, к микросервисам напрямую и так далее.
За гибкость мы платим ограничениями. Только вот клиент платит деньгами, а менеджеру глубоко до фени все вкусности и красивости.
Кто знает? Может быть клиент готов платить за софт который не тормозит и не выжирает всю память, а менеджер просто не в курсе что так можно было?
На мой взгляд с масштабируемостью серверных мощностей как раз таки проблем нет. У есть есть виртуальные сервера в облаках и мы можем динамически добавлять серверные мощности в случае наплыва пользователь. Достаточно, чтобы сервис умел масштабироваться горизонтально. С другой стороны повлиять на конечное устройство мы не можем. Оно может быть медленным, устаревшим, завирусованым и так далее. Чем слабее мы его нагрузим, тем лучше.
Под «рендерить» подразумевается отображение бизнес-данных в браузерный DOM. Рендерингом картинки конечно же занимается браузер, который прекрасно знает о конечном устройстве.
Никто ни вчем не виноват. Поясню на примере. Есть программист который пишет программы под специальные промышленные восьмибитные процессоры, в которых самый минимальный набор инструкций. Созданы они были 20 лет назад и до сих пор всех устраивают. Этот программист пишет замечательные программы на ассемблере для этого процессора, которые не тормозят, не текут, работают годами без сбоев. Более того, когда этим летом, на практику к нему пришли стажеры из университета, они без труда поняли код прошивок, которые он написал. Что тут можно сказать? Это замечательный программист, великолепно знающий свою область, обладающий системным мышлением, думающий о коллегах и о цели своей работы. Однако ему будет не о чем говорить на конференции. Зачем же ему ехать?
Я специально утрирую, потому что разработка для микроконтроллеров не лишена романтики. В глубине души, любому разработчику хочется программировать огромные станки и космические корабли, и все равно на чем. Но в действительности в этой теме нет ничего интересного для современных разработчиков. Ассемблер, он и в Африке ассемблер.
Или другой пример. Вот допустим дикий негр из племени мумба-юмба. Может быть он отличный человек, и даже прогрессивный по меркам своего племени. На пример считает, что нет особых отличий между поеданием сердца врага и его задницы: сил одинаково прибавляет. В племени его за это считают чудаком, а некоторые заявляют, мол больно умный. Будет ли интересно с ним пообщаться?
Да, обсуждали сходство в комментах к моему посту. Непонятен только вес рантайма для сервер-сайд режима. Если он весит мегабайты как Vaadin, то это не имеет особого смысла. Королев специально сделан так чтобы весить минимально.
Если речь о тестах проверяющих сам Королев, то нет, не до конца. Работает через раз. Выглядит так будто сервер проглатывает события. Я бы грешил на сам Королев, но есть тесты производительности/корректности, которые работают по реальному "накликаному" логу событий и там 100% детерминизм даже под дикой нагрузкой (т.е. события таки не проглатываются). Возможно проблема в Sauce Connect Proxy. Надо садиться и дебажить, а времени особо нет.
То есть игра с анимациями и вот этим всем Вас не убеждает?
Действительно. Судя по этой статье разработчики Blazor идут по очень похожему пути что я с королевым.
Я делал такое на Scala.js в 2014 https://medium.com/@yelbota/-18195d44f574 Потом мне в голову пришла идея, что то что крутится в веб-воркере может крутиться на сервере. Я совместил это с идеями React/Redux так и получился Korolev.
Судя по описанию Blazor больше похоже на Vaadin.
Вес клиентской части все же достаточно большой, не смотря на то что компоненты управляются с сервера. Королев не грузит ничего дополнительного, если сам программист этого не захотел. 6 Кбайт несжатого JS достаточно для работы.
А без интернета не работает вовсе!
Для интеграции JS предлагается использовать веб-компоненты. Типичный пример — карты.
Но пользователь этого не заметит.
Из этой статьи не очевидно как реализовать подобное Королеву. Судя по документации ReactDOMServer это и не предполагается. Чтобы работало как в Королеве нужен метод который будет рендерить в список событий для отправки по веб-сокету. При чем он должен выдавать только изменения. Опять же на стороне клиента должен быть механизм, который такие списки будет обрабатывать.
1) Круто! Можно ссылку на пример?
Во-первых, на сколько я понимаю, React не позволяет обрабатывать события на сервере, а предлагает только рендер начального состояния. Во-вторых React 16 вышел на год позже Королева. Хотя в любом случае изобретение не мое. Ниже в комментариях есть ссылка на проект с подобной философией для языка Erlang.
Да, n2o один из источников вдохновения. При всей нелюбви к Максу Сохацкому лично, надо отдать ему должное: в своей работе он воплощает то каким софт должен быть на мой взгляд. В Королеве несколько другой подход к работке.
Можно. В Королеве для этого предлагается использовать веб-компоненты.
королев, Королев, Королёв, Korolev, korolev. Как Вам угодно :)
На каждый клик сравнение двух версий виртуального DOM. 1 млн. CCU это чудовищно много. Такие показатели бывают только у супер-разрекламированных онлайн-игр на запуске. Представим что нормальный сервак держит 10000 CCU. Если уж у вашего сервиса такая популярность, то купить 100 серверов не большая проблема.
Это не сарказм, а реальное положение дел. В начале пилит Вася, потом к нему присоединяются Петя с Колей, потом Вася увольняется и пошло-поехало. К сожалению разработка выстроена не всегда грамотно. Особенно в стартапах.
Использовать Королев и Реакт совместно довольно проблемно.
Кто-то должен платить. По вашему будет лучше, если заплатить пользователь? Почему мы продолжаем делать веб на PHP, Ruby, Python, а не перейдем, на пример на Rust чтобы платить еще меньше?
Надо замерять. Невозможно сравнить Королев и условный веб-сервер собирающий JSON. Синтетические тесты показывают, что тот самый дохлый макбук 2013 года прекрасно держит 500 одновременных пользователей, которые раз в секунду что-нибудь кликают.
О том и разговор. Можно ходить к БД на прямую, к очереди напрямую, к микросервисам напрямую и так далее.
Кто знает? Может быть клиент готов платить за софт который не тормозит и не выжирает всю память, а менеджер просто не в курсе что так можно было?
Под «рендерить» подразумевается отображение бизнес-данных в браузерный DOM. Рендерингом картинки конечно же занимается браузер, который прекрасно знает о конечном устройстве.
Я специально утрирую, потому что разработка для микроконтроллеров не лишена романтики. В глубине души, любому разработчику хочется программировать огромные станки и космические корабли, и все равно на чем. Но в действительности в этой теме нет ничего интересного для современных разработчиков. Ассемблер, он и в Африке ассемблер.
Или другой пример. Вот допустим дикий негр из племени мумба-юмба. Может быть он отличный человек, и даже прогрессивный по меркам своего племени. На пример считает, что нет особых отличий между поеданием сердца врага и его задницы: сил одинаково прибавляет. В племени его за это считают чудаком, а некоторые заявляют, мол больно умный. Будет ли интересно с ним пообщаться?