• Chipmunk: обновления
    +1
    Спасибо за ваш комментарий.
    Текущая картина такая:

    TS: ~74%
    Rust: ~16%
    HTML, LESS, CSS, Ruby — rest


    На rust сейчас наиболее ресурсоёмкие операции: индексация, декодирование/кодирование и другие. Но сессии и поиск модерируются на nodejs. Миграция ядра на rust подразумевает модерацию сессий, включая поиск, на уровне rust; на nodejs останутся лишь какие-то общие задачи. И даже в версии 3.0, я уверен доля rust не вырастет выше 30-35% и это вполне ок, ибо на front-end довольно много кода.

    Уточнить: rust не «сбоку», на нем уже сейчас лежит основополагающий функционал по подготовке контента к отображению (как было сказано выше: индексация, кодирование/декодирование). Ну а с версией 3 так и все ядро будет на нем.
  • Обновления в смотрелке логов
    +1
    Да, только english. Не уверен, что в ближайшее время появится поддержка других языков. Как минимум это не будет приоритетной задачей.
  • Обновления в смотрелке логов
    0
    Спасибо за Ваш вопрос. Из структурированных форматов, сейчас есть поддержка только для DLT формата. Иные форматы воспринимаются как plain text. Между тем, Вы можете создать feature request здесь и описать своё видение, что очень важно. Например мне сложно представить, что именно Вы хотели бы видеть в качестве поддержки логов в формате JSON. Как должна отображаться строка логов? Как текст или, например, поименованными столбцами (а если JSON имеет вложенную структуру?). Или может вы хотели бы видеть на sidebar представление выделенной строки логов как JSON pretty print? Как видите вопросов возникает масса, поэтому мы призываем создавать feature request, где Вы и мы могли бы обсудить как именно должна быть реализован тот или иной функционал.

    Ниже на скрине показано как выглядит DLT файл в chipmunk. Представление строк — столбцами; плюс на sidebar разбивка по полям.

    image
  • Обновления в смотрелке логов
    0
    Спасибо за Ваш отклик. Поддержка tail и возможность включения любых дополнительных кодировок появится в версии 3.x вместе с упомянутой мной оптимизацией производительности. Произойдёт это не раньше чем через 1-1.5 месяца.

    Что касается горячих клавиш, создал issue.
  • Обновления в Chipmunk
    0
    К сожалению, такого рода временные метки не могут быть идентифицированы прямым путём. Я имею ввиду, что это не соответствует формату YYYY, MM, DD, hh, mm, ss etc. Как отличить «20200825223600050161» от простого числа логах? Полагаю, что никак.

    Кроме того, в вашем случае нужно не только найти значение, но и преобразовать его, что несколько осложняет задачу.

    Для решения подобных задач в следующих версиях мы хотим добавить определение формата, как регулярного выражения с поименованными группами. Что-то вроде.

    (?&ltYYYY&gt\d{4})\s(?&ltMM&gt\d{2})(?&ltDD&gt\d{2})\s(?&lthh&gt\d{2})(?&ltmm&gt\d{2})(?&ltss&gt\d{2})

    Это должно будет работать и для вашего случая
  • Время в логах
    0
    Какого рода интеграцию вы имеете ввиду? Например, интеграция с DLT понятна — декодирование и разбиение на столбцы для удобства чтнения. С opentracing немного не ясно, что именно нужно интегрировать. Поясните пожалуйста.
  • Время в логах
    0
    Спасибо за разъяснения.
    На данный момент у нас есть в работе (на стадии спецификации) более широкий функционал (связывание записей логов по признаку, например, request <-> response по id), который однако, учитывает возможность связывания строки лога, имеющей временную метку, с последующими строками без таковой.
    Описанная вами ситуация непростая. Если мы говорим о логе, как о файле, то, очевидно, 1 запись лога — это 1 строка в файле. Такой подход не требует дополнительной индексации файла — открывай и читай. Если же мы хотим связать 1 запись лога с неким признаком, как дата и время, то мы автоматически говорим об индексации файла. То есть мы должны его прочитать, найти признак (в данном случае — это дата и время), создать карту (индекс), где-то её эффективно хранить. Конечно, это операция не из дешёвых и вряд ли должна «включаться» по умолчанию при открытии файла, скажем, в 4 Гб. Однако и необходимость в таком подходе тоже имеется конечно.
  • Время в логах
    0
    Спасибо за ваш комментарий.
    Chipmunk, конечно располагает всем базовым функционалом, включая, естественно и поиск. Подробнее об основных возможностях вы можете прочитать здесь.
    Относительно работы с многострочными сообщениями не совсем ясно, что именно вы имеете ввиду. Не могли бы вы в деталях раскрыть идею?
  • Безумные логи
    0
    просто обновите ruby. Там были обновления URI библиотеки.
  • Безумные логи
    0
    Спасибо
  • Безумные логи
    0
    думаю, что да.

    git clone https://github.com/esrlabs/chipmunk.git
    cd chipmunk
    rake full_pipeline


    Релиз увидите в

    chipmunk/application/electron/dist/release
    

    На борту надо иметь:
    • node 10 и младше
    • ruby 2.6 и младше
    • rust
  • Безумные логи
    0
    Полностью с вами согласен, юзкейсов очень много. И далеко не всегда логи хранятся удалённо. У нас, например, довольно большая группа пользователей, работающих с embedded software. И там можно получать десятки гигобайт логов лишь за ночь или за одну сессию тестирования. При этом логи часто бывают от нескольких источников, что вовсе не облегчает жизнь. Ну и конечно, такие логи живут более ли менее локально.
  • Безумные логи
    0
    Спасибо за ваш вопрос. Там были изменения в порядке подписания приложения. Мы «покрыли» тот порядок, который установлен на 10.15 и младше, и, честно, не стали заморачиваться над поддержкой процедуры подписания для более поздних версий. Дело только в подписи. Решили, что если появится issue на этот счёт, то обязательно добавим поддержку более ранних версий ОС, но пока запросов не поступало.
  • Безумные логи
    0
    нет, релизы пока публикуются только на github
  • Безумные логи
    0
    Спасибо за ваш совет. Как ответить — не знаю. Задумался. Ведь так то вилка умеет три четверти того, что делает ложка, но меж тем она существует :/
  • Безумные логи
    0
    Спасибо за ваш комментарий.
    Полагаю я уже ответил частично на ваш комментарий здесь. Могу добавить, что есть несколько идей по тому чтобы научить chipmunk цепляться по ssh, что во многом снимает вопрос удалённого доступа, но открывает проблемы другого характера. Пока думаем над этим. Но если у вас есть какие-то идеи или пожелания, будем очень рады увидеть их в качестве feature request.
  • Безумные логи
    0
    Спасибо за ваш комментарий. Я отвечу сравнением, если позволите.

    В каких-то повседневных задачах, не знаю, файл с настройками подправить, я вот не задумываясь прибегну к nano (или если настроение плохое, к vim). Но все же, для работы над проектом, я открою VSCode или что-нибудь от JetBrains. Я сделаю это не потому что не могу кодить в vim или nano, а просто потому, что удобнее это делать в IDE. Хотя, если задуматься, IDE добавляет в общем-то какие-то совсем тривиальные вещи: подсветку, обзор папки с решением, поиск по файлам, поиск по зависимостям и ссылкам, отладчик, конечно. И вот эти вот мелочи делают работу удобнее и быстрее.

    Как-то так и возник chipmunk. Блин, а как сохранить шаблоны поиска (скажем фильтров 5-10) и не терять их, а ещё по необходимости шарить с коллегами? А как усадить студента-тестировщика и не ввергать его в шок консольными командами, а сказать: «увидишь здесь красное — кричи!». А у нас в логах тут куча закодированных данных, которые было бы очень здорово не копи/пастить по окнам, а сразу читать. Ну и так далее. То есть базово вопрос не в том, что chipmunk умеет делать что-то что не умеют другие, нет, а в том, чтобы попытаться делать это проще. Хотя есть и DLT, которые с консоли декодировать та ещё проблема.

    На счёт tail, то уже есть feature request по этому поводу. Думаю что в ближайших обновлениях это появится, то есть chipmunk будет открывать файл и обновлять по мере его изменений.

    ЗЫ. Кстати ripgrep шустрее )
  • Пора ли увольняться?
    +4
    Не бывает «некуда уходить». Бывает только «страшно». Просто начинайте смело работать над своим желанием лучшего. Заставьте себя хотеть перемен. Убедите себя в том, что иного выхода, кроме как двигаться вперед у вас тупо нет. Прямо так – или я тут в конце концов сопьюсь (утрированно), или я стану крутым парнем из столицы. Никто, вообще никто не держит вас на месте, кроме вас самих. Поймите это, и все потихонечку начнет двигаться.

    Посмотрите требования к тем позициям, которые вам интересны. Проанализируйте то чего вам не хватает. Подтяните это. Шаг за шагом в течение года вы при должном стремлении и желании найдете новую работу и без труда осуществите переезд. Говорю вам как человек сменивший три города и две страны )
  • 42 строки кода для выхода из лимба
    0
    Не думаю, что событие должно порождать событие (то есть само себя). Из этой парадигмы мы исходили, да и исходим в проектировании. Если же возникнет такая ситуация, то лучше работать с такой ситуацией, как со специальным случаем, а не наоборот. Поэтому дефалтное поведение – остановить, а возможность «вырваться» из проверки остается через «небезопасный» асинхронный вызов.

    Так же ваше решение отличается еще тем, что переопределяется ряд нативных средств (setTimeout, setInterval и другие), у нас это запрещено религией), хотя по большому счету к делу это и не относится. Но в целом мне нравится. Спасибо за ваше время на эксперименты.
  • 42 строки кода для выхода из лимба
    0
    Спасибо, сработали суеверия. Вы совершенно правы. Подправил, обновил.
  • 42 строки кода для выхода из лимба
    0
    Если у вас есть событие «Aa» и событие «a», то это два разных события.
  • 42 строки кода для выхода из лимба
    0
    Каких-то специальных тестов я не делал. Не совсем ясно, что тут может понизить производительность, тем более в жизни события не запускаются один за другим так «плотно». По тому проекту, где было применено данное решение никакого ухудшения замечено не было. Все-таки – это больше реакция на какое-то внешнее воздействие, а не поток событий.

    С другой стороны, я делал тест на глубину цепочки, это да. Выложил на github в examples если интересно. Прогонка на 1000 событий, где 1000ое событие взывает нулевое, образуя цикл. Главным образом делалась проверка на утечки, но и производительность с этого теста тоже видна.
  • 42 строки кода для выхода из лимба
    0
    Может я что-то делаю не так, но ваше решение не работает (будьте осторожны JS уйдет в глубокий нимб после запуска).

    У меня было решение без именных функций сродни вашему, но там возникает проблема иного рода, а именно нужно чуть более усердно думать об очистке за собой. Поэтому решение с именными функциями мне показалось наиболее оптимальным, так после себя ничего не оставляет. С этим примером можно в этом убедиться.
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    Извините, Борис

    Но я никак не могу понять, что вы хотите сказать/доказать?

    • Что react знает больше людей? Очевидно.
    • Что я покусился на святое? Я уже ответил Вам ниже, что никто react «уделывать» не собирается.
    • Что react и подобное нужно использовать везде (даже в до безобразия маленьких проектах)? Весьма и весьма спорный тезис.
    • Что не нужно / нельзя / запрещено искать собственные решения для тех или иных задач? А как же тогда тот же react на свет появился? До него, что не было альтернатив? А как быть с нашим Яндексом? Уж сколько он «пилит» своих решений. Он тоже плохой?
    • Или может вы считаете, что если некий проект сделан на react, то его с ходу «прочитает» любой сторонний разработчик? Да, нет. Все также придется какое-то время сидеть и разбираться, что к чему.


    Конечно, специалистов по react много. Очень много. И эта вот заветная надпись в CV: react или angular, она прибавляет в стоимости специалиста (о чем вы не упомянули). Но… Могу сказать из опыта нашей команды. Мы, как бы это сказать, «побаиваемся» супер-спецов в react / angular / [вписать нужное]. Потому что за тем «комфортом», который создается фреймвоком теряется сам язык и сама платформа. Может, когда-нибудь в будущем pure JS будет чем-то вроде asm сегодня. Но сейчас, мне больно видеть, как «программисты» по JQ теряются и не знают, как сделать ajax вызов без оного. Или супер-спецы по react не понимают, что такое void 0 или элементарные bind, call и apply.

    Еще раз, у спора должен быть предмет. Я его не вижу. Вы во всем совершенно правы. Но говорите вы не о конкретном решении, приведенном в этой статье, то есть говорите вы не о Flex.Patterns (он же виновник) и даже не о react вы говорите, а говорите вы о том, как в вашей компании ведут бизнес, то есть вы говорите о вашей бизнес-модели. Но статья то не об этом.

    То, что шаблон на react смотрится не сложнее шаблона на Flex.Patterns – очевидно. Я и не говорил нигде, что он смотрится проще. Я лишь делал акцент, что в Flex.Patterns нет никакого дополнительно синтаксиса, кроме стандартного, что делает его доступным для понимания любому человеку знакомому с JS и HTML.

    Спасибо.
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    Спасибо
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    +1
    У меня, конечно, то еще самомнение, но в одиночку противопоставлять себя замечательным, талантливым и умным ребятам, создавшим react?

    Нет, я никого не хочу «уделывать». И если вы посмотрите на мой предыдущий пост об этом шаблонизаторе, то увидите, как яростно я отказывался сравнивать шаблонизатор вообще с чем-либо. Во-первых, не время – не все еще готово из задуманного. Во-вторых, и концепция от части может поменяться.

    Что бы как-то ответить на ваш вопрос, я расскажу (и от части повторюсь) о том, с чего все началось.

    Какое-то время назад на паре проектов (админки) была необходимость отображать куски (порой большие) HTML. Особенностью было то, что эти элементы (хотя по объему это были порой страницы) нужны были далеко-далеко не всегда. Ну кто ж его знает пользователя, клацнет он по заветной кнопке или нет. Выделять под это дело адрес отдельный (новую страницу) – не выход; а держать в разметке (на тот случай если таки клацнет пользователь) – дорого. Решения были не наши (мы их лишь дорабатывали, а не переделывали, поэтому ни о каких react или чем-то еще и речи быть не могло) и прежняя реализация была через фреймы (тут даже мужчины имеют право на слезу). Тогда возникла идея написать небольшую тулзу (она и была небольшой в самом начале ~2000 строк), которая бы умела грузить HTML файл, проверять его ресурсы (JS, CSS), грузить и их, делать какие-то вставки, все это аккуратно собирать и бережно хранить на клиенте. Вот в этом моменте и был зачат проект. Реализация никаких нареканий не вызвала, все работало (и работает) прекрасно, а версальщик так вообще был очень доволен, ибо получал в работу обычную HTMLшку, которую мог открыть локально и отладить все что нужно. Так вот это все и зародилось. Я же свою идею решил не оставлять, а «повозиться» с ней еще «немного». По мере движения и прикручивания «тулзы» в разные другие проекты она стала обрастать мясом и в итоге вы видите то, что есть сейчас.

    Иными словами, в момент «зачатия» проекта никто ни о каком react’е не думал и тем более о том, чтобы его уделывать.

    Что же касается минификации, то этот вопрос все еще открыт. Думаю, над ним. Технически объединение шаблонов не проблема. Но есть ряд иных вопросов, связанных с тем, как вставляет контент в разметку шаблонизатор, что мешает идти, скажем так, простым и накатанным путем.

    Спасибо за ваш вопрос и ваше время на эксперимент )

  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    Ну на самом деле – это верный подход. Должны быть некие свойства/характеристики, которые отличают продукт от его конкурентов/аналогов.

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

    Сейчас как раз она и есть, стадия разработки. Поэтому я могу дать (и даю) перечень идей, лежащих в основе продукта. Я могу повторить:

    • Избегание дополнительного окружения (библиотек, тулзов и прочего). Полная самодостаточность и возможность расширения функционала внутри решения со стороны разработчика. Это уже во многом реализовано. Flex.Patterns легко позволяет добавлять свой функционал к тому, что уже есть. Скажем вы «прицепились» к узлу, Flex.Patterns даст вам основной набор инструментов (ну там события прицепить, размеры снять, стили переопределить, анимацию применить и прочее). Но на ряду с этим у вас есть простой интерфейс для добавления своих инструментов к данному функционалу и, что очень важно, интегрировать эти вот свои инструменты внутрь Flex.Patterns – то есть делать свою собственную сборку конечного продукта.
    • Только стандартный синтаксис. Ну об этом я уже очень много говорил.
    • Хранение шаблонов и их ресурсов на клиенте.


    Вот три идеи, которые на данный момент формируют вектор развития проекта. Но, а о «киллер-фитчах» мне пока говорить преждевременно.

    Спасибо за ваш вопрос.

  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    спасибо
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    0
    Спасибо, исправил.
  • Как мы всех на юх послали (ну или продолжение истории про шаблонизотор)
    +1
    Я бы не был столь категоричен. Да и нет здесь предмета спора.

    Я особо не идеализирую решения, за которыми стоят (далее список) крупные команды и/или компании. От них сюрпризы случаются совсем нередко. Не стоит их идеализировать. То версию обновят так, что интерфейсы изменятся; то методы отрубят, которые раньше вполне себе работали. В результате для некрупного проекта, версия той или иной библиотеки попросту «замораживается», потому что переделывать все под очередное обновление выходит слишком дорого. В npm можно найти далеко не одно решение для каких-нибудь нужд, например, на базе react. Хорошие решения, грамотные. А запускаешь с последней версией react’a и сыплются в консоль «this method deprecated».

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

    Что же до топика, то описанный шаблонизатор как раз и задумывался как максимально упрощенный. Никакого дополнительного синтаксиса кроме стандартного HTML и JS. Как раз для того, чтобы сопровождение и/или мелкая коррекция проекта не вызывала особых трудностей.
  • Front-end шаблонизатор
    0
    Спасибо, обязательно посмотрю.
  • Front-end шаблонизатор
    0
    Спасибо за ваш комментарий.

    Чуть выше в комментарии я рассказал с чего все началось (как этот шаблонизатор был выделен в отдельное решение). Оба тех проекта, где всецело применено это решение – это админки. То есть по существу – это одинаковый набор элементов управления, где разница есть в их компоновке и данных. В такой ситуации перенос представлений на клиента дал хороший результат. Первая загрузка подольше будет, зато вторая и последующие ощутимо шустрее. В свою очередь разбиение разметки на компоненты дало возможность их отладки в отрыве от приложения, что было очень удобным. Кроме того, после реализации первого проекта к началу работы над вторым уже была хорошая коллекция контролов, которые просто брали и использовали.

    Таким образом, идея переноса представлений на клиента состояла в том, чтобы очень большую часть разметки, банально повторяющуюся от страницы к странице перенести на клиента. Перенеся все это на клиента, уменьшили отклик от сервера. А разбив все по элементам управления добились переносимости между подобными проектами.

    Требования к мобильным устройствам в данных проектах практически не выставлялись, хотя и на них работает (но не тестировалось так глубоко и основательно, как десктоп).
  • Front-end шаблонизатор
    0
    Спасибо всем за радужный прием)

    Из всего спектра комментариев лишь одно дельное замечание, про экранирование (упущенное из виду). Спасибо.
    На все остальное (там, где я проигнорировал) я могу ответить парой абзацев, потому как обсуждать, например, то, как проект выложен на github’е я смысла не вижу.

    Я писал свое решение, не потому что других решений не существует, а потому что хотел разобраться как это работает. Для меня это здоровая (от слова здоровье) мотивация разработчика. И если собственник проекта не против экспериментов, то для программиста – это находка и глупость упускать подобный шанс; шанс понять, как оно работает изнутри; шанс проверить себя – смогу / не смогу сделать работящее самостоятельное решение. Не пригодится в будущем? Возможно. Кому-то не понравится? Конечно! Но, хвала Зевсу, для меня это не главное и практически не важно.

    Видимо часть людей просто стала забывать, что разработка – это прежде всего творчество, искусство, возможность дать своей мысли форму. По крайне мере для меня – это именно так и именно по этой причине я пришел в эту профессию. Поэтому что я могу сказать? «Велосипедил» и буду «велосипедить» дальше, даже несмотря на то, что рядом лежит ReactJS, AngularJS, Jade, EJS и прочие тысячи инструментов.

    Еще раз спасибо за Ваше время.

  • Front-end шаблонизатор
    0
    Спасибо за комментарий. На это уйдет какое-то время, чтобы создать сопоставимые и наглядные примеры и «красиво привинтить» их к документации. Думаю, что неделя или две и я что-то подобное выложу.
  • Front-end шаблонизатор
    –2
    Спасибо за комментарий.
    Потому что тег TEMPLATE часть стандарта, а мне не хотелось свое «нестандартное» решение смешивать со стандартами. Однако в patterns предусмотрена простая возможность переопределения корневого тега шаблона.

  • Front-end шаблонизатор
    0
    Спасибо )
  • Front-end шаблонизатор
    +1
    Спасибо за ссылку. Почитал, очень интересно. У нас с вами разное целеполагание. У вас более глобально, что ли. У меня же все приземленно )). Моя задача была – шаблонизатор только для front-end.

    Да, есть возможность вставки шаблонов в HTML, но опять же и сборка шаблона, и вся работа по его анализу – все на клиенте.

    Кроме того, все началось с простой и банальной задачи. Я опишу, если позволите. Было приложение, со множеством разных «окошек» (админка в общем). И там была куча разных контролов. Почти все создавалось на серверной стороне. Потом пришла в голову мысль – а не перенести ли нам все это на клиента – нехай он сам парится, а на сервере все почистить, минимизировать и в идеале оставить только API. Посчитали количество контролов, вышли на несколько десятков очень простых элементов, которые могут работать автономно (то есть не зависят от какой-либо библиотеки и/или фреймвока). Тогда и пришла в голову мысль, а не распихать ли эти контролы по папочкам с JS и CSS, которые к ним относятся. Ну а на клиенте просто их подключать по мере необходимости.

    В результате всего этого сервер стал передавать лишь базовую разметку, а вся рутина по рендерингу ушла на клиента вместе с нагрузкой. Мне не удалось, безусловно, превратить серверную часть просто в API сервис, но представлений с серверной стороны было убрано очень много. Ну разве что базовая разметка осталась, как я уже отметил.

    Потом была еще пара подобных проектов, где перенос представлений на клиента прошел довольно успешно.

    Ну а потом я решил, что пора это все привести в достойный вид (более ли менее) и выложить, может кому и полезным будет.

    Иными словами, вот эта штука, которую я тут на ваш суд выставил – это такой инструмент, который позволяет представления вытаскивать с back-end на front-end. И главное, это позволяет проводить отладку каждого шаблона в отрыве от всего проекта. И такого рода инструмент он не универсален, безусловно, он для определенного круга задач.
  • Front-end шаблонизатор
    –10
    Поясните, пожалуйста, зачем выкладывать «расковырянную» версию и почему то, что лежит сейчас на github нереальные исходники? )

    Просто я искренне полагал (и полагаю), что рабочий «мусор» на паблике ни к чему. Есть файл, есть история с которой видны изменения ну и так далее.

    Если вам интересен какой-то отдельный модуль, то просто сверните код до второго уровня вложенности и вы увидите все девять модулей по отдельности. Да и станет очевидным то, как все это собирается.
  • Front-end шаблонизатор
    –3
    Если посмотреть на код и свернуть блоки до 2-ой вложенности, то вы увидите 9-ть независимых друг от друга модулей (в том смысле, независимых, что они могут существовать отдельно). То что вы видите на github, да и на промо сайте — это уже результирующий файл.
  • Front-end шаблонизатор
    –1
    Спасибо за комментарий. Я думаю, что сравнивать этот шаблонизатор с React нельзя — разные масштабы, да и React — это не шаблонизатор. Ну а то что сделал я — это для очень узкого круга задач — фактически это просто инструмент для создания не слишком сложных UI компонентов (по крайне мере я его так применяю). У React спект применения значительно, значительно шире.
    Для меня (я могу судить только по себе :)) главное приимущество: это возможность открывать шаблоны в отрыве от проекта, отлаживать их, править стили. Мне это удобно. Даже если компонент стал сложный, с логикой какой-то, то на создание тестовой страницы (что бы открыть его отдельно) уходит 3-и минуты и все, я снова могу отлаживать копмонент в отрыве от всего приложения.