Найбільші підводні камені GWT? [зачинено]

Я на початку / середині проекту, який ми вирішили реалізувати, використовуючи GWT. Хтось стикався з будь-якими серйозними підводними помилками у використанні GWT (та GWT-EXT), які не вдалося подолати? Як щодо перспективності?

Кілька речей, які ми бачили / чули, вже включають:

• Google не може індексувати вміст
• CSS та стилізація взагалі здаються дещо хиткими

Шукаєте будь-які додаткові відгуки про ці елементи. Дякую!

Почну з того, що я є великим шанувальником GWT, але так, є багато підводних каменів, але більшість, якщо не все, що нам вдалося подолати:

Проблема: тривалість компіляції триває, оскільки ваш проект зростає, а також збільшується кількість часу, необхідного для його складання. Я чув про повідомлення 20-ти хвилинних компіляцій, але мої в середньому близько 1 хвилини.

Рішення: розділіть свій код на окремі модулі та скажіть мурашці будувати його лише тоді, коли він змінений. Також під час розробки ви можете значно прискорити компіляцію разів, лише створивши для одного браузера. Це можна зробити, ввівши це у свій .gwt.xml файл:

<set-property name="user.agent" value="gecko1_8" />

Де gecko1_8 - це Firefox 2+, тобто 6 - IE тощо.

Проблема: Розміщений режим дуже повільний (принаймні на OS X) і не наближається до відповідності змін "наживо", які ви отримуєте, коли ви редагуєте такі речі, як сторінки JSP або Rails, і натискаєте оновити у своєму браузері.

Рішення: Ви можете надати хостинговому режиму більше пам’яті (я зазвичай отримав 512 мільйонів), але він все ще повільний, я виявив, що як тільки ви отримаєте достатньо хороший вміст з GWT, ви перестанете користуватися цим. Ви робите великий фрагмент змін, потім компілюєте лише для одного браузера (як правило, компілювати 20 років), а потім просто натисніть оновити у своєму браузері.

Оновлення. З GWT 2.0+ це більше не є проблемою, оскільки ви використовуєте новий "Режим розробки". Це в основному означає, що ви можете запускати код безпосередньо у своєму браузері за вибором, тому не втрачайте швидкість, плюс ви можете запускати / перевіряти його тощо.

http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM

Проблема: код GWT - це java, і він має інший менталітет до викладання HTML-сторінки, що робить прийняття HTML-дизайну та перетворення його на GWT складніше

Рішення: Знов ви звикаєте до цього, але, на жаль, перетворення HTML-дизайну в GWT-дизайн завжди буде повільніше, ніж робити щось на зразок перетворення дизайну HTML на сторінку JSP.

Проблема: GWT трохи забирає голову, та ще не є основною. Це означає, що більшість розробників, які приєднаються до вашої команди або підтримують ваш код, повинні вивчити його з нуля

Рішення: Залишається зрозуміти, чи вийде GWT, але якщо ви компанія, яка контролює того, кого ви наймаєте, то ви завжди можете вибрати людей, які або знають GWT, або хочуть її навчитися.

Проблема: GWT - кувалда порівняно з чимось на зразок jquery або просто звичайним javascript. Для цього потрібно набагато більше налаштувань, ніж просто включення файлу JS.

Рішення: Використовуйте такі бібліотеки, як jquery, для менших, простих завдань, які підходять для них. Використовуйте GWT, коли ви хочете створити щось справді складне в AJAX або там, де вам потрібно передавати свої дані туди-сюди через механізм RPC.

Проблема: Іноді для заповнення вашої сторінки GWT вам потрібно здійснити виклик сервера, коли сторінка спочатку завантажується. Користувачам може бути прикро для того, щоб сидіти там і дивитись символ завантаження під час отримання необхідних даних.

Рішення: У разі сторінки JSP, ваша сторінка вже була виведена сервером, перш ніж стати HTML, так що ви можете фактично робити всі ваші дзвінки GWT і попередньо завантажувати їх на сторінку для миттєвого завантаження. Детальніше дивіться тут:

Прискорити завантаження сторінки за допомогою попередньої серіалізації викликів GWT

Я ніколи не мав жодних проблем з CSS, як стилізувати свої віджети, нестандартно, користувальницькі чи іншим способом, тож я не знаю, що ви маєте на увазі під тим, що ви потрапили в підводний камінь?

