Уместен ли GWT для новых проектов?

Для пункта 1 я могу дать вам несколько критериев, которые я бы использовал:

При использовании фреймворков на основе JavaScript вы обычно очень быстро создаете исходный код. По моему опыту, вы намного медленнее, когда дело доходит до обслуживания (исправления ошибок, новых функций, рефакторинга), поскольку поддержка инструментов не так хороша, как для языков со статической типизацией. Поэтому для более крупных или длительных проектов я всегда выбирал бы GWT из-за Java и его проверок компилятора / экосистемы / инструментов. Я думаю, что со временем вы выиграете от повышения эффективности и масштабирования разработки, поскольку у вас не будет странных проблем из-за динамической типизации. Для небольших проектов, которые не живут слишком долго или не нуждаются в большом рефакторинге, JavaScript Frameworks могут существенно ускорить разработку.

Потребности в отладке в контексте вашей целевой платформы также являются для меня критерием. Отладка кода GWT очень удобна, если у вас есть браузер, который поддерживается DevMode или, по крайней мере, может использоваться с новыми исходными картами на основе SuperDevMode. Например. Safari в MacOS X не поддерживается. Для мобильных устройств вы можете удаленно отлаживать JavaScript в Android Chrome, но, насколько мне известно, это невозможно для GWT.

Еще один критерий для меня - размер команды и текучесть кадров. Инструменты на основе Java (IDE, средства проверки качества кода, ...) помогают разработчикам, особенно новичкам, ориентироваться в коде других разработчиков. Это также верно для других языков статических типов, но вы просили GWT / Java.

Следующий вопрос - стек ... GWT легко решает клиентскую и удаленную коммуникационную часть, если использовать контейнер сервлетов на стороне сервера. Его также легко комбинировать со зрелыми корпоративными технологиями Java (JPA, EJB, Spring framework, ...). Это большая сила, если вам нужен / вы хотите иметь стек. Если вы собираетесь работать в многоязычном режиме без JVM на стороне сервера (как упоминалось выше), этот вариант не для вас.

Конечно, есть больше критериев для фреймворков GWT и JavaScript.

И большой вопрос в предпочтениях. В JavaScript есть действительно хорошие концепции (например, замыкания), но он также представляет собой риск из-за динамической типизации. Какой из них вы предпочитаете?

По пункту 2:

Я не уверен, есть ли реальная альтернатива GWT, которая предоставляет аналогичные функции и инструменты. Большинство других фреймворков сосредоточены только на одном аспекте (виджеты, оптимизация, привязка данных, удаленная связь, поддержка браузера, I18n, ...). Это не значит, что другие фреймворки плохи, но обычно вам нужна комбинация разных фреймворков, чтобы получить функциональность, предоставляемую GWT.

Относительно пункта 3:

• Я бы определенно взглянул на TypeScript, потому что он улучшил набор текста и совместимость с JavaScript.
• Насколько я помню, у Дарта похожая цель
• Вечнозеленым является JQuery, но в зависимости от ваших потребностей есть хорошие альтернативы. Но это очень субъективно
• Для виджетов подойдет Twitter Bootstrap (http://getbootstrap.com/), если это вам подходит. Есть даже его версия для GWT (http://gwtbootstrap.github.io/)

Отличный ответ Штеффена. Я начал набирать его как комментарий к его, но обнаружил, что набрал больше, чем ожидал, поэтому сделал это отдельным ответом. Не охота за очками ...

Я просто хотел добавить 1 свой субъективный момент. Реальность такова, что большинство разработчиков - это так называемые backend-разработчики без знаний, опыта и, самое главное, желания разрабатывать веб-интерфейс. Реальность ИТ-рынка США такова, что большинство предпочло бы Java в своем резюме JS, PHP, Python и другим экзотическим языкам. Причина - компенсация. Java-разработчикам в среднем платят больше. Не уверен насчет других стран.

Таким образом, большинство разработчиков в компании будут разработчиками Java (или .NET, о чем идет речь). Чтобы заставить их работать в пользовательском интерфейсе, вы должны использовать Java-совместимую технологию, например JSP или GWT. JSP потребовалось бы изучить библиотеки JS, чтобы сделать интерфейс более или менее презентабельным.

Очевидно, что если вы хотите произвести впечатление на публику уникальным пользовательским интерфейсом, вам нужно использовать библиотеки JS, которые позволяют более полно настраивать. И JSP, и GWT будут работать, поскольку большая часть работы будет выполняться на JS. Как я уже упоминал выше, немногие компании имели бы в штате опытных разработчиков JS.

Однако большинство приложений написано для внутреннего использования, а не для публики. Судя по тому, что вы описали, ваш вариант использования может подпадать под эту категорию.

Внутренние закрытые инструменты часто имеют более сложную функциональность, чем общедоступные веб-сайты, но требования к их дизайну более мягкие, если они доступны и удобны для внутреннего использования.

В этом случае вы можете обойтись без GWT, который менее чужд Java-разработчикам, чем jQuery и высокоуровневые библиотеки, такие как GXT со стандартной темой.

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

Просто перейдите на страницу примеров GWT, демонстрацию реальных примеров приложений GWT

Просто прочтите о сверхтяжелой природе этих примеров.

Сам GWT не такой легкий, и я сомневаюсь, что он был разработан для создания датпикера. GWT - это нечто совершенно иное, чем jQuery. Возможно, он более сопоставим с JSF2, чем с jQuery. На вопрос «следует ли мне использовать GWT или jQuery?» Можно ответить так:

если вы хотите добавить датпикеры, некоторые эффекты, сортируемую таблицу, автозаполнение здесь и там. Вам, вероятно, следует использовать jQuery.

Если вы хотите выяснить, хотите ли вы использовать GWT в качестве механизма / механизма внешнего интерфейса, вам следует рассмотреть другие, которые фактически сопоставимы. При обсуждении Java, вероятно, ваш единственный выбор - JSF2. И кривая обучения JSF крутая.

Копаю глубже и нашла грустный пост:

http://polygoncell.blogspot.mx/2013/07/gwt-for-new-project-no-thanks.html

Я зашел на эту страницу, потому что читал о грядущих проектах, таких как AngularJS, Backbone, одностраничные приложения (SPA): короче говоря, Google отказался от GWT. GWT теперь с открытым исходным кодом, потому что они просто отказались от него. Теперь AngularJS получил большой толчок от Google.

РЕДАКТИРОВАТЬ наш дорогой Андрей сказал мне "доказать мою точку зрения"

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

1) Зайдите на свой любимый сайт о вакансиях

