Dev підходить до складного інтерфейсу JavaScript [закрито]

Я намагаюся зрозуміти ландшафт різних підходів та найкращих практик навколо розробки складного JavaScript на стороні клієнта.

Я не впевнений, що мітити цей клас додатків, можливо, важкі AJAX або RIA (але не такі плагіни, як Flash / Silverlight). Я маю на увазі веб-додатки з такими характеристиками:

• Емуляція багатофункціонального / рідного робочого столу UX в JavaScript
• Найбільше / все поведінка в JS на стороні клієнта, використовуючи сервер як API даних (JSON / Html-Templates).

Це на відміну від використання веб-сервера для надання інтерфейсу користувача, створюючи весь HTML у моделі оновлення сторінки.

Деякі приклади:

• Документи Google / Gmail
• Mindmeister
• Основний трекер

Коли ми рухаємося вперед до HTML5, я бачу, що цей стиль розвитку RIA з важким JavaScript стає все більш поширеним і необхідним для конкуренції.

ЗАПИТАННЯ: Отже, які спільні підходи виникають навколо управління такими важкими розробками СВ?

Код клієнта, як додаток зростає у функціях, є нелегко складним. Є проблеми з масштабуванням зусиль на розробку в декількох командах із сирим JS (або я так чую, і я в це можу повірити).

Google вирішив проблему, створивши GWT, що компілює з мови вищого рівня (Java) на JS, спираючись на існуючу інфраструктуру розробки, якою володіє мова вищого рівня (Eclipse, сильний набір тексту, інструменти рефакторингу), а також обмеження сумісності браузера та інші питання, що відходять від розробника.

Є й інші інструменти, наприклад, Script # for C #, які роблять щось подібне. Все це ставить JS більше в ролі IL (Intermediate Language). тобто. "Ви більше ніколи не пишете на цій" низькій мові "."

Але ця «компіляція до JS» - не єдиний підхід. Не очевидно, що GWT є домінуючим підходом ... чи дійсно стане ним.

Що люди роблять із JavaScript з багатим клієнтом? Деякі орієнтуючі питання:

• Чи більшість магазинів розробляє JS вручну (зверху, наприклад, jQuery та ін)?
• Або існує багато різних підходів, без чітких найкращих практик?
• Чи більшість магазинів уникають розробки масштабів RIA на користь простішої для розробника моделі на стороні сервера / перемальовування сторінок? Якщо так, чи це триватиме?
• Чи є компіляція в JS можливою тенденцією в майбутньому? Або це просто неправильна голова?
• Як вони керують складністю та рефакторингом клієнта JS?
• Модуляризація та розподіл роботи по командах?
• Застосування, впровадження та тестування моделей на стороні клієнта, таких як MVC / MVP тощо.

Отже, які тенденції виникають у цьому важкому майбутньому нашого JavaScript та HTML5?

Спасибі!

Більшість веб-застосунків, які я бачу (і веб-розробників, з якими я говорив), які рухаються в цьому напрямку, використовують jQuery як свою базу.

Ціле міркування GWT (і подібних багаторівневих мов) полягає в тому, що JavaScript занадто невловимий / надто крихкий / занадто мінливий, щоб використовувати "справжніх програмістів". Але якщо у вас є рамка, що обробляє дрібні / крихкі / мінливі біти для вас, то немає ніяких причин додавати цей додатковий шар складності.

Просто моя думка ...

Я б сказав, що GWT є ризикованим. Після того, як ви вирішили використовувати його, ви з цим застрягли. В основному це означає, що ви ставитесь до розмітки, DOM та деяких аспектів CSS як середовища виконання. Поєднувати написаний JavaScript вручну з GWT стає дуже важко, оскільки ваш клієнтський код стає все більш досконалим. У GWT є власні методи, але вони досить обмежені з точки зору можливої ​​застосованості. Це велика торгівля, і це велика ставка.

Google намагається продати GWT як дуже швидке середовище виконання X-платформи з гідною інтеграцією на стороні сервера. Але як вже зазначали інші, це вже не так - JQuery і YUI так само швидко, якщо не швидше. І набагато простіше профілювати та оптимізувати ваші сторінки, коли вони збираються вручну, щоб ви мали повний контроль над CSS, розміткою та JavaScript.

