Comments 78
благодаря статье вспомнил что есть google wave :)
Расскажите, пожалуйста, по-подробней про использование UiBinder в шаблоне!
Давайте внесём ясность в созданную мной путаницу. UiBinder это фреймворк, входящий в состав GWT, который позволяет создавать части интерфейса используя HTML и CSS. Эти самые части и называются UiBinder-шаблонами (UiBinder templates), потому что их можно использовать в интерфейсе сколько угодно раз. Чтобы статья была проще, я намеренно старался не приплетать UiBinder, поэтому «UI-шаблон» нужно понимать как «UiBinder template». Так что вы хотите узнать о UiBinder и/или о UiBinder-шаблонах?
При разработке на GWT обязательно серверную часть писать на Java?
Нет, не обязательно
Достаточно реализовать gwt-rpc протокол для взаимодействия с серверной частью
есть биндинг для php, например: code.google.com/p/gwtphp/
Достаточно реализовать gwt-rpc протокол для взаимодействия с серверной частью
есть биндинг для php, например: code.google.com/p/gwtphp/
Можно, например, писать серверный код на Scala, а shared&client на Java :)
Надеюсь, однажды можно будет все части писать на Scala: code.google.com/p/scalagwt
Надеюсь, однажды можно будет все части писать на Scala: code.google.com/p/scalagwt
Было бы классно, если бы кто-нибудь, давно работающий с GWT, провёл сравнительный анализ разработки проекта на GWT и на JS, учитывая все факторы — не только клиентскую оптимизацию, но и удобство сопровождения, скорость разработки и т.п.
Java vs Javascript — на разработку софта влияет разница между языками с динамической и статической типизацией. Плюсы Java в этом разрезе — возможность написания БОЛЬШИХ объемов связного кода. Поэтому плюсы GWT проявляются там где это надо, т.е. в супердинамичных Web20 приложениях, где уже нету никакого HTML вообще а только куча кода, а бровзер — это просто виртуальная среда такая, заковыристая, с глюками. Для сайтов с HTML (web 1.0) GWT будет как бревно в глазу.
Этот же плюс влечет за собой минус — девелоперы тут же родят тонны кода, забывшись, что они не под сервер пишут. Надо в узде народ держать бы…
Другой аспект GWT — отладка прямо в привычном отладчике (java), кто к какому привык. Довольно быстрая итерация compile/debug по сравнению со всякими Application Servers. В последних версиях GWT страница в бровзере перезагружается достаточно бысто после изменения кода. И хотя на JS перезагрузка страницы еще быстрее, Java отладчик всегда лучше любого firebug/visual studio/что еще есть.
Третий аспект — родное RPC на 99% удовлетворительное, и даже становится лучше. Не надо ничего изобретать и добавлять. Сразу из коробки просто пишутся AJAX-apps на той же Java, и объекты одни и те же, и строго типизировнные. Сравните с AJAX/JS — на сервере свой набор объектов, ежели есть вообще.
Может чего еще забыл.
Вывод — на GWT писать надо красивые динамические сайты. Для индексации сайтов гуглем положено делать readonly упрощенную HTML версию, если надо.
(пишу на GWT с тех пор, как только он появился)
Этот же плюс влечет за собой минус — девелоперы тут же родят тонны кода, забывшись, что они не под сервер пишут. Надо в узде народ держать бы…
Другой аспект GWT — отладка прямо в привычном отладчике (java), кто к какому привык. Довольно быстрая итерация compile/debug по сравнению со всякими Application Servers. В последних версиях GWT страница в бровзере перезагружается достаточно бысто после изменения кода. И хотя на JS перезагрузка страницы еще быстрее, Java отладчик всегда лучше любого firebug/visual studio/что еще есть.
Третий аспект — родное RPC на 99% удовлетворительное, и даже становится лучше. Не надо ничего изобретать и добавлять. Сразу из коробки просто пишутся AJAX-apps на той же Java, и объекты одни и те же, и строго типизировнные. Сравните с AJAX/JS — на сервере свой набор объектов, ежели есть вообще.
Может чего еще забыл.
Вывод — на GWT писать надо красивые динамические сайты. Для индексации сайтов гуглем положено делать readonly упрощенную HTML версию, если надо.
(пишу на GWT с тех пор, как только он появился)
Я разрабатывал приложение на GWT и в течении почти года не написал ни одной строчки кода на JS, а приложение работает и радует пользователей. Вообще магия.
Большое спасибо за столь развёрнутый ответ!
А стоит ли браться за GWT, если нам нужно переписать клиентскую часть под web 2.0 уже у готового проекта?
Система написана на Ruby on Rails, клиентская часть реализована на ExtJS. Т.к. это был наш первый опыт работы с js-only представлением, да и сроки были неоправданно сжатые, клиентский код получился ужасным. Собираемся переписать и выбираем: GWT(closure)/ExtGWT или простой js(closure или extjs), но с более продуманным подходом.
А стоит ли браться за GWT, если нам нужно переписать клиентскую часть под web 2.0 уже у готового проекта?
Система написана на Ruby on Rails, клиентская часть реализована на ExtJS. Т.к. это был наш первый опыт работы с js-only представлением, да и сроки были неоправданно сжатые, клиентский код получился ужасным. Собираемся переписать и выбираем: GWT(closure)/ExtGWT или простой js(closure или extjs), но с более продуманным подходом.
Всяко GWT круче, если в команде есть шарящий java программист. За счет прозрачности этих компиляций в JS вы сэкономите кучу нервов и времени.
GWT хорош для Java-программистов. Ruby-программистам проще, наверное, работать с чистым Javascript, HAML и SASS.
У одного девелопера прошлое Java, я баловался с ней пару лет назад.
Я считаю, что для динамичного развития команды нужно способствовать динамичному развитию используемых инструментов, поэтому новые(для нас) технологии нас не пугают. Важно лишь выяснить целесообразность.
Я считаю, что для динамичного развития команды нужно способствовать динамичному развитию используемых инструментов, поэтому новые(для нас) технологии нас не пугают. Важно лишь выяснить целесообразность.
Целесообразность меня и смущает. GWT — это лишний слой. Плюс ещё больше ограничений Java → длиннее и сложнее код (хотя бы посмотрите на сложность ООП в Java по сравнению с Ruby и тем более Javascript).
Посмотрите, лучше в сторону Coffeescript jashkenas.github.com/coffee-script/ — попытка починить синтаксис JS на основе красоты и лаконичности Ruby и Python.
Посмотрите, лучше в сторону Coffeescript jashkenas.github.com/coffee-script/ — попытка починить синтаксис JS на основе красоты и лаконичности Ruby и Python.
GWT — это не слой. В конечном итоге получается обычный js. Очень хорошо обфусцированный. Такого уровня оптимизации не добиться обычными js обфускаторами, потому что gwt — компилируется в js и может удалить неиспользуемые методы, применить method inlining, оптимизировать мат. операции и т.п.
Это слой между Вами и браузером. В случае ошибки в браузере, Вы не поймёте где ошибка в Java-коде. Вы не можете просто скопировать код какой-то из примеров для JS библиотеки (которую Вы используете вместе с GWT). Это лишние инструменты и генераторы. Вот, что я имею в виду под словом «слой».
Ошибки в браузере не будет, потому что, если вы ошиблись, код просто не скомпилируется.
Это не так, и Вы прекрасно это знаете :). Ошибки типизации очень редки — как часто Вы с ними сталкиваетесь в Ruby проектах? Большинство ошибок — это что метод не нашёл элемент и вернул undefined или была ошибка в алгоритме и Вы находите другой элемент, так что анимация показывается не там.
gwt-проект код можно дебажить любым дебаггером ява-кода(если верить автору).
Причём здесь ruby-то? Сравнение некорректно. Динамическая и статическая типизации — одно из главных отличий между этими языками :)
Причём здесь ruby-то? Сравнение некорректно. Динамическая и статическая типизации — одно из главных отличий между этими языками :)
Дебажить код можно, но если Вы видите, что что-то не так в конкретном браузере? Что не так отрисовывается анимация. да и зачем всё это, когда есть простые дебагеры для JS, сильно интегрированные в браузер.
Не знаю, Sun13 выше написал
И это логично, учитывая, что пишешь проект на языке со статической типизацией.
Java отладчик всегда лучше любого firebug/visual studio/что еще есть
И это логично, учитывая, что пишешь проект на языке со статической типизацией.
Java-отладчик может и лучше, как отладчик кода в вакууме. Но как вы будете проводить отладку CSS и HTML вместе. Дело в том, что отладчики в браузере рассчитаны именно на Веб и по этому лучше. Там есть профилирование именно в браузере (а из-за особенностей браузеров Java-отладчик вам ничего не даст), там есть очень удобная проверка действий по сети, в том числе и при загрузке статики, что бывает полезно.
Я сравнивал с Ruby, чтобы показать Вам, что статическая компиляция не помогает в борьбе с ошибками. Другой защиты у компилятора Java нет.
Ну и плюс GWT несёт кучу ограничений — требует тяжёлых инструментов (IDE, генератора Java→JS). По сообщению об ошибке в JS от пользователя нельзя понять, где ошибка была в JS.
Как я понимаю на GWT нельзя писать навешиваемый JS (то есть, когда в JS описаны лишь эффекты и реакции, а сайт в целом может работать и без JS, например, в поисковиках)?
Меня так же смущает лишний слой абстракции.
Ну и самое главное, ведь Java более низкоуровневый ЯП. Получается так, что кода на Java будет больше, чем на Javascript.
Да и вообще, мне кажется, что лучше пытаться понять смысл JS, делать инструменты для него. jQuery — прекрасный, красивый пример. Или та же node.js.
Меня так же смущает лишний слой абстракции.
Ну и самое главное, ведь Java более низкоуровневый ЯП. Получается так, что кода на Java будет больше, чем на Javascript.
Да и вообще, мне кажется, что лучше пытаться понять смысл JS, делать инструменты для него. jQuery — прекрасный, красивый пример. Или та же node.js.
Уж больно мне кажется, что GWT — это для Java-разработчиков, которые не хотят привыкать к языку с другой парадигмой и с другим подходом к разработке.
Посмотрите внимательней на пример в статье.
Из 8 значимых строчек получилась одна.
Из 8 значимых строчек получилась одна.
Вот именно 8 строк на Java → одна на Javascript :D. Но вообще это плохой пример — редко, когда встречается такой код.
Хотя, я, наверное, не понял что Вы хотели сказать.
Хотя, я, наверное, не понял что Вы хотели сказать.
На js это было бы так же 8 строк.
Гораздо короче (хотя строк и столько же). Посмотрите, сколько лишнего Вам навязывает Java:
CircleMath = {
area: function(radius) {
return Math.PI * radius * radius;
},
circumference: function(radius) {
return Math.PI * radius * 2;
}
}
Ну естественно для простого математического класса никакой gwt не нужен. Он для крупных проектов с большим количеством кода.
js и его обфускаторы не сделают вам method inlining. А gwt делает. Хорошо видно в примере.
js и его обфускаторы не сделают вам method inlining. А gwt делает. Хорошо видно в примере.
Точно так же в большом проекте с большим количеством кода, Java заставит вводить Вас лишние интерфейсы, лишнюю архитектуру из-за своих ограничений. Посмотрите на JavaEE проекты и на Ruby on Rails. Я видел исследование, когда две команды писали один проект на ASP.Net и Django (думаю это сравнимо) — на Python было в два раза быстрее.
Нет, не сравнимо. Java & .NET это один уровень, Django и RoR — совершенно другой.
Вот именно, я сравнивал уровень Java/.Net и Django/RoR — второй быстрее в разработке, так как меньше ограничений.
Вот именно про это я и хочу вам сказать: это разные, несравнимые уровни.
Если они не сравнимые, то почему Вы сравниваете Java (GWT) и Javascript (который ближе к Ruby)?
Смешной вопрос :)
Потому что я выбираю инструмент для работы из этих двух вариантов.
Потому что я выбираю инструмент для работы из этих двух вариантов.
Но если на Rails быстрее, чем на JavaEE, то и на Javascript будет проще, чем на GWT (если конечно, ты не пытаешься писать на JS, как на Java, а используешь философию языка).
Скорость — не единственный критерий.
Ну точно так же, подумайте, что удобнее разрабатывать, поддерживать — Rails-приложение или JavaEE? Где всё проще и понятнее, где меньше лишних классов и архитектуры? Где Вы можете понять, что и как выполняется без сложных систем с кучей аббревиатур между вами и системой ;).
Здесь такая аналогия совсем неуместна и на её основе делать выбор нельзя.
Вы правы, но всё же эта аналогия показывает, что аргументы «статическая типизация улучшает поддержку и понимание кода» неверны. А кроме этого аргумента у GWT нет никаких преимуществ против JS+SASS+HAML+Jammit.
В случае с rails да.
А js-код тяжело сопровождать, когда его много, когда весь клиентский код состоит только из js и стилей. Ещё очень подкупает то, что разработчики ExtJS сделали интеграцию с GWT в виде ExtGWT, а также closure, также поддреживаемая GWT.
Поэтому меня очень заинтересовала технология.
А js-код тяжело сопровождать, когда его много, когда весь клиентский код состоит только из js и стилей. Ещё очень подкупает то, что разработчики ExtJS сделали интеграцию с GWT в виде ExtGWT, а также closure, также поддреживаемая GWT.
Поэтому меня очень заинтересовала технология.
Проблема, мне кажется в ExtJS. На прошлой работе, мы тоже с ним работали. Но он не пытается понять JS, как jQuery, они переносили опыт Java-программиста на JS — куча классов и т. д. Всё это вылилось в ряд проблем — например, постоянная неразбериха с this.
Так или иначе, я не вижу фундаментальных проблем, почему код на Javascript поддерживать хуже, чем на Java. Так что если проблема и есть, то она в самом коде (или framework’е), а не в языке.
Так или иначе, я не вижу фундаментальных проблем, почему код на Javascript поддерживать хуже, чем на Java. Так что если проблема и есть, то она в самом коде (или framework’е), а не в языке.
В Вашем случае (писать код для ExtJS на GWT) может и будет проще, так как ExtJS создавался в Java-философии. Но это полу-мера, посмотрите, например, в сторону jQuery UI и Javascript, как языка со своим подходом.
… и далеко не главный, когда проект большой.
Да пример с method inlining мне понравился. Но в чём преимущество?
Существенно быстрее.
Именно благодаря ему, например, rubinius или pypy быстрее своих сишных реализаций на большинстве тестов.
Именно благодаря ему, например, rubinius или pypy быстрее своих сишных реализаций на большинстве тестов.
Большинство JS кода тормозит не из-за математических вычислений, а из-за работы с DOM, которой method inlining не поможет.
Тем более method inlining есть в нормальных JS-машинах в браузерах. Увы, но в GWT method inlining помогает только для небольшого уменьшения размера файла и работы в устаревающем IE 6 с самой примитивной JS ВМ.
Тем более method inlining есть в нормальных JS-машинах в браузерах. Увы, но в GWT method inlining помогает только для небольшого уменьшения размера файла и работы в устаревающем IE 6 с самой примитивной JS ВМ.
Кстати, а почему Вы всю логику виджетов держите в JS? Это же нарушает MVC (Model — HTML, View — CSS, Controller — JS), в итоге и получается тяжёлый для сопровождения код, так как он не разделён правильно.
*ответ на вопрос выше
Наш проект — что-то типа CRM, интегрированной с Asterisk с автопрозвоном клиентов. Сейчас выполнена в виде WebOS с некоторым подобием рабочего стола, почтовым клиентом и колл-центром.
Всю логику виджетов держим в js, потому что ExtJS так задуман.
В случае с closure lib будет по-другому. Мутулз пробовали. Отпал потому же, почему отпал jquery — базового функционала не хватает, а бегать по интернетам и дёргать различные реализации, которые в итоге, собранные вместе, неорганично выглядят, и приходится костылитьв css — не хочется.
Приятно, когда всё в одном месте, как в Closure или ExtJS.
Наш проект — что-то типа CRM, интегрированной с Asterisk с автопрозвоном клиентов. Сейчас выполнена в виде WebOS с некоторым подобием рабочего стола, почтовым клиентом и колл-центром.
Всю логику виджетов держим в js, потому что ExtJS так задуман.
В случае с closure lib будет по-другому. Мутулз пробовали. Отпал потому же, почему отпал jquery — базового функционала не хватает, а бегать по интернетам и дёргать различные реализации, которые в итоге, собранные вместе, неорганично выглядят, и приходится костылитьв css — не хочется.
Приятно, когда всё в одном месте, как в Closure или ExtJS.
Нууу. Вы же в Rails весь код в одном месте тоже не держите? Rails имеют только базовый функционал — всё остальное в плагинах. Весь код тоже не в одном месте, логика разделена на блоки и пишется отдельно.
Меня в отсутствии CSS смущало, что система вёрстка ExtJS какая-то ужасная. Тоже самое, что я смогу сверстать на пару минут в CSS, в ExtJS приходилось делать сложнее на базе их собственной системы а-ля Swing.
Да, есть такое. Но им это и нужно было: обеспечить аналог десктопа в вебе.
Да у нас тоже был такой проект, когда ExtJS делали :). Но стартап, слава богу быстро сдулся в начале кризиса — не было сил видеть дальше этот код :). Вот только я не очень думаю, что с GWT станет сильно проще. те же проблемы останутся, в GWT нет кучи возможностей (как у млн плагинов jQuery), код так же будет в одном месте. Просто на другом языке писать.
В WebOS всё тоже не в одном коде, а такое же разделение на CSS, HTML и JS (в каждом блоке есть свои расширения для особенностей ОС).
КОгда я говорил «всё в одном месте», я имел в виду инструменты. Например, исчерпывающая библиотека ui.
А расскажите для общего образования, чего в jQuery UI не хватало?
Лояльности заказчика, если честно :)
И у js-спецов в команде на тот момент не было тёплых чувств к jquery. Может быть, недосмотрели, но очень не хватало способа передать излишние параметры в тело функции-обработчика события, например, как это сделано в ExtJS через параметр scope. А ещё у проекта не было дизайнера(он вообще создавался на одном энтузиазме), и темы jqueryui покрывали намного меньше наших требований, чем у extjs.
Ну и jqueryui на тот момент(версии 1.4-1.5 если не ошибаюсь) он был не так хорош, как сегодня(пару проектов на нём поднял), но, глядя на вкладку «ui» документации по closure и меню demos у jqueryui, мне кажется, что с первым времени на разработку уйдёт существенно меньше.
А вы можете показать пример прямо-таки совсем вебдванольного проекта, написанного на jquery? Я таких не видел, но искал. Нашёл толкьо несколько довольно известных проектов на YUI.
И у js-спецов в команде на тот момент не было тёплых чувств к jquery. Может быть, недосмотрели, но очень не хватало способа передать излишние параметры в тело функции-обработчика события, например, как это сделано в ExtJS через параметр scope. А ещё у проекта не было дизайнера(он вообще создавался на одном энтузиазме), и темы jqueryui покрывали намного меньше наших требований, чем у extjs.
Ну и jqueryui на тот момент(версии 1.4-1.5 если не ошибаюсь) он был не так хорош, как сегодня(пару проектов на нём поднял), но, глядя на вкладку «ui» документации по closure и меню demos у jqueryui, мне кажется, что с первым времени на разработку уйдёт существенно меньше.
А вы можете показать пример прямо-таки совсем вебдванольного проекта, написанного на jquery? Я таких не видел, но искал. Нашёл толкьо несколько довольно известных проектов на YUI.
А в анонимных функциях, scope лучше не менять, а использовать замыкание (помним, что у каждого языка своя философия):
Тут сразу видно, что скрываем мы список, а не непонятный this. Впрочем, если способы и привязать нужный this к функции, в том числе сразу в jQuery. Но не забываем, что JS вообще не ООП, в том смысле как в Java. В JS объекты — лишь хеши, а this — лишь синтаксический сахар.
var list = this
$('a').click(function() {
list.hide()
})
Тут сразу видно, что скрываем мы список, а не непонятный this. Впрочем, если способы и привязать нужный this к функции, в том числе сразу в jQuery. Но не забываем, что JS вообще не ООП, в том смысле как в Java. В JS объекты — лишь хеши, а this — лишь синтаксический сахар.
Ну лично я на jQuery писал atata.com/ — «соц. сервис от создателей Хабра» :). Только лучше войдите через OpenID, многие интерфейсные штуки, там анонимно не видны (настройки например, особенно настройки дизайна ;) ).
Ещё www.lookatme.ru/ на jQuery.
technorati.com/ самый что ни на есть Веб 2.0 тоже на jQuery :). Долго можно перечислять — термин Веб 2.0 слишком обширный :). И Твиттер тоже на jQuery.
Так и думал, что нужно уточнить :)
Меня интересует full-ajax приложение с поддержкой истории.
Начитавшись топиков и документации, пришёл к выводу, что closure lib — наиболее подходящий для этого инструмент.
Вот ещё интересное обсуждение.
Меня интересует full-ajax приложение с поддержкой истории.
Начитавшись топиков и документации, пришёл к выводу, что closure lib — наиболее подходящий для этого инструмент.
Вот ещё интересное обсуждение.
Поддержку истории (в долгосрочной перспективе) лучше всего делать через HTML5 History API (а для IE временно делать костыль). Да или через #hash в URL история сейчас тоже отлично работает (см. atata.com )
Таких же целей можно достичь и на GWT. Для обработки истории есть встроенный класс History
Я сам предпочитаю сам создавать классы для элементов UI — всё равно они часто отличаются друг от друга, а с нормальным верстальщиком сверстать основной набор — не проблема.
спасибо. где-то час читал комментарии)))
Sign up to leave a comment.
Google Web Toolkit и клиентская оптимизация