Алексей Ярошевич

Блок должен находится на уровне переопределения. Например: app.blocks.
Удобнее блоку сделать свою папку (и все блоки хранить каждый в своей папке): app.blocks/hello-world
У блока должна быть какая-то реализация. Например, css: app.blocks/hello-world/hello-world.css

Возвращаясь к вопросу:

mkdir ./app.blocks/hello-world/ -p
touch ./app.blocks/hello-world/hello-world.css

Либо, если хотите использовать bem-tools:

npm i bem-tools
bem create level app.blocks
bem create block -l app.blocks hello-world

Один из простых способов:
1. Генерируем из исходного json по каким-то правилам bemjson c описанием структуры формы и блоков с элементами;
2. Используем https://github.com/bem/bem-forms как базу (или пишем аналог) для создания базовой библиотеки с шаблонами и базовыми типами полей и контролов;
3. На уровне проекта расширяем своими контролами (шаблонами, стилями, и т.д.);
4. Собираем чем-то стандартным, типа enb.

MVC для фронтенда не есть удачное решение, это становится очевидно, когда кол-во успешных MVC фреймворков для JS фактически равно нулю. MV* парадигма вполне работает, но без контроллеров.

С шаблонами мусташ ситуация следующая — либо не будет возможно доопределять трансформации, описанные шаблонами: т.е. придется копировать из исходной библиотеки шаблон и изменять его, в итоге проблемы при обновлениях; либо не использовать библиотечный подход для шаблонов вообще. Почему так: потому что mustache интерполируемый и императивный шаблонизатор, его технически нельзя научить доопределению. Если все же нужен именно mustache — достаточно будет написать технологию для enb, в гитхабе точно есть примеры для jade, и, кажется, некоторых других. По сути, пара несложных функций, где пишется: возьми этот файл как шаблон для шаблонизатора такого-то и создай из него функцию для отрисовки данных.

Если думаете про i-bem.js, то jquery у вас так и так будет (потому что i-bem использует jquery), с require.js — возможно, будет проще использовать ymodules: не сильно отличается от require.js, на нем уже основаны bem-core/bem-components и, соотв., bem-forms тоже, и взяв стандартный набор джентельмена от яндекса ничего не надо будет менять с этой точки зрения — все уже настроено.

Применять БЭМ-подход, не используя БЭМ-стек технологий, обычно больно, и так или иначе начинает писать свой БЭМ-стек технологий. Многие это проходили (если не все) и большинство перестали так делать.

А вообще, есть форум, где на такие вопросы отвечают намного быстрее и с примерами ;-)

Если использовать https://github.com/bem/bh и https://github.com/bem/bh-php (шаблоны там почти 1-в-1, с точностью до $ в переменных), то можно выгружать шаблоны и на фронт, и на бекенде собирать нужное.

Еще лучше использовать прослойку на nodejs чисто для сборки html для первого захода, поисковиков, людей без JS, и не думать про это в целом, а на PHP оставить всю логику и использовать как API.

Еще, чтобы уменьшить размер передаваемых данных:
а) gzip;
б) raw-json;
в) protobuf.

Если передавать только нужное и не потеряться — нужно сделать двухпроходную шаблонизацию, т.е. в 2 шага — 1) конвертируем из сырых данных в некий промежуточный view-ориентированный json, а затем из последнего собираем html с помощью шаблонов на матчерах.

Если любите экспериметировать, можете попробовать еще вот так:

// Допустим, у нас есть выгруженные шаблоны на фронт
bh.match('users-list', function ... );
bh.match('user', function ... );
// etc.
// дальше мы должны получить данные с бекенда, для простоты укажем их явно
var usersFromBackend = [{name: 'Vasya', id: 5}, {id: 42, name: 'Petya'}, ...];
// как получили — собираем каким-то образом некую view-ориентированную структуру типа:
var viewOriented = {
  // здесь можно использовать и что-то более умное
  block : 'users-list',
  content : fromBackend.map(function (el) {
    return {
      block : 'user',
      // привязываем к users-list по БЭМ
      // (мало ли понадобится что-то в стилях-скриптах подтюнить)
      mix : { block : 'users-list', elem : 'item' }, 
      // выводим контент в каждый div
      content : {
        block : 'link',
        mix : { block : 'user', elem : 'link' },
        url : el.url || '/users/' + el.id,
        text : el.name
      }
    };
  })
};
// И после получаем готовый HTML еще одной операцией, который останется куда-то вставить
console.log(bh.apply(viewOriented));

