Основная идея в том, что есть «повседневные» задачи, которые могут решаться из коробки, без применения доп.лоадеров. А если нужно что-то более сложное и эдакое, то, пожалуйста, используйте лоадер
Можно было бы сделать новые лоудеры, которые делалли бы тоже самое и были бы под крылом создателей вебпака.
Указанные лоадеры итак под крылом команды разработки. Учитывайте, что webpack идет в сторону 0CJS (Zero Configuration JS) для того, чтобы для повседневных задач устанавливать и настраивать как можно меньше дополнительных модулей — установил вебпак и он с минимальными настройками (а в идеале без них) делает все, что нужно.
AM заменяют собой основную функциональность сразу трех лоадеров: file-loader, url-loader и raw-loader, избавляя от необходимости их устанавливать, а в случае с limit, еще и настраивать. Так же, все новшества связанные с АМ будут подъезжать вместе с обновлениями самого вебпака
АМ — это не про кардинальное уменьшение строк в конфиге
Если говорить про разницу, то она несомненно большая (речь не про лучше/хуже, а про различия).
Вот некоторые моменты:
Basis.js имеет более декларативный подход в описании компонентов — налаживание связей между частями приложения и организация потока данных.
При описании шаблона, разработчик действительно описывает только шаблон, без выражений и условных/циклических операторов, т.к. задачи связи представления с данными выполняют отдельный модули, о чем было рассказано в предыдущей статье.
В basis.js нет digest-цикла. Синхронизация данных устроена при помощи токенов, которые были рассмотрены в первой части.
Basis.js «из коробки» поддерживает инструментирование кода, но это тема для отдельной статьи.
Что из этого считать профитом — решайте для себя сами. Я бы рекомендовал попробовать оба фреймворка в разных задачах и сделать собственные выводы.
> Можно убрать атрибут b:hide из шаблона и будут показаны данные из кеша (с фоновой синхронизацией).
Да. Я добавил b:hide для того, чтобы во время показа надписи «загрузка», основной список не сползал вниз и не прыгал в случае быстрой загрузки. Но это уже вопрос UX. Можно убрать b:hide и прикрутить какой-нибудь Line Progress Bar, тогда визуально всё будет гладко
Ничем. Я не призываю от них отказываться, т.к. это невозможно. Просто их отсутствие в клиентском коде дает более линейный код.
Так в чем преимущество basis.js в этом случае?
Как я и говорил в прошлой статье, для простых задач, basis.js может показаться избыточным. Потерпите, скоро рассматриваемые задачи усложнятся ;) мы подбираемся к ним постепенно…
Основная идея в том, что есть «повседневные» задачи, которые могут решаться из коробки, без применения доп.лоадеров. А если нужно что-то более сложное и эдакое, то, пожалуйста, используйте лоадер
Прошу прощения https://m.habr.com/ru/post/488464/comments/#comment_21284512
Описанная логика AM применяется к правилу после запуска на нем лоадеров.
Но да, наверное это стоит явно описать в документации. Спасибо
Ответил тут habr.com/ru/post/488460 )
Указанные лоадеры итак под крылом команды разработки. Учитывайте, что webpack идет в сторону 0CJS (Zero Configuration JS) для того, чтобы для повседневных задач устанавливать и настраивать как можно меньше дополнительных модулей — установил вебпак и он с минимальными настройками (а в идеале без них) делает все, что нужно.
АМ — это не про кардинальное уменьшение строк в конфиге
На данный момент из коробки это не поддерживается. Пока можно использовать сторонние решения типа https://github.com/trivago/parallel-webpack
Да, поправил ссылку
Спасибо!
Передал инфо ;)
Спасибо за конференцию и доклады!
Жаль только, что в статье не нашлось места для Романа Дворнова
Единственный русскоязычный доклад в ТОП-5
Используем basis.js + basis.js inspector
Вот некоторые моменты:
Basis.js имеет более декларативный подход в описании компонентов — налаживание связей между частями приложения и организация потока данных.
При описании шаблона, разработчик действительно описывает только шаблон, без выражений и условных/циклических операторов, т.к. задачи связи представления с данными выполняют отдельный модули, о чем было рассказано в предыдущей статье.
В basis.js нет digest-цикла. Синхронизация данных устроена при помощи токенов, которые были рассмотрены в первой части.
Basis.js «из коробки» поддерживает инструментирование кода, но это тема для отдельной статьи.
Что из этого считать профитом — решайте для себя сами. Я бы рекомендовал попробовать оба фреймворка в разных задачах и сделать собственные выводы.
Да. Я добавил b:hide для того, чтобы во время показа надписи «загрузка», основной список не сползал вниз и не прыгал в случае быстрой загрузки. Но это уже вопрос UX. Можно убрать b:hide и прикрутить какой-нибудь Line Progress Bar, тогда визуально всё будет гладко
Спасибо! Исправил.
Это где я такое сказал?
Ничем. Я не призываю от них отказываться, т.к. это невозможно. Просто их отсутствие в клиентском коде дает более линейный код.
Как я и говорил в прошлой статье, для простых задач, basis.js может показаться избыточным. Потерпите, скоро рассматриваемые задачи усложнятся ;) мы подбираемся к ним постепенно…
Пожалуйста!
Для этого в basis.js есть такая вещь как Expression, о которой мы поговорим позднее.
Ну так и я о том же.
Надеюсь :)