А почему глобальная точка входа должна быть одна? Зачем всю систему завязывать на один элемент? Как потом разбираться какой код можно выбросить? Как оченить степень последствий при изменениях?
Да, там немножко надо подпиливать напильником, но при учете не слишком частой необходимости вообще подключения новой бибилиотеки, это вполне можно потерпеть.
С этим у Kotlin плохо, но есть одно но: сконвретировать TypeScript в Kotlin очень просто, так что «куча типов для уже известных js библиотек» есть и у Kotlin с небольшой платой.
Во-первых, Koltin я поставил в тот же ряд. Во-вторых, я так и не понял зачем использовать redux и RxJs при работе с React. RxJs вполне перекрывается корутинами или async/await. Redux вносит глобальное состояние, что просто зло ИМХО.
Я знаю, что эта гибкость сделана для постепенной миграции и это плюс. Но это же и минус при поддержке (не помню чтобы где-либо встречал гибкость без увеличения сложности). Кроме того, если кто-то делает миграцию, то явно не просто так, он хочет получить плюшки, которых он не получит, пока не доведет миграцию до конца, т.е. заплатив всё туже полную цену.
И никто не заставляет переписывать весь проект целиком. Я не пробовал серьезных сочетаний, но, кажется, это ничем не отличается от TypeScript и JS в одном проекте.
Которого нет в Kotlin варианте. А вместе с ним нет никаких ограничений что код, а что не код.
Я уже упоминал, что сторогость компиляции TypeScript зависит от конфигов, что означает, что и сам код зависит от этих конфигов (наверно, очень весело поддерживать одновренно два проекта на TypeScript с разными конфигами, у меня один, слава богу). Код зависит от того, какой ES подключен (набор разрешенных конструкций, насколько я понял). Т.е. чтобы понять что и как ты можешь писать сейчас, надо знать настройки конкретного проекта. В случае Kotlin у тебя всегда полная реализация языка без каких-либо допущений и подкручиваний.
я использую сочетание gradlew --continuous и webpack-dev-server, так что изменения подхватываются автоматически. Обновление при это, действительно, в районе 30 секунд. Возможно, это можно ускорить, не пробовал. Для меня это приемлемое время, особенно по сравнению с jsf, где на каждый чих надо перезапускать сервер. При этом в большинстве случаев мне не надо сразу смотреть результат, а когда надо, то результат уже обновлен. Кроме того, ребята из JetBrains посмотянно тюнят компилятор, когда-нибудь оно само ускорится
С Babel всё-равно придется иметь дело в любом случае, потому что он отвечает за то, чтобы ( ) превратился в React компонент. Наверно, все к этому привыкли и не замечают (хотя там даже для использования обычного JS надо {} писать).
Внутренние объекты как есть передаются на отрисовку и где-то очень далеко после уже используются. И если проверки не было бы, то мне пришлось проверять весь код до того места, потому что я воплне мог накосячить в js части
И никто не заставляет переписывать весь проект целиком. Я не пробовал серьезных сочетаний, но, кажется, это ничем не отличается от TypeScript и JS в одном проекте.
Которого нет в Kotlin варианте. А вместе с ним нет никаких ограничений что код, а что не код.
Я уже упоминал, что сторогость компиляции TypeScript зависит от конфигов, что означает, что и сам код зависит от этих конфигов (наверно, очень весело поддерживать одновренно два проекта на TypeScript с разными конфигами, у меня один, слава богу). Код зависит от того, какой ES подключен (набор разрешенных конструкций, насколько я понял). Т.е. чтобы понять что и как ты можешь писать сейчас, надо знать настройки конкретного проекта. В случае Kotlin у тебя всегда полная реализация языка без каких-либо допущений и подкручиваний.
JS — 83kb
Kotlin — 139kb
Теперь разыв не в ~2, а ~1.5 раза
JS — 375kb
Kotlin — 752kb
JS — 3.5mb
Kotlin — 5.4mb
Внутренние объекты как есть передаются на отрисовку и где-то очень далеко после уже используются. И если проверки не было бы, то мне пришлось проверять весь код до того места, потому что я воплне мог накосячить в js части
Валидность второго — вопрос, конечно, спорный