Нельзя просто взять и распечатать страницу написанную на React: есть разделители страниц, поля для ввода. Кроме того, хочется один раз написать рендеринг, чтобы он генерил как ReactDom, так и обычный HTML, который можно сконвертить в PDF.

Самое сложное, что у React свой dsl, а у html свой. Как решить эту проблему? Написать ещё один!

Чуть не забыл, всё это будет написано на Kotlin, так что, на самом деле, это статья о Kotlin dsl.

Мысль перевести фронт на какой-либо js фреймворк появилась одновременно с возможностью писать React на Kotlin. И я решил попробовать. Основная проблема: мало материалов и примеров (постараюсь эту ситуацию поправить). Зато у меня полноценная типизация, безбоязненный рефакторинг, все возможности Kotlin, а главное, общий код для бека на JVM и фронта на Javascript.

В этой статье будем писать страницу на Javasript + React параллельно с её аналогом на Kotlin + React. Чтобы сравнение было честным, я добавил в Javasript типизацию.

Java позволяет писать последовательный, параллельный и асинхронный код. Асинхронный — это когда регистрируется callback, который запустится после какого-либо события (например, файл прочитан). Это позволяет избежать блокировки потока, но ломает последовательность выполнения, так что на java пишут такой код скорее когда нет других вариантов. Kotlin даёт решение — корутины, с ними асинхронный код выглядит почти так же, как последовательный.

По корутинам мало статей. Конкретных примеров, показывающих их преимущества — ещё меньше.

Что нашёл:

• Избавление от callback hell. Актуально для UI
• Понравились концепции channels и actors. Они не новы, можно и без них, но для event систем должны очень хорошо подойти
• Совет от Романа Елизарова: «Корутины нужны для асинхронных задач, которые ожидают чего-либо большую часть времени»

Последнее интересно — большинство enterprise приложений всё время что-нибудь ждут: БД, другие приложения, изредка и файл нужно прочесть. И всё это может быть полностью асинхронным, а значит всё приложение можно перевести на асинхронную обработку запросов.

Итак, посмотрим как ведут себя корутины под нагрузкой.

В прошлой части я рассказывал о подводных камнях Kotlin, в этой я расскажу что их перевешивает.

Меня несколько раз спрашивали, а что же такого в Kotlin, что могло бы сподвигнуть на переход с Java, в чем его фишка? Да, Kotlin привнес Null-safety и большое количество синтакcического сахара, закрыл часть слабых мест Java. Но это не становится поводом для перехода. Что может стать? Новые возможности и новая философия.

Написано довольно много статей о Kotlin, но об его использовании в реальных проектах – единицы. В особенности, Kotlin часто хвалят, поэтому я буду говорить о проблемах.

Сразу оговорюсь: я ничуть не жалею об использовании Kotlin и всем его рекомендую. Однако хочется предупредить о некоторых подводных камнях.