Надішліть Ембер на дієту та процвітайте інноваціями

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

Спочатку я хочу надати деяку довідкову інформацію про себе та компанію, в якій я працюю. Ми в Roomle використовуємо Ember, оскільки це дуже ранні дні. Наше перше зобов’язання щодо нашого проекту Ember датується початком 2013 року. За цей час ми отримали великий досвід і познайомилися з хорошими та поганими частинами Ember. Ми також запустили виробничі веб-програми, які використовують Glimmer.js як свою структуру інтерфейсу. Зараз ми переписуємо частини нашого головного додатку в Ember Octane за допомогою TypeScript, тому ми також знаємо, як бути першим користувачем.

Оскільки ми невеликий стартап і зосереджені на створенні власного продукту, ми не внесли додаткові доповнення чи велику кількість коду, але допомогли виправити деякі проблеми, а також створили невеликі PR для кількох проектів екосистеми Ember.

Перш ніж почати, я хочу додати застереження: нам дуже подобається Ембер, і я не хочу створювати враження, що нам це не подобається. Цей допис у блозі стосується областей, які слід вдосконалити, а не приємних речей 😉

Ca Підсумок дорожньої карти 2018 року

Перш ніж зануритися у майбутнє, я хочу зробити короткий підсумок «Дорожньої карти» 2018 року. Я хочу зазначити, що я підбиваю підсумки як аутсайдер, який не входить до жодної основної команди. Тож майте на увазі, що дуже ймовірно, що я пропускаю деякі важливі речі. Тим не менше, я думаю, що можу надати хороший зворотний зв'язок, оскільки це також те, як інші, хто не дописував внески, могли бачити прогрес рамки. Давайте подивимось теми, які ми як спільнота хотіли вдосконалити минулого року:

Поліпшити спілкування та впорядкувати прийняття рішень

У цій темі було багато покращень. Крім того, перехід на Discord був хорошим і пройшов гладко. Але я думаю, що спілкування навколо Ember Octane було не надто ідеальним. Люди стримували проект, тому що не хотіли розпочинати з «спадщини» Ембера. Оскільки Ember Octane все ще не поставляється (лише попередній перегляд), деякі мої колеги оглянули інші фреймворки, а деякі з них залишили Ember на користь Vue та Vue-CLI (здебільшого завдяки чудовим інструментам збірки).

На мою точку зору, спілкування навколо Октану мало дві великі проблеми

Надмірна комунікація: важко було відстежувати, що відбувається і що має сенс прийняти. Звичайно, кожен міг залишитися на «щасливому шляху», але коли ви починаєте новий проект, ви не хочете використовувати старий спосіб робити щось. Ми також розпочали новий проект Ember незадовго до Ember Conf 2019, і ми також боялися, що запустимо абсолютно новий додаток у застарілому вигляді. Я відчував, що спілкування навколо Октана створює певну невизначеність.

Над перспективним і недостатнім: коли ми розглянемо цілі, які були встановлені для Octane, багато з них були відкладені (особливо довгоочікувані вдосконалення для збірки, я детально опишу збірку в наступному розділі). Не зрозумійте мене неправильно. Я дуже люблю Ember Octane, але більша частина виконаної роботи стосується досвіду розробників. Я знаю, що такі речі, як рідні класи, створюють основу для подальших вдосконалень, але зараз ці речі насправді не задіяні. Ember має історію багатообіцяючих речей, наприклад: маршрутизовані компоненти, уніфікація модулів тощо, які ніколи не потрапляють, тому, я думаю, нам потрібно бути дуже обережними, що ми обіцяємо і як ми повідомляємо ці обіцянки громадськості.

Tldr; спілкування значно покращилося, але в деяких випадках ми повинні бути більш чутливими до того, як і як ми спілкуємось

Завершіть те, що ми розпочали, і відправте вугільний октан

Обидві цілі дорожньої карти мали багато перекриттів. Я думаю, що громада Ембер змогла закінчити багато розпочатих справ. Що стосується Ember Octane, нам не вдалося його доставити протягом часу дорожньої карти 2018 року (я все ще вважаю попередньою версією). Я також хочу виділити деякі цілі Ember Octane, які не були відправлені, і я думаю, що це має бути частиною дорожньої карти 2019 року, тому я починаю з кількох цитат дорожньої карти 2018 року:

