По-прежнему ли GWT подходит для новых проектов?

Ответ 1

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

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

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

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

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

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

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

Относительно точки 2:

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

Относительно точки 3:

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

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

Просто подойдите к: Страница примера GWT, демонстрация реальных примеров приложений GWT

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

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

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

Если вы хотите выяснить, хотите ли вы использовать GWT в качестве механизма шаблона/механизма frontend, вы должны рассмотреть другие, которые на самом деле сопоставимы. При обсуждении 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) Поиск {технологии, которая вас интересует} jobs

3) Проверьте количество отверстий, связанные с ними требования к технологиям и т.д.

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

5) Оцените

сегодня 19 мая 2016 года, в ходе работы я искал задания GWT.

Работа: 23.

Я искал задания angularjs.

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

Какие проекты GWT хорошо? GWT намного сложнее:

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

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

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

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