Комментарии 16
Поскольку код, отвечающий на события, выполняется на сервере, может возникнуть небольшая задержка между действием, вызывающим событие, и любыми изменениями в DOM, вызванными обработчиком событий. Это была обычная жалоба на предыдущие серверные веб-фреймворки, такие как Vaadin, что препятствовало их внедрению.
Сейчас есть Vaadin Fusion, где фронт можно писать на TypeScript, причем можно комбинировать обычный Vaadin и Vaadin Fusion, соответственно критичные по производительности участки можно не на стороне сервера обрабатывать, а на клиенте. А можно вообще всё на Vaadin Fusion написать если не нужен SSR, короче очень удобно.
Но Kotlin как язык банально лучше Java. И писать на нем по ощущениям большинству попробовавших программистов приятнее. Да и для DSL Kotlin лучше подходит, а тут у нас как раз HTML-подобный DSL.
Самое главное что меня отталкивает в котлине это его неясное будущее, например есть такая проблема:
Что-то, чего в Java раньше не было, но теперь появилось. Если Kotlin очень повезло, то в Java это сделали достаточно похоже, и разработчику в процессе переучивания с Java на Kotlin это не создаёт проблем. Но что, если это не так?
со временем всё больше и больше фич Kotlin будут попадать под эту проблему, и поэтому подход «как Java, только лучше» — обречён
Ну и ещё конечно других проблем хватает в котлине, так что насчёт того что "котлин банально лучше джавы" я бы поспорил.
Автор этой статьи путает причину со следствием)
Наоборот, это Java отчаянно пытается догнать Kotlin, но не догонит, так как несет груз обратной совместимости и новые возможности прибиваются страшными синтаксическими костылями.
Мне почему-то покойный ASP.NET вспомнился (который еще без MVC). Главный девиз программистов всех времен и народов: зачем изучать чужие велосипеды, если можно изобрести свой собственный, с блекджеком и ... (сюда вписать любимую игрушку)?!!! :)
Подскажите, а делали сравнение с https://github.com/Kotlin/kotlinx.html ?
ul {
li().text("One")
li().text("Two")
}
Правильно ли я понимаю, при необходимости поправить вёрстку, надо залезть в код Котлина, поправить, и скомпилировать?
Создание полнофункциональных веб- приложений обычно требует навигации по ужасной экосистеме Javascript, выбора между огромным множеством инструментов, транспиляторов, минификаторов, специалистов по сопровождению состояния и т.д., Большинство из которых устареют через 6 месяцев.
Что в ней такого ужасного? Разве плохо, что появляются новые инструменты и платформа развивается? "устаревают" – что устаревает-то? Фреймворки React/Vue/Angular и популярные тулы по типу Redux/Vuex или сборщики (Webpack) живут себе годами. И ничто вам не мешает их использовать. Если выйдет новая версия, никто не заставит вас сразу же на нее обновляться.
Этот простой пример уже показывает некоторые важные особенности Kweb:
* Установить и запустить веб-сайт очень просто, не нужно возиться с сервлетами или сторонними веб-серверами.
* Ваш код Kweb будет примерно отражать структуру генерируемого HTML-кода.
Чем это лучше аналогичных примеров на других языках программирования? Например, на Go https://tproger.ru/translations/go-web-server/ или Node.js https://expressjs.com/ru/starter/hello-world.html ?
Затем вы сталкиваетесь с взаимодействием между клиентом и сервером, что представляет собой совершенно другой мир боли.
KWeb исправляет это.
Современные веб-сайты состоят как минимум из двух тесно связанных компонентов, один из которых работает в браузере, а другой — на сервере. Они часто написаны на разных языках программирования и должны связываться друг с другом через HTTP-соединение.
Цель Kweb — устранить это разделение сервера и браузера, чтобы архитектура вашего веб-приложения определялась решаемой проблемой, а не ограничениями современных инструментов.
Какая конкретно боль между взаимодействием клиента и сервера? Что плохого в разделении на клиента и сервера (один из принципов REST, между прочим).
Слабо себе представляю бекендера, который будет писать фронтовую логику, HTML и стили (если приложение больше, чем обычный TO DO list).
Фронту для этого придется учить котлин и делать исправления на бекенде?
Как вы потом искать людей будете под такой стек?
Это перевод. Автор фреймворка вас не услышит :-).
Чем это лучше аналогичных примеров на других языках программирования? Например, на Go https://tproger.ru/translations/go-web-server/ или Node.js https://expressjs.com/ru/starter/hello-world.html ?
Ничем. Фреймвор для тех, кто хочет писать на Котлине.
Какая конкретно боль между взаимодействием клиента и сервера? Что плохого в разделении на клиента и сервера (один из принципов REST, между прочим).
Тоже ничего плохого. Но в некоторых случаях я предпочел бы писать бакенд и фронтенд на одном языке, не заморачиваясь взаимодействием фронтенда и бакенда.
Как вы потом искать людей будете под такой стек?
Подойдет любой Kotlin программист. Или Java программист с небольшим периодом адаптации. И такой стек в отличие от JS будет стабильно актуален еще с десяток лет, в отличие от "прогрессивного" мира JS, где фреймворки и инструменты сменяют друг друга каждые полгода.
Интересная идея серверного рендеринга, однако к сожалению, годится только для небольших автономных веб страничек. Уже давно пишу на Vaadin бизнес приложения, и идея серверного state management-а на порядки упрощает разработку, позволяя ограничиться только одной платформой/языком и убирая рудиментарную прослойку ввиду API.
Но проблема в том, что в современном фронтэнде сложно ограничиться только библиотекой стилей и виджетов -- так или иначе потребуется интеграция с мощной экосистемой JS. Это было основным и правильным решением для Vaadin Flow: теперь там можно достаточно просто интегрировать JS-библиотеки, при этом не теряя возможности серверного state-management-а.
Спасибо! А главное, это очень удобно для бекенд разработчиков. Написал логику и быстро в том-же сервисе прикрутил UI (как я понимаю библиотека стилей в комплекте даст возможность не тратиться на дизайн).
Kweb — Облегченный веб-фреймворк Kotlin для backend-разработчиков