При том, что шаблоны у нас одинаковые (для php с точностью до $ в переменных) для фронта и бекенда — кол-во дублируемого кода падает. Появляется возможность вставлять одинаковые блоки в разные места на странице с разными данными, структурировать CSS (самое известное из BEM, даже гугл рекомендует), и т.д.

Я бы ничего не менял. Возможно, попробовал бы еще tarantool для микрозадач или как замена редиса.

Но как вариант — C# или Java, и RavenDB какой-нибудь тоже вполне вкатит под «технологии highload».

Еще вместо обычного mongo можно попробовать drop-in замену в виде TokuMX: https://github.com/Tokutek/mongo

Можно еще попробовать https://github.com/2gis/slot

У них там специфичный БЭМ, изоморфность, и все такое.

Можно еще через OOP в Ruby. www.theodinproject.com/ruby-programming/object-ori...

Берете OOP в Ruby, отсекаете Классы и Мета-классы, добавляете (вместо классов и метаклассов) — свою реализацию типа https://github.com/dfilatov/inherit или любую другую — получаете классы в JS.

ES6 классы, насколько я знаю, это просто сахар, так что не питайте надежд — оно не далеко уйдет от того, что есть сейчас, просто появится возможность писать более коротко.

Возьмите, например, d3js.org

Какой-то у вас вопрос из разряда «Пацаны в гугле забанили спасите!»

Если на входе: координаты, кол-во кубов (через коэффициент или число, кратное 8) и размеры, geometry, material.
То: мне видится цикл вложенности 3, который можно будет оптимизировать, и который будет считать координаты для кубов для каждой размерности, ну и запускать там вашу функцию (только слегка модифицированную, ибо x, y, z не должны быть 0).

Сделайте расчет координат отдельно, выведите их, проверьте что все правильно, и после подставьте туда отрисовку в нужных координатах вашего куба. Самое простое — это разделить задачу на несколько простых и после использовать их в правильном порядке.
Простите, без кода ;-)

Идея, мягко говоря, очень плохая. Лучше сделайте так:

$(document).ready(onDOMReady);
function onDOMReady () {
  // ваш код
}

И в нужном месте просто вызовите эту функцию.

Это будет и быстрее, и надежнее.

Я бы еще предложил:
- написать библиотеку промисов или монад (www.youtube.com/watch?v=b0EF0VTs9Dc);
- поучаствовать в одном из сотен тысяч опенсорс проектов на гитхабе (https://github.com/search?q=language%3AJavaScript&...);
- поотвечать на вопросы новичков про JS на тостере ;-), искать самому ответ, параллельно читать ответы других участников, как проверочный материал.

А вообще — весь спектр классических задач — лучше брать те, которые самому интересны. JS таков, что ограничений на алгоритмы у него нет, хочешь используй как функциональный язык, хочешь — как императивный — простор для фантазии ;-)

Не очень понятно зачем это делать через websocket, но даже если представить какой объем вы будете через них отправлять — качество будет того.

Можно попробовать посмотреть в сторону решений типа https://github.com/phoboslab/jsmpeg, но это на nodejs и требует ffmpeg/VLC.

Сам капистрано хорошо справляется с задачей, но аналоги есть.

Например, https://github.com/1602/roco
Если будет интересно — я переписал его, чтобы его можно было пилить дальше и использовать для создания своих оберток, но остановился на тестах и процесс пока встал. Т.е. оно вроде бы работает, но без тестов МР не поставишь, а тесты были сильно завязаны на внутреннюю архитектуру, которая поменялась.
Ну и да, кроме того, что он на nodejs, его скрипты не синхронные, как и сам nodejs, хотя таски и группы создаются аналогично.

Сами таски описываются на coffee и очень похожи на таски capistrano.

Сходу, это Q, и Vow (именно его я чаще всего и использую, в т.ч. на клиенте).
Еще есть менее известные then promise и bluebird
Все это называется Промисы (обещания) или Promises/A+
Это то, что касается промисов. Есть и другие библиотеки bit.ly/1putPFj

Есть еще вариант использования различных библиотек для контроля потоком, которые тоже из горной лапши делают более-менее стройный код.
В т.ч. async, более простая, но не менее эффективная обертка над стандартными колбеками.
И другие: Step, Seq, FuturesJS.

Кроме этого, в стандарт рано или поздно будут включены т.н. генераторы (yield) — часть harmony es6. Уже даже есть наработки в эту сторону типа koajs (замена expressjs).
Они находятся в ветке 0.11, но требуют флага при запуске. Гарантий, что это появится в 0.12, конечно, нет, но в 0.14 или 0.16 оно появится с большой долей вероятности.