Програми вмісту, де сторінки мають велику кількість тексту і де перше завантаження є критичним. У середовищах з обмеженою продуктивністю сильні правила Ember можуть допомогти розробникам створювати швидші програми за замовчуванням.

Тут ключова фраза перше навантаження. Якщо ви робите ember init і створюєте просту програму "Hello World", набори JS складають приблизно 700 КБ. Мої перші експерименти з Embroider були кращими, але все одно не дали задовільних результатів. Пакет все ще складав близько 400 КБ JavaScript. Це занадто багато. Хоча мені дуже подобається Ember, нам довелося залишити Ember для певних проектів через розмір пакета JS. Не кожен проект є адміністративним інтерфейсом для введення даних для бекенда. Спеціально для наших проектів електронної комерції Ember не був життєздатним варіантом лише через розмір пакета. Я хотів би бачити значні вдосконалення в цій галузі 💖

Treeshaking для автоматичного видалення коду, який не використовується додатком

Це дуже пов’язано з пунктом зверху. Ембер має стати першокласним і провідним у галузі з точки зору похитування дерев. Оскільки Ember - це “батареї, що входять до комплекту”, наші комплекти завжди будуть величезними, якщо ми не маємо чудового струшування дерев.

Збірки Svelte, де застарілі функції вилучаються з фреймворку. Ми ставатимемо більш агресивними щодо припинення використання коду, який не використовується широко.

Я думаю, що такий сучасний інструмент побудови, як Embroider, повинен просто видалити все непотрібне. Незалежно від того, застаріла функція чи ні.

НІ З ЯКИХ ЦІЛЕЙ: Подальша оптимізація Glimmer VM. Ефективність блискучої роботи є провідною в галузі, а не вузьким місцем у більшості додатків Ember.js. На даний момент корисне навантаження Ember.js є основним вузьким місцем для продуктивності, і ми повинні звернути свою увагу на забезпечення кращої продуктивності там.

Підводячи підсумок, основна команда усвідомлює, що розмір корисного навантаження - це велика тема, і вона була відповідно розглянута в дорожній карті на 2018 рік, але ми не досягли цієї мети.

Нам дійсно потрібно зменшити розміри корисного навантаження і доставляти лише те, що потрібно для початкового відтворення!

Все інше потрібно завантажувати на вимогу і ліниво. Оскільки Ember має сильні умови, ми могли б зробити ці складні речі досить приємними для розробників.

Tldr; мій підсумок 2018 року: будь ласка, будь ласка, будь ласка виправити розмір корисного навантаження Ember щоб зробити його можливим для більшої кількості проектів 🚀

🎁 Побажання на 2019 рік

Я думаю, що нам слід зосередитись на наслідках з 2018 року, але я також маю побажання на 2019 рік

AgainЗалужте знову до інновацій

Багато років тому Ember був провідним у галузі в багатьох аспектах. Давайте подумаємо про чудовий маршрутизатор, прийняття ES6 та ES-модуля, використання Promises, CLI тощо. Протягом останніх років здається, що Ember працює позаду великих фреймворків і має проблеми, щоб не відставати.

Я не думаю, що нам слід намагатися впроваджувати інновації швидше за інших, але нам слід починати спочатку, щоб процвітати інновації в просторі Ембер. Можливо, було б непогано створити команду “інновацій”, як у нас є основна команда, навчальна команда тощо. Команда інновацій могла б зосередитись на речах, які є унікальними для Ember. Деякі речі я не бачив у жодній іншій структурі:

Бінарні шаблони
Візуалізуйте движок як модуль WebAssembly
не має прямого відношення до Ember, але щось на зразок css-block буде чудовим

Перші дві функції вже були представлені на виставці Ember Conf 2018, але вони все ще не поставляються. Ембер знову повинен мати деякі особливості, які відрізняють його від усіх інших. Сама по собі “Конвенція щодо конфігурації” буде занадто меншою, щоб залишатися актуальною.

Build Збірка та вишивка

Багато інших вже зазначали, що Embroider - це найважливіший проект 2019 року. Я можу повністю погодитися, оскільки це дозволить Ember використовувати стандартні в галузі інструменти для упаковки. Деякі побажання Вишивати та вдосконалену систему збірки:

створювати різні версії пакетів JavaScript, щоб ми могли доставляти невеликий та сучасний код до сучасних браузерів та застарілих пакетів для старого браузера
включайте лише те, що потрібно він же тремтіння дерев
полегшити ледачим завантаження речей. У часи HTTP2, натискання сервера, попереднє завантаження тощо та примітиви JavaScript, такі як async/await, ми повинні почати широко використовувати ліниве завантаження

