• Клон Trello на Phoenix и React. Части 1-3
    +1

    Вы совершенно правы — с user-friendly поддержкой внешних стилей из npm зависимостей есть затыки. Сделаем; с этой проблемой не часто обращались.

  • Клон Trello на Phoenix и React. Части 1-3
    0
    Я никогда не имел дела с Branch, поэтому вместо него мы применим Webpack.

    Кстати, зря. Брунч таки сильно быстрее и проще. Это как нынешний create-react-app.

  • Сравнение популярных систем сборки для frontend-разработчиков
    0
    Если речь идет о ruby-haml, то все системы для сборки на node будут страдать от медленности его компиляции.

    Дело в том, что haml / sass (не libsass) будут использовать сабпроцессы для компиляции, в то время, как, например, jade — прямые вызовы node.js функций. Один тупой вызов сабпроцесса это 300мс на моей машине. Можно представить сколько времени может потенциально уйти на компиляцию реально большого проекта.

    Есть вариант использовать haml, переписанный на node, но у него будут отсутствовать фичи. Попробуйте сделать плагин лично, это очень просто. Вот, например, Jade-brunch — 1 маленький файл. Просто если плагин делает какой-то человек, который реально его использует, то он будет даже лучше поддерживаться, чем мейнтейнерами бранча, которые на него смотрят раз в год.
  • Сравнение популярных систем сборки для frontend-разработчиков
    +1
    А еще Бранч имеет бесплатную поддержку на русском. Будем рады выслушать ваши вопросы на toster.ru с тегом #brunch.
  • GulpJS — фантастически быстрый сборщик проектов
    0
    Миф используют, думаю, 0.01-0.1% людей от всех кто юзает альтернативные CSS-препроцессоры. Так что он не особо релевантен.

    Медленный сасс сегодня более актуален. Если через галп-вотч можно валить инкрементальные билды, то четко — надо поглядеть
  • GulpJS — фантастически быстрый сборщик проектов
    0
    Да, бранч решает чисто фронтэндовские проблемы. Галп подойдет много для чего.
  • GulpJS — фантастически быстрый сборщик проектов
    +1
    Та же тема, что и грант, только значительно чище и проще. Однозначно лучше гранта.

    Но проблемы, которые решаются бранчем оно не решает.

    Например, нет инкрементальной компиляции. И я не вижу как это с их архитектурой можно сделать. То есть при изменении одного файла, у них запустится пайплайн компиляции без поддержки кэшей и тд — медленно если файлов много.

    Для сложных проектов все еще нужно много настраивать. Например, «взять все файлы с bower, отсортировать и сгруппировать по зависимостям, добавить в очередь компиляции перед остальными файлами проекта, все свалить в один файл» — такое было бы не очень просто.

    Или даже банально — есть файлы coffeescript и jade. Как их скомпилять в один файл? Вижу как сделать два таска которые будут вотчить a) *.coffee b) *.jade и компилять в разные файлы, но не в один. Разве что через какую-то промежуточную функцию / таск.
  • Экзоскелет — быстрая и современная замена Backbone
    0
    Дак да — если андерскор подключен, он будет использоваться на 100% как и в обычном бэкбоне. Тут нет изменений, разве что дополнительные оптимизации из-за отсутствия поддержки старых браузеров.
  • Экзоскелет — быстрая и современная замена Backbone
    0
    У меня логика была бы такова:

    — Не прекомпиленные темплейты плохо, медленно. У меня для этих целей сидит brunch.io
    — is* заменяется toString.call(item) === '[Object Something]', typeof, instanceof или Array.isArray
    — extend и result встроены в экзоскелет (.utils) ибо они часто юзаются внутренностями.
    — defer это просто setTimeout(..., 0)
    — шаффл использует свой хитрый алгоритм, но мне обычно хватало [].sort(function() {return 0.5 — Math.random()})

    Подтверждаю насчет дебаунса, но его и другие особо полезные вещи можно добавить отдельными функциями в приложение, без необходимости тащить все 43кб андерскора.
  • Экзоскелет — быстрая и современная замена Backbone
    0
    Чисто ради интереса, что именно вы чаще всего используете?
  • Экзоскелет — быстрая и современная замена Backbone
    0
    Как я уже заметил, скорее всего не выйдет — это идет вразрез с интересами автора Бэкбона. Или что-то такое. Он консервативен и хочет поддерживать IE6 в своих кофескриптах и андерскорах-бэкбонах. Но я попробую.
  • MVC-фреймворки на JavaScript: сравнение Marionette и Chaplin
    +1
    По потреблению памяти наоборот — только реально нужные для текущего экрана вьюхи сидят в ней. Если какая-то вьюха (объект, модель) должна сидеть на двух+ экранах, можно это просто сделать через Composer и она не будет перегенерироваться.

    По процессорному времени создание нового экземпляра занимает мало времени. Короче говоря, в моей практике это никогда не было узким местом. Можно поглядеть накладность на ost.io, например.

    По скорости интерфейса идет зависимость от latency сети — как быстро можно сделать запрос к API и скушать JSON. Если все таки нужно 1-16ms вместо 200ms, есть вариант все кэшировать данные моделей через Backbone.dualStorage.

    Главное преимущество такого подхода в его простоте.
  • MVC-фреймворки на JavaScript: сравнение Marionette и Chaplin
    +3
    На самом деле весь MVC создавался для долгоживущих десктопных приложений. Это в двухтысячных пришли рельсоджанги и стали крутить свое. У рельс, кстати, не MVC, а Model2.
  • MVC-фреймворки на JavaScript: сравнение Marionette и Chaplin
    +2
    Дак не обязательно же. Многие используют его без кофе. Спецом для этого есть chaplin boilerplate plain.
  • Модульный подход к разработке web-приложений с использованием JavaScript: AMD и RequireJS
    0
    Можно и так, но зачем? Не лучше ли иметь окружение разработки (асинхронные модули) консистентное с окружением продакшена (конкатенированные синхронные модули)?

    Есть аргумент за легкость дебаггинга каждого файла по одиночке, да. Однако дебажить конкат. файлы в целом довольно просто, буквально за сутки можно привыкнуть. Особенно расставляя точки остановки в исходниках (debugger). И этот аргумент умрет с повсеместным распространением source maps (конец этого года).
  • Модульный подход к разработке web-приложений с использованием JavaScript: AMD и RequireJS
    0
    Да, самое главное с использованием этого стека: не нужно заморачиваться со сборщиком, с конфигами requirejs. Все это just works при выполнении одной команды в консоли, и очень похоже на другие языки (руби, питон).
  • Модульный подход к разработке web-приложений с использованием JavaScript: AMD и RequireJS
    +2
    Многие не осознают, что require.js это не единственное решение для хорошей модульности фронтэнда. А по-моему, это один из худших вариантов. Предпочитаю CommonJS для фронта, ну, который и в ноде используется.

    1. Нужно использовать очень хреновый и невнятный синтаксис == ужасно для дебаггинга. В commonjs можно просто написать в консоли браузера require('models/user') и выдаст то, что ожидается.
    2. По-умолчанию, requirejs шлет AJAX-реквесты, когда вызывается require и модуль не находится в кеше. Такой подход просто невероятно неэффективен в продакшене. Ведь круче сжать все в один файл и работать с синхронными модулями. Асинхронная дозагрузка может быть полезна только на штуках типа локализаций, но их можно прибить и к common.js тоже.
    3. Реализация де-факто стандартного require.js занимает 77 килобайт. Зепто, который почти полностью копирует API jQuery без поддержки старых браузеров, к слову, занимает 47K. CommonJS реализации на клиенте занимают в 30+ раз меньше, обычно.
    4. CommonJS означает возможность использования модуля в node.js. Для аналогичного действия с require.js надо проделывать трюки и прикручивать костыли.


    Пример полностью модульного commonjs приложения без глобальных переменных (backbone + chaplin): ost.io (папка «app»). Автоматическую сборку и объединение всего в два файла (один для app/, второй для сторонних библиотек) делает Бранч. Как видно, можно даже шаблоны подключать таким же образом (прекомпиляцией тоже занимается бранч).
  • Другой IncludeJS
    0
    Полностью согласен, однако это немного не в компетенции билдеров, скорее данные функции должны выполнять менеджеры зависимостей.

    В любом случае, бранч скоро получит поддержку оных (twitter bower, tj holowaychuk component.js) и, думаю, вопрос будет решен.
  • Другой IncludeJS
    0
    Как, на ваш взгляд, должна работать конкатенация скриптов? Что именно тулза может делать автоматом?
  • Обзор JS-фреймворков. Путешествие через джунгли JavaScript MVC. Ч. 2
    +10
    По-поводу билдеров. Если вы строите веб-приложение на любом фреймворке, вам скорее всего понадобится стэк, который автоматизирует всякую рутину. Например, автоматическое заворачивание файлов в “модули”, авто-компиляция coffeescript / less / sass / stylus / handlebars, авто-линтинг или авто-минификация в продакшене etc.

    Так вот, рекомендую “поздний завтрак” brunch.io для этого. Его в принципе можно использовать с любым фреймворком, а не только с backbone и ember как написано в статье. В частности, парни уже создали скелеты (базовые приложения) для angular.js, spine и так далее.

    Его аналог yeoman.io над которым работает Адди и команда yeoman как минимум до второй версии будет иметь дефицит всяких фич. Банально — поддержки виндоуза (даже с линуксом в текущей непубличной бете проблемы).

    А еще на неделе-второй Твиттер запустит проект Bower, это такой менеджер пакетов для фронтэнда, который базируется на спеке components от visionmedia. С билдером его использовать самое то.

    По-поводу фреймворков. Из списка бэкбон самый популярный и на нем сделано больше всего реально используемых приложений (Disqus, LinkedIn, Wordpress), так что вкупе с простотой, по-моему, это лучший вариант для новичка.

    Правда из коробки его стремновато использовать и, как в статье написано, лучше добавить небольшой фреймворк поверх (Marionette, Chaplin, Aura, Thorax): сравнение.

    Чаплин сейчас второй по популярности фреймворк на базе бэкбона, сразу после Aura от Адди, да и он единственный имеет open-source примеры, которые в отличии от todomvc реально показывают много деталей архитектуры. Скажем, твиттер-клиент или целый форум ost.io с рельсо-бэкендом.

    А вот brunch with chaplin (дефолтное базовое приложение бранча) уже объединяет простой билдинг с чаплином, кофескриптом и handlebars templates. Безумно удобно, кстати.