• Знакомство с графовыми API
    0
    Да, каждому инструменту найдется свое применение :-)
  • Знакомство с графовыми API
    –1
    У этого решения тоже есть свои недостатки:
    — трудности с переносом в другой проект;
    — на мелких проектах на любые велосипеды не хватит времени;
    — не очень широкие возможности по фильтрации (а если вам нужны только группы удовлетворяющие определенному условию?);
    — никто не сказал, что у вас хватит времени на корректную имплементацию этого добра (например, так чтобы вы загружали только запрошенные данные, но при этом еще и работал бекендский кеш)

    Но как бы можно, да.
  • Знакомство с графовыми API
    –1

    Этого недостаточно. Как минимум, при REST появляются запросы зависязие от результата предыдущего запроса (например, для вложенности третьего уровня).
    И самое важное: при graphql у вас гибче сервер, что упрощает разработку клиента.

  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    0
    Да, верно. Если не делать ничего, то и инструменты не понадобятся :-)
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    0
    Как человек смотревший на оба подхода в плане long-term я заявляю, что есть необходимость.
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    –1
    Не так уж и сложно, по сравнению например с C++.
    Ну если вы говорите о сложности C++, а не о частоте его используемости, то у вас тут маленький косячок в рассуждениях.

    Дело в том, что людей нанимают не из-за знания чего-то, а чтобы эти люди решали какие-то проблемы. У brainfuck порог вхождения еще ниже чем у sql, но найти senior brainfuck developer будет куда сложнее, даже если язык будет популярен.

    Код все равно приходится выбрасывать, потому что бизнес требования постоянно меняются.
    Бизнес-требования меняются, но не все и не в один момент. А 100к — это дохуя, даже чуть больше чем дохуя.
    Одно дело, если вы понимаете что рационально что-то выбросить. Другое дело, если вам приходится выбрасывать код из-за левых причин.
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    +1
    А что, десктоп приложения еще кому-то нужны в таких количествах, чтобы создавать много рабочих мест?
    В любом случае писать десктопное приложение с прямым доступом к бд — затея так себе. Конечно, за исключением встраиваемых бд (нерасшариваемых).
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    0
    Да, вы не говорили про html. Html это просто для примера того, что в теории можно сделать на sql

    Где я говорил, про чистый SQL?
    Мм, вы говорили про то, что вы не уверены, что не стоит писать бизнес-логику на SQL. Я предложил вам задачку: написать логику игры в морской бой.

    то что мы не видели, не означает, что этого нет.
    Слыхали про чайник Рассела? Вероятность этого явления чрезвычайно мала.
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    –1
    Потому что SQL не предназначен для бизнес-логики. Да, в нем есть куча всякого. В теории, вы можете написать небольшой веб-сервер, который будет перегонять все входные данные из запроса в параметры для хранимки и вызывать её. А хранимка будет формировать уже готовый JSON-ответ или html. И ваш тоненький сервер будет отдавать результат клиенту. И можете даже сделать больше одного API (роутинг, и т.д.). Можете. У вас есть средства для этого. Но это не значит, что стоит так пытаться сделать.

    Так вот: я не видел успешных попыток решить задачу через полностью не подходящий инструмент. Это удел хаба ненормальное программирование, а не продакшен кода.

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

    Предложу вам задачку. Напишите мультиплейерный морской бой на чистом SQL. И сравните итоговый код с какой-нибудь реализацией на современном языке программирования.
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    0
    Никакой реальной экономии нет на долгосроке. В краткосроке может быть.

    В самом тупом варианте вы напишите http-обертку над вызовом хранимки за достаточно малое время. Проценторно в долгосроке затраты на такую прослойку будут стремиться к нулю.

    В более умном варианте вы используете ООП/ФП, фреймворки и чужие библиотеки, что делает вам x10 буст по сравнению с написанием хранимок.

    А также: в sql огромные проблемы с реюзом кода. Отсюда вытекают нарушения DRY.

    У меня к вам вопрос: вы вообще пытались на практике активно писать годик командой в таком стиле?
  • Удивительный Angular
    +1
    То, что кто-то пишет плохие, негодные компоненты — это проблема сообщества. Вы для любого фреймворка всякое говно при желании найдете. Да вобщем-то и для любого языка и для любой области, просто в случае жс/веба эта проблема стоит наиболее остро.

    Вы знаете, проимплементить фреймворк в базовой комплектации не такая уж долгая задача, если знать как (к примеру, смотря на другие фреймворки).

    Мне кажется, что весомая часть разумного выбора фреймворка опирается на то, что у него есть сообщество, что фреймворк будет поддерживаться. Если вы говорите, что сообщество Ангуляр говно, то это минус Ангуляру. А не какой-то сторонний факт, не относящийся к делу.
  • Удивительный Angular
    0
    Эмм… Только вот релизный цикл у ангуляра весьма короткий. Это убивает компоненты уже оттестированные и уже работающие. И есть большая разница между обновлять компонент раз в два года и обновлять раз в полгода. Не каждому нравится онанировать по столько частому графику.
  • Удивительный Angular
    +1
    Добавлю
    1. Нетипизированный роутинг
    2. Нетипизированные формы
    3. Dependency Injection строго иерархический: нельзя предоставить сервис объявленный на нижнем уровне внутрь сервиса объявленного на верхнем уровне. Дрочево.
    4. DI не предоставляет хуков для уничтожения сервисов
    5. Бойлер-плейт везде.
    6. Нет способа добавить поведение к компоненту извне. Директивы не считаются, ибо умеют только с нативным аттрибутами и ивентами работать.
    7. Для того, чтобы ngFor работал не через жопу нужно написать trackBy и объявить метод в компоненте. Варнинга нет. Самый частый кейс: взять одно свойство. Раньше были идеи о простом синтаксисе, но это выкинули. Угар.
    8. Потрясная совместимость с rxjs. Если вы начинаете дрочиться с rxjs, то вам приходится руками писать в ngOnChanges костыли, чтобы у вас получился стрим ченджей.
  • Экспресс-оценка сложности алгоритма (+разбор задачи c Joker 2017 и DotNext 2017 Moscow)
    +1
    Только random-access будет работать не за O(1), да? И при выводе строки констата вырастет порядочно.
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    –1
    Я бы хотел бы уточнить маленький момент. В ряде случаев получается быстрее выбрать данные и объединить их на уровне приложения, чем выбрать объединенные данные. Это получается из-за того, что одну бд использует больше одного клиента в один момент времени; и бд труднее реплицировать. Таким образом какая-то нетривиальная выборка может просто-напросто съесть все много ресурсов бд (память, цпу). Из-за этого ваша выборка будет работать быстро на локальном сервере, а на продакшене тупить как хрен знает что. Нужно бенчи делать.
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
    0
    Да, они действительно мешают. Но при этом очень многие бд имееют возможность дропнуть процедуру по условию её существования и создать новую. Но бывает проблема с тем, что некоторые процедуруры/функции дефинируются как зависимые, поэтому наивный drop невозможен: нужно понимать какие хранимки от каких зависят.

    Тем не менее, для выбранной вами бд вполне может существовать уже готовый тулинг, который умеет подобное.
  • Почему не стоит использовать двухуровневую архитектуру при разработке клиент-серверных приложений
  • Микросервисное безумие пройдет в 2018 году
    0
    В корзине/заказе обычно может быть больше одного товара. Поэтому N+1. Одна сущность + N связанных. Да, можно было бы реализовать балк-запрос на N связанных сущностей, но вылезут дополнительные трудности с кешом.
  • Микросервисное безумие пройдет в 2018 году
    0
    В слове «распределенный»

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

    Также заодно распишите почему браузерный кеш — ок, а распределенный кеш на бекенде — не ок. Реально интересно :-)
  • Микросервисное безумие пройдет в 2018 году
    0
    Вообще в целом это довольно динамические данные, которые изменяются редко. Но не суть.

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

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

    В описанных мною случаях отсутствие кеша на бекенде будет почти аналогично отсутствию кеша вообще.
  • Микросервисное безумие пройдет в 2018 году
    0
    Вы заоптимизировались под определенный путь навигации пользователя. Это очень хорошая оптимизация. Но она не будет и не может работать всегда. Это не решает проблему, хотя и очень сильно уменьшает её.
  • Микросервисное безумие пройдет в 2018 году
    0
    Улыбаюсь :-)
  • Микросервисное безумие пройдет в 2018 году
    0
    При денормализации join не нужен. В этом и смысл денормализации.

    У вас же больше двух таблиц в бд. Вот здесь оптимизировали чтение, улучшилась общая отзывчивость бд. А вот здесь продолжаем использовать join.

    Распределенный — кэш не мешает

    Смотрите, есть какой-нибудь запрос: дай мне заказ со всеми товарами. Это один запрос к бд с использованием join. Дальше, я беру и результаты сохраняю в распределенном кеше. В следующий раз я беру и достаю из кеша результат этого запроса. Естественно, не забывая про инвалидацию.

    Кеш есть, join есть. В чем проблема?
  • Микросервисное безумие пройдет в 2018 году
    0
    Это снижает и загрузку и ваших каналов связи и каналов связи сервера Хабра и нагрузку на сервер Хабра.

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

    Что?

    Допустим я хочу посмотреть детали заказа. В классической системе это один запрос к бд и один запрос к серверу. В описанной вами схеме это N+1 запросов к бд и N+1 запросов к серверам. Соответственно количество данных, которые нужно кешировать увеличивается. Но память ограниченная. Значит кеш теперь может спасать меньшее количество запросов.
  • Микросервисное безумие пройдет в 2018 году
    0
    Это почти ничего не стоит.
    В сотни раз дешевле микросервисов.

    Думаю, что все же испробовано.

    Вы смешной. Я вам говорю о том, что вижу с самого начала проекта. Это не какая-то сранная гипотетическая ситуация. Такие проекты реальны, я их видел.

    Ибо тут вы уже напрочь отходите от тех самых «легких и простых и дешевых» join с которых и начался наш разговор.

    Я не понимаю как распределенные кеши могут мешать делать join. Я не пониманию, как денормализация может мешать делать join. Шардирование — да, может, но количество таких ситуаций в идеале будет реже. Просто потому что разрез выбирается согласно данным, а не согласно фичам.
  • Микросервисное безумие пройдет в 2018 году
    0
    3 — это не микросервисы. Это просто сервисы.
    Окей, допустим. В таком случае поясните какая по вашему мнению разница между ними.
    Может показаться нужным делать join в «Корзине» и «Заказе» для отображения наименований товаров в корзине и списка товаров при заказе.

    Но вполне достаточно в БД сервисов «Заказы» и «Корзина» хранить только ID товара, отдавать ID товара на фронтенд, а дальше фронтэнд уже запросит у «Каталога» конкретное наименование по ID (запрос название цены и описания товара по ID легко кэшируется на стороне веб-клиента и не будет дергаться каждый раз)
    Серьезно? Вы создали N+1 запросов на ровном месте. Без кеша это адское падение производительности. С кешом это по прежнему адское падение, потому что вы увеличили количество данных для кеширования и они теперь не помещаются в кеш! Да и еще предлагаете кеш втулить на клиент, что делает кеш еще менее влияющим на производительность бекенда. Просто жесть.
    Более того, БД всех 3 сервисов — могут быть разного типа, смотря что лучше для данной подзадачи.

    Например, каталог с полнотекстовым поиском — это специализированная БД для полнотекстового поиска.
    Корзина — какая-нибудь БД in-memory с сохранением состояния типа Tarantool
    Ну а заказы — классическая реляционная СУБД.
    Ничто не мешает в монолите юзать три разные бд, если они нужны. Но при этом количество ситуация «не могу сделать join» будет в разы меньше.
  • Трансдьюсеры в JS – так ли уж необходимы?
    +1
    Про голословность таки зря. Совсем не заметил приписку про личное мнение.
    JS всё-таки скорее императивный язык
    Вы может удивитесь сколько людей считают JS функциональным языком. Однако, хотел бы отметить, что функциональный подход не накладывает требования на отсутствие императивщины. И никаких обид, сам считаю js нихрена не функциональным :-)

    Мне тоже проще понять генераторный подход
    Я постараюсь объяснить поподробнее, что мне не нравится в вашем утверждении.

    Вкратце, что такое трансдьюсер. Это функция, которая принимает элемент коллекции и выдает указание что делать дальше для постройки новой коллекции. Это абстракция над map/filter без привязки к входной и выходной коллекции. А генератор это абстракция над map/filter с привязкой к входной коллекции (если она есть) и без привязки к выходной коллекции. Ужасно большое понимание требуется для первого и никакого для второго, да :-)

    У вас в статье написаны библиотечные функции. Мне кажется стремным предъявлять к библиотечному коду требования простоты. Просто я очень сомневаюсь, что вы легко понимаете код браузера. Да блин, библиотеки существуют, чтобы делать какие-то типичные задачи наилучшим образом, а не самым понятным. Я надеюсь, это снимет вопрос о понимании map/filter.

    Касательно генераторов. Когда у вас есть map/filter, то количество кода на генераторах стремится к минимуму. И никто вам не запрещает писать генератор. Мы же тут не говорим о том, чтобы брать микроскоп для забивания гвоздей.

    И вот когда у вас есть уже готовая библиотека, то вопрос о сложности превращается: а насколько легко это использовать? И вы легко можете написать вместо transduce функции mapIntoArray(sourceCollection, algo), mapIntoSet(soureCollection, algo) и т.д.

    Я просто реально не понимаю где вы видите сложность этого подхода. Я вижу только то, что у transducers ужасная документация и идиотское именование.
  • Микросервисное безумие пройдет в 2018 году
    0
    А также нытье исходит от людей, которые пришли в проекты с микросервисным безумием имея достаточный бэкграунд, чтобы понять как легко ломается система
  • Микросервисное безумие пройдет в 2018 году
    0
    Занятно. Мы говорим о разных вещах. Скажем так, по вашим цитатам получается, что микросервисы по сути изолированные системы с изолированными командами. Я не спорю, что когда у вас сотня разработчиков, то делать единый монолит — не самая лучшая идея.

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

    Выглядит как «возможность сделать все что я хочу не думая ни о каких ограничения».

    В рамках описанных вами масштабов это скорее всего даже невозможно. Точно так же, как если бы я предъявлял бы в претензию стороннему продукту, что я не могу сделать join на их данные.

    В рамках масштабов типичных (небольшая команда, данные в одной бд) невозможность сделать join является чем-то реально странным. Модульность модульностью, но если за неё вы платите реальным проседанием производительности системы, то вы облажались при продумывании.

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

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

    Но вообще есть еще: распределенные кеши, репликация, шардирование не по логической структуре, денормализация для ускорения чтения, снижение времени проводимого в транзакциях (многие современные системы держат транзакцию дольше, чем пишут данные), всякие точечные оптимизации. У всех техник свои недостатки. Примечание: но это техники снижения нагрузки, а не техники хендлинга большого количества данных.
  • Микросервисное безумие пройдет в 2018 году
    0
    Если адаптация легкая — это как раз является хорошим продумыванием.
    Так как тогда возможность сделать join (т.е. легкая адаптация) является плохим продумыванием?

    Проследите нить разговора чуть выше.
    Я просто говорю о том, что для снижения нагрузки на бд можно использовать другие техники.
  • Микросервисное безумие пройдет в 2018 году
    0
    Может развернете концепцию плохо продуманной БД? Просто для меня немного удивительно читать ваше сообщение.

    Является ли легкая адаптация к изменившимся требованиям плохим продумыванием?
    И почему вы противопоставляете микросервисам только монолит, а не что-то обеспечивающие модульность без лишних сетевых взаимодействий?
  • Трансдьюсеры в JS – так ли уж необходимы?
    0
    Кстати, асинхронные итераторы тоже есть как proposal
  • Трансдьюсеры в JS – так ли уж необходимы?
    –1
    И вообще, мне показалось, что статья не про «Трансдьюсеры — кака», а про «Трансдьюсеры это те же генераторы». И если вы не можете вкурить про трансдьюсеры, вкурите про генераторы и пользуйтесь на здоровье. То же самое, только с перламутровыми пуговицами.

    В этом то и дело, что трансдьюсеры != генераторы. Трансдьюсеры мощнее и гибче. А код на генераторах писать более привычно. По своей сути генераторы являются кастрированной специализированной do-нотацией. Генераторы — это сахар. Трансдьюсеры сахаром не являются.

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

    Итераторы — нет, но генераторы-то ведь да?

    Да, есть такой proposal. Он позволяет писать асинхронный код на генераторах, не спорю. Пожалуй, я криво сформулировал начальное предложение. Возможно даже похоже на то, как сформулировал автор поста вступление :-).

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

    Мне вот лично тоже кажется, что генераторы понять проще, чем трансдьюсеры.

    Эм… Лол? Очень голословное и двоякое утверждение.

    Посему есть вопросики:
    1: Кому проще-то? Какой бэкграунд должен быть у человека? Мы же не спорим о том, что будет проще для абстрактных пекарей? Вы же не основываете свое личное мнение на «сложных» статьях, которые пишутся для тусовки, в которую вы не входите?
    2: Проще понять концепцию или код, который получается?
    3: Вы уверены, что с ростом количества кода вы все равно будете понимать как работает код на генераторах лучше, чем код на трансдьюсерах?
    4: Откуда у вас уверенность, что вы понимаете как работает код написанный на генераторах? Не подменяете ли вы реальное понимание на ложное интуитивное?
  • VDOM своими руками
    +1
    В Реакте для этого есть костыль с указанием key для элементов полученным из массивов.

    Это не костыль. Это единственно верное решение, которое не приводит к нестабильному и потенциально некорректному поведению.

    1. За элементом VDOM может стоять компонент с каким-то состоянием.
    2. Элемент VDOM привязан к DOM-узлу с определенным unmanaged состоянием.
    3. Если у вас есть несколько похожих по типу элементов VDOM подряд, то это с большой вероятностью значит, что там цикл, а где цикл — там список объектов. Таким образом VDOM элемент с большой вероятностью привязан к объекту.

    Исходя из этих пунктов вытекает следующее: некорректно проставленный key может испортить текущий стейт неопределенным образом. Это было бы не критично, если бы у вас весь стейт был бы глобальным деревом, которым управляете вы. Но в том же DOM есть очень много внутреннего состояния, которое мы не можем программным образом контролировать.

    Поясню более детально. Кейс:
    1. В массиве есть один объект.
    2. Объект меняется. А может даже вместо него создается копия с модифицированными полями — т.е. на ссылки полагаться нельзя.
    3. Добавляется еще один объект.

    Нельзя просто так взять и идентифицировать объект — нужен айдишник. А айдишник может отсутствовать. Или может быть записан в id, Id, key, Key, isoCode или еще какое-то упоротое поле. А значит нельзя понять соответствие внутреннего состояния между старыми компонентами (или DOM-узлами) и новыми компонентами. Терять это внутреннее состояние мы не можем: пользователь или может этого не хотеть, или может не мочь восстановить это состояние сам.

    Этот кейс вылазит в следующих случаях:
    1. У вас данные из одного объекта имеют сложную связь с его местоположением в массиве. Например, первый объект не может иметь каких-то свойств. Это например, цепочка ответственности отображенная на UI. Кейс редкий, да :-)
    2. У вас перерисовка происходит батчами и стейт успевает поменяться два раза (например с сервера по Websockets приходит все, что юзер пропустил будучи оффлайн)

  • Реализация параллельной быстрой сортировки при помощи ForkJoinPool
    0
    Нет, неверно. Я наконец-то понял о чем говорил этот товарищ.

    Вот этот вот код в js отработает моментально:
    let a = [];
    a[1000 * 1000 * 1000] = 1;
    


    Потому что в js массивы могут быть разреженными. Интересная особенность языка, о которой легко забыть. И тогда они внутре хранятся точно также как HashMap (или OrderedMap, в зависимости от реализации движка).

    temp в таком случае будет весить порядка 100 млн умноженное на константу (для 16 байт это будет порядка 1.6гб)
    Если это распараллелить, то по памяти примерно 1.6гб и выйдет.

    А вот комбинирование результатов угарное. Асимптотика для непараллельного алгоритма будет порядка O(maxValue + arrayLength), но амортизированная.
  • Реализация параллельной быстрой сортировки при помощи ForkJoinPool
    0
    Ага, в Java тоже есть GC. И на всякий случай: у вас есть гарантия когда уничтожится переменная, но нет гарантии когда уничтожится объект на который указывает переменная.
  • Реализация параллельной быстрой сортировки при помощи ForkJoinPool
    0
    1) Фоллбек к bubble sort на отрезке длины 16 это замечательно.
    2) Мне кажется, что не стоит параллелить до упора — накладные расходы никто не отменял. Подозреваю, что можно форсировать отсутствие параллельного режима на отрезках длины порядка 10^3
    3) Для последовательной сортировки популярна оптимизация через хвостовую рекурсию. Мне кажется, что в данном конкретном случае выигрыш будет еще больше. Но не уверен.
    4) Я не очень хорошо знаком с Java. Скажите, поле типа final int (не static) будет выброшено из экземпляра класса или будет занимать лишнее место?
    5) А нет никаких веселых эффектов связанных с тем, что сбрасываете кэши из-за малых размеров блоков?
  • Трансдьюсеры в JS – так ли уж необходимы?
    +2
    1) А теперь возьмите, и напишите нормальные имена вместо fn, a, args. Потом вынесите условие из тернарника в переменную с говорящим именем. И вообще, разверните тернарник в явный if/else, потому что он сложный.
    2) Добавьте JSDoc с пояснением зачем это нужно. Имя curry является стандартом де-факто и облегчает переход между языками программирования, но нарушает концепцию говорящих имен. Так, к примеру C# в свое время говнили за то, что map называется Select, filter называется Where, а reduce называется Aggregate.
    3) Обратите внимание на то, что функция curry либо входит в стандартную библиотеку функциональных языков программирования, либо ненужен. Вы не должны видеть такого кода в проекте, потому что этот код должен быть объявлен в какой-то библиотеке.
    4) Занимательный прикол: каррирование можно делать и без curry.
  • Трансдьюсеры в JS – так ли уж необходимы?
    +2
    Нет. Трандьюсеры нужны не только для этого. Они также нужны для того, чтобы полностью разнести логику обработки данных и логику работы с коллекцией. Мне очень жалко, что изначальное обоснование необходимости трандьюсеров просто проходит мимо всех туториалов

    1) Изначальный пост о введении transducers в clojure ("Transducers are coming") говорит, что они приходят в «core» и «core.async». К примеру, ваши хваленные итераторы не могут работать с асинхронными источниками данных (rxjs, к примеру). Кейсы, когда нужен реюз одного алгоритма и для массива, и для асинхронного потока — есть, но весьма редки. Если у вас такого нет, то вы можете не использовать трандьюсеры с чистой душой.

    2) Трандьюсеры очень серьезно помогают дизайну языка. Рича Хикки просто задолбало то, что для каждого вида коллекции нужно реализовывать набор методов поразительно схожий по коду. Если вы не пишите свой язык и не пишите свои коллекции, то вы можете не обращать внимания на транcдьюcеры с чистой душой. Они просто придут к вам внезапно. Если выживут, конечно.

    3) На всякий случай. Изначально в clojure были ленивые последовательности и все методы работы с коллекциями прекрасно с ними работали. Это чтобы вы не думали, что их из-за незнания итераторов ввели.
  • firebase.js ПРОСТО ОГРОМНЫЙ (и что мы можем с этим сделать)
    +1
    На 100-мегабитном интернете при втором заходе на сайт (при грамотном кешировании) даже 2мб — это не плохо.
    Но вот для тех, кто впервые заходит на сайт — это плохо.
    Для тех, кто заходит на сайт через 2G/3G — это плохо.
    Для тех, у кого слабый CPU время парсинга становится убер-высоким.

    Если ваши зависимости весят по 100кб, то с развитием проекта у вас вылезет больше одной такой зависимости, что приведет к раздуванию бандла до неприличных размеров