Щодо продуктивності, я завжди виявляв, що один раз компільований код GWT швидкий, а виклики AJAX майже завжди менші, ніж проведення оновлення всієї сторінки, але це не зовсім унікально для GWT, хоча рідні пакети RPC, які ви отримуєте, якщо використовуєте задній кінець JAVA досить компактний.

Ми працюємо з gwt майже 2 роки. Ми засвоїли багато уроків. Ось що ми думаємо:

1. Не використовуйте сторонні бібліотеки віджетів, особливо gwt-ext. Це вб'є вашу налагодження, розробку та продуктивність. Якщо у вас є питання, як це відбувається, зв’яжіться зі мною безпосередньо.

2. Використовуйте gwt лише для заповнення динамічних частин ваших додатків. Тож якщо у вас є складна взаємодія користувачів з великою кількістю полів. Однак не використовуйте панелі, які постачаються з ним. Візьміть наявні сторінки, що постачаються дизайнером запасів. Виділіть області, які містять елементи керування для вашої програми. Приєднайте ці елементи керування до сторінки в onModuleLoad (). Таким чином, ви можете використовувати стандартні сторінки від вашого дизайнера, а також робити всі стилі за межами gwt.

3. Не створюйте весь додаток як одну стандартну сторінку, яка потім динамічно створює всі частини. Якщо ви зробите те, що пропоную в пункті 2, це все одно не відбудеться. Якщо ви будуєте все динамічно, ви вбиватимете продуктивність і споживаєте величезну кількість пам'яті для середніх і великих додатків. Крім того, якщо ви робите те, що я пропоную, кнопка "назад" буде чудово працювати, тому пошукова система індексуватиметься тощо.

Інші коментатори також мали кілька хороших пропозицій. Я використовую правило: створювати сторінки, схожі на стандартну веб-сторінку. Потім виріжте шматочки, які повинні бути динамічними. Замініть їх елементами, які мають ідентифікатори, а потім використовуйте RootPanel.get( id ).add( widget )для заповнення цих областей.

Підводні камені, з якими ми стикалися:

• Хоча ви можете отримати багато пробігу, використовуючи щось на зразок GWT EXT, кожен раз, коли ви використовуєте цей тип тонкого шпону поверх бібліотеки JavaScript, ви втрачаєте можливість налагодження. Не раз я бив головою за стіл, тому що не можу перевірити (всередині мого відладчика IntelliJ) те, що відбувається в класі таблиці GWT EXT ... Все, що ви можете бачити, це те, що це JavaScriptObject. Це ускладнює з'ясування того, що пішло не так ...

• Якщо у вашій команді немає когось, хто знає CSS. З мого досвіду, неважливо, що людина не була досвідченою ... досить, що він має хороші робочі знання та знає правильні умови для google, коли це необхідно.

• Налагодження через веб-переглядачі. Слідкуйте за режимом, що не розміщений з процесом [ 1 ] [ 2 ] [ 3 ], сподіваємось, що він надходить у GWT 1.6 ... Поки що вам просто потрібно виправити речі з розміщеним режимом, а потім скористатися кнопкою "Компілювати / Оглянути" , де ви можете грати з іншими браузерами. Для мене, що працює в Windows, це означає, що я можу переглядати свою роботу в FireFox і використовувати FireBug, щоб допомогти налаштувати та покращити ситуацію.

• IE6. Дивно, наскільки різні IE 6 будуть рендерувати речі. Я взяв підхід до застосування стилю до самого зовнішнього "огляду" відповідно до браузера, щоб я міг мати правила CSS, такі як:

  .my-style { /* stuff that works most everywhere */ }
  
  .msie6 .my-style { /* "override" so that styles work on IE 6 */ }

Нарешті, переконайтеся, що ви використовуєте редактор, який вам допомагає. Я використовую IntelliJ - у ньому багато розумних GWT. Наприклад, якщо я спробую використовувати клас, який не обробляється емуляцією JRE, це дає мені знати; якщо я вкажу стиль для віджета, і я ще не визначив цей стиль, код набуде маленького червоного зубчика ... Або, дивлячись на CSS, він підкаже мені, коли я вказав суперечливі атрибути в єдине правило. (Я ще не пробував цього, але я розумію, що версія 8 має ще кращу підтримку GWT, як, наприклад, синхронізацію "локального" та "асинхронного" інтерфейсів і реалізацій RPC.)

GWT 2.0, який повинен з'явитися десь у найближчі кілька місяців, вирішує багато обговорених питань.

