ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Я просто недовольный младший разработчик ... это мнения

Мой первый опыт создания приложения на ember был кошмаром. Просто импорт moment.js был невероятно сложным процессом. Стоит ли использовать аддон ember-cli? Стоит ли использовать мост зависимостей npm, например ember-cli-cjs-transform? Должен ли я загружать его с компакт-диска как отдельный веб-пакет?

… Даже сейчас, решив проблему, я не мог сказать, какое решение я использовал.

Проблема с этой структурой двоякая. Во-первых, фреймворк собрал массу технических проблем, которые редко встречаются в мире javascript, потому что версия 1.0 Ember.js была выпущена 8 лет назад. Во-вторых, и в дополнение к первому, одним из основных убеждений сообщества ember является обратная совместимость. Это замедлило внедрение современных JS-функций во фреймворк и привело к массивной избыточности под капотом (я опасаюсь за всех разработчиков, пытающихся отлаживать, проверяя объекты).

JavaScript - совсем другой зверь, чем был 8 лет назад. Когда на сцене появился ember, backbone.js и JQuery были стандартными инструментами для создания сложных интерактивных веб-приложений. Не было веб-пакетов, сотрясение деревьев еще не было даже рукопожатием, а идея компонентного дизайна только начинала проникать в сердца и умы разработчиков. На самом деле, когда родился Ember, я был слишком молод, чтобы пить пиво и только разбираться в том, как создать игру с нуля.

Сейчас 2019 год, и мы можем заменить html на функциональный jsx. React захватил мир и, следовательно, сделал webpack самым мощным инструментом сборки на планете.

импортировать файл svgFile из "пути / в / каталог"

Добавление SVG в функциональный компонент кажется правильным способом использования ресурсов в мире, где у нас есть мощный этап транспиляции и построения. Но где сейчас Эмбер? Эмбер только что получила уроки по родному. Паттерн, который устаревает в других фреймворках. Хуже всего то, что я не верю, что в ember.js когда-нибудь будут функциональные однофайловые компоненты.

Но есть проблеск надежды ... (не обращайте на меня внимания, я худший)

Новый движок рендеринга для ember, glimmer.js, - это гигантская попытка подтолкнуть ember к современной эпохе. Это дает нам такие вещи, как настоящий родной класс, упрощенный жизненный цикл компонентов и, что наиболее важно, гораздо более мощный этап сборки. glimmer выполняет предварительную визуализацию своих шаблонов для внутренних операций JS, не нуждаясь в виртуальном домене, как у Svelt.

ГОРЯЧЕЕ ПРЕДУПРЕЖДЕНИЕ: виртуальный дом - это костыль

Виртуальный dom - это то, что нам нужно, чтобы перейти от императивной модели к модели на основе компонентов, но накладные расходы на память и время синтаксического анализа для инфраструктуры на основе виртуального dom никогда не будут лучше, чем сценарий, который просто вставляет кучу элементов. React пытается минимизировать вес виртуального dom с помощью хуков, чистых компонентов и гидратации, но он все еще создает избыточное dom в памяти. Если бы мы могли знать все возможные состояния компонента, мы могли бы использовать реальный объект в качестве нашей объектной модели документа… безумно. Вот тут-то и появляется Ember / Glimmer ...

Самое лучшее в этом фреймворке (на мой взгляд) - это строгая модель MVC. Это сохраняет вашу честность, вы не можете просто добавить теринари в свои шаблоны, вы не можете передавать обратные вызовы по 5 компонентам, чтобы ссылаться на часть состояния, которой у вас не должно быть, и вы не можете опасно устанавливать innerHtml. Сложно навязать лучшие практики веб-разработчикам, которые живут от спринта к спринту. Но если единственный способ создать приложение - это правильный способ, люди будут строить его правильно. Это позволяет glimmer сохранять ссылки на расположение данных шаблона и управлять компонентами без виртуального dom.

Это правильный способ визуализации компонента, и нам, как сообществу, он нужен прямо сейчас. Очень тяжелые одностраничные приложения, использующие виртуальные домены, захватывают Интернет, и это плохая привычка. Ни один из «большой тройки» (react, vue, angular) не движется в этом направлении, потому что эргономика этих технологий для разработчиков требует своего рода виртуального дома. Glimmer уже существует, но, чтобы сохранить обратную совместимость, ember.js разместил поверх него от десятков до сотен полифиллов для поддержки ember api. Это настолько велико, что любые накладные расходы на память, которые сохраняются в обычном приложении без использования виртуального dom, теряются из-за полифиллинга.

Так что нам делать.

МНЕНИЕ ВНИМАНИЕ

Форк ember.js, разбей все до RFC октанового числа угля. Соглашение вместо конфигурации - это мантра, которую стоит сохранить, а с ember.js - нет. Сделайте объединение модулей, переместите систему сборки в webpack и перейдите к классу компонента glimmer.

ГОРЯЧИЙ ПРИЕМ 2. Функциональные компоненты не важны без виртуального дома

Различие между шаблоном и файлом компонента отлично подходит для создания логических приложений. Стручки потрясающие. Услуги (Синглтоны) имеют смысл. Миксины тупые. EmberObject буквально гитлер.

Ember.js - это накопитель, давайте навести порядок в доме.