Коли не використовувати веб-інструментарій Google? [зачинено]

Я розглядаю можливість використання GWT для головного внутрішнього проекту розробки веб-додатків, а саме головна перевага в моїх очах - це перехресна компіляція до Javascript, яка (принаймні теоретично) допоможе моїй команді зменшити розмір стека технологій на один .

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

Які аргументи проти використання GWT і чому?

Я і добре, і погано відповідати на це питання - добре, тим, що я його фактично використовував раніше, і погано, тим, що я був досить досвідченим з HTML / CSS / JavaScript перед роботою з GWT. Це залишило мене збентеженим від використання GWT таким чином, що інші розробники Java, які насправді не знають DHTML, не могли бути.

GWT робить те, що говорить, - абстрагує JavaScript і певною мірою HTML в Java. Для багатьох розробників це звучить геніально. Однак ми знаємо, як стверджує Джефф Етвуд, всі абстракції - це невдалі абстракції (варто прочитати, якщо врахувати GWT). Що стосується GWT, це конкретно вводить такі проблеми:

Використання HTML у GWT відстійно.

Як я вже казав, певною мірою навіть абстрагує HTML. Це добре звучить для розробника Java. Але це не так. HTML - це формат розмітки документа. Якщо ви хочете створити об'єкти Java для визначення документа, ви б не використовували елементи розмітки документа. Це безумно багатослівне. Це також недостатньо контролюється. У HTML існує по суті один спосіб запису <p>Hello how are <b>you</b>?</p>. У GWT у вас є 3 дочірні вузли (текст B, текст), приєднані до Pвузла. Ви можете створити P першим або спочатку створити дочірні вузли. Один із дочірніх вузлів може бути результатом повернення функції. Після декількох місяців розробки з багатьма розробниками, спроба розшифрувати, як виглядає ваш HTML-документ, відстежуючи код GWT - це процес, що викликає головний біль.

Зрештою, команда вирішила, що можливо використання правильного шляху HTMLPanel для всіх HTML. Тепер ви втратили багато переваг GWT - наявність елементів, доступних для коду Java, для легкого зв’язування даних.

Використання CSS у GWT відстійно.

Приєднання до абстракції HTML це означає, що спосіб використання CSS також відрізняється. Це, можливо, покращилось з моменту останнього використання GWT (близько 9 місяців тому), але на той час підтримка CSS була безлад. Через те, як GWT змушує вас створювати HTML, у вас часто є рівні вузли, які ви не знали, що їх було введено (будь-який розробник CSS знає, як це може різко вплинути на рендерінг). Існує надто багато способів вбудовування або зв’язування CSS, що призводить до заплутаного безладу просторів імен. Крім того, у вас була підтримка спрайту, що знову звучить приємно, але насправді вимкнено ваш CSS, і у нас виникли проблеми з написанням властивостей, які потім довелося явно перезаписати пізніше, або, в деяких випадках, зірвали наші спроби співставити наші руки - закодований CSS і потрібно просто переробити його таким чином, щоб GWT не накрутив його.

Союз проблем, перетин переваг

Будь-які мови матимуть свій власний набір проблем та переваг. Чи використовуєте ви це - зважена формула, заснована на них. Коли у вас є абстракція, ви отримуєте об'єднання всіх проблем і перетин переваг. У JavaScript є свої проблеми, і це зазвичай насміхається серед інженерів на стороні сервера, але він також має досить багато функцій, які корисні для швидкого веб-розробки. Подумайте про закриття, скорочення синтаксису, спеціальні об’єкти, усі речі, виконані Jquery (як запит DOM за допомогою селектора CSS). Тепер забудьте про його використання в GWT!

Поділ проблем

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

Настільний! = Інтернет

Як @Berin Loritsch розмістив у коментарях, модель або менталітет GWT створений для живих додатків, де програма має живий дисплей, щільно поєднаний з процесорним двигуном. Це звучить добре, тому що саме так багато хто відчуває в Інтернеті. Але є дві проблеми: A) Веб-мережа побудована на HTTP, і це по суті відрізняється. Як я вже згадував вище, для цієї платформи були побудовані технології, побудовані на HTTP - HTML, CSS, навіть завантаження ресурсів та кешування (зображення тощо) . B) Розробники Java, які працюють в Інтернеті, не легко переходять на цей настрій настільних додатків. Архітектура в цьому світі - зовсім інша дисципліна. Розробники Flex, ймовірно, більше підходять для GWT, ніж веб-розробники Java.

На закінчення ...

GWT здатний досить легко створювати швидкі та брудні програми AJAX, використовуючи лише Java. Якщо швидко і брудно виглядає не так, як ви хочете, не використовуйте це. Компанія, над якою я працювала, - це компанія, яка багато піклувалася про кінцевий продукт, і користувачеві це почуття польської, як візуальної, так і інтерактивної. Для нас, що розробляються на передньому рівні, це означало, що нам потрібно було керувати HTML, CSS та JavaScript способами, завдяки яким GWT намагався грати на фортепіано з боксерськими рукавичками.

Ми використовуємо GWT для великого веб-додатку електронного уряду (SOA в бекенде), який має велике використання. Старий інтерфейс був у DHTML, але у нас виникли проблеми із сумісністю браузера, оптимізацією продуктивності та процесом розробки, тому ми шукали альтернативи.

Наші вимоги:

• рівень інтерфейсу клієнтської сторони для мінімізації завантаження сервера
• сумісність браузера
• RIA на основі веб-сторінок
• Прості оптимізації продуктивності
• Не потрібна установка клієнтських плагінів, вона повинна працювати з звичайною установкою Windows

Ми обрали GWT, і я ніколи про це не шкодую. Нова команда не мала або менше досвіду DHMTL, і тому процес розробки Java GWT був дуже корисним. Що ви отримуєте від коробки:

• сумісність браузера
• Процес розробки та використання коду на основі Java
• просте мінімізація запитів (пакет зображень, ...)
• легке агресивне кешування (нові програми повністю кешовані на стороні клієнта)
• легке стиснення всіх ресурсів (навіть з js на старих баггі IE)
• і багато іншого, багато що тут згадати

Наша програма надсилає лише один запит на сервер при запуску. З негативної сторони те, що GWT (а також Android) має поганий дизайн поза коробкою, але все одно, якщо ви застосовуєте власний вигляд і відчуваєте, що вам доведеться адаптувати CSS. Крім того, ви можете використовувати різні бібліотеки компонентів для GWT, що спрощує застосування правильних стилів та тематизації.

Для мене немає сенсу, що, можливо, HTML DOM не такий хороший, як ручний, це ніколи не було проблемою. Коли я розробляю C ++, я не дивлюся на створений код асемблера. Коли я розвиваюся в GWT, ніколи не було для мене приводу дивитися JS-код і лише один раз привід дивитись на DOM і робити якийсь рефакторинг.

Для мене GWT - єдиний вибір, коли мова йде про розвиток RIA, і я сподіваюся, що GWT має світле майбутнє. Дивіться заяву місії за адресою:

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

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

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC