Выпуск №11: в котором JavaScript не вызывает зависимости (в гостях Антон Шувалов)

Антон Шувалов — фронтенд разработчик в Рамблере. Вы возможно знаете его по проектам page.js, code screenshots, выступлению на MoscowJS 15. Вместе с ним мы обсуждаем инструменты и сетап разработчиков, подходы к сборке скриптов и альтернативы Backbone.

Скачать выпуск (mp3, 29 MB)
  • instanceofpro

    Антон как будто бы нервничает.

    • В следующем выпуске Антон снова с нами, будет еще интереснее. Stay tuned!

      • instanceofpro

        Кстати, для marionette.js в будущем планируется разделение на отдельные модули всех сущностей. Issue на это есть, ребята коммитят. Но вот в каком релизе это будет пока непонятно.

  • Ivan Voischev

    Webpack Webpack… а вот мы уже давно используем все то о чем Миша так восхищенно говорит используем в своих БЭМ проектах) на полном стеке технологий.

    Посмотрите еще сборщик ENB (ну еще менее актуально bem-tools) он позволяет собирать любые технологии. В обоих инструментах есть dev server, autoreloader, в коробке autoprefixer borshik, модульная система! и тд. все это либо модули либо из коробки. Конечно не все идеально, но кажется это просто придирки разработчика который давно что-то использует. И да, по большому счету — это просто шикарно )))
    А плюс еще bem stack с компонетнами и другими блоками вообще огонь)

    • Ivan Voischev

      Ну а на 48минуте Антон говорит про БЭМ стек который есть уже сейчас. Только с оговоркой на MVC

    • Denis Izmaylov

      Special for you 🙂 http://habrahabr.ru/post/245991/

      • Ivan Voischev

        Не совсем понял о чем должна была поведать мне эта статья? ) В ней я все еще вижу больше проблем чем в экосистеме технологий БЭМ)

        • Конкретно тебе это может разве что расширить кругозор. Но вряд ли ты всю жизнь будешь работать с одним только БЭМ-стеком. Поэтому неплохо будет понимать, что есть что-то универсальное, позволяющее работать с любыми фреймворками/либами.

          • Ivan Voischev

            Спасибо. Может и вам всем понадобится информация о том что инструменты БЭМ как бы не запрещают работать с другими технологиями и фреймворками. Есть доклад с moscowjs про react например

          • React.js не в счет, это просто умный и очень быстрый DOM-шаблонизатор. Как и другие шаблонизаторы, очевидно, что он должен быть легко переиспользуемым почти в любой ситуации Даже с AngularJS его легко можно состыковать 🙂

          • Ivan Voischev

            Ну не важно всчет или нет. Посыл в том что совершенно не запрещено использовать другие технологии. Проблема лишив том что никто почему то не рассматривает эти инструменты всерьез. А на практете все и немного больше ,о чем ты радостно рассказывал об Вебпак люди использующие инструменты БЭМ уже успешно используют продолжительное время. Я считаю что в данном случае только сообщество краеугольный камень, к большому сожалению

          • не могу с тобой согласиться что дело в сообществе
            у БЭМа есть своя ниша, ты в ней и тебе хорошо… БЭМ идеально ложится в голову людей, которые раньше верстали, хорош для тех, кто любит верстать технологично и сейчас
            он хорош для тех приложений, где основной рендеринг на сервере, а на клиенте только малосвязанные виджеты/компоненты (ключевое – малосвязанные, то есть которые между собой почти не общаются)

            идем сюда https://events.yandex.ru/lib/talks/1588/ и смотрим как выглядит простейшее приложений с динамикой на клиенте… слишком сложно имхо, потому что не для этого БЭМ создавался, ему еще расти в этом направлении, а может и не ему, а чему-то на его основе, может даже стоит другое название придумать для полноценного фреймворка

            если послушать Антона в 14-ом выпуске, то вроде как получается, что они для динамики на клиенте выбрали все равно Angular, хотя и стек БЭМа заюзали для того, чтобы билдить на сервере нужный HTML… это ок, но лично я бы не стал брать БЭМ в такой ситуации, потому что мне кажется, что в этом слишком мало пользы и есть туча способов решить это без тулзов БЭМа, а средствами любого серверного фреймворка, то есть в данном кейсе высока конкуренция решений и люди выбирают что им ближе основываясь на том, что привыкли юзать на сервере (я бы некоторое время назад сделал бы это на Rails, чтобы не вставлять еще и node (+1 системная зависимость) на сервере плюсом к уже существующему Ruby)

            касательно React’а скажу чуть подробнее… имхо это как раз то же самое поле, в котором играет БЭМ, а именно – создание инкапсулированных компонентов
            сравнивать их разумно и честно, и на данный момент React давит всей мощью маркетинга со стороны Facebook… я бы рад был увидеть не маркетинговое, а техническое сравнение их, особенно в области производительности и пожирания ресурсов системы

            webpack в контексте маркетинга со стороны Facebook тоже выглядит очень мощно) пиарят его везде и всюду, инструменты под него как грибы появляются, а самое главное – он очень (ОЧЕНЬ!) легко внедряется у уже существующих юзеров Browserify и Require.js, что наверняка скажется на скорости миграции на него и как следствие популярности.. может ли этим похвастаться сборщик БЭМа? я не знаю (может это моя проблема, а может просто про это никто нигде не рассказывает)
            надеюсь ты знаешь и ответишь в комментариях, может даже стоит доклад про сборщик БЭМ сделать для будущих MoscowJS, BEMup… я бы рад был увидеть в докладе их сравнение с webpack, также как БЭМ-компоненты vs React

            подитожу:
            1) своя ниша безусловно есть
            2) в этой нише много сильных игроков, и сложно обвинить сообщество в том, что оно выбирает их, а не БЭМ, особенно с учетом легкой миграции и адаптации существующего кода под некоторые из них
            3) эта ниша почти не пересекается с нишей клиентских full-stack фреймворков вроде Backbone, Angular, Ember, поэтому тут на данный момент говорить о БЭМ не приходится

            PS: надеюсь воспримешь это как здоровую критику, а не наезд 🙂

          • Ivan Voischev

            Ты все правильно понял!!! Но опять же по словам Антона нам не хватает лишь MVC на клиенте что бы он отказался от ангуляра и подобного. Как он сам говорил приходится много писать кода что бы работать с ангуляром(просто работать даже без бэм) и кажется с решение в стеке может быть гораздо проще.

            Про два мира разработки фронт/и бек у себя в студии я наблюдаю положительную ситуацию мы ни как не влияем на друг друга и одни зависимости не мешают другим, кроме того каждый по отдельности следит за своими зависимостями 🙂 А с серверами сегодня кажется все просто.

            Ну у реакта кажется нужно писать все же html руками… У реакта виртуальный дом. Для виртуального дома кажется достаточно написать технологию на основе https://github.com/dfilatov/vidom только вместо json засунуть туда bemjson ))) и будет не менее крутая скорость шаблонизации больших данных.

            Но я думаю все же что большую часть проблем решает не фреймворк 😉

            Чем я недоволен. Тем что как вы тоже заметили сегодня куча технологий крутых. Всему хочется научиться. Все хотят единый модульный фронтэнд, единые библиотеки. И мне кажется что БЭМ со своей методологией и подходом может стать таким золотым самородком который всем сразу и поможет, за счет того что все будет в единых терминах, сообществу будет проще с этим работать. Ну и тд… Только кажется бэм всегда обходят стороной, но все стремятся к тому что уже реализовано (может быть не так как хочется всем, но можно улучшить сообществом).

            Что посмотреть. Ну я смотрел все доклады. Последние bemup’ы хороши. Новости тоже думаю не стоит упускать.

          • Alexej Yaroshevich

            Что-то мне в этой статье на хабре намекает, что webpack можно в конец сборки навернуть уже когда бандлы css/js собраны 😉 Может быть “bundle.js”, who knows.