Якщо у нас є надзвичайний чудовий інструмент збірки та комплектування, ми також можемо виконати обіцянку npm встановити ваш шлях до Ember. Я думаю, що нам слід перейменувати цю фразу, оскільки iner init все ще може встановлювати всі пакунки в папку node_modules, але розробник додає щось до корисного навантаження, лише якщо він/він імпортує його в якийсь момент програми. Мені подобається ця ідея, тому що ми все ще могли б надати кураторський набір інструментів і не карати користувачів, яким потрібні лише невеликі частини фреймворку.

Якщо ми продовжуємо використовувати Брокколі, ми повинні краще документувати, як писати плагіни. Якщо мені справді доводиться писати плагін збірки, я завжди в кінцевому підсумку копіюю подібні плагіни Брокколі і видаляю непотрібні мені речі. Часто мені доводиться налагоджувати за допомогою node --inspect-brk. Розробка плагінів для побудови - зовсім не цікаво

👵 Переосмислити “стабільність без застою”

Я дуже люблю Ember за те, що робить оновлення легкими і не порушує зворотну сумісність. Але завжди, коли я починаю новий проект Ember, я думаю:

"Чому я повинен нести весь цей багаж років тому"

Також відчувається, що зосередження на зворотній сумісності сильно уповільнює нас. Я не впевнений, як вирішити цю проблему, і думаю, що насправді важко потрапити в солодке місце між тим, як "ламати" речі і залишати все як є. Можливо, ми могли б забезпечити полізаповнення для старих програм і видалити застарілий код із кодової бази Ember. Іноді я відчуваю, що ми більше стоїмо на стороні застою, особливо з великих тем, таких як збірка, контролери, новий макет файлової системи тощо.

TypeScript

Ми працюємо з ember-cli-typecript з лютого 2019 року, і це працює як шарм. Ми любимо підвищення продуктивності, яке дає нам TypeScript. Крім того, це полегшує виявлення коду для всіх розробників проекту. З TypeScript набагато менше шансів, що хтось реалізує щось, що вже існує. Особливо для бібліотек та аддонів чудово мати такі речі, як заповнення коду та IntelliSense.

Незважаючи на те, що TypeScript та Ember чудово грають разом, я думаю, що нам слід ще більше вдосконалювати підтримку TypeScript в екосистемі Ember. Було б чудово, якби топ-100 аддонів мали визначення TypeScript і були закодовані для роботи з TypeScript.

Нещодавно ми маємо деякі проблеми з декораторами TypeScript та новими характеристиками декоратора TC39. Не впевнений, у чому проблема, але ми завжди повинні також враховувати користувачів TypeScript.

Крім того, було б чудово бачити такі речі, як набрані шаблони тощо.

✨ Glimmer.js

Ми використовуємо Glimmer.js в одному з наших проектів, і він чудово працює, але відчувається якось як мертва земля. На початку було так багато розробок, але зараз здається, що всі сили об’єднані, щоб Ембер Октан був відправлений. Нам потрібен якийсь спосіб повернути користувачів Glimmer.js назад у “щасливий шлях” Ember. Можливо, нова система збірки та Embroider могли б тут допомогти, але зараз ми відчуваємо себе загубленими з Glimmer.js ☠

Data Ember-Data

Коли ми починали свій останній проект Ember, нам довелося залучити нових розробників. І основні концепції Ембера їм було легко зрозуміти. Але часто плутанина виникала, коли у них виникало якесь питання в поєднанні з Ember-Data. З точки зору навчання, я думаю, є три основні проблеми

Що таке Ember-Data і що таке Ember? Рядки дуже розмиті.
Навіщо нам потрібні спеціальні методи, такі як objectAt, іноді, а іноді ні? Чому нам потрібно toArray перед застосуванням власних методів масивів тощо.
Удосконаліть документи та поясніть, що таке Ember-Data, надайте кілька найкращих практик та рецептів та порівняйте їх із інструментами з інших систем. Деякі з наших розробників, які перейшли з React, завжди думали, що Ember-Data - це Redux в Ember

Крім того, нам також потрібно розглянути, як зменшити розмір корисного навантаження Ember-Data

🌃 Моно-репо

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

Я не знайшов простого способу імпорту з папки common-stuff. Було б чудово, якби я міг просто зробити імпорт .