Большое спасибо за книгу! Приобрел себе на leanpub больше полугода назад. Всячески рекомендую книгу по архитектуре — т.к. содержит конкретные и емкие примеры без лишнего словоблудия.
Мне разве что местами не хватало последовательных шагов. В целом превосходная книга и своих денег стоит. Стоит поддержать автора рублем.
Скажу честно дал паре человек почитать и они потом купили свои экземпляры книги.
Все так. Плюс несколько добавлений. Есть макро и микроприложения.
Макро — клей между микроприложениями. Он должен быть как можно легче и загружаться как можно быстрее, т.к. он присутствует на любой странице и грузится в любом случае.
Для 95% приложений не нужны микрофронты достаточно продуманного API на input и output и релиза раз в день.
Какие еще оверхеды несет микрофронт?
1. Частые билды вхолостую — например, когда меняется общий компонент — мы должны проверить типы во всех местах использования, чтобы убедиться, что ничего не сломано.
2. Появляется отдельная сервисная команда сопровождающая макроприложение, т.к. все хотят туда залезть, но кому-то нужно следить за консистентностью API.
3. Нетривиальный роутинг сделать не получится.
В идеальной картине мира — каждый микрофронт имеет свой namespace, а уже внутри него накручивает те урлы, что ему нужны. Но может быть нюанс, если на странице несколько микрофронтов с одинаковым неймспейсом — как быть тогда.
4. Обработка глобальных клавиш — постоянные коллизии для стрелочек, enter, esc, особенно если они все подписаны на window.
Возможно как-нибудь напишу статью о подводных камнях.
Это потому что со временем накапливается ошибка и если глядеть на ползунок прокрутки слева он все время скачет вверх-вниз из-за накапливания и уменьшения ошибки расчета комментария.
Вообще я снимаю шляпу за рабочее решение по виртуальному скроллингу для контента произвольной высоты для веба без первоначального обсчета и рендеринга всех элементов в дом.
recoil работает очень медленно.
1к обновлений занимает на моем ноутбуке 700мс.
Тогда как обновление того же свойства напрямую 8мс, с Object.assign 32мс.
Плюс я бы не сказал, что синглтон требующий на вход уникальные строки на все приложение так уж хорош.
Язык в вашем случае значения не имеет. $mol сам по себе отдельный язык.
Ваших контактов не было, да и желания обращаться к человеку писавшему eval в коде нет совершенно.
Hello world текущей версии мола запускал — но вылетела ошибка компиляции, ведущая в недра фреймворка. redyuf мне помочь не смог. Сказал что у него все работает.
Так случилось что с вашим кодом я познакомился лично 4 года назад, когда работал в одной компании, где был внедрен $mol.
Моей первой задачей было немного модифицировать pipeline сборки — протащить новую схему локализации, собрать артефакт под разные среды сразу, собрать js чуть иначе.
На эту задачу я потратил 3 месяца.
Сборка была написана на $mol.
Что я обнаружил:
1. Код написан на ES1 code style, с eval, new Function('asksd ')
2. Активно используются сайд-эффекты в непредсказуемых для общей логики местах.
3. Активно используются глобальные переменные.
4. Тесты отсутствуют.
5. Написано несколько дополнительных шаблонизаторов — tree, mhtml без документации.
Я не понимал, что делает код, как повлияют мои изменения на остальную часть системы.
При этом весь этот монолит работал как единый организм. Любое мое изменение — отторгалось.
Так продолжалось 2 недели. Я приходил на работу пытался понять, что происходит в коде — уходил с работы.
Дальше я не выдержал, сломался. Поэтому переписал весь код на gulp. Сборка стала в разы понятнее. В коде использовал другую наработку github.com/zerkalica/reactive-di как заменитель ambient_context.
Однако каждый раз когда, я думал, что можно релизиться — выяснялись нюансы. Билды опирались на артефакты от предыдущих сборок и я должен был частично повторять эту логику в новой системе. $mol генерировал файлы сборки рядом с исходным кодом, а не в отдельной папке под артефакт. Это было отдельной проблемой.
Потом я столкнулся с автоматической системой сборки модулей без явных import, export на глобальных переменных. Вкратце как она работает. Есть код на регулярках. Он находит все глобальные переменные в коде начинающиеся на $ например: $zoo.animal.putInCage. Сборщик анализирует в каком файле она находится и строит дерево зависимостей между переменными. Затем делает список и конкатенирует. Проблема в том, что система поддерживала даже циклические зависимости. Поэтому в коде встречались и такие конструкции $zoo['ani' + 'mal'].putInCage и даже $zoo[anotherGlobalVarWIthAnimal].putInCage
Отдельного реверанса достойны длинные имена файлов: index.env=production.mode=development.jam.js
вместо того, чтобы разложить файлы по нужным папкам окружений.
Сейчас mol стал взрослее. Часть багов была поправлена, но распространения он так и не получил.
Есть репозиторий github.com/eigenmethod/mol
Весь uikit реализован прямо внутри фреймворка и не отделим от него.
К чему я это все?
Давайте просуммируем что имеем в сухом остатке.
1. Много детских багов.
2. Закрытая экосистема подчиненная одному автору.
3. Сомнительные архитектурные решения, т.к. не было код-ревью.
4. Нет совместимости со сторонними модульными системами.
5. API написан под конкретную задачу и не учитывает потребности внешних потребителей.
6. Если нужно делать расширение компонентов — это нужно делать с оглядкой на uikit в репозитории mol.
Mol имеет внутри множество потрясающих инженерных решений. Это действительно шедевр, как Коралловый замок. Это целая экосистема, но она бесполезна. Т.к. ее нельзя разделить на части:
1. View framework c concurrent rendering
2. Атомы
3. uikit
4. модульная система
5. inversion of control
6. helpers
7. intl
8. сборочная система
и т.д. ты не можешь использовать часть этих отличных решений не затащив в свою сборку сборку от mol.
Советы для vintage
1. Перестаньте выступать на конфах и писать статьи в руссскоязычном сегменте.
2. Выкинуть tree и заменить его на jsx — людям будет проще и привычнее принять ваш образ мыслей.
3. Сделать мостик для совместимости с react компонентами.
4. Пиариться в англоязычном коммьюнити.
5. Сделать mam как лоадер или плагин для вебпака.
6. Пересмотреть полностью внешнее API.
7. Нанять bunopus для продвижения фреймворка. C dart он смог.
З.Ы. Статья хорошая. Даже плюсанул, но с автором по многим вопросам не согласен принципиально, поэтому минусанул профиль.
Не совсем корректно сравнивать реализации композиции и наследования. Ведь композицию можно сделать иначе — без пересоздания объекта на каждый чих.
А если сделать объекты без методов? Пусть будут stateless сервисы по колдунству, что умеют работать с колдунами и паладинами, а с рыцарями пусть не работают? Взамен они будут возвращать или измененный объект или новый инстанс объекта с измененными свойствами.
Насколько я знаю устоявшийся перевод для слова Accessibility - доступность. Инклюзивность все-таки немного про другое.
Большое спасибо @haqreu.
Всегда с удовольствием читаю ваши статьи!
Пишите еще!
Мне разве что местами не хватало последовательных шагов. В целом превосходная книга и своих денег стоит. Стоит поддержать автора рублем.
Скажу честно дал паре человек почитать и они потом купили свои экземпляры книги.
www.youtube.com/watch?v=SsxkYauiICQ
Макро — клей между микроприложениями. Он должен быть как можно легче и загружаться как можно быстрее, т.к. он присутствует на любой странице и грузится в любом случае.
Для 95% приложений не нужны микрофронты достаточно продуманного API на input и output и релиза раз в день.
Какие еще оверхеды несет микрофронт?
1. Частые билды вхолостую — например, когда меняется общий компонент — мы должны проверить типы во всех местах использования, чтобы убедиться, что ничего не сломано.
2. Появляется отдельная сервисная команда сопровождающая макроприложение, т.к. все хотят туда залезть, но кому-то нужно следить за консистентностью API.
3. Нетривиальный роутинг сделать не получится.
В идеальной картине мира — каждый микрофронт имеет свой namespace, а уже внутри него накручивает те урлы, что ему нужны. Но может быть нюанс, если на странице несколько микрофронтов с одинаковым неймспейсом — как быть тогда.
4. Обработка глобальных клавиш — постоянные коллизии для стрелочек, enter, esc, особенно если они все подписаны на window.
Возможно как-нибудь напишу статью о подводных камнях.
Вообще я снимаю шляпу за рабочее решение по виртуальному скроллингу для контента произвольной высоты для веба без первоначального обсчета и рендеринга всех элементов в дом.
1к обновлений занимает на моем ноутбуке 700мс.
Тогда как обновление того же свойства напрямую 8мс, с Object.assign 32мс.
Плюс я бы не сказал, что синглтон требующий на вход уникальные строки на все приложение так уж хорош.
Ваших контактов не было, да и желания обращаться к человеку писавшему eval в коде нет совершенно.
Hello world текущей версии мола запускал — но вылетела ошибка компиляции, ведущая в недра фреймворка. redyuf мне помочь не смог. Сказал что у него все работает.
Действительно. 4 года.
Так случилось что с вашим кодом я познакомился лично 4 года назад, когда работал в одной компании, где был внедрен $mol.
Моей первой задачей было немного модифицировать pipeline сборки — протащить новую схему локализации, собрать артефакт под разные среды сразу, собрать js чуть иначе.
На эту задачу я потратил 3 месяца.
Сборка была написана на $mol.
Что я обнаружил:
1. Код написан на ES1 code style, с eval, new Function('asksd ')
2. Активно используются сайд-эффекты в непредсказуемых для общей логики местах.
3. Активно используются глобальные переменные.
4. Тесты отсутствуют.
5. Написано несколько дополнительных шаблонизаторов — tree, mhtml без документации.
Я не понимал, что делает код, как повлияют мои изменения на остальную часть системы.
При этом весь этот монолит работал как единый организм. Любое мое изменение — отторгалось.
Так продолжалось 2 недели. Я приходил на работу пытался понять, что происходит в коде — уходил с работы.
Дальше я не выдержал, сломался. Поэтому переписал весь код на gulp. Сборка стала в разы понятнее. В коде использовал другую наработку github.com/zerkalica/reactive-di как заменитель ambient_context.
Однако каждый раз когда, я думал, что можно релизиться — выяснялись нюансы. Билды опирались на артефакты от предыдущих сборок и я должен был частично повторять эту логику в новой системе. $mol генерировал файлы сборки рядом с исходным кодом, а не в отдельной папке под артефакт. Это было отдельной проблемой.
Потом я столкнулся с автоматической системой сборки модулей без явных import, export на глобальных переменных. Вкратце как она работает. Есть код на регулярках. Он находит все глобальные переменные в коде начинающиеся на $ например: $zoo.animal.putInCage. Сборщик анализирует в каком файле она находится и строит дерево зависимостей между переменными. Затем делает список и конкатенирует. Проблема в том, что система поддерживала даже циклические зависимости. Поэтому в коде встречались и такие конструкции $zoo['ani' + 'mal'].putInCage и даже $zoo[anotherGlobalVarWIthAnimal].putInCage
Отдельного реверанса достойны длинные имена файлов: index.env=production.mode=development.jam.js
вместо того, чтобы разложить файлы по нужным папкам окружений.
Сейчас mol стал взрослее. Часть багов была поправлена, но распространения он так и не получил.
Есть репозиторий github.com/eigenmethod/mol
Весь uikit реализован прямо внутри фреймворка и не отделим от него.
К чему я это все?
Давайте просуммируем что имеем в сухом остатке.
1. Много детских багов.
2. Закрытая экосистема подчиненная одному автору.
3. Сомнительные архитектурные решения, т.к. не было код-ревью.
4. Нет совместимости со сторонними модульными системами.
5. API написан под конкретную задачу и не учитывает потребности внешних потребителей.
6. Если нужно делать расширение компонентов — это нужно делать с оглядкой на uikit в репозитории mol.
Mol имеет внутри множество потрясающих инженерных решений. Это действительно шедевр, как Коралловый замок. Это целая экосистема, но она бесполезна. Т.к. ее нельзя разделить на части:
1. View framework c concurrent rendering
2. Атомы
3. uikit
4. модульная система
5. inversion of control
6. helpers
7. intl
8. сборочная система
и т.д. ты не можешь использовать часть этих отличных решений не затащив в свою сборку сборку от mol.
Советы для vintage
1. Перестаньте выступать на конфах и писать статьи в руссскоязычном сегменте.
2. Выкинуть tree и заменить его на jsx — людям будет проще и привычнее принять ваш образ мыслей.
3. Сделать мостик для совместимости с react компонентами.
4. Пиариться в англоязычном коммьюнити.
5. Сделать mam как лоадер или плагин для вебпака.
6. Пересмотреть полностью внешнее API.
7. Нанять bunopus для продвижения фреймворка. C dart он смог.
З.Ы. Статья хорошая. Даже плюсанул, но с автором по многим вопросам не согласен принципиально, поэтому минусанул профиль.
gist.github.com/kevmoo/b60dc2fc7ea49acecb1fd2b57bf9be57
А если сделать объекты без методов? Пусть будут stateless сервисы по колдунству, что умеют работать с колдунами и паладинами, а с рыцарями пусть не работают? Взамен они будут возвращать или измененный объект или новый инстанс объекта с измененными свойствами.