Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
GWT отличная технология, но на данный момент имеет определенные минусы, которые значительно уменьшают удовольствие от разработки: время компиляции, отсутствие инкрементальной компиляции (обещают, вроде, в версии 2.5), отладка в хроме тормозит ужасно (хотя, может, уже и поправили за последние пару месяцев).
компилить в JS надо только во время деплоймента. Отладка в хроме раза в 2-2.5 медленнее чем в FF, да, но раньше было по ощущениям в 5 раз 8). Поэтому девелопмент удобно делать в FF, а в хроме уже доводить совместимость.
Деплоймент всякий раз когда нужно посмотреть что получилось. А нужно постоянно.
Это ведь не js, который открыл в окне и мгновенно видишь как оно меняется по мере разработки. В консолько залез и поравил что нужно, внес изменений в код.
А тут: что-то поменял, запустил, ждешь две минуты пока скомпилится, увидел что получилось чуток не так, правишь, снова запускашь, снова две минуты ждешь, и так далее…
Пробовал простенький проект написать, как время компиляции дошло до 4 минут — плюнул и отказался.
Это ведь не js, который открыл в окне и мгновенно видишь как оно меняется по мере разработки. В консолько залез и поравил что нужно, внес изменений в код.
А тут: что-то поменял, запустил, ждешь две минуты пока скомпилится, увидел что получилось чуток не так, правишь, снова запускашь, снова две минуты ждешь, и так далее…
Пробовал простенький проект написать, как время компиляции дошло до 4 минут — плюнул и отказался.
Вы не понимаете? Hosted mode, не нужно ничего ждать. Простой проект, изменил какой-нибудь IF в java, нажимаешь F5 имеешь за 2-3 секунды результат, весьма сложный проект — 10 секунд предел.
Не так давно хостед мод тоже вполне себе тупил.
Браузер, который для хостед-мода используется — весьма себе поделие, кажущее периодически погоду. А чтобы в реальном браузере открыть — нужно компилить.
Вообще GWT создает впечатление продукта который постоянно находится в глубокой бете.
За 6 лет, которые его пилят, он так и не выстрелил. Что весьма себе показатель.
Браузер, который для хостед-мода используется — весьма себе поделие, кажущее периодически погоду. А чтобы в реальном браузере открыть — нужно компилить.
Вообще GWT создает впечатление продукта который постоянно находится в глубокой бете.
За 6 лет, которые его пилят, он так и не выстрелил. Что весьма себе показатель.
Уже давно (года три минимум) hosted mode работает в реальных браузерах.
Достаточно поставить специальный плагин.
Достаточно поставить специальный плагин.
чтобы в реальном браузере открыть — нужно компилить.
Сейчас не надо. Отладка работает без компиляции в любом браузере, где можно установить GWT Development Plugin. Правда тормозит на тяжелых проектах. Компилировать же не так часто надо. Но одна мысль, что надо бы скомпилировать наконец, вызывает у меня ужас.
Firebug — наше все.
Меня это всегда удивляло, почему технологии продвигаемые одной и той же компанией так плохо совмещаются во время разработки. Почему в IE и FF отладка работает на порядок шустрее остается для меня загадкой.
Да, статей по GWT и вправду мало на хабре.
не индексируется поисковиками, как продвигать?
да, вы правы, это минус GWT. надеюсь гугл когда нибудь ситуацию исправит. А вообще, конкретно этот сайт не нуждается (почти) в индексировании.
Гугл уже исправил это.
Я делал перевод, что человек имеет против данного подхода.
Ограничения с индексированием сайта полностью сделанного на GWT это на самом деле огромная проблема. Вот Ваш сайт например похож на магазин. Любой опытный сеошник взглянув на его структуру ( фактически одну страницу ) скажем Вам что проблемы с продвижением будут гигантские ( если вообще разрешимые ). Нужны отдельные страницы для каждого товара, их перелинковка, уникальный контент на каждой странице и пр…
Вообще я допускаю что есть сайты не нуждающиеся в продвижение через поисковики, но это скорее исключение чем правило.
С другой стороне на GWT можно сделать все что делается на JS и при этом намного быстрее и эффективнее, тк мы имеем полную поддержку и контроль со стороны Java и IDE на этапе разработки. Например рефакторинг в GWT ( что-то типа сделать доп packages и пергруппировать функционал из классов ), делается элементарно. В JS это просто катастрофа, даже не смотря на все потуги IDE помочь в этом.
Вообще я допускаю что есть сайты не нуждающиеся в продвижение через поисковики, но это скорее исключение чем правило.
С другой стороне на GWT можно сделать все что делается на JS и при этом намного быстрее и эффективнее, тк мы имеем полную поддержку и контроль со стороны Java и IDE на этапе разработки. Например рефакторинг в GWT ( что-то типа сделать доп packages и пергруппировать функционал из классов ), делается элементарно. В JS это просто катастрофа, даже не смотря на все потуги IDE помочь в этом.
да, полностью согласен. С точки зрения сеошника этот сайт одна большая катастрофа. Но я пытался проталкивать этот сайт активно, связываясь с потенциальными клиентами, поэтому индексация в данном случае не играет вообще никакой роли.
По поводу эффективност: прямое попадание, именно это я и хотел донести. На GWT можно сделать абсолютно все и немного больше.
По поводу эффективност: прямое попадание, именно это я и хотел донести. На GWT можно сделать абсолютно все и немного больше.
Ошибочное мнение. Если вы посмотрите на фреймворк ext js, то увидите, что там также есть packages, mvc паттерн как основа. Есть классы, наследование и mixing и много чего еще :)
Я более чем знаком с ext js фреймворком. Заметьте, я не утверждал что на GWT можно сделать что-то такое чего нельзя сделать на JS. Такое утверждение было бы неверным, так как во время испольнения все написанное на GWT является обычным JavaScript.
Но разработка на GWT дает преимущество по сравнению с разработкой на простом JS ( для средних и крупных проектов ). Это преимущество обусловлено контролем типов Java на этапе разработки и развитыми средствами IDE ( например для рефакторинга ).
Но разработка на GWT дает преимущество по сравнению с разработкой на простом JS ( для средних и крупных проектов ). Это преимущество обусловлено контролем типов Java на этапе разработки и развитыми средствами IDE ( например для рефакторинга ).
Хорошый пример сайта на GWT.
GWT неплохая технология для таких сайтов. В принципе она хорошо вписывается стандартный сайт из какого-нибудь туториала любой интернет технологии (ну и конечно же «блог»). Веселости начинаются, когда твой сайт не просто переходы по страничкам, а уже Rich Interface Application, с рабочим столом, окошками, да и просто нетривиальная форма, с табличкой, фильтрацией, автокомплитом и т.п. Тут уже можно запросто выстрелить себе в ногу.
Я уже неоднократно убеждался и высказывал это мнение, что 80% функциональности на таких технологиях делается отлично, 10 процетов делается с большим трудом, а еще 10 с запредельными затратами, а то и вообще не возможно. Поэтому с аджайл-проектом, я бы не комитался на GWT.
А что касается продолжения, вы можете попробовать написать как unit-тестить GWT приложение, про паттерн MVP, про улучшайзеры типа либы GWT-Ext. Желательно в порядке усложнения и навешивания.
Я уже неоднократно убеждался и высказывал это мнение, что 80% функциональности на таких технологиях делается отлично, 10 процетов делается с большим трудом, а еще 10 с запредельными затратами, а то и вообще не возможно. Поэтому с аджайл-проектом, я бы не комитался на GWT.
А что касается продолжения, вы можете попробовать написать как unit-тестить GWT приложение, про паттерн MVP, про улучшайзеры типа либы GWT-Ext. Желательно в порядке усложнения и навешивания.
вы не писали или не поняли GWT (?), поэтому ваше разделение на 80-10-10 неверно. Это не та технология связки java/javascript, где применимо подобное разделение. Не могли бы вы описать ваши сложности?
Скажем подцепить к GWT бэкенд отличный от GAE
_Всегда_, когда надо изменить поведение стандартных GWT-виджетов, начинаются сложности — потому что там все внутренности прибиты гвоздями и не позволяют вносить модификации*. В итоге чаще всего оказывается, что самый простой способ — это создать в _своём_ проекте пакет наподобие «com.google.gwt.user.client.ui» (потому что в GWT практически везде используется дефолтная область видимости, т.е. в пределах пакета), создать там свой класс, скопировать в него код нужного виджета, и уже там его изменять. При этом очень часто отнаследоваться от нужного виджета не получится, поэтому, скажем, какой-нибудь MyTextCell не будет являться TextCell-ом** — что часто очень неудобно.
Так что я вполне согласен с оценкой 80-10-10.
* — В последних версиях наметились некоторые подвижки в сторону улучшения, но пока очень небольшие. Ситуация в целом пока что остаётся прежней.
** — Пример навскидку, конкретно от TextCell-а отнаследоваться, может быть, и получится — надо смотреть.
Так что я вполне согласен с оценкой 80-10-10.
* — В последних версиях наметились некоторые подвижки в сторону улучшения, но пока очень небольшие. Ситуация в целом пока что остаётся прежней.
** — Пример навскидку, конкретно от TextCell-а отнаследоваться, может быть, и получится — надо смотреть.
Гугл в курсе данной проблемы и предложил Appearance_Pattern
Сенча подхватила это, и последняя, 3-я версия GXT интенсивно использует данный метод.
Сенча подхватила это, и последняя, 3-я версия GXT интенсивно использует данный метод.
Статья понравилась, спасибо, все никак руки не доходят самому разобраться.
Кстати, есть ремейк GWT на Python — Pyjamas, если кого Java не устраивает. Разработчики говорят, что у них получилось тот же функционал вместить в 8 000 строк кода против 80 000 у GWT.
Кстати, есть ремейк GWT на Python — Pyjamas, если кого Java не устраивает. Разработчики говорят, что у них получилось тот же функционал вместить в 8 000 строк кода против 80 000 у GWT.
Когда последний раз его пробовал, работало криво на приложениях сложнее хелловорда и часть пимеров с сайта вообще не работало.
в GWT есть еще режим отладки и плагин для этих целей в бровзере. Вы пишете и отлаживаете код в бровзере без долгой компиляции в JS, а результат получается тот же (в том смысле, это это не эмуляция). Это и есть основная killer feature, которой в Pyjamas нету.
На самом деле не все так гладко получается. Некоторые вещи, которые пишите на gwt отлично работают на jetty в дебаге, но не работают на, например, websphere. И я говорю не о хитрых конструкциях а о простых операциях в java. типо сравнение енумов и кое что еще
поэтому всегда советую тестировать gwt приложения на том что будет в проме. по крайней мере перед коммитами
вы о клиент сайде? он не зависит от бакенда
вы о сервер сайде? он не зависит от gwt
RPC тоже стандартное (сервлет на сервере, и стандартный XMLHTTPRequest с клиента).
Что я упустил такое?
Может для вебсферы нужен ibm jre? И оттуда нюансы?
вы о сервер сайде? он не зависит от gwt
RPC тоже стандартное (сервлет на сервере, и стандартный XMLHTTPRequest с клиента).
Что я упустил такое?
Может для вебсферы нужен ibm jre? И оттуда нюансы?
gwt в дебаге иgwt скомпилянное это разные вещи. Конечно маленький процент различий но они есть. Проверено на собственном опыте. от бэкенда не зависит. просто у нас была сфера в проме
когда только начинал проект меня самого этого удивило когда начали валиться баги в багтрекер и я не мог их воспроизвести на jetty. а потом с помощью кучи алертов выявились баги, которые проявлялись только если по честному скомпилять gwt код полностью. Еще это вызывало проблемы из-за того что проект компиляется целиком полтора часа :)
два часа это жесть. этот сайт компилируется полностью за 90 секунд в худшем случае на слабенькой машине
проект реально огромен. напрягает очень сильно время компиляции. и при этом выжирает кучу оперативки, но правда когда даешь больше оперативки все упирается в диски. поэтому особо не помогает увеличение оперативки в какой-то момент
да, нужны хорошие тачки: больше ЦПУ и больше мозгов чтобы в параллел запускать билдиться модули при деплойменте. НО это в том случае если у вас не изолированы такие проблемы. Если вы видите расхождения между hosted mode и js mode (а я ни разу не видел, при плотном девелопменте большого проекта 3 года группой товарищей), вам следовало бы их изолировать отладить и пользовать уже этот код.
различие между hosted mode и js mode было только в том, что они давали разное прохождение таймеров. Если код был не продуман, то вполне возможная, но непредвиденная последовательность выполнений таймеров вылезала в js, которой не было в hosted mode, ну тут уже программист корявый значит, нареканий к gwt не было.
от этого всего я шизею, в хорошем смысле слова.
так что же за баги были у вас? про енумы что-то но я не понял что.
различие между hosted mode и js mode было только в том, что они давали разное прохождение таймеров. Если код был не продуман, то вполне возможная, но непредвиденная последовательность выполнений таймеров вылезала в js, которой не было в hosted mode, ну тут уже программист корявый значит, нареканий к gwt не было.
от этого всего я шизею, в хорошем смысле слова.
так что же за баги были у вас? про енумы что-то но я не понял что.
Проблемы вылазят иногда из-за неправильного перевода нативных JRE классов в Javascript. Некогда подпортила мне нервов реализация метода Char.isDigit в GWT. В дебаге все работало, после компиляции не работало. Оказалось, что isDigit в GWT работает только для стандартных латинских цифр (отладчик показал, что заменяется на простой регексп), для других же цифр метод работает некорректно.
> но правда когда даешь больше оперативки все упирается в диски
RAM-drive? ;-)
RAM-drive? ;-)
хм, вопросы не задаются. значит ли это, что ничего не интересует?
Да просто такие элементарные вещи делаются на любом js mvc фреймворке в полторы строчки. Не видно в этих примерах ничего, кроме необходимости писать в 10 раз больше кода. Быть может, для крупных rich-client приложений и есть профит, но на приведенном примере не понять.
с удовольствием увижу полторы строчки кода для плавного изменения контента при переходе на другую страницу. А вообще имелись ввиду вопросы по другим моментам, здесь не описанных.
Находим, например, jquery history, находим там Try out a demonstration, открываем исходник, находим полторы строчки. Добавляем какой-нибудь transition-эффект для сменяющихся блоков через CSS, и вуаля, у нас есть сайт с навигацией без перезагрузок, с плавным изменением контента. При правильной настройке он еще и индексироваться корректно будет.
ну так не честно. если я начну стороннии плагины использовать, я такого натворю… Вот посмотрите:
code.google.com/p/gwtquery/
тут есть абсолютно все (некоторые моменты появляются с запозданием) что умеет jQuery. Даже синтаксис тот же.
code.google.com/p/gwtquery/
тут есть абсолютно все (некоторые моменты появляются с запозданием) что умеет jQuery. Даже синтаксис тот же.
Зачем делать StartRu.html и StartDe.html? У вас верстка меняется в зависимости от языка? оО
Встроенные средства для перевода конечно не фонтан, но это лучше чем то как это реализовано…
На самом деле пример приведенные мне не очень нравится.
GWT создан чтобы быть понятным Java разработчику, чтобы он не думал (за редким исключением) что такое JS и как это все будет связано.
Встроенные средства для перевода конечно не фонтан, но это лучше чем то как это реализовано…
На самом деле пример приведенные мне не очень нравится.
GWT создан чтобы быть понятным Java разработчику, чтобы он не думал (за редким исключением) что такое JS и как это все будет связано.
вы правы, есть такая штука. в свое оправдание могу сказать, что мой велосипед прост, понятен, легко расширяем и самое главное я точно знаю как он работает и что надо сделать, что бы он работал по другому. Естейственно подход имеет право на жизнь до тех пор, пока код использую только я, а в этом случае так и есть.
Вот как интернационализация делается по-GWTшному
опять схавало ссылку
code.google.com/intl/ru-RU/webtoolkit/doc/latest/DevGuideI18n.html
code.google.com/intl/ru-RU/webtoolkit/doc/latest/DevGuideI18n.html
Мы всё ждём 2.5, в котором будут обещанные SourceMaps. Dev Mode пока самая тормозная сторона GWT. Firefox работает быстрее всех, но релизы плагина всегда запаздывают на пару версий, Chrome & IE очень медленные, Safari с версии 5 вообще перестал работать.
В остальном — наверное самый переспективный RIA Web фреймворк для Java.
В остальном — наверное самый переспективный RIA Web фреймворк для Java.
Firefox работает быстрее всех, но релизы плагина всегда запаздывают на пару версий
Можно скачать Firefox Portable последней версии, под которую есть GWT Developer Plugin (на данный момент это Firefox 10).
В Chrome при фокусе на поиск (http://3d-port.com) появляется оранжевая рамочка, выглядит некрасиво. В FF — нет.
Просто из праздного любопытства интересно два момента:
1. Она есть, потому что над проектом работали в FF (судя по комментарию выше все остальные браузеры тупят) и в других браузерах не смотрели / не смогли добиться того же результата?
2. Насколько сложно будет вам ее убрать (будет ли это из первой или второй десятки 80-10-10, о которых тут человек писал)?
Просто из праздного любопытства интересно два момента:
1. Она есть, потому что над проектом работали в FF (судя по комментарию выше все остальные браузеры тупят) и в других браузерах не смотрели / не смогли добиться того же результата?
2. Насколько сложно будет вам ее убрать (будет ли это из первой или второй десятки 80-10-10, о которых тут человек писал)?
Добрый день!
Однажды я участвовал в разработке одного очень крупного проекта на GWT в качестве верстальщика. Проблем возникала просто масса, самый простой пример: стандартный компонент похожий на меню выдавал блок, ползущий в одном из браузеров, перекрытием стилей решить не удалось, поэтому пришлось переверстывать заново и подключать просто как кусок xhtml.
Вообще если честно, то вот эта фраза с приведенным далее кодом звучит очень неубедительно для меня, как для JS разработчика. Что такого вы можете написать на GWT, чего нельзя написать на JavaScript?
Однажды я участвовал в разработке одного очень крупного проекта на GWT в качестве верстальщика. Проблем возникала просто масса, самый простой пример: стандартный компонент похожий на меню выдавал блок, ползущий в одном из браузеров, перекрытием стилей решить не удалось, поэтому пришлось переверстывать заново и подключать просто как кусок xhtml.
Вообще если честно, то вот эта фраза с приведенным далее кодом звучит очень неубедительно для меня, как для JS разработчика. Что такого вы можете написать на GWT, чего нельзя написать на JavaScript?
С помощью этого замечательного Фреймворка можно делать такие вещи, которые большинству JavaScript программистам просто не по зубам.
DOM.setEventListener(element, new EventListener() {
public void onBrowserEvent(Event event) {
if (DOM.eventGetType(event) == Event.ONCLICK) {
// наша логика
}
}
});www.alexey-schroder.de/projekts/zombie/
это сделано на GWT. я гарантирую, что сделать это за 2 вечера на JavaScripte невозможно (не фрику конечно). А вот на GWT очень даже, т.к. именно это я и сделал
это сделано на GWT. я гарантирую, что сделать это за 2 вечера на JavaScripte невозможно (не фрику конечно). А вот на GWT очень даже, т.к. именно это я и сделал
На первый взгляд, приложение чем-то похоже на знаменитую игру «жизнь». Такую же игру парни писали на JavaScript как раз за два дня на хакатоне. Пруф.
Честно говоря, сложность алгоритма по вашей ссылке мне не совсем ясна, поэтому возможно я и ошибаюсь, но за два дня такое написать более чем реально.
Честно говоря, сложность алгоритма по вашей ссылке мне не совсем ясна, поэтому возможно я и ошибаюсь, но за два дня такое написать более чем реально.
Что такого вы можете написать на GWT, чего нельзя написать на JavaScript?
Во-во. Особенно, если принять во внимание, что это трансляция Java -> JavaScript, т.е. несмотря на супер умности, воспроизвести всю мощь и гибкость JavaScript'а на хорошем уровне при таком подходе не получится.
Но в некоторых приложениях, где риск «протекающей абстракции» минимален, конечно, можно пойти простым путем, и переложить низкоуровневую работу на плечи фреймворка.
Статья просто ну совершенно ни о чем. Посмотрите какой я красавчик — написал на GWT сайт и я не умею писать ни на js и ни знаю ни html ни css. Ждал хотя бы примеры использования mvp, activities places and etc общую модель проекта.
Пример с тем, как вы вешаете клики на кнопки это вообще меня повергло в пичаль.
Есть uibinder и тому сопутствующие вещи, которые позволяют вешать любые listeners на любые объекты (ну кроме некоторых исключений, которые опять же обходятся в 1 строчку).
Также — использование статических header и footer, тоже не самое правильное решение. Куда лучше использовать nesting layouts как в примере, но вы же не использовали mvp… а зря. Вот к примеру как вы будете исправлять свой код, если еще понадобиться сделать мобильную версию сайта? При правильном написании это бы заняло только время на написание мобильного layout.
По моему скромному мнению-здесь совершенно нечем хвастаться. Если вы не знаете таких вещей, то как минимум я бы этим не хвастался. Я писал несколько лет как на GWT так и на js и у каждого из этих подходов есть свои преимущества.
На GWT удобно писать RIA, которые имеют большой функционал, как пример — web version Evernote. Это то, приложение, которое я бы писал на GWT потому что там не нужна индексация страниц, и такой большой проект будет проще писать сразу и front and back ends на java как пример.
Но если нужно написать максимально быструю версию сайта, которую нужно индексировать, то я бы это делал на js. Поскольку в итоге мы будем иметь больше плюшек, чем с GWT. Также проще работать с верстальщиками и тд.
Ну и чтобы сравнивать — нужно попробовать оба варианта, а потом делать выводы.
Пример с тем, как вы вешаете клики на кнопки это вообще меня повергло в пичаль.
Есть uibinder и тому сопутствующие вещи, которые позволяют вешать любые listeners на любые объекты (ну кроме некоторых исключений, которые опять же обходятся в 1 строчку).
Также — использование статических header и footer, тоже не самое правильное решение. Куда лучше использовать nesting layouts как в примере, но вы же не использовали mvp… а зря. Вот к примеру как вы будете исправлять свой код, если еще понадобиться сделать мобильную версию сайта? При правильном написании это бы заняло только время на написание мобильного layout.
По моему скромному мнению-здесь совершенно нечем хвастаться. Если вы не знаете таких вещей, то как минимум я бы этим не хвастался. Я писал несколько лет как на GWT так и на js и у каждого из этих подходов есть свои преимущества.
На GWT удобно писать RIA, которые имеют большой функционал, как пример — web version Evernote. Это то, приложение, которое я бы писал на GWT потому что там не нужна индексация страниц, и такой большой проект будет проще писать сразу и front and back ends на java как пример.
Но если нужно написать максимально быструю версию сайта, которую нужно индексировать, то я бы это делал на js. Поскольку в итоге мы будем иметь больше плюшек, чем с GWT. Также проще работать с верстальщиками и тд.
Ну и чтобы сравнивать — нужно попробовать оба варианта, а потом делать выводы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем сайт на GWT: Часть 1