Комментарии 62
Да, разбитие всего JS кода на кусочки — очень удобно при этом не используя предварительную сборку проекта (легче в местах возникновения ошибок ориентироваться). Правда я сначала застопорился с их подключением к системе, но теперь решил проблему.
Полноценный фреймворк с роутером, контроллерами, моделями, вьюхам и маленькой, но полезной вещичкой как events, творят просто чудеса во время разработки.
А перед публикацией, все сбивается в один файл, минифицируется и тада. Проект похудел на ~50% из-за минификатора и по причине наличия одного файла, начала загружаться значительно быстрее.
Полноценный фреймворк с роутером, контроллерами, моделями, вьюхам и маленькой, но полезной вещичкой как events, творят просто чудеса во время разработки.
А перед публикацией, все сбивается в один файл, минифицируется и тада. Проект похудел на ~50% из-за минификатора и по причине наличия одного файла, начала загружаться значительно быстрее.
Говорят, не сразу ясно, что такое «автобусное число», если отвлечься от происхождения фразы, то автобусное число — это количество разработчиков, которых можно отпустить в отпуск одновременно
Не совсем. Автобусное число может быть равным числу разработчиков, а вот отпустить в отпуск одновременно всех разработчиков все-таки нельзя — кто-то же должен работать над проектом :)
Кстати, первый раз встречаю перевод «автобусное число», обычно всё-таки «автобусный фактор» как калька с оригинального bus factor.
Нет, не отпустить в отпуск. Именно задавить автобусом :) Подразумевается, что у этих людей не будет возможности «передать дела» и т.п.
Расскажите почему выбрали Closure, а не Dojo или Ext?
Если честно, мы не смотрели в сторону Dojo или Ext. Closure показался нам достаточно мощным, для решения всех наших задач, к тому же у нас в команде есть люди, у которых есть опыт разработки приложений именно на Closure. Ну и большим плюсом за Closure стала его мощная инфраструктура, в частности Closure Compiler, который лучше всего жмет код, написанный на Closure.
Почему именно Google Closure?
Если сравнивать со стандартными
* require.js + r..js для сборки
* Backbone + Chaplin (Marionette etc)
* jQuery
В чем получается преимущество? Набор готовых виджетов? Но я уверен, вы все равно пишите свои.
Конечно, я думаю вы проводили сравнение, можете про него рассказать?
Если сравнивать со стандартными
* require.js + r..js для сборки
* Backbone + Chaplin (Marionette etc)
* jQuery
В чем получается преимущество? Набор готовых виджетов? Но я уверен, вы все равно пишите свои.
Конечно, я думаю вы проводили сравнение, можете про него рассказать?
Основное преимущество Closure в том, что это цельный, мощный продукт.
Помимо набора готовых виджетов там есть и встроенная система сборки зависимостей и шаблоны и минификатор кода и оптимизатор css-классов и все, что только можно придумать. Разумеется, мы пишем свои виджеты, но в качестве базового класса используем классы из Google Closure, такие как goog.events.EventTarget, goog.ui.Component, goog.ui.Control.
В текущей версии островка, все написано на jQuery, но после того, как мы с его помощью реализовали мощный функционал, мы поняли, что повторяем то, что уже есть в Google Closure, просто на свой лад.
Конечно, можно было взять набор из нескольких решений, jQuery как базовую библиотеку + Backbone, для MVC + еще что-нибудь для сборки зависимостей, но опыт показывает, что интегрировать разрозненные решения достаточно сложно. Наши коллеги, разрабатывающие Экстранет островка (http://habrahabr.ru/company/ostrovok/blog/155013/) сначала использовали Backbone, потом им пришлось частично от него отказаться и часть функционала реализовать на Knockout.js, потом выяснилось, что такие решения не рассчитаны на такие продукты как Экстранет и часть функционала им приходится реализовывать на чистом js. Мы, конечно же, учли этот опыт и постарались найти как можно более полную библиотеку, которая бы подошла для наших нужд.
К тому же большим плюсом за Closure, стало то, что у нас есть в команде люди, которые имеют опыт работы с этой бибиотекой.
Помимо набора готовых виджетов там есть и встроенная система сборки зависимостей и шаблоны и минификатор кода и оптимизатор css-классов и все, что только можно придумать. Разумеется, мы пишем свои виджеты, но в качестве базового класса используем классы из Google Closure, такие как goog.events.EventTarget, goog.ui.Component, goog.ui.Control.
В текущей версии островка, все написано на jQuery, но после того, как мы с его помощью реализовали мощный функционал, мы поняли, что повторяем то, что уже есть в Google Closure, просто на свой лад.
Конечно, можно было взять набор из нескольких решений, jQuery как базовую библиотеку + Backbone, для MVC + еще что-нибудь для сборки зависимостей, но опыт показывает, что интегрировать разрозненные решения достаточно сложно. Наши коллеги, разрабатывающие Экстранет островка (http://habrahabr.ru/company/ostrovok/blog/155013/) сначала использовали Backbone, потом им пришлось частично от него отказаться и часть функционала реализовать на Knockout.js, потом выяснилось, что такие решения не рассчитаны на такие продукты как Экстранет и часть функционала им приходится реализовывать на чистом js. Мы, конечно же, учли этот опыт и постарались найти как можно более полную библиотеку, которая бы подошла для наших нужд.
К тому же большим плюсом за Closure, стало то, что у нас есть в команде люди, которые имеют опыт работы с этой бибиотекой.
Перед тем, как выложить код, разработчик сам просит кого-то из товарищей проверить его код.
Если не секрет, как это реализовано технически? Написавший код пишет ревьюверу в аську, тот подходит и из-за плеча читает код, давая вслух комментарии?
У нас есть специальный внутренний веб-ресурс для этого. Человек, который хочет выложить свой код, ставит галочки напротив имен тех, кто по его мнени должен посмотреть код и нажимает кнопку «Попросить ревью». Этим людям на почту приходят уведомления.
Этот ресурс показывает все изменения, которые внес этот человек, либо в виде git diff'a, либо просто исходники изменившихся файлов. Ревьюеры могут давать свои комментарии по поводу кода через специальную форму. Если проще объяснить на словах, то тогда, можно и прокомментировать и из-за плеча :)
Если ревьюер считает, что код можно публиковать, он нажимает на кнопку «Разрешить публикацию». Есть еще кнопка «Запретить». Код не будет выкачен, пока все ревьюеры не нажмут кнопку «Разрешить».
Этот ресурс показывает все изменения, которые внес этот человек, либо в виде git diff'a, либо просто исходники изменившихся файлов. Ревьюеры могут давать свои комментарии по поводу кода через специальную форму. Если проще объяснить на словах, то тогда, можно и прокомментировать и из-за плеча :)
Если ревьюер считает, что код можно публиковать, он нажимает на кнопку «Разрешить публикацию». Есть еще кнопка «Запретить». Код не будет выкачен, пока все ревьюеры не нажмут кнопку «Разрешить».
У нас есть своя небольшая система code-review под названием WTF. Мы про нее еще отдельно расскажем, она очень клёвая.
Она самописная, или основана на каком-либо готовом решении?
Мы посмотрели на несколько решений code review: facebook phabricator, gerrit2 и конечно github pull requests. И написали свою очень простую (особенно по-началу) систему, которая заточена под git, feature branches и continuous integration. Расскажем подробнее и не исключено что заопенсорсим.
Если не секрет, чем Phabricator не понравился? Я его сейчас рассматриваю в качестве основного кандидата на внедрение.
* в фабрикаторе каждому разработчику придётся поставить клиент для работы с ним, который превносит дополнительные сложности к и так не простому процессу параллельной разработки в ветках
* в нём нет никакой гибкости в настройках разрешений — кому можно отправлять код в master, а кому нет
для маленькой команды, я бы скорее выбрал github
* в нём нет никакой гибкости в настройках разрешений — кому можно отправлять код в master, а кому нет
для маленькой команды, я бы скорее выбрал github
в фабрикаторе каждому разработчику придётся поставить клиент для работы с ним, который превносит дополнительные сложности к и так не простому процессу параллельной разработки в ветках
Если не секрет, что за клиент? Насколько я понимаю, все действия по code review выполняются через веб интерфейс Phabricator, разработчикам ничего кроме веб браузера не нужно.
сабмитить патчи через браузер совсем печально, если речь идёт о code review всего что пишется.
клиент эту задачу немного упрощает www.phabricator.com/docs/phabricator/article/Arcanist_Quick_Start.html
клиент эту задачу немного упрощает www.phabricator.com/docs/phabricator/article/Arcanist_Quick_Start.html
Не смотрели в сторону MVVM- фреймворков? AngularJS, EmberJS (может быть каких-то аналогов)? MVVM представляется более логичным и подходящим для фронт-енда по сравнению с MVC. Опять-же, верстальшики будут в восторге, да еще и смогут помимо верстки добавлять базовую динамику для вьюх.
Почему вы взяли за основу синтаксиса шаблонов underscore.js? Он же исполнен синтаксическим шумом.
Как вы устанавливаете связь между css/scss и шаблонами? По структуре каталогов?
Устанавливается ли связь между конкретной «вьюхой» на клиентской стороне и шаблоном?
Как вы планируете сжимать имена классов в будущем, если у вас они вшиты в шаблоны?
Какие идентификаторы элементов используете для связи js с DOM?
Также я успел заметить что в css используются имена тэгов и вложенность, это несколько несоответствует методологии BEM. Часто ли приходится решать конфликты «веса» селекторов при таком подходе?
Заранее спасибо.
Как вы устанавливаете связь между css/scss и шаблонами? По структуре каталогов?
Устанавливается ли связь между конкретной «вьюхой» на клиентской стороне и шаблоном?
Как вы планируете сжимать имена классов в будущем, если у вас они вшиты в шаблоны?
Какие идентификаторы элементов используете для связи js с DOM?
Также я успел заметить что в css используются имена тэгов и вложенность, это несколько несоответствует методологии BEM. Часто ли приходится решать конфликты «веса» селекторов при таком подходе?
Заранее спасибо.
underscore.js мы взяли за основу потому что это решение напрашивалось само. Мы использовали библиотеку underscore в своем проекте, поэтому не пришлось далеко ходить за решением. К тому же у нас на глазах уже был опыт Экстранета, который в то время писал на Backbone, а в нем, как вы знаете используется underscore.
По поводу синтаксического шума, позволю себе с вами не согласиться — шаблоны underscore достаточно лаконичны и в то же время читаемы. Мы одно время смотрели на Mustache, но они показались нам слишком уж простыми. Кое-какую js-логику иногда полезно вынести в шаблон. Разумеется в пределах разумного.
По поводу синтаксического шума, позволю себе с вами не согласиться — шаблоны underscore достаточно лаконичны и в то же время читаемы. Мы одно время смотрели на Mustache, но они показались нам слишком уж простыми. Кое-какую js-логику иногда полезно вынести в шаблон. Разумеется в пределах разумного.
Конечно я не считаю шаблоны mustache/handlebars достаточно хорошими, и прежде всего я бы предложил избавиться от xml нотации DOM элементов. Например bem-tools использует синтаксис на основе json'а, некоторые шаблонизаторы indent-based (a la haml/jade/etc.), некоторые исользуют сам язык программирования как dsl для шаблонов и так далее.
Связь между серверными шаблонами и scss на текущем сайте устанавливаем по структуре каталогов, да. Клиентские шаблоны зачастую тоже удобно положить рядом с ними, но не всегда. Мы не связываем напрямую клиентский шаблон и «вьюху» (кстати, мы не используем этот термин), мы предпочитаем развязывать себе руки и действовать более гибко. К тому же есть шаблоны, которые могут использоваться многократно в разных «вьюхах».
Для связи js и DOM используем обычные имена css-классов, никаких специальных классов, только для js у нас нет. Для сжатия классов в новой версии мы используем встроенные в Google Closure инструменты, которые никаким образом не зависят от используемого языка шаблонов, главное, чтобы он компилировался в js.
В текущей версии сайта мы используем «чистый» БЭМ и названия наших классов полностью соответствуют БЭМ-методологии, в примере я его не использовал для чистоты примера, ровно чтобы показать как мы пишем js-код, не отвлекаясь на детали.
Для связи js и DOM используем обычные имена css-классов, никаких специальных классов, только для js у нас нет. Для сжатия классов в новой версии мы используем встроенные в Google Closure инструменты, которые никаким образом не зависят от используемого языка шаблонов, главное, чтобы он компилировался в js.
В текущей версии сайта мы используем «чистый» БЭМ и названия наших классов полностью соответствуют БЭМ-методологии, в примере я его не использовал для чистоты примера, ровно чтобы показать как мы пишем js-код, не отвлекаясь на детали.
Прелесть BEM'а не только в универсальной конвенции, а ещё и в возможности сгенерировать элементы блока втоматически, задавая им только имена элементов.
В случае ручной работы с методологией BEM она слабо раскрывает свои достоинства.
В случае ручной работы с методологией BEM она слабо раскрывает свои достоинства.
Да, вы правы. Вообще в перспективе выяснилось, что БЭМ не слишком хорошо подходит для нашего проекта (а может мы просто не умеем его готовить) и в новой версии островка мы решили от него отказаться в пользу более простой системы.
У команды БЭМ есть практика выездных приватных семинаров. Разработчики составляют свои вопросы, а мы, подготовившись, приходим на чай с плюшками. Так общение получается более продуктивным, вопросы рассматриваем с учётом архитектуры ваших проектов. Можем к вам придти :-)
Я не к тому, чтобы вы всё взяли и переделали, а просто если есть предположение, что «не умеем готовить» и просто любопытно, как это сделали бы мы, то мы всегда готовы поделиться.
Я не к тому, чтобы вы всё взяли и переделали, а просто если есть предположение, что «не умеем готовить» и просто любопытно, как это сделали бы мы, то мы всегда готовы поделиться.
Посмотрел главную страницу вашего сайта через Firebug быстро, немного удивили 60 с чем-то загружаемых изображений. Особенно с учетом того, что бОльшую их часть я на странице, потыкавшись несколько минут в интерфейсе, так и не нашел.
Конечно, скорее всего я просто чего-то не понял, но там точно ничего лишнего не грузится? :)
И логотипы в «пресса об Островке», наверное, меняются довольно нечасто. Может лучше их в спрайт склеить, нет?
Ну это так, в порядке мыслей вечером в понедельник.
Конечно, скорее всего я просто чего-то не понял, но там точно ничего лишнего не грузится? :)
И логотипы в «пресса об Островке», наверное, меняются довольно нечасто. Может лучше их в спрайт склеить, нет?
Ну это так, в порядке мыслей вечером в понедельник.
Еще такой вопрос: пробовали ли использовать CoffeeScript? Может быть вполне актуально при таком количестве JS-кода.
Мы думали о CoffeScript, один из наших разработчиков, который имел большой работы работы с ним, даже провел нам лекцию, но мы не нашли никаких больших плюсов, чтобы перейти на него. Все удобные обвязки для классов, итераторов и пр., у нас есть и так (в текущей версии в виде наших решений и библиотеки underscore, а в будущей — в Google Closure), а вот синтаксис достаточно непривычный.
К тому же нет однозначного ответа как именно отлаживать код, скомпилированный из Coffee. У нас много разработчиков, каждый предпочитает свои инструменты для разработки, поэтому найти решние которое всех бы устраивало сложновато.
Поэтому не используем.
К тому же нет однозначного ответа как именно отлаживать код, скомпилированный из Coffee. У нас много разработчиков, каждый предпочитает свои инструменты для разработки, поэтому найти решние которое всех бы устраивало сложновато.
Поэтому не используем.
Ну на самом деле используем, просто не в островке, а в некоторых наших других продуктах. Возможно и в островке будет, но пока да, на основном сайте ничего нет.
С дебагом и правда есть некоторые накладки. Но обычно проявляются, если кто-то не вполне понимает, как именно CoffeeScript транслируется в JavaScript.
А вот это вполне себе аргумент: «Все удобные обвязки для классов, итераторов и пр., у нас есть и так (в текущей версии в виде наших решений и библиотеки underscore, а в будущей — в Google Closure), а вот синтаксис достаточно непривычный.»
Но могу добавить, что синтаксис — дело привычки. К нему так привыкаешь (к лучшим сторонам), что потом очень не хочется «обратно».
А вот это вполне себе аргумент: «Все удобные обвязки для классов, итераторов и пр., у нас есть и так (в текущей версии в виде наших решений и библиотеки underscore, а в будущей — в Google Closure), а вот синтаксис достаточно непривычный.»
Но могу добавить, что синтаксис — дело привычки. К нему так привыкаешь (к лучшим сторонам), что потом очень не хочется «обратно».
К слову — а на чем сделан бэк-энд (веб-фейс, app-server, итд)?
И вообще — будет про него статья? Островок — крутой и навороченный проект, очень интересно, как устроен внутри!
И вообще — будет про него статья? Островок — крутой и навороченный проект, очень интересно, как устроен внутри!
Хочу спросить никто не решал такую проблему с шаблонизатором: проеткт на backbone+require.js шаблоны на underscore подгружаются плагином !text. Без оптимизации все работает нормально — шаблоны подгружаются из файлов. Если собирать проект как описанно в документашке к require — то шаблоны включаются в общий файл. что совершенно не нужно. Требуется чтоб шаблоны были отдельно и в любой момент их можно было отредатировать.
9 человек на фронтенде — это имеется в виду только кодеры? Компетенции как-то разделены, или все могут всё?
Что-то не совсем понятно. Вы нахваливаете стек от Google, при этом используете свой шаблонизатор JST, и свою систему разрешения зависимостей и сборщик (что вроде как делается через goog.require/goog.provide с последующей сборкой closure compiler). И еще Вы пишите:
Судя по всему вы это тоже не используете, но можно поподробней?
И правильно ли я понял, что вы используете только утилиты из closure library, а модель компонентов UI у вас своя?
и язык стилей, интегрированный с Google Closure Compiler и поэтому позволяющий минифицировать даже имена css-классов (голубая мечта любого разработчика, использующего БЭМ)
Судя по всему вы это тоже не используете, но можно поподробней?
И правильно ли я понял, что вы используете только утилиты из closure library, а модель компонентов UI у вас своя?
Все просто. В статье речь идет о двух версиях сайта Островок — текущей и той, которая в скором времени выйдет. Свои решения мы используем сейчас, а в новой версии заменим их на решения, которые входят в стек Google Closure.
С моделью компонентов та же история — сначала мы написали свою, но в грядущей версии мы активно используем встроенные в Closure компоненты.
С моделью компонентов та же история — сначала мы написали свою, но в грядущей версии мы активно используем встроенные в Closure компоненты.
Коллеги, а как подружили питон и Closure Tools? Или вы не используете Closure на стороне сервера совсем?
Можно я немного яда подолью? :-) Про фронтэнд?
Как сейчас дела обстоят я не знаю — это было в июне-июле этого года.
У Вас в экстранете для включение / выключения чего-либо используется грид из кучи таких переключателей-движков.
Мало того что это жутко неудобно — вообще экстранет должен быть максимально простым — а тут глаза от ряби дизайна выпадывают, так еще и жутко все это счастие тормозило.
В Booking другая крайность там все топроно и старо, вебдванольненьким не пахнет — но работает быстро и живо.
Сидел я на хреновом канале и не на сильном компе — надо было срочно убрать номера из бронирования. Так вот при переключении КАЖДОГО переключателя в гриде гдето к 5-7 штукам начинало все жутко при жутко тормозить.
Я глянул код — там класс на классе и классом погоняет вобщем при щелчке там что-то порождается и затем отсылается на сервак, по скольку канал нестабильный и узкий — эти кучки плодились и плодились и потом минуту надо было курить и ждать пока все уйдет.
Ведь можно баланс какойто делать, не все оопешить? это выдливается в тонны ненужных классов и тормоза при работе ибо бинд на чтото вызывает и порождает 15 классов, а не вызывает одну единственную функцию.
Зачем так усложнять? Зачем рисовать дизайнерские фенечки вместо простого и понятного грида? Выглядит менее красиво? Да, но это экстранет а не витрина в магазине.
Нет я пониимаю что ООП дает модульность, дизайн — красоту и все такое — но что из этого получается — я описал.
Желаю Вам устранить все эти недостатки и развиваться дальше — проект нужный и замечательный, я посмотрю чем оно все закончится и быть может снова начну пользоваться.
Как сейчас дела обстоят я не знаю — это было в июне-июле этого года.
У Вас в экстранете для включение / выключения чего-либо используется грид из кучи таких переключателей-движков.
Мало того что это жутко неудобно — вообще экстранет должен быть максимально простым — а тут глаза от ряби дизайна выпадывают, так еще и жутко все это счастие тормозило.
В Booking другая крайность там все топроно и старо, вебдванольненьким не пахнет — но работает быстро и живо.
Сидел я на хреновом канале и не на сильном компе — надо было срочно убрать номера из бронирования. Так вот при переключении КАЖДОГО переключателя в гриде гдето к 5-7 штукам начинало все жутко при жутко тормозить.
Я глянул код — там класс на классе и классом погоняет вобщем при щелчке там что-то порождается и затем отсылается на сервак, по скольку канал нестабильный и узкий — эти кучки плодились и плодились и потом минуту надо было курить и ждать пока все уйдет.
Ведь можно баланс какойто делать, не все оопешить? это выдливается в тонны ненужных классов и тормоза при работе ибо бинд на чтото вызывает и порождает 15 классов, а не вызывает одну единственную функцию.
Зачем так усложнять? Зачем рисовать дизайнерские фенечки вместо простого и понятного грида? Выглядит менее красиво? Да, но это экстранет а не витрина в магазине.
Нет я пониимаю что ООП дает модульность, дизайн — красоту и все такое — но что из этого получается — я описал.
Желаю Вам устранить все эти недостатки и развиваться дальше — проект нужный и замечательный, я посмотрю чем оно все закончится и быть может снова начну пользоваться.
Мне кажется, что вы немного путаете понятия. Дело в том, что сам факт использования или не использования ООП никоим образом не влияет на качество конечного продукта. Можно написать плохой код и в функциональном стиле: дело не в этом. Это примерно так же как не важно как собирается на заводе ваш телефон: вручную или умными роботами — главное что он хорошо работает. Стоит разделять понятие инструмента и конечного продукта.
Конечно бывают случаи, когда инструмент неподходящий, можно пытаться ножом колоть дрова, но в случае с разработкой интерфейсов и ООП этот пример не срабатывает, потому что этот подход давно себя зарекомендовал среди разработчиков сайтов. Посмотрите на продукты Google и поймите что дело не в том какой подход использовать.
Перед нашим экстранетом стоят нетривиальные архитектурные задачи и они постоянно работают над улучшением своего продукта. Думаю, вам как человеку пользовавшемуся нашим экстранетом и разбирающемуся в программировании будет интересно посмотреть их доклад с 404-феста (http://habrahabr.ru/company/ostrovok/blog/155013/), где они рассказывают про свое приложение, про проблемы с которыми они сталкиваются и как они их решают.
Возможно, вам даже стоит связаться с ними, чтобы отправить им свои пожелания по улучшению продукта напрямую.
Спасибо вам за фидбек и пожелания. Мы постоянно развиваемся и стараемся стать лучше.
Конечно бывают случаи, когда инструмент неподходящий, можно пытаться ножом колоть дрова, но в случае с разработкой интерфейсов и ООП этот пример не срабатывает, потому что этот подход давно себя зарекомендовал среди разработчиков сайтов. Посмотрите на продукты Google и поймите что дело не в том какой подход использовать.
Перед нашим экстранетом стоят нетривиальные архитектурные задачи и они постоянно работают над улучшением своего продукта. Думаю, вам как человеку пользовавшемуся нашим экстранетом и разбирающемуся в программировании будет интересно посмотреть их доклад с 404-феста (http://habrahabr.ru/company/ostrovok/blog/155013/), где они рассказывают про свое приложение, про проблемы с которыми они сталкиваются и как они их решают.
Возможно, вам даже стоит связаться с ними, чтобы отправить им свои пожелания по улучшению продукта напрямую.
Спасибо вам за фидбек и пожелания. Мы постоянно развиваемся и стараемся стать лучше.
Мы знаем про кучу проблем в экстранете, особенно с производительностью. В ближайшие несколько недель выйдет большой апдейт фронтэнда, который решит многие проблемы. Большое спасибо за фидбэк, мы постараемся учесть и все остальные пожелания в будущих версиях.
Возникло несколько вопросов:
1. Используется/планируется автоматическая сборка изображений в спрайты?
2. Для код-ревью смотрели ли в сторону Crucible?
3. В чем именно заключался отказ от БЭМ при переходе на Google Clousure, т.к. сейчас именование классов идет в духе БЭМ, либо имеется ввиду организация файловой системы проекта?
Спасибо за шаринг опытом. Было бы здорово, если бы поделились опытом, как прошел собственно переход на Google Closure.
1. Используется/планируется автоматическая сборка изображений в спрайты?
2. Для код-ревью смотрели ли в сторону Crucible?
3. В чем именно заключался отказ от БЭМ при переходе на Google Clousure, т.к. сейчас именование классов идет в духе БЭМ, либо имеется ввиду организация файловой системы проекта?
Спасибо за шаринг опытом. Было бы здорово, если бы поделились опытом, как прошел собственно переход на Google Closure.
1. Используется.
2. Нет, не смотрели, потому что нас полностью устраивает наша система)
3. БЭМ используется в той части сайта, которая еще не была переписана на Closure, если вы обратите внимание на главную страницу сайта и посковую выдачу, то там БЭМ не используется.
Вообще, по поводу новой версии сайта готовится не менее подробный пост. Stay tuned)
2. Нет, не смотрели, потому что нас полностью устраивает наша система)
3. БЭМ используется в той части сайта, которая еще не была переписана на Closure, если вы обратите внимание на главную страницу сайта и посковую выдачу, то там БЭМ не используется.
Вообще, по поводу новой версии сайта готовится не менее подробный пост. Stay tuned)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Фронт-энд Островка изнутри