Сережа, где же твоя карма? ) Я присутствовал на разговоре Бобука, кажется с Надей (уже не помню точно) Речь шла о том, что найти разработчиков со знанием jQuery сильно легче чем со знанием y5. Ну и сам помнишь, после ухода Андрея ее банально некому было развивать
Говоря о популярности БЭМ, и что сам ГУГЛ его использует в mdl,
надо всё-таки по-честному разделять подход к наименованию классов, который и правда хорош и распространен (с небольшими изменениями у того же Гугл), и инструменты типа bem-tools, которые мягко говоря медленные ) и никакой ГУГЛ их использовать никогда не будет.
Да, есть enb, но не странно ли, что один разработчик в свободное от работы время, «на коленке» написал сборщик,
работающий в разы быстрее bem-tools, непонятно, чем же тогда занималась вся команда БЭМ? Наверное писала статьи на хабр… )
Сейчас mdevils ушел и я вижу практически нулевую активность в графе enb на гитхабе – исправляют код-стайл и тесты ))
И это совсем не обнадеживает.
Встав сейчас перед выбором технологии я скорее посмотрю в сторону React и JSX на котором гораздо проще и нагляднее описываются компоненты/дерево компонентов (все же XML-ситаксис гораздо легче читать, в сравнении с BEMJSON) и который не привязывает меня к конкретным инструментам сборки и к конкретным реализациям Model/Controller
Как бы там ни было, БЭМ прошел огромный путь, имеет хорошую поддержку и стоит того, чтобы как минимум его попробовать и иметь о нем свое мнение, а не просто хаять, как делают здесь некоторые комментаторы.
И я желаю разработчикам успехов в его совершенствовании.
PS:
В части «с чего всё начиналось» можно было рассказать и о «y5.js» который был до лего-бэма
и был благополучно похоронен на основании тех же доводов о «пороге вхождения»
Если у вас небольшой проект и нет возможности настроить свой кеширующий прокси, вы можете использовать описанный в статье инструмент, и получить через него код добавления меток
1. Очень печальная документация на WebDAV АПИ
Открывая доку на GoogleDrive я вижу примеры работы с их АПИ для 7-ми!!! языков программирования.
А тут только http-заголовки. Какой АПИ выберет разработчик, кажется ответ очевиден.
2. Нет возможности написать Вэб-клиент, т.к. вы НЕ отдаете CORS-заголовки. ПОЧЕМУ?!!! Сколько человеко-лет разработки нужно чтобы отдать в http-заголовке звездочку "*"?
3. Нет поддержки для multipart/fom-data, а именно они используются браузерами при отправке форм (Гугл их кстати поддерживает)
4. У АПИ нет никакого версионирования. Все же это разумно дописывать номер версии в URL,
а у вас просто webdav.yandex.ru. Видимо вы написали «идеальное» АПИ с первой попытки )
5. Большинство методов отдают XML, кроме одного
Это что тяжелое наследие легаси клиентов? Для этого и нужен пункт 4. А как же консистентность АПИ?
Сложных элементов мы не делали, т.к. это всё же примеры и они должны быть простыми и понятными.
Если только поисковый контрол с автокомплитом.
Соглашусь с Мариной, — подход «накидать html и навесить» хорош для простых контролов, а в более сложных случаях нужно отделять представление от бизнес-логики контрола, иначе поддерживать такой контрол будет проблематично.
Такое разделение собственно и позволяют сделать макеты. Это по сути реализация паттерна MVC, и как мне кажется более «правильный» путь.
надо всё-таки по-честному разделять подход к наименованию классов, который и правда хорош и распространен (с небольшими изменениями у того же Гугл), и инструменты типа bem-tools, которые мягко говоря медленные ) и никакой ГУГЛ их использовать никогда не будет.
Да, есть enb, но не странно ли, что один разработчик в свободное от работы время, «на коленке» написал сборщик,
работающий в разы быстрее bem-tools, непонятно, чем же тогда занималась вся команда БЭМ? Наверное писала статьи на хабр… )
Сейчас mdevils ушел и я вижу практически нулевую активность в графе enb на гитхабе – исправляют код-стайл и тесты ))
И это совсем не обнадеживает.
Встав сейчас перед выбором технологии я скорее посмотрю в сторону React и JSX на котором гораздо проще и нагляднее описываются компоненты/дерево компонентов (все же XML-ситаксис гораздо легче читать, в сравнении с BEMJSON) и который не привязывает меня к конкретным инструментам сборки и к конкретным реализациям Model/Controller
Как бы там ни было, БЭМ прошел огромный путь, имеет хорошую поддержку и стоит того, чтобы как минимум его попробовать и иметь о нем свое мнение, а не просто хаять, как делают здесь некоторые комментаторы.
И я желаю разработчикам успехов в его совершенствовании.
PS:
В части «с чего всё начиналось» можно было рассказать и о «y5.js» который был до лего-бэма
и был благополучно похоронен на основании тех же доводов о «пороге вхождения»
Открывая доку на GoogleDrive я вижу примеры работы с их АПИ для 7-ми!!! языков программирования.
А тут только http-заголовки. Какой АПИ выберет разработчик, кажется ответ очевиден.
2. Нет возможности написать Вэб-клиент, т.к. вы НЕ отдаете CORS-заголовки. ПОЧЕМУ?!!! Сколько человеко-лет разработки нужно чтобы отдать в http-заголовке звездочку "*"?
3. Нет поддержки для multipart/fom-data, а именно они используются браузерами при отправке форм (Гугл их кстати поддерживает)
4. У АПИ нет никакого версионирования. Все же это разумно дописывать номер версии в URL,
а у вас просто webdav.yandex.ru. Видимо вы написали «идеальное» АПИ с первой попытки )
5. Большинство методов отдают XML, кроме одного
Это что тяжелое наследие легаси клиентов? Для этого и нужен пункт 4. А как же консистентность АПИ?
Если только поисковый контрол с автокомплитом.
Соглашусь с Мариной, — подход «накидать html и навесить» хорош для простых контролов, а в более сложных случаях нужно отделять представление от бизнес-логики контрола, иначе поддерживать такой контрол будет проблематично.
Такое разделение собственно и позволяют сделать макеты. Это по сути реализация паттерна MVC, и как мне кажется более «правильный» путь.