GWT или DOJO или что-то еще?

Если вы готовы работать с Java, GWT — это то, что вам нужно. Это позволяет вам иметь относительно единую кодовую базу для клиент-сервера и использовать только один язык на обоих.

Есть некоторые ограничения для выполнения очень необычных вещей AJAXy (которые GWT делает трудными, но не невозможными), но в любом случае это не похоже на ваш вариант использования.

GWT позволит вам масштабироваться, используя больше его функций по мере того, как ваше приложение становится более сложным, и ваш прототип не будет одноразовым кодом.

Если вы хотите написать интерфейс и серверную часть на JAVA и хотите делать сложные вещи типа ajax, тогда GWT — отличный способ.

Проще всего представить себе, что создание GWT-приложения похоже на создание Swing-приложения JAVA, которое подключается к серверу. Точно так же, как свинг-приложение, которое использует сервер, вы можете сделать его толстым или тонким. Когда вы закончите, все это скомпилируется в HTML и javascript и будет иметь очень хорошую поддержку современных браузеров (например, 6+ ff, Opera, Safari).

Он абстрагирует весь javascript и HTML, но если вы хотите, чтобы он выглядел хорошо, вам все равно нужно понимать CSS.

Я думаю, что любой, кто говорит, что это разрушает MVC или что это путаница между клиентом и сервером, не понимает GWT. GWT — это фреймворк на стороне КЛИЕНТА. И используется только на КЛИЕНТЕ. GWT предоставляет механизм RPC для подключения его к JAVA (и другим) бэкендам, но это всего лишь протокол связи, это не означает, что ваш серверный код волшебным образом становится вашим клиентским кодом. Конечно, вы можете написать целую кучу бизнес-правил в свой пользовательский интерфейс, если вы действительно этого хотите, но вы можете сделать это с любым фреймворком, поэтому было бы глупо говорить, что GWT чем-то отличается в этом отношении.

GWT — хороший выбор, в то время как если вы выберете более мощную среду JavaScript, основанную на GWT (например, SmartGWT), скомпилированный материал будет слишком тяжелым.

Выберите прямой JavaScript, если вам нужен компактный проект.

Я поклонник GWT, однако хорошо знаком с Java. Я обнаружил, что это интуитивно понятно и на удивление легко быстро получить хорошие результаты. Если вы собираетесь использовать GWT, то вам обязательно понадобится бесплатная и очень мощная Eclipse IDE.

Одним из недостатков GWT является то, что он требует поддержки Javascript браузером, что означает отсутствие "изящной деградации".

Мы рассмотрели большой список фреймворков и выбрали Echo2.

• Вам нужно только кодировать на Java. Javascript вам нужен, только если вы хотите писать свои собственные компоненты.
• С такими крупными проектами, как GWT, проблем с производительностью при запуске не возникает.
• Вы можете использовать весь спектр Java в своем клиентском коде, потому что он работает на сервере. В GWT вы можете использовать только очень небольшой набор классов Java.

IDE для Java – это Eclipse. Это не зависит от используемого фреймворка.

Я поклонник jQuery, цепочка действий, обходов и команд действительно мощная. Мой хороший друг без ума от Mootools, он работает в магазине Java FWIW. Он упомянул замечательную особенность Mootools в том, что вы можете указать функциональность, которую вы хотите включить в фреймворк, и он сгенерирует всю библиотеку в одной строке в файле, который вы можете включить на свою страницу, чтобы минимизировать вес фреймворка (довольно мило). крутая функция). На самом деле все зависит от того, что вам удобнее. У jQuery есть отличные учебные пособия, он очень быстрый и может использоваться вместе с другими фреймворками javascript.

Не имеет отношения к GWT, но рассматривали ли вы другие серверные части, с которыми GWT мог бы хорошо работать?

Grails — это серверная часть, которая очень хорошо связана с GWT.

Лично я бы избегал фреймворков на стороне сервера, которые пытаются внедрить или скрыть фреймворк на стороне клиента. Я уверен, что GWT отлично подходит для быстрого запуска чего-либо и, вероятно, подходит для определенных типов приложений, но вы, вероятно, столкнетесь с множеством проблем «на периферии» для более сложных приложений. Отделение клиентской инфраструктуры от серверной позволяет избежать этих проблем.