Получим красивую вложенную структуру в которой все посчитается. Тут только важно следить, чтобы количество итемов в списке не было очень большим. Это решение не страдает если данных слишком много (можно фильтровать по дням). У аналитикса так же можно сделать подобную штуку.
Недавно я решил поэксперементировать и сверстать TUI на HTML. Используя блочную модель и привычные border, background-color можно сделать интерфейс, который будет транслироваться в текст. Пока проект существует как proof-of-concept. Можно запускать в браузере или в консоли через phantomjs. Те мы фактически за даром получаем движок(CSS Box Model) и используя привычные многим языки(HTML+CSS+JS) можем рендерить текстовые интерфейсы. Живет на GH.
Забыл еще важный момент. Тк конфиги LMD декларативны, то возможно делать миксины и наследование конфигов, например прозрачно подменять локаль миксином или наследовать от абстрактной сборки. Еще есть мелочи вроде изоляции модуля, когда тот не может делать require() и алиасы (симлинки) для модулей.
Изоморфность оч скользкая штука. Например если ее рассматривать ее в контексте реиспользования кода, то как правило таких случаев очень мало или нужно писать абстрактный код (как написано в статье). Чаще все-таки есть сторона АПИ, прокся (для агрегации АПИ) и фронтэнд. Если проект достаточно большой, то 3 эти части могут писать разные группы и под разные среды. Например Ruby + Node.js + DOM (как написано в статье Закаса). И тогда пересечений в общей базе кода у них должно быть по минимуму во избежания конфликтов или каскада наследований в абстрактных частях.
Остается изоморфность модулей те методы запуска CommonJS в браузере. Тут способов более чем 3. Ну и спрашивать меня что лучше не совсем корректно :)
Когда есть модуль, который был изначально написан под ноду и очень хочется его запустить в браузере для демонстрации его. Единственное, что останавливало это разные способы ввода-вывода и браузерифай это место отлично чинил. Или же есть проект под любую среду, но разделенный на CommonJS модули браузерифай отлично собирал эти модули для отправки на клиент.
browserify main.js > bundle.js и готово — это было прекрасно.
Потом эта идея обросла хотелками от сообщества и браузерифай превратился в комбаин по натягиванию окружения node.js на реальность в браузере. В этот момент я сбежал от него.
— адаптация: browserify-shim — хорошая штука, но чинит не все, например, не умеет подменять this, но это может быть исправлено.
— относительные пути: ФС нет в браузере и соответственно пути ../../models/user не нужны. Вместо них можно использовать абстрактную ФС и подключать вот так models/user или modelsUser. И соответственно можно помешивать куски чужой абстрактной ФС в вашу сборку и использовать их как вам удобно.
— в LMD проще подключать динамические модули в сборку.
В остальном идеи схожи за исключением вкусовщины вида «как конфигурировать сборку декларативно или императивно».
Старнные у вас доводы. Складывается такое ощущение, что я впариваю какое-то плацебо вместо реальных советов из жизни…
но странная
Почему?
Прекрасно понимаю для каких вещей лучше использовать браузерифай, а для каких нет ;) Компиляция нодовых модулей — да; Веб приложения(SPA) — нет;
определять зависимости по конфигу?
Не зависимости, а правила именования модулей в вашем проекте и группировку модулей по бандлам плюс тюнинг LMD под ваши нужды.
— Конфиг в том или ином виде не избежен потому, что нельзя без полировки натянуть нодовую модульную архитектуру на особенности веб-приложений. В браузерифае это «гибкие трансформации», конфигурация бандлов, хардкодинг динамических модулей и прочий тюнинг.
— В браузере нет ФС — зачем использовать ../../models/user? Хотя можно использовать вот так models/user или userМodel при том, что такое именование можно задать одной строчкой сразу для сотни модулей.
Хорошо. jQuery это просто обертка над DOM те фактически DOM просто пофиксенный. Остается $name vs name в этом случае первоая переменная расскажет больше о своем содержании чем вторая (придется догадаться, почитать код).
Получим красивую вложенную структуру в которой все посчитается. Тут только важно следить, чтобы количество итемов в списке не было очень большим. Это решение не страдает если данных слишком много (можно фильтровать по дням). У аналитикса так же можно сделать подобную штуку.
Ну и, конечно (или подобный метод короткого GET)
Потом грепаем access.log и строим таблицу.
peopleCountElementя сразу вижу DOM элемент;$peopleCount— jQuery; Element Div и Ко будут сбивать с толку если в проекте есть jQuery.Остается изоморфность модулей те методы запуска CommonJS в браузере. Тут способов более чем 3. Ну и спрашивать меня что лучше не совсем корректно :)
browserify main.js > bundle.jsи готово — это было прекрасно.Потом эта идея обросла хотелками от сообщества и браузерифай превратился в комбаин по натягиванию окружения node.js на реальность в браузере. В этот момент я сбежал от него.
— относительные пути: ФС нет в браузере и соответственно пути
../../models/userне нужны. Вместо них можно использовать абстрактную ФС и подключать вот такmodels/userилиmodelsUser. И соответственно можно помешивать куски чужой абстрактной ФС в вашу сборку и использовать их как вам удобно.— в LMD проще подключать динамические модули в сборку.
В остальном идеи схожи за исключением вкусовщины вида «как конфигурировать сборку декларативно или императивно».
Почему?
Прекрасно понимаю для каких вещей лучше использовать браузерифай, а для каких нет ;) Компиляция нодовых модулей — да; Веб приложения(SPA) — нет;
Не зависимости, а правила именования модулей в вашем проекте и группировку модулей по бандлам плюс тюнинг LMD под ваши нужды.
— Конфиг в том или ином виде не избежен потому, что нельзя без полировки натянуть нодовую модульную архитектуру на особенности веб-приложений. В браузерифае это «гибкие трансформации», конфигурация бандлов, хардкодинг динамических модулей и прочий тюнинг.
— В браузере нет ФС — зачем использовать
../../models/user? Хотя можно использовать вот такmodels/userилиuserМodelпри том, что такое именование можно задать одной строчкой сразу для сотни модулей.