• Створіть макети, використовуючи синтаксис типу html / xml
• Динамічне завантаження скриптів - спочатку завантажується тільки необхідний JS. Решта буде завантажено за потребою
• Режим розміщення в браузері - це може вирішити обговорювані проблеми швидкості розміщення в режимі розміщення, серед інших переваг
• "Оптимізація компілятора" - Швидше складання, сподіваємось

GWT 2.0 Попередній перегляд відео в Google I / O

Не "не в змозі подолати", а трохи болить за щось основне.

Обробка дати:

GWT використовує застаріле, java.util.Dateщо може призвести до несподіваної поведінки під час роботи з датами на стороні клієнта. java.util.Calendarне підтримується GWT. Більше інформації тут .

Приклади пов'язаних проблем:

• GWT java.util.Дати помилку серіалізації
• Отримати детальну інформацію про дату (день, місяць, рік) у GWT
• Підтримка часового поясу клієнта в GWT

Додамо декілька пунктів до вже згаданих:

• Обв'язування / перевірка даних. GWT не підтримує прив'язку даних / перевірку даних, хоча деякі проекти з цієї області починають з'являтися. Ви опинитеся так багато:

Ім'я TextField, фейдрес;
...
fname.setText (person.getName ());
faddress.setText (person.getAddress ());
...

• Ледаче завантаження. Оскільки gwt знаходиться на стороні клієнта, ліниве завантаження насправді не є можливим. Для цього вам потрібно буде ретельно розробити свої RPC та об’єкти домену
  • надіслати всі необхідні ваші об'єктні дані
  • не бажайте отримувати всі ваші дані
  • Вам також доведеться переконатися, що ви не будете надсилати проксі-сервери / не серіалізаційні об’єкти. hibernate4gwt може допомогти вам у цих питаннях.
• Дизайн інтерфейсу У java (Панелі, кнопки тощо) візуалізувати інтерфейс складніше, ніж у html.
• Підтримка історії. GWT не постачається з підсистемою "Історія", а також не постачається з будь-якою підсистемою для приємних URL-адрес або державних закладок. Вам доведеться прокрутити свій власний (хоча у ньому є підтримка жетонів історії, що є початком). Це відбувається з усіма інструментами AJAX AFAIK.

IMHO, GWT відсутня рамка, яка б не підтримувала всі питання, згадані в цій темі.

Я зараз працюю над проектом, який використовує EXT GWT (GXT), щоб не плутати його з GWT EXT. Існує різниця, EXT GWT - це та, яка насправді виробляється компанією, яка написала ExtJS бібліотеку javascript. GWT EXT - це обгортка GWT навколо бібліотеки ExtJS. GXT - це рідний GWT.

У будь-якому разі, GXT все ще дещо незрілий і не має міцної спільноти, яку, на мою думку, має GWT EXT. Однак майбутнє - за GXT, оскільки він є рідним GWT і фактично розроблений компанією, яка створила ExtJS. GWT EXT дещо калік, коли ліцензія змінилася на бібліотеці ExtJS, тим самим сповільнюючи розвиток GWT EXT.

В цілому, я думаю, що GWT / GXT - це гарне рішення для розробки веб-додатків. Насправді мені дуже подобається розміщений режим для розвитку, він робить все швидким і легким. Ви також отримаєте вигоду від можливості налагодження коду. Тестування з JUnit також є досить солідним. Я ще не бачив чудової системи тестування одиниць JavaScript, яка, на мою думку, була досить зрілою для тестування корпоративного додатку.

Для отримання додаткової інформації про GWT EXT: http://gwt-ext.com/

Для отримання додаткової інформації про EXT GWT (GXT): http://extjs.com/products/gxt/

Жодних великих підводних каменів, які мені не вдалося легко подолати. Використовуйте розміщений режим сильно. Коли ви використовуєте GWT-ext, вам майже ніколи не потрібно буде самостійно торкатися CSS, якщо ви не хочете налаштувати зовнішній вигляд.

Моя рекомендація - використовувати "рідний" віджет GWT над бібліотекою, де вони близькі за можливостями.

Повторне індексування пошукової системи: так, сайт не матиме звичайних URL-адрес для навігації (якщо тільки ви не додаєте віджети до елементів звичайного веб-сайту). Однак ви можете робити історію назад / вперед.

Я деякий час тому використовував GWT та GWT-ext у проекті. Я вважав цей досвід досить гладким у процесі розробки веб-сайтів, але моя порада буде такою:

