Comments 32
Порог вхождения на то и выше, что тратя время сначала, потом ты существенно экономишь время. Тут очень тонкий баланс. С одной стороны, на маленьких проектах не хочется тратить много времени на ядро проекта и всякие CI, c другой стороны, это всегда потом экономит кучу времени, когда билдишь и деплоишь по одной кнопке.
Порог вхождения на то и выше, что тратя время сначала, потом ты существенно экономишь время.
В «порог вхождения» в этом случае нужно включать не только время на чтение документации и мануалов, но и постоянные расходы на проект (бойлерплейт и прочую муть). В силу этого делать на ангуляре что-то маленькое (да и даже среднее, если честно) — не слишком-то имеет смысл, эти все расходы просто не успеют отбиться, и «сначала» время будет потрачено, а вот «потом» так и не наступит.
При разработке на JS-фреймвёрке не из списка TOP-3 приходится решать на порядок больше технических вопросов, чем это ожидается в начале разаботки
Вы судите обо всех фреймворках лишь по одному, не самому толковому из них. Не надо так.
Если Вы имеете в виду какой-то конкретный фреймворк, который не входит в ТОП-3, и в котором решены все или многие из поднятых вопросов — я готов проделать ту же самую работу с этим фреймворком (имеется в виду разработку приложения realworld и написания по итогам сообщения на Хабре) — только назовите его.
Согласен, надо на многое обращать внимание, однако и у ТОП-3 полно косяков, которые тоже надо иметь ввиду. Например, скорость загрузки и работы приложения, удобство отладки, архитектурная сложность, статическая типизация. Насчёт 1000 разработчиков — это вы на пару порядков преувеличили. Взять тот же Ангуляр — там всего пара десятков активных разработчиков. Отчасти это связано с архитектурной сложностью — не каждый сможет и захочет в это погружаться. А вот статей, конечно полно, в этом и суть хайпа. Ведь ТОП-3 они именно за счёт хайпа, а не за счёт каких-то своих исходных качеств.
Смело. Вы, наверно, думаете, что "все движки JS-фреймворков похожи друг на друга", однако это не так. Взять в пример $mol — у него в корне иная философия. Там нет html-шаблонов, а любое приложение создаётся путём кастомизации и комбинации готовых компонент. А особое внимание уделено автоматизации, отладке и реверс-инженерингу. Да даже если пройтись по вашему чек-листу:
- Наличие режима разработки и рабочего приложения
Наличие такого разделения приводит к неприятным багам вида: у разработчика всё хорошо, а прод лежит.
- Информативные сообщения об ошибках компиляции проекта (имя исходного файла, номер строки в исходном файле, описание ошибки)
Всё процессится тайпскриптом, так что с этим всё хорошо.
- Информативные сообщения об ошибках времени выполнения (имя исходного файла, номер строки в исходном файле, описание ошибки)
Плюс путь к объекту в рантайме от корня приложения.
- Быстрая пересборка измененных модулей
Пересобирать приходится всё, чтобы тайпскрипт всё проверил. Но делается это относительно быстро — неколько секунд.
- Горячая перегрузка компонентов в браузере
Что порождает весёлые баги вида: сейчас работает, после перезагрузки падает. Или наоборот. Гораздо лучше, когда полная перезагрузка приложения происходит мгновенно с сохранением состояния.
- Наличие версионности в имени файлов (например 4a8ee185040ac59496a2.main.js)
Лучше так: main.js?hash=4a8ee185040ac59496a2 или так: main.js?time=2019-06-17T00:00:00Z.
- Компоновка мелких модулей в один или несколько модулей (чанков)
- Разбиение кода на чанки с использованием динамического импорта
А ещё лучше, когда кода получается так мало, что его не надо резать на чанки.
Если фреймворк о котором Вы говорите это $mol — то я готов поработать с ним. Однако есть один нюанс. Мне интересно работать с технологиями которые поддерживают универсальные/изоморфные приложения то есть в общем случае хотя бы ssr. Если в этом фреймворке ssr идет из коробки или же я смогу найти к нему какую-нибудь библиотеку которая обеспечит ssr — то мне это будет интересно.
Да, он полностью изоморфный. Нужен только лёгкий адаптер для экспресса c примерно следующим содержимым:
// Configure ambient context
const $ = $mol_ambient({
$mol_stateg_arg : class extends $mol_state_arg {
static href : ()=> href
}
})
// Application instance with context
const app = $mol_app_todomvc.make({ $ })
// Render app to html
const html = app.dom_tree().outerHTML
1. Среда разработки
2. Среда сборки
3. Наличие роутинга
4. Менеджер состояний.
Вобщем-то я хотел добавить чеклист по универсальным прилоежния но во-первых такой перчень я уже раньше давал в другой своей статье. И во-вторых универсальные приложения как я заметил не вызывают большого интереса.
Но Ваш вопрос очень показательный. Вы хотели прочитать в правилах например должен ли быть там одно направленный поток данных или двунапралвенный, изменяемый стор или неизмняемый стор. А я про текстовые редакторы и про линтеры. Где же про фреймворк, справшивается?
Идея статьи в том что кроме самого фреймворка еще нужно обращать внимание на процесс разработки.
Но она не содержит того, о чём указано в заголовке.
Если бы у вас был перечень важных вопросов и рекомендации по выбору в зависимости от ответов — то да, это были бы правила.
У вас же получился только краткий и неполный перечень того, о чём нужно бы подумать тому, кто в первый раз попробует применить js-фреймворк…
Справедливости ради, эффектор покрывает не 100% функционала мобыкса. У мобыкса все зависимости by design ленивые — это может быть лучше по производительности и априори предотвражает утечки памяти.
Хотя учитывая остальные особенности мобыкса, я бы тоже выбрал эффектор.
Какие особеноости?
Я так и не понял что не так с мобыксом. Ну кроме размера.
Из-за мутабельности могут быть похожие баги.
По поводу рантайм семантики (и связанных с этим проблем у мобыкса) вы уже видели мой доклад, на сколько я помню, но вот еще раз.
Как там реализуются Map и Set, их «слабые» версии?
Через прокси. Как например $mol_atom2_dict.
Из-за мутабельности могут быть похожие баги.
А при чём тут мутабельность и кривой дизайн эффектора? MobX вполне адекватно реагирует на исключения. Разве что поддержки SuspenseAPI не хватает.
По поводу рантайм семантики (и связанных с этим проблем у мобыкса) вы уже видели мой доклад, на сколько я помню, но вот еще раз.
И помнится раскритиковал его. Код с доступом по индексу в цикле в любом случае медленнее итерирования по коллекции. Независимо от того используются прокси или нет. Да, прокси и геттеры не бесплатны. И если в проекте используется автотрекинг зависимостей, то не стоит лениться помещать свойства объектов в локальные переменные, а не дёргать их на каждый чих.
Нет, как обычному пользователю взять и начать использовать обычный Map / Set с мобыксом? В базовой поставке его нет, нужно писать свои враперы и мокать ВСЕ апи? Выглядит очень не тривиально, особенно учитывая что для некоторых методов нужно будет батчинг делать. Ну и это только пример, но он касается еще перечня менее популярных структур данных. В эффекторе / редаксе все просто — работай с данными как угодно, главное верни нову ссылку, все.
> MobX вполне адекватно реагирует на исключения
Разве исключения в derived откатят зависимые изменения? А, часто, именно этот flow подразумевается (пример по ссылке с эффектор не связан в принципе, это общая проблема реактивных данных)
По поводу семантики… Это вещи уже, я так наблюдаю (и за собой), более вкусовые, но, кажется, в мобыксе с прокси объекты могут уходить и в сторонние либы и что там будет происходить совершенно неизвестно? И автор мобыкса мне лично говорил что это крутая фича, а не то что нужно ее избегать и каждый раз сериализовать в plain data отдаваемые либам данные.
Поймите, я не хейчу мобыкс, даже часто зажищаю его (с чего начался тред), но нужно объективно оговаривать все аспекты…
(забавно, вся эта ветка уже происходила в телеграме пол года назад)
А вы так и не попробовали $mol_mem? :-)
как обычному пользователю взять и начать использовать обычный Map / Set с мобыксом?
Думаю так же как и с эффектором — никак. Является ли это проблемой?
В эффекторе / редаксе все просто — работай с данными как угодно, главное верни нову ссылку, все.
Можно подумать в мобыксе так нельзя.
Разве исключения в derived откатят зависимые изменения? А, часто, именно этот flow подразумевается
В случае ошибки вы всегда показываете устаревшие данные? Вы уверены, что пользователю всегда нужно именно это, а не сообщение об ошибке?
прокси объекты могут уходить и в сторонние либы и что там будет происходить совершенно неизвестно
Как и любые другие функции. Значит ли это, что от функций стоит отказаться?
Вполне как — засунули в стор, в редусере иммутабельно меняете, проблем нет, все очевидно
> пользователю всегда нужно именно это
пользователю библиотеки(!) нужен выбор как хендлить исключения: с иммутабельными данными можно поставить трай-кетч в редусере и в кетче выбрать дальнейшее поведение: упасть и «откатить» все наработки других редусеров / вернуть значение по умолчанию / вернуть ошибку… А с мутациями «откат» сделать будет наааамного сложнее
> Как и любые другие функции. Значит ли это, что от функций стоит отказаться?
Я думаю у нас конструктивный разговор, а вы передергиваете. Я стараюсь приводить достаточно понятные и практические пример, если у меня не получается — текстом дальше сложно общаться.
Иммутабельно с нативными мапами — это полным их пересознанием при изменении? этот вариант и на мобх элементарно работает. Но для больших данных лучше всё же создать реактивную мутабельную мапу.
Собственно с мобиксом всё то же самое, если не увлекаться реакциями, а ограничиваться компьютедами.
Вовсе не передёргиваю, прокси, геттеры, функции — всё это абстракции скрывающие сложность от пользователя. Внутри там может быть что-то легковесное, а может быть полная содомия.
Проект, который разрабатывался в ходе написания этой статьи, наконец, был одобрен контрибьюторами https://github.com/gothinkster/realworld и добавлен ссылкой в основной проект (как Riot.js + Universal + Effector):
Правила выбора JS-фреймворка