Comments 44
После работы с GWT теперь каждый раз, когда слышу про идею делать фронт на Java, у меня начинает дергаться глаз.
Может, проблема не в том, что Java для написания фронта плоха, а в том, что плох GWT?
Случай с GWT — это прям шампунь и кондиционер в одном флаконе, т.е. и GWT плох и Java тоже не радует. Тут стоит пояснить почему Java — не самый лучший вариант. Помимо того, что она оочень многословна, она еще и далека от JavaScript по синтаксису. И вроде бы что тут плохого, вы ведь не хотим знать JS? А придется. Рано или поздно придется лезть в отладку и смотреть что происходит под капотом.
Поэтому зашел TypeScript и пока не сильно заходят Kotlin и ScalaJs (но тут, по крайней мере, потенциально есть языковые плюшки). Помимо этого, тулинг и процесс разработки на JS сильно вырос по сравнению с тем временем, когда стартовал GWT. И применительно к фронту, он стал гораздо проще чем на Java. И тут сложно что-то сделать, т.к. всегда будут накладные расходы на получение JS из Java. Разве что, c взлетом WebAssembly что-то поменяется, но и тогда я бы взял лучше Котлин.
Поэтому зашел TypeScript и пока не сильно заходят Kotlin и ScalaJs (но тут, по крайней мере, потенциально есть языковые плюшки). Помимо этого, тулинг и процесс разработки на JS сильно вырос по сравнению с тем временем, когда стартовал GWT. И применительно к фронту, он стал гораздо проще чем на Java. И тут сложно что-то сделать, т.к. всегда будут накладные расходы на получение JS из Java. Разве что, c взлетом WebAssembly что-то поменяется, но и тогда я бы взял лучше Котлин.
Помимо того, что она оочень многословна
Думаю, что для тех, кому Java очень многословна, она и на бэкэнде не нужна. Есть полно других языков, которые менее многословны. Думаю, что те, кто выбирают Java, выбирают её не за краткость. Вот, например, лично мне "многословность" Java не мешает. Всё равно львиная доля времени уходит на обдумывание задачи, уточнение требований, отладку, тестирование. А код IDE помогает писать. И аргумент с тем, что более краткий код является более лаконичным, тоже сомнительный. Вспомним языки J и K. Очень читабельный на них код?
она еще и далека от JavaScript по синтаксису.
Java, например, очень далека по синтаксису от систем команд x86/x64 и ARM. Разве это кому-то мешает писать бэкэнд и мобильные приложения на ней и потом давать на откуп JVM или ART трансляцию эти платформы?
И вроде бы что тут плохого, вы ведь не хотим знать JS? А придется. Рано или поздно придется лезть в отладку и смотреть что происходит под капотом.
Отладку какую? В браузер с source maps или прямо в сгенерированный JS? С первым чем это отличатся от просто подебажить Java в IDE? Второе — ну это как дизассемблировать. Такое редко но делают, в основном, когда натыкаются на баги в JVM, и хотят сами разобраться в деталях вместо того, чтобы сразу писать багрепорт.
Разве что, c взлетом WebAssembly что-то поменяется
А что поменяется? Вместо относительно понятного JS будет генериться совсем низкоуровневый код, похожий на ту же систему команд процессора. Как раз в этом смысле генерация JS даже выигрывает.
Сама по себе многословность не основная проблема, да, это дело вкуса. Но часто, например на бэке вариантов сменить язык нет по разным причинам, там Java пока что стандарт.
Кусок страницы, которая рисуется динамически, не отображается или отображается некорректно или в одном браузере норм, в другом — нет. И вот начинаются танцы с браузером, который работает с JS.
JS станет не главным языком, на котором все крутится, а «одним из», на равных условиях. Вот тогда ваша аналогия с x86/x64 будет уместна, ну и неизбежно в браузерах появятся средства отладки не привязанные к языку (сейчас что-то есть, но не в том объеме).
Отладку какую?
Кусок страницы, которая рисуется динамически, не отображается или отображается некорректно или в одном браузере норм, в другом — нет. И вот начинаются танцы с браузером, который работает с JS.
Вместо относительно понятного JS будет генериться совсем низкоуровневый код, похожий на ту же систему команд процессора.
JS станет не главным языком, на котором все крутится, а «одним из», на равных условиях. Вот тогда ваша аналогия с x86/x64 будет уместна, ну и неизбежно в браузерах появятся средства отладки не привязанные к языку (сейчас что-то есть, но не в том объеме).
Кусок страницы, которая рисуется динамически, не отображается или отображается некорректно или в одном браузере норм, в другом — нет.
Помню, такое бывало в далёком 2008-м. Но в 2018-м? Первый раз слышу. К тому же, опять приведу аналогию с нативным миром — это всё равно, что забиндить к Java через JNI какой-нибудь GTK, и потом пересесть на C, только потому, что приходится в процессе разбираться с устройством этого GTK, который написан на C.
И вот начинаются танцы с браузером, который работает с JS.
Ну так JSNI/JSInterop позволяет взять и писать на JS. Это же небольшое количество нативного кода. Помню, сам в проекте на 200К строк Java-кода понаставил несколько грязных хаков на JSNI (это в далёком 2014-м, когда корпоративные клиенты всё ещё сидели на IE8), но в совокупности их там и на 200 строк не набралось бы.
JS станет не главным языком, на котором все крутится, а «одним из», на равных условиях. Вот тогда ваша аналогия с x86/x64 будет уместна, ну и неизбежно в браузерах появятся средства отладки не привязанные к языку (сейчас что-то есть, но не в том объеме).
Что-то не разделяю я вашего оптимизма. Как разработчики браузеров не сделали нормальных тулов для транспайлеров, так они и для компиляторов в wasm ничего не сделают. Вроде уже года полтора как зарелизили MVP, но до сих пор по дебагу ничего нет, кроме весьма куцых сорсмапов.
>Java — не самый лучший вариант. Помимо того, что она оочень многословна
Какие альтернативы? Только прошу, не предлагайте Котлин, уже не смешно.
>она еще и далека от JavaScript по синтаксису
Вы следите за развитием ECMAScript и современным фронтендом, чтобы так утверждать? С 2010 года очень многое поменялось на фронтенде, если что.
>накладные расходы на получение JS из Java
Нет этих расходов, по крайне-мере они не меньше и не больше, чем получение JS из TypeScript. Другой вопрос, что GWT не умеет это делать правильно. Но, тогда повторю выше обозначенный вопрос, причём тут Java?
Какие альтернативы? Только прошу, не предлагайте Котлин, уже не смешно.
>она еще и далека от JavaScript по синтаксису
Вы следите за развитием ECMAScript и современным фронтендом, чтобы так утверждать? С 2010 года очень многое поменялось на фронтенде, если что.
>накладные расходы на получение JS из Java
Нет этих расходов, по крайне-мере они не меньше и не больше, чем получение JS из TypeScript. Другой вопрос, что GWT не умеет это делать правильно. Но, тогда повторю выше обозначенный вопрос, причём тут Java?
Какие альтернативы? Только прошу, не предлагайте Котлин, уже не смешно.
Я бы не брал никаких альтернатив, а брал бы именно JavaScript. Только не надо говорить про строгую типизацию, уже не смешно (мне понравилась ваша аргументация). Ну если непременно хочется альтернатив, то TypeScript и на совсем крайний вариант Котлин.
С 2010 года очень многое поменялось на фронтенде, если что.
Разумеется, в 2010 я был за GWT обеими руками, а сейчас вот нет.
Другой вопрос, что GWT не умеет это делать правильно.
Покажите мне кто на Java делает это правильно, а заодно быстро и удобно.
>Только не надо говорить про строгую типизацию
Извините, но мы тут в топике про статическую типизацию, GWT и вот это всё, не распиваем смузи с другими бородачами падкие на всё блестящее и модное?
>Ну если непременно хочется альтернатив, то TypeScript
Вы серьёзно предлагаете писать бекенд на TypeScript? Я полагаю вы понимаете, что сегодня заканчивается 2018 год и до людей начинает доходить преимущества единой кодовой базы? Изоморфные фреймворки, не?
>крайний вариант Котлин
А вы случайно за груви не топили, когда он был в трендах? CoffeeScript может использовали? Нет, делайте свои пет проекты на чём хотите, я не осуждаю.
Но я думал мы говорим о долгосрочных проектах, где исполнитель, не избалованный ребёнок, из-за которого нужно заново всё переписывать, а заказчик не корпорация типа Твиттера, готовая оплачивать смузихлебам развлечения с модным ЯП?
>Покажите мне кто на Java делает это правильно, а заодно быстро и удобно.
В процессе. Скоро в этих ваших интернетах и на хабре в частности.
Извините, но мы тут в топике про статическую типизацию, GWT и вот это всё, не распиваем смузи с другими бородачами падкие на всё блестящее и модное?
>Ну если непременно хочется альтернатив, то TypeScript
Вы серьёзно предлагаете писать бекенд на TypeScript? Я полагаю вы понимаете, что сегодня заканчивается 2018 год и до людей начинает доходить преимущества единой кодовой базы? Изоморфные фреймворки, не?
>крайний вариант Котлин
А вы случайно за груви не топили, когда он был в трендах? CoffeeScript может использовали? Нет, делайте свои пет проекты на чём хотите, я не осуждаю.
Но я думал мы говорим о долгосрочных проектах, где исполнитель, не избалованный ребёнок, из-за которого нужно заново всё переписывать, а заказчик не корпорация типа Твиттера, готовая оплачивать смузихлебам развлечения с модным ЯП?
>Покажите мне кто на Java делает это правильно, а заодно быстро и удобно.
В процессе. Скоро в этих ваших интернетах и на хабре в частности.
мы тут в топике про статическую типизацию, GWT и вот это всё
Вы спросили что бы я выбрал, я ответил. Я серьезно считаю, что лучше фронт писать на чистом js, в котором после написания строчки браузер тут же отображает изменения (даже страницу обновлять не надо) и в дебаге ты спокойно видишь ровно то, что писал. А не долгие пересборки с последующей декомпиляцией в голове.
Вы серьёзно предлагаете писать бекенд на TypeScript?
Где я такое говорил? Я предлагал на нем писать фронт, если что. Хотя, думаю вы прекрасно поняли о чем я.
что сегодня заканчивается 2018 год и до людей начинает доходить преимущества единой кодовой базы? Изоморфные фреймворки, не?
Вы сами-то со смузи не балуетесь?
А вы случайно за груви не топили, когда он был в трендах?
Нет не топил, предлагаю встретиться где-то на хабре лет через 5 и посмотреть кто на чем будет писать.
Но я думал мы говорим о долгосрочных проектах, где исполнитель, не избалованный ребёнок,
А я думал мы говорим не о кровавом энтерпрайзе, где поменять цвет надписи в стиле занимает пару часов.
Короче, желание писать все на Java и хрен класть на все остальное — оно кажется красивым, но на практике выглядит утопично. Пишем фронт на Java с криком «нам не нужен JS», но при этом все равно вынуждены его знать. Пишем слой DAO на хибере с криком «нам не нужен SQL», но все равно вынуждены его знать и т.д.
Я серьезно считаю, что лучше фронт писать на чистом jsГода три назад я бы вас поддержал. Но сегодня я ушел дальше.
Вы сами-то со смузи не балуетесь?Нам, тут в Сибири, не до смузи )
А я думал мы говорим не о кровавом энтерпрайзе, где поменять цвет надписи в стиле занимает пару часов.Вы опять не в ту сторону. Я говорю о простых людях, малом и среднем бизнесе, которым нужно просто чтобы работало и у них нет денег на ваши развлечения с модными технологиями.
и у них нет денег на ваши развлечения с модными технологиями.
С какими модными-то? Обычный JS, куда уж проще? Фронтенд разработка это отдельная специфичная отрасль и не надо это пытаться скрыть. Искать js разработчика будет стоить гораздо дешевле (к вопросу о деньгах) чем джавера на фронт. Заменить его будет также проще, как и расширить команду и т.д.
А вы искали? Расширяли команду, чтобы вот это всё утверждать? Или думаете зачем столько транспайлеров к JavaScript напили со статической типизацией, от нечего делать?
Угу, искали. От GWT в лучшем случае воротят нос, в худшем шарахаются как от прокаженного. С JS проблем вообще никаких. Даже если кто-то не знает TypeScript, обычно не против изучить, потому что это будущее для этих людей. А GWT — прошлое и никто не хочет тратить время, связываясь с тем, что подыхает.
Понятно, мы опять пришли к вопросу — Причём тут Java? ) Нет, я согласен, что для джавы сейчас нет нормального фреймворка для фронтенда, как у TypeScript. Но я, например, работаю над этой проблемой.
Понятно, мы опять пришли к вопросу — Причём тут Java? )
При том, что у всех языков есть свое назначение. На C++ никто не пишет крупный backend в здравом уме, не потому что язык плохой, а потому, что он для другого. Тут такая же история и с Java.
Но я, например, работаю над этой проблемой.
Искренне желаю успехов
>И вроде бы что тут плохого, вы ведь не хотим знать JS? А придется. Рано или поздно придется лезть в отладку и смотреть что происходит под капотом.
Вижу с вами не всё потеряно ) Кстати, если уж быть точнее то джава не многословна, а как сказал Гослинг — у нас в джаве плохо сделаны умолчания.
Вижу с вами не всё потеряно ) Кстати, если уж быть точнее то джава не многословна, а как сказал Гослинг — у нас в джаве плохо сделаны умолчания.
если уж быть точнее то джава не многословна
Это вопрос терминологии. Умолчания ли это или многословность, результат один — дофига букв, которые не очень нужны. Именно поэтому таки добавили var и именно поэтому lombok становится таким популярным.
>добавили var
И сегодня я плююсь, когда вижу джава код с гитхаба в окне браузера. Я не против var для определенных кейсов. Но люди этого не понимают (также как вы, наверное против многословности — против, чтобы только быть против?), теперь без IDE чтение кода замедлилось, я просто не могу тут же увидеть тип переменной, нужно искать объявление метода.
И сегодня я плююсь, когда вижу джава код с гитхаба в окне браузера. Я не против var для определенных кейсов. Но люди этого не понимают (также как вы, наверное против многословности — против, чтобы только быть против?), теперь без IDE чтение кода замедлилось, я просто не могу тут же увидеть тип переменной, нужно искать объявление метода.
теперь без IDE чтение кода замедлилось, я просто не могу тут же увидеть тип переменной
Мне кажется это ваши личные трудности. Всем не угодишь.
Нет, не только мои. Здесь был топик недавно и там на это жаловались. Причём жаловались не джуны, а дяди, занимающиеся известными в узких кругах проектами. Вплоть до запрещения использования var в коде.
Джуны и мидлы не видят проблему в перспективе. Им бы только меньше букв написать, но они не понимают, что проект нужно будет поддерживать через 5 лет и через 10 лет. И чем больше времени будет уходить на чтение кода средним программистом «где меньше букфф», тем больше затрат будет нести компания.
Джуны и мидлы не видят проблему в перспективе. Им бы только меньше букв написать, но они не понимают, что проект нужно будет поддерживать через 5 лет и через 10 лет. И чем больше времени будет уходить на чтение кода средним программистом «где меньше букфф», тем больше затрат будет нести компания.
Причём жаловались не джуны, а дяди
Это старпёрство. А жаловались всегда и на все. На функциональщину в 8 Джаве, даже на for по коллекции.
Вплоть до запрещения использования var в коде.
Ну вот нормальный ход, если серьезным дядям не нравится, то пусть запрещают. А чтобы наверняка, лучше еще и не обновляться, сидеть на Java 6.
И чем больше времени будет уходить на чтение кода средним программистом «где меньше букфф», тем больше затрат будет нести компания.
Господи, вы в блокноте что ли кодите по старинке?
>lombok становится таким популярным
Ну вот, вы сами решили проблемы многословности джавы ) Зачем вам котлин? Хотя я конечно бы не рекомендовал использовать ломбок не в пет проектах… Но с другой стороны если осмелились на котлин, то тогда уж лучше ломбок )
Ну вот, вы сами решили проблемы многословности джавы ) Зачем вам котлин? Хотя я конечно бы не рекомендовал использовать ломбок не в пет проектах… Но с другой стороны если осмелились на котлин, то тогда уж лучше ломбок )
Зачем вам котлин?
Null safety, корутины. На самом деле я как писал на Java, так и пишу. Просто не понимаю, почему такой негатив к Котлину. Это не Groovy с нестрогой типизацией и не надмозгная Scala.
Хотя я конечно бы не рекомендовал использовать ломбок не в пет проектах…
Ни разу с ним проблемы не было, не пет проекты
>Null safety, корутины
Всё это есть в новых джавах, корутины в процессе. Хотя, как я понимаю, в котлине они не настоящие, а тупо эмулируются на тредах. Поэтому для джавы можно написать библиотеку и иметь такие же корутины.
>почему такой негатив к Котлину
Фрагментация. Он не даёт особых преимуществ перед джавой, но фрагментирует платформу и повышает энтропию. Тот же MapDB мог быть написан на джаве, но разработчик решил выпендриться…
Всё это есть в новых джавах, корутины в процессе. Хотя, как я понимаю, в котлине они не настоящие, а тупо эмулируются на тредах. Поэтому для джавы можно написать библиотеку и иметь такие же корутины.
>почему такой негатив к Котлину
Фрагментация. Он не даёт особых преимуществ перед джавой, но фрагментирует платформу и повышает энтропию. Тот же MapDB мог быть написан на джаве, но разработчик решил выпендриться…
Всё это есть в новых джавах
Нету даже близко. Optional ни разу не это, если что. Если интересно — kotlinlang.org/docs/reference/null-safety.html
корутины в процессе
В Java 14?
Поэтому для джавы можно написать библиотеку и иметь такие же корутины.
Да все можно, дьявол кроется в деталях, которых дофига всплывает.
Фрагментация.
Как по мне так конкуренция скорее. С появлением альтернативы на JVM, стали чаще выкатываться фичи, которые уже давно есть в других языках. Если бы не они, сейчас бы не было ни лямбд ни стримов. Гоняли бы for, зато все читабельно, даже без IDE.
Тот же MapDB мог быть написан на джаве, но разработчик решил выпендриться…
Вы контрибьютили туда что ли?
>Нету даже близко. Optional
Optional как раз «близко».
>Да все можно, дьявол кроется в деталях, которых дофига всплывает.
Я думаю такие фреймворки есть, просто я не сталкивался. Как минимум, недавно были модны фреймворки обменивающиеся иммутабельными объектами. Забыл уже как этот паттерн называется.
>С появлением альтернативы на JVM
Вот точно не с Котлин брали примеры в новую джаву. Скорее из Go и Rust, может со Скалы что-то утащили, но скорее с функциональных идей, а не с конкретной реализации.
>Вы контрибьютили туда что ли?
Нет, использовал как-то в проекте. Но оно сильно тормозило, открыл я код в Eclipse посмотреть, а там какие-то крякозябры. По итогу выкинул и поставил решение написанное на джаве (кстати, от молодого человека, которого вы выше старпером назвали). И это решение на порядки было быстрее и очень экономно кушало память, как будто на Си писанная, но всё было на джаве.
Optional как раз «близко».
>Да все можно, дьявол кроется в деталях, которых дофига всплывает.
Я думаю такие фреймворки есть, просто я не сталкивался. Как минимум, недавно были модны фреймворки обменивающиеся иммутабельными объектами. Забыл уже как этот паттерн называется.
>С появлением альтернативы на JVM
Вот точно не с Котлин брали примеры в новую джаву. Скорее из Go и Rust, может со Скалы что-то утащили, но скорее с функциональных идей, а не с конкретной реализации.
>Вы контрибьютили туда что ли?
Нет, использовал как-то в проекте. Но оно сильно тормозило, открыл я код в Eclipse посмотреть, а там какие-то крякозябры. По итогу выкинул и поставил решение написанное на джаве (кстати, от молодого человека, которого вы выше старпером назвали). И это решение на порядки было быстрее и очень экономно кушало память, как будто на Си писанная, но всё было на джаве.
Optional как раз «близко».
Нет, не близко. Optional это практически монада Option из Scala. А в Котлин притащили что-то близкое к C#
недавно были модны фреймворки обменивающиеся иммутабельными объектами
Если речь про akka, то это тоже из Scala мира и с корутинами мало чего общего имеет, разве что внутренняя реализация близка, так там по другому и не сделать.
Вот точно не с Котлин брали примеры в новую джаву
Нет не с Котлина, вы невнимательно читаете. Альтернативы — это еще и Scala (в первую очередь) и Groovy и Clojure. А функциональные идеи давно друг у друга тырят.
Но оно сильно тормозило
А если бы было на Джаве, то что автоматом летало бы что ли? Все от программиста же зависит.
от молодого человека, которого вы выше старпером назвали
Я никого старпером не обзывал, я назвал подход старперским. Запретить, не пущать.
>Разве что, c взлетом WebAssembly что-то поменяется
Поменяется всё, каждый будет пилить код на чём захочет. Я буду на джаве с openjdk, вы на котлине и все будут счастливы )
Поменяется всё, каждый будет пилить код на чём захочет. Я буду на джаве с openjdk, вы на котлине и все будут счастливы )
А чем так плох GWT? Вот пример сайт на GWT — www.friseur-termin.eu, а вот демка библиотеки (Material Design) dominokit.github.io/domino-ui-demo
На вопрос, чем плох GWT, пусть отвечают создатели GWT, которые его успешно похоронили и теперь делают J2CL. А так же многочисленные пользователи GWT, которые в нём почему-то разочаровались. Лично от себя могу добавить следующие моменты:
- Действительно, когда-то GWT имел детские болезни, вроде отсутствия инкрементальной компиляции, кривой дебаг и т.п. Сейчас это полечено.
- Морально устаревшая и кривая библиотека виджетов. Это когда весь мир сидит на реакте.
- Кривой интероп (который заменили в последних версиях на нормальный).
- Невозможность совмещать в одном проекте Java, Scala и Kotlin.
Короче, проблема номер два решалась выпиливанием старой библиотеки виджетов и написанием нормального Angular/Java (ведь написал же гугл форки для TS и Dart, чего бы Java не осилить?), а не выкидыванием всего GWT и заменой его на J2CL
Я бы не сказал, что это проблемы.
- Уже не помню с какой версии давно как летает.
- Так никто и не заставляет ее использовать. Даже в .gwt.xml отключается. Обычно хватало GwtQuery. Есть Elemental. Есть форк реакта под GWT.
- Он и сейчас кривой. В J2CL его так и оставили. Основная проблема — нет dynamic types, то есть возможности напрямую общаться с JS-объектами.
- Это все же к области экзотики. Пишите сервер на Scala/Kotlin, а API и фронт на Java.
Настоящие проблемы, которые точно также остались у J2CL:
- Отсутствие динамического доступа в JS: window.getObject("JSON").invoke("stringify", myjs) как GwtQuery. Писать типизированные обертки для каждого типа напрягает. Есть же JavaScriptObject, но нету методов для динамического доступа — идиотизм.
- Отсутствие интеграции с Node и экосистемой. Че бы J2CL не пускаться как Babel plugin?
- Как бы есть Definetly Typed. Вон в Kotline написали-таки тулзу ts2kt для генерации тайп враперов.
- Java плохой язык для декларативного программирования и DSL-ей. В нем фактически отсутствует возможность читабельно написать иерархические структуры, такие как DOM. Как выход либо прикручивается сторонний темплейтер с кучей не type-safe байндингов, либо структура городится императивно.
- В Java много специфической семантики, отличной от JS. С одной стороны мы хотим сделать по стандарту, как в GWT, с другой мы хотим сделать язык интероперабельным, и придется ей жертвовать, как в JSweet.
Обычно хватало GwtQuery. Есть Elemental. Есть форк реакта под GWT.
Всё это весьма и весьма кривое и неудобное. После Angular 2+/TypeScript реально неуклюжим кажется.
Java плохой язык для декларативного программирования и DSL-ей. В нем фактически отсутствует возможность читабельно написать иерархические структуры, такие как DOM.
В JavaScript тоже нет никаких возможностей таких. Вот для этого и прикрутили JSX/TSX.
Как выход либо прикручивается сторонний темплейтер с кучей не type-safe байндингов
Либо прикручивается сторонний темплейтер, поддерживающий типизированные байндинги, вроде этого.
В Java много специфической семантики, отличной от JS. С одной стороны мы хотим сделать по стандарту, как в GWT
А чего в плане интероперабельности не хватает в JSInterop?
Создатели GWT дружно ушли из гугла какое-то время назад. О причинах я не знаю, но могу догадываться. Стоны про UI в GWT мне никогда не были понятны. GWT это прежде всего компилятор, который позволяет писать сложный, но надёжный клиент-серверный код.
Всё то, что хорошее было в GWT успешно взяли на себя TypeScript, ES6 и другие многочисленные языки программирования. Они легко и просто встраиваются в веб-проекты, взаимодействуют друг с другом, их легко интегрировать в webpack. А ГМейл как пример неудачного веб-приложения с точки зрения производительности и т.п. уже здесь разбирали не раз.
Даже модули в npm не положили. Хотя может быть энтузиасты и запилят плагины к популярным фреймворкам… Посмотрим.
Даже модули в npm не положили. Хотя может быть энтузиасты и запилят плагины к популярным фреймворкам… Посмотрим.
Ну как же это? JSweet упомянули, а TeaVM нет, хотя у него и на гитхабе звёздочек больше, и делает его ваш соотечественник.
Хочу сказать о достаточно узкой нише, где без GWT (или аналога) — никак. Это приложения в несколько миллионов строк Java-кода, которые нужно запускать ещё и на Web (при этом требований к нативности интерфейса нет). Это всякие мультимедиа-приложения, игры и т.п. Переписывать всю эту тонну кода на TS и держать две параллельные ветки кода — это слишком затратно.
программисты на Clojure/ClojureScript тоже чешут бороду от недоумения — Зачем? Когда уже 10 лет как есть прекрасный язык, который и в JVM, и в JavaScript.
Разрабатывать только Web приложение, используя J2CL — немного странновато. Ещё глупее делать это используя Kotlin и подобные ему языки.
J2CL действительно нужен только для больших проектов, которые было бы не целесобразно поддерживать на N разных платформах. Взгляните не продукты гугл: Gmail, Calendar, Drive, Docs. Все эти приложения имеют клиентов на 3-х платформах (Web, Android, iOS).
J2CL это всего лишь один из инструментов в крос-платформенной разработке. Вторым инструментом является J2ObjC. Нету смысла имлементоировать один и тот же функционал 3 раза на разных языках. Гораздо выгоднее написать это всё один раз, чтобы оно работало везде. От сюда и тесная связь с bazel.
А сюда добавьте ещё и ингеграционные тесты для сервера. Там где надо вместе с сервером нужно запускать ещё и какого-нибудь клиента. Гораздо проще это делать если у вас есть нативный Java клиент (уже имеем 4 платформы: JRE, Android, iOS, Web).
Цена, которую приходится платить за это удовольствие, тоже есть. Это люди, которые поддерживают крос-платформенную инфраструктуру. Не думаю, что вне гугла найдётся много команд, которые смогут полноценно пользоваться J2CL.
J2CL действительно нужен только для больших проектов, которые было бы не целесобразно поддерживать на N разных платформах. Взгляните не продукты гугл: Gmail, Calendar, Drive, Docs. Все эти приложения имеют клиентов на 3-х платформах (Web, Android, iOS).
J2CL это всего лишь один из инструментов в крос-платформенной разработке. Вторым инструментом является J2ObjC. Нету смысла имлементоировать один и тот же функционал 3 раза на разных языках. Гораздо выгоднее написать это всё один раз, чтобы оно работало везде. От сюда и тесная связь с bazel.
А сюда добавьте ещё и ингеграционные тесты для сервера. Там где надо вместе с сервером нужно запускать ещё и какого-нибудь клиента. Гораздо проще это делать если у вас есть нативный Java клиент (уже имеем 4 платформы: JRE, Android, iOS, Web).
Цена, которую приходится платить за это удовольствие, тоже есть. Это люди, которые поддерживают крос-платформенную инфраструктуру. Не думаю, что вне гугла найдётся много команд, которые смогут полноценно пользоваться J2CL.
Забыл добавить. На J2CL пишут незначительную но критическую чать приложения. Обычно это бизнес логика. А весь UI пишется используя нативные языки и фрэймворки.
Так же стоит понимать, что не смотря на то, что у Гугла становится всё больше и больше Open Source проектов, ещё большая часть спрятана от публики. И очень часто без этих кусочков не реально запустить проект в продакшн. Посмотрите на closure-compiler, вы увидите что много лет в нём живёт j2cl код, хотя сам j2cl был опубликован недавно. Как Вы думаете, сколько похожих приватных интеграций внутри j2cl? И сколько j2cl фич всё ещё остаётся недоступно вне гугла.
Так же стоит понимать, что не смотря на то, что у Гугла становится всё больше и больше Open Source проектов, ещё большая часть спрятана от публики. И очень часто без этих кусочков не реально запустить проект в продакшн. Посмотрите на closure-compiler, вы увидите что много лет в нём живёт j2cl код, хотя сам j2cl был опубликован недавно. Как Вы думаете, сколько похожих приватных интеграций внутри j2cl? И сколько j2cl фич всё ещё остаётся недоступно вне гугла.
Sign up to leave a comment.
J2CL — Лучше поздно, чем никогда