Не змішуйте рідні віджети GWT з віджетами EXT. Це заплутано як пекло, оскільки зазвичай імена однакові (GWT.Button або GWText.Button?)

Одне, що трапилося зі мною, що дійсно зробив код складнішим, ніж мені хотілося, - це те, що я хотів, щоб панель була a) динамічно оновленою

Рідні панелі GWT динамічні, панелі Ext - каскадні. Рішення? GWT.VerticalPanel, що обгортає панель GWTExt ... Хаос. :)

Але ей, це працює. ;)

Другий коментар від ykagano, найбільшим недоліком є ​​втрата V у MVC. Хоча ви можете відокремити справжній клас інтерфейсу від решти коду клієнтської сторони, ви не можете легко використовувати сторінку HTML, створену графічним / веб-дизайнером. Це означає, що вам потрібен розробник, щоб перевести HTML в Java.

Отримайте редактор wysiwyg ui, це заощадить багато часу. Я використовую GWTDesigner.

Найбільша перевага GWT - це можливість забути про проблеми з веб-переглядачем. Це не на 100%, але забирає майже весь цей біль. У поєднанні з налагодженням налагодженого режиму (на відміну від Firebug, який є відмінним, але не таким, як налагоджувач Java), він дає розробнику величезну перевагу в створенні складних додатків ajax.

Ох і його швидкість під час виконання, особливо якщо ви використовуєте gzip-фільтр.

Трохи поза темою, але канал #gwt на irc дуже корисний, на випадок, якщо у вас є проблеми.

GWT досить прямолінійний та інтуїтивно зрозумілий.

Особливо з випуском UIBinder, щоб дозволити віджети GWT розміщувати в XML, а потім кодувати у Java.

Отже, якщо ви використовували інші інструменти дизайну Ajax або Flash, або Silverlight тощо, GWT дуже легко вивчити.

Основна перешкода, якщо не падіння, - це GWT RPC. Сама причина, яку ви хочете використовувати GWT, полягає в тому, що GWT async RPC. Інакше, чому б просто не покластися на css для форматування вашої сторінки?

GWT RPC - це той елемент, який дозволяє вашому серверу оновлювати дані на вашому сервері без необхідності оновлення сторінки. Це абсолютна вимога до сторінок, таких як моніторинг ефективності запасів (або поточний національний і державний борг США або кількість ненароджених дітей, аборт яких припинено в усьому світі).

GWT RPC докладає певних зусиль, щоб зрозуміти, але, маючи кілька годин, це повинно бути зрозумілим.

Над цим, доклавши певних зусиль, щоб вивчити GWT RPC, ви нарешті виявите, що не можете використовувати JSP в якості сервісного компонента для RPC, якщо тільки ... У моєму блозі є серія із 8 частин (я думаю) про те, як використовувати JSP як GWT RPC serviser. Однак, оскільки ви не просили відповіді, а лише питання, я не хочу рекламувати свій блог.

Так. Я дуже вважаю, що найгіршими перешкодами / підводними проблемами використання GWT є з'ясування того, як правильно розгорнути GWT async RPC та як дозволити йому використовувати сервіси JSP.

Нам дуже важко було одружувати нашу кодову базу GWT з веб-шаблонами HTML, які ми отримали від веб-дизайнера (статичні HTML-сторінки з конкретними ідентифікаторами, якими ми хотіли керувати GWT). Принаймні, коли ми використовували його, ми не могли змусити GWT інтегруватися з частинами нашого веб-сайту, які не були закодовані в GWT. Ми зрештою працювали, але це був великий злом.

• Інтерфейс Async, який потрібно записати для кожного сервісного інтерфейсу, виглядає як щось, що могло бути автоматично сформовано компілятором GWT.
• Часи компіляції стають довгими для великих проектів

Але для великого проекту Javascript це найкращий вибір

GWT 2.4 виправив багато згаданих вище проблем, і з Beta виходить велика бібліотека віджетів (Ext GWT 3.0.4, також GXT), яка повністю написана на GWT, а не в обгортку JS lib.

Залишився біль:

• Відсутність підтримки CSS3-селектора, ви можете використовувати "literal ()" в деяких випадках, щоб обійти його.
• Відсутність підтримки для CSS3 та сучасних подій браузера, таких як TRANSEnd .
• Відсутність підтримки класу Java Calendar (через багато років).
• Відсутність підтримки JUnit4 (5 років і підрахунок).
• Відсутність чіткої дорожньої карти та графіку випуску від команди GWT Google.

Що стосується GWT 2.4, використовуйте Firefox при налагодженні GWT, але він набагато швидше, ніж при використанні хрому. І якщо ви використовуєте лише firefox, подумайте про те, як ввести цей рядок у файл project.gwt.xml

<set-property name="user.agent" value="gecko1_8" />

Крім того, якщо ви використовуєте eclipse, тоді додайте наступне під аргументами -> аргументи VM:

-Xmx512m -XX: MaxPermSize = 1024м -XX: PermSize = 1024м

Ви можете розділити ваш сервер і клієнта і використовувати наступні під аргументами -> Аргументи програми: -codeServerPort 9997 -startupUrl http: // yourserver / project -noserver

Крім того, щоб запобігти оновленню сервера під час кожної зміни, використовуйте JRebel http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/ А ось демонстрація в прямому ефірі http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY

Одним з основних недоліків є те, що іноді потрібно чітко призначити ідентифікатор тому, що в кінцевому підсумку стає елементом HTML, щоб мати можливість використовувати певні стилі CSS. Наприклад: GWT TabPanel буде робити: наведення курсору на tabBarItems, коли табулятору tabPanel був призначений ідентифікатор, і ви вказали: наведіть курсор на цей елементId.

Я писав про деякі інші недоліки GWT в інших місцях, але вони вже охоплені іржавими відповідями :).

Нещодавно я багато пропрацював над GWT, і це все, що я повинен сказати:

1. CSS-стиль складний лише іноді, використовуйте інструмент розробника IE в IE і firebug в Firefox, щоб з’ясувати, що саме відбувається, і ви отримаєте чітке уявлення про те, що потрібно змінити css
2. Ви можете скористатися хитрощами, щоб отримати Google для його індексації. Дуже відомий сайт http://examples.roughian.com/ перевіряйте його рейтинги на google. Набагато менш відомий сайт - www.salvin.in (не міг протистояти згадці про це), я оптимізував його до слів: домашня сторінка Сальвіна (пошукайте Google за цими трьома словами).

Я мало знаю про GWT-EXT, але я теж вважаю, що не потрібно включати сторонні бібліотеки.

Успіхів у вашому рішенні :)

GWT виконує перегляд браузера замість функції виявлення функцій, і ваша програма не працюватиме в деяких браузерах (особливо нових)

Ось кілька посилань на проблему:

• google-web-toolkit Випуск 2938: RFE: покращити провайдер властивостей user.agent, щоб впоратися з "маскуванням" рядка userAgent
• Iceweasel більше не підтримується? - Довідка Google Документів
• Реалізація GWT для кожного браузера

Ось кілька посилань на Виявлення функцій:

• Виявлення браузера (і що робити замість цього)
• Виявлення функцій: Сценарій веб-переглядачів мистецтва
• Виявлення функцій браузера

Витягнутий із порівняння рамок JavaScript - Вікіпедія

Команда GWT зробила багато великих вдосконалень минулого року, випустивши GWT 2.7. Однією з головних недоліків GWT було те, що компіляція займає багато часу в GWT 2.6 і нижче. Це вже пішло GWT не має поступового компіляції, який є дуже швидким і збирає лише зміни.

GWT 2.7 тепер має ( Джерело ):

• Інкрементальне нарощування зараз лише за секунди
• Більш компактні, точніші SourceMaps
• Підтримка GSS
• JSInterop
• Відмінна продуктивність JavaScript
• Менший розмір коду

Найкращий спосіб отримати достовірні факти - це опитування gwt. . Однією з найбільших проблем GWT завжди був тривалий час складання. На щастя, воно вдосконалюється дуже швидко, тому найближчим часом це не стане суттєвою проблемою. Інша проблема полягає в тому, що GWT значно складніший, оскільки Java - це більш складна мова, яка чинить опір поганим кодерам на кожному кроці шляху. Крім того, компіляція додає шар. Наприклад, для js interop потрібно трохи котла. Основоположним питанням є те, що GWT не був спроектований просто. Він був розроблений з нуля для надзвичайно складних веб-додатків, і все співтовариство послідовно визначає пріоритети, продуктивність, якість коду, архітектуру та інше просте кодування.
Пам'ятайте, що ви можете використовувати js в GWT в будь-який момент, тому якщо ви боретеся з GWT, подумайте про використання js. Зрештою, GWT - js, тому ви можете робити все, що можна в GWT, що ви можете в js. Насправді, більшість проектів GWT використовують js. Проблема полягає в тому, що ГВТ значно складніше. Тим не менш, іноді варто додаткової складності.

Варто зазначити, що GWT 3.0 принесе значні вдосконалення.

Повторне використання об’єктів обслуговування RPC.
Це спричиняє умови перегонів із симптомами, схожими на звисання програми.

Підводні камені я наткнувся на 1. Різна поведінка в режимі супердеву. Наприклад, Someclass.class.getName () працює абсолютно добре в режимі Superdev і повертає повністю кваліфіковану назву класу. У продуктивному режимі це не працює.

2. addWidget (віджет) викличе віджет видалити з прозорого ()

GWT - це шедевр технології. Він об'єднує клієнтське та серверне програмування, роблячи це єдиним узгодженим додатком - способом написання програмного забезпечення перед "шаруванням" та способом його написання. Це виключає різні набори навичок, неправильну комунікацію між членами команди та взагалі всю фазу веб-дизайну: і художнього, і програмування. І це найближче до мобільного, наприклад, розробка Android. Насправді GWT був розроблений для генерування різних власних інтерфейсів, а не лише HTML. Хоча для забезпечення такої розв'язки потрібна величезна дисципліна - щоб зберегти внутрішні шари уявлення-агностики.

Перша помилка, якої ви повинні уникати, і на це мені знадобилося чотири роки, - використання сторонніх розширень, таких як EXT-GWT aka GXT та SmartGWT. Дуже спокусливо почати використовувати їхні досить настільні віджети, а не інвестувати у власну стилізацію, але я не можу сказати, скільки проблем у мене було зі SmartGWT, поки я нарешті не набридла. Коротше кажучи, він заморожує основну функцію GWT, встановлену на певному (досить застарілому) рівні, а потім будує поверх неї. Також майте на увазі, що в даний час вичленований вигляд на робочому столі виглядає нерозумно, не кажучи вже про мляву продуктивність, тони помилок та функції сумісності - особливо на мобільних пристроях. Ви хочете залишатися якомога ближче до нативної контролі веб-переглядача, тобто можливо, спадні файли відображаються як нативні елементи <select>, а не деякі власні забарвлені елементи управління.

Завдяки тенденціям для мобільних пристроїв, цілий UX стає простішим і простою, тому вам не потрібно робити багато для того, щоб стильно виглядати додаток. Хоча, якщо ви хочете "3D" виглядати, також є градієнти. CSS3 зробив все просто, а GWT обертає його елегантним об'єктно-орієнтованим способом на відміну від необробленого CSS. Тож не варто відмовлятись, дивлячись на досить потворні елементи керування баребонами у вітрині GWT. Команда GWT навмисно не пропонувала будь-якої стилізації, оскільки це робота розробника.

Решта - це майже звичайне програмування браузера на сильно набраному Java з красивими стислими API. Але звичайно ніколи не забуваючи, що ваш код працює всередині браузера, тому всі виклики є асинхронними, наприклад, ви не можете викликати методи GWT-RPC у циклі (для заповнення якогось списку), але потрібно рекурсивно ланцюгати їх, якщо ви коли-небудь прийдете до цього ситуація.

Є деякі самопроголошені "анти-шаблони", такі як не використовувати GWT-RPC. Мені це було добре поки що: 10 років. Простота є ключовою. Я б не подумав ні секунди пожертвувати деякою граничною продуктивністю для елегантності коду та ремонтопридатності. до того ж не там, де були б ваші вузькі місця - у базі даних. Звичайно, пам'ятайте, скільки даних ви надсилаєте клієнту.

І якщо ви не можете знайти або стилізувати існуючий гаджет - читайте багатий набір елементів HTML5, ви завжди можете обгорнути його стороннім. Я зробив це за допомогою популярного jQuery FullCalendar. Зовсім не ракетна наука. Все інше, як Google Maps та Google Charts, має напів офіційні обгортки GWT.

GWT ідеально. Єдина причина, по якій вона не отримує достатньої любові - це те, що ранні користувачі Інтернету, які все ще впливають на галузь, не прийшли з інформатики та об'єктно-орієнтованих мов, щоб оцінити їх. Вони мають або художній (Photoshop / WordPress), або мережевий (Perl / Python) фон.