> Суть мысли, или даже вопроса — почему никто (встречавшийся мне) не использует блоки кода в своих JavaScript приложениях?
На самом деле блоки кода в своих приложениях используют все программисты, потому что блоком является именно выражение заключенное в фигурные скобки, а значит когда вы пишете даже простейший if, вы используете блок.
Другое дело, что в использовании блоков самих по себе без какого-то предстоящего перед ними выражения нет особого смысла, потому что способов группировки — масса.
Мне кажется тут надо следовать правилу «Бритва Оккама» — не надо плодить лишние сущности без надобности.
2. Нет, не смотрели, потому что нас полностью устраивает наша система)
3. БЭМ используется в той части сайта, которая еще не была переписана на Closure, если вы обратите внимание на главную страницу сайта и посковую выдачу, то там БЭМ не используется.
Вообще, по поводу новой версии сайта готовится не менее подробный пост. Stay tuned)
Мне кажется, что вы немного путаете понятия. Дело в том, что сам факт использования или не использования ООП никоим образом не влияет на качество конечного продукта. Можно написать плохой код и в функциональном стиле: дело не в этом. Это примерно так же как не важно как собирается на заводе ваш телефон: вручную или умными роботами — главное что он хорошо работает. Стоит разделять понятие инструмента и конечного продукта.
Конечно бывают случаи, когда инструмент неподходящий, можно пытаться ножом колоть дрова, но в случае с разработкой интерфейсов и ООП этот пример не срабатывает, потому что этот подход давно себя зарекомендовал среди разработчиков сайтов. Посмотрите на продукты Google и поймите что дело не в том какой подход использовать.
Перед нашим экстранетом стоят нетривиальные архитектурные задачи и они постоянно работают над улучшением своего продукта. Думаю, вам как человеку пользовавшемуся нашим экстранетом и разбирающемуся в программировании будет интересно посмотреть их доклад с 404-феста (http://habrahabr.ru/company/ostrovok/blog/155013/), где они рассказывают про свое приложение, про проблемы с которыми они сталкиваются и как они их решают.
Возможно, вам даже стоит связаться с ними, чтобы отправить им свои пожелания по улучшению продукта напрямую.
Спасибо вам за фидбек и пожелания. Мы постоянно развиваемся и стараемся стать лучше.
Не используем :) Единственное что нам нужно со стороны сервера от Closure, так это plovr, но он не пересекается с основными задачами бекендеров вообще.
Все просто. В статье речь идет о двух версиях сайта Островок — текущей и той, которая в скором времени выйдет. Свои решения мы используем сейчас, а в новой версии заменим их на решения, которые входят в стек Google Closure.
С моделью компонентов та же история — сначала мы написали свою, но в грядущей версии мы активно используем встроенные в Closure компоненты.
Да, именно кодеры. Компенетции разделены — как по специализации человека, так и по сфере деятельности — у каждого из разработчиков своя область, за которую он отвечает. Специалист по странице отеля, по картам, по поисковой выдаче, по лендингам и так далее.
Он нам не подошел. Шаблоны и низкая связанность — это не все условия, которые нам нужны, поэтому мы используем другое решение. Подробнее на вопрос почему именно Closure я отвечал ниже в комментариях.
Да, вы правы. Вообще в перспективе выяснилось, что БЭМ не слишком хорошо подходит для нашего проекта (а может мы просто не умеем его готовить) и в новой версии островка мы решили от него отказаться в пользу более простой системы.
Поскольку, у нас с шаблонами работают в том числе и верстальщики, для нас важно, чтобы код шаблона был прост и привычен. Именно поэтому мы решили не отказываться от XML-нотации DOM-элементов. Поэтому шаблонизатор, в котором используется HTML + JS, показался нам достаточно удобным.
Мы думали о CoffeScript, один из наших разработчиков, который имел большой работы работы с ним, даже провел нам лекцию, но мы не нашли никаких больших плюсов, чтобы перейти на него. Все удобные обвязки для классов, итераторов и пр., у нас есть и так (в текущей версии в виде наших решений и библиотеки underscore, а в будущей — в Google Closure), а вот синтаксис достаточно непривычный.
К тому же нет однозначного ответа как именно отлаживать код, скомпилированный из Coffee. У нас много разработчиков, каждый предпочитает свои инструменты для разработки, поэтому найти решние которое всех бы устраивало сложновато.
Да, Михаил, мы знаем про этот недостаток. Это картинки для блока «Популярные направления» и их действительно лучше склеить в спрайт и не загружать до тех пор пока пользователь не откроет этот блог. Мы работаем над этим и, в скором времени, исправим.
Связь между серверными шаблонами и scss на текущем сайте устанавливаем по структуре каталогов, да. Клиентские шаблоны зачастую тоже удобно положить рядом с ними, но не всегда. Мы не связываем напрямую клиентский шаблон и «вьюху» (кстати, мы не используем этот термин), мы предпочитаем развязывать себе руки и действовать более гибко. К тому же есть шаблоны, которые могут использоваться многократно в разных «вьюхах».
Для связи js и DOM используем обычные имена css-классов, никаких специальных классов, только для js у нас нет. Для сжатия классов в новой версии мы используем встроенные в Google Closure инструменты, которые никаким образом не зависят от используемого языка шаблонов, главное, чтобы он компилировался в js.
В текущей версии сайта мы используем «чистый» БЭМ и названия наших классов полностью соответствуют БЭМ-методологии, в примере я его не использовал для чистоты примера, ровно чтобы показать как мы пишем js-код, не отвлекаясь на детали.
underscore.js мы взяли за основу потому что это решение напрашивалось само. Мы использовали библиотеку underscore в своем проекте, поэтому не пришлось далеко ходить за решением. К тому же у нас на глазах уже был опыт Экстранета, который в то время писал на Backbone, а в нем, как вы знаете используется underscore.
По поводу синтаксического шума, позволю себе с вами не согласиться — шаблоны underscore достаточно лаконичны и в то же время читаемы. Мы одно время смотрели на Mustache, но они показались нам слишком уж простыми. Кое-какую js-логику иногда полезно вынести в шаблон. Разумеется в пределах разумного.
Мы изучили много вариантов перед тем, как остановиться на Closure. Самые распространенные MVVM и MVC библиотеки показались нам недостаточно хорошо подходящими для нашего проекта. Полнее я отвечал в комментариях выше.
На самом деле блоки кода в своих приложениях используют все программисты, потому что блоком является именно выражение заключенное в фигурные скобки, а значит когда вы пишете даже простейший if, вы используете блок.
Другое дело, что в использовании блоков самих по себе без какого-то предстоящего перед ними выражения нет особого смысла, потому что способов группировки — масса.
Мне кажется тут надо следовать правилу «Бритва Оккама» — не надо плодить лишние сущности без надобности.
2. Нет, не смотрели, потому что нас полностью устраивает наша система)
3. БЭМ используется в той части сайта, которая еще не была переписана на Closure, если вы обратите внимание на главную страницу сайта и посковую выдачу, то там БЭМ не используется.
Вообще, по поводу новой версии сайта готовится не менее подробный пост. Stay tuned)
… вчера исполнилось ровно девять лет…… через три недели можно отмечать еще один юбилей…
Конечно бывают случаи, когда инструмент неподходящий, можно пытаться ножом колоть дрова, но в случае с разработкой интерфейсов и ООП этот пример не срабатывает, потому что этот подход давно себя зарекомендовал среди разработчиков сайтов. Посмотрите на продукты Google и поймите что дело не в том какой подход использовать.
Перед нашим экстранетом стоят нетривиальные архитектурные задачи и они постоянно работают над улучшением своего продукта. Думаю, вам как человеку пользовавшемуся нашим экстранетом и разбирающемуся в программировании будет интересно посмотреть их доклад с 404-феста (http://habrahabr.ru/company/ostrovok/blog/155013/), где они рассказывают про свое приложение, про проблемы с которыми они сталкиваются и как они их решают.
Возможно, вам даже стоит связаться с ними, чтобы отправить им свои пожелания по улучшению продукта напрямую.
Спасибо вам за фидбек и пожелания. Мы постоянно развиваемся и стараемся стать лучше.
С моделью компонентов та же история — сначала мы написали свою, но в грядущей версии мы активно используем встроенные в Closure компоненты.
К тому же нет однозначного ответа как именно отлаживать код, скомпилированный из Coffee. У нас много разработчиков, каждый предпочитает свои инструменты для разработки, поэтому найти решние которое всех бы устраивало сложновато.
Поэтому не используем.
Спасибо за фидбек.
Для связи js и DOM используем обычные имена css-классов, никаких специальных классов, только для js у нас нет. Для сжатия классов в новой версии мы используем встроенные в Google Closure инструменты, которые никаким образом не зависят от используемого языка шаблонов, главное, чтобы он компилировался в js.
В текущей версии сайта мы используем «чистый» БЭМ и названия наших классов полностью соответствуют БЭМ-методологии, в примере я его не использовал для чистоты примера, ровно чтобы показать как мы пишем js-код, не отвлекаясь на детали.
По поводу синтаксического шума, позволю себе с вами не согласиться — шаблоны underscore достаточно лаконичны и в то же время читаемы. Мы одно время смотрели на Mustache, но они показались нам слишком уж простыми. Кое-какую js-логику иногда полезно вынести в шаблон. Разумеется в пределах разумного.