2) Найдите {интересующую вас технологию} вакансии

3) Проверьте количество вакансий, требования к соответствующей технологии и т. Д.

4) Повторите №2 и №3 для конкурентных технологий.

5) Оценить

сегодня, 19. мая 2016, на upwork я искал GWT вакансий.

Вакансий: 23.

Я искал angularjs вакансий.

Вакансий: 1338. Верно. одна тысяча триста тридцать восемь.

точка доказана?

Думаю, чтобы ответить на пункт 1, вам нужно будет посмотреть, какова ваша текущая ситуация и каковы ваши цели.

Если у вас есть команда разработчиков, которые использовали Java большую часть своей карьеры, вы, вероятно, можете рассчитывать на то, что они потратят 6 месяцев на изучение парадигм JavaScript. Если у вас есть опыт работы с такими языками, как Groovy или Clojure, вы, вероятно, могли бы немного сократить это время. Итак, если вы не ожидаете, что проект продлится больше года или около того, то GWT, вероятно, будет лучшим вариантом.

И наоборот, если у вас есть команда разработчиков JS, они могут найти систему статической типизации довольно разочаровывающей, и обучение ее эффективному использованию может занять у них полгода. Так что, если это так, то вы, вероятно, не захотите использовать GWT для любого нового проекта, где кривая обучения перевешивает продуктивность.

Я не совсем уверен, о чем спрашивает пункт 2. Если вы спрашиваете о фреймворках целого стека, я предполагаю, что вы могли бы найти что-то, используя nodejs, хотя я не думаю, что у меня достаточно опыта, чтобы давать советы по этому поводу.

В пункте 3, где я работаю, мы, кажется, движемся к использованию JS-фреймворков (в частности, AngularJS) с некоторыми (новыми) серверами / службами, написанными на Python и Groovy, а устаревшие системы все еще находятся на Java. У нас также есть несколько сервисов, написанных на Clojure.

GWT уместен. Им пользуются 130 000 разработчиков. Если вы мне не верите, просто посмотрите на [GWT возвращается в ... в 2015 году] [blog.xam.de/2014/02/gwt-is-coming-back-in-2015.html] и еще один вопрос по stackexchange. который говорит об этом. GWT не должен быть вашим первым вариантом, потому что он добавляет много сложности.

Для каких проектов подходит GWT? GWT намного сложнее:

• Java - более сложный язык, поэтому писать плохой код сложно
• Компиляция в javaScript добавляет сложности
• GWT был создан с нуля для чрезвычайно сложных веб-приложений.
• Сообщество GWT имеет тенденцию ставить во главу угла взаимодействие с пользователем и производительность над опытом разработчика больше, чем сообщество javaScript.

Однако он чище, удобнее в обслуживании, это java, он быстрее, и вы можете повторно использовать свой код на jvm и ios, если используете J2ObjC

есть несколько очень веских причин использовать GWT - Java
- повторно использовать свой собственный код с других платформ. Например, почтовый ящик Google повторно использует большую часть своего кода Android в Интернете с помощью GWT и повторно использует его код снова на iPhone (спасибо J2ObjC) и на сервере (спасибо за способность JVM работать на многих разных платформах). - использовать библиотеки и инструменты java, разработчики java - многие разработчики предпочитают java js и имеют веские причины предпочесть его - созданы с нуля для сложных, производительных веб-приложений. - Код Java чище и удобнее в обслуживании

GWT снижается согласно тенденциям Google и действительно тенденции в сфере вакансий, но javaScript и jQuery также снижаются. Я не знаю, почему все эти технологии падают. Моя теория заключается в том, что существует множество новых фреймворков, которые крадут разработчиков из GWT и javaScript. Я не думаю, что это обязательно означает, что javaScript и GWT еще умирают. Это не более чем результат гораздо большей конкуренции.