GWT намагається приховати від вас базову платформу, що насправді може бути неправильним способом вчинити. Багато так званих компонентних веб-фреймворків зробили те саме. Ви повинні були написати неоднозначний XML-похідний код із EL та спеціальними тегами, вкинутими у них. Вихід був би безладно погано сформованим HTML-кодом з невеликими шматочками шаленого JavaScript, посипаних у всьому місці. Сторінки були повільними, баггі та абсолютно нездійсненними.

У нашому поточному проекті ми використовуємо Stripes - низькорівневий фреймворк, що базується на дії, - та JQuery на стороні клієнта. Зробити Ajax дуже просто, коли ви чітко бачите всі фрагменти головоломки: ось ваш код на стороні сервера, який працює на даних. Ось ваш код на стороні клієнта - для пошуку даних та для того, щоб все сталося на сторінках. Ось ваш CSS, ось ваша розмітка, ось ваша шаблона - все чисто і нероздільно. Легко розширюваний, рухомий, настроюється та налагоджується. Я це люблю.

Мені подобається JQuery за його ставлення до швидкості та простоти. Я люблю YUI3 за модульність і вичерпні віджети. Мені подобається YUI CSS за те, що він надає послідовність у веб-переглядачах. Я люблю JavaScript за гарні частини. Я люблю Java за те, що дозволив мені виконати роботу.

Просто KISS, і ти будеш добре!

Я чув про це під назвою "Односторінкові програми".

Це нове середовище, і правила ще не написані повністю. Я працював над відносно великим односторінковим додатком минулого року (2010), і це інструменти, якими ми користувалися.

Задньою частиною була Java, використовуючи сервлети для надання послуги JSON, яку сторінка використовувала для остаточного подання підготовленого замовлення. Ця послуга також використовувалася для деяких етапів перевірки та ціноутворення.

Передній код був javascript. Ми використовували jQuery для маніпулювання елементами сторінки, Pure для шаблонів та RequireJs для розбиття коду на модулі. (Інструмент збирання RequireJs використовувався для забезпечення оптимальних завантажень.)

Ми написали наші тести, використовуючи qUnit , і провели тест jUnit, який використовував htmlunit для запуску кожного тесту qUnit, а потім скреблі виведення для отримання результатів і передача або збій на основі стану проходження / відмови qUnit. Їх додали до наших тестів jUnit для заднього кінця та запустили до нашого ci, використовуючи Хадсона / Дженкінса .

Я працюю над таким додатком, побудованим поверх Ext JS. Додаток організовано модульно. Різні модулі реалізуються як автономні компоненти, які очищаються після себе, коли вони видаляються з ієрархії компонентів Ext. Завантажувачі на замовлення завантажують додаткові компоненти безпосередньо перед необхідністю (один js-файл = один компонент).

Я виявив, що такий підхід не такий важкий для масштабування. Єдині реальні обмеження, на які я зіткнувся, пов'язані з тим, що в дереві одночасно є занадто багато елементів DOM у дереві. Рішення там полягає в стратегічному вивантаженні прихованих частин програми. Оскільки всі маніпуляції з DOM відбуваються через ієрархію компонентів Ext, DOM майже повністю абстрагується, і розвиток залишається прямолінійним.

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

Щось мене здивувало, про що ніхто не згадував, - це тестування. Зараз загальноприйнято, що у складних серверних додатків повинні бути автоматизовані тестові одиниці, і я думаю, що вже настав час, коли JS у додатках RIA є досить складним, щоб потребувати тестування одиниць - разом з архітектурою / кодом, що робить це можливим.

Однак, на відміну від складних програм на стороні сервера, моє відчуття кишки ґрунтується на тому, що я бачу і чую, що переважна більшість складних клієнтських додатків абсолютно не мають одиничного тестування (я не кажу тут про тестування селену, реальне тестування одиниць).

Я думаю, що наступною тенденцією, що розвивається, буде впровадження одиничного тестування (та коду, який може бути перевірений одиницею). Щойно закінчивши проект з помірною кількістю перевіреного JavaScript, який не використовується, я сподіваюся, що він буде останнім.