От сравнений мне было не уйти, иначе не всегда можно донести в чем же плюс. Но я старался делать это как можно мягче, дабы не обидеть сторонников другого решения :)
Согласен, что babel не такой уж и страшный зверь и у меня в принципе нет проблем с его настройкой, но не могу этого сказать про некоторых своих коллег. А мне надо было сделать так чтобы процесс сборки совсем не отнимал наше время. И да, конечно код получаемый babel в некоторых местах будет лучше и быстрее, но для нас это не так важно.
Модули в Angular очень похожи на стандартные es6 модули, но имеют некоторые отличия. Так например модуль это сущность для компилятора ангуляр, а значит можно использовать его конструктор как init метод (мы в нем например инжектируем локализацию в продукт). Во вторых вы помещаете весь роутинг вашего модуля внутрь модуля и это очень удобно. Также можно поступить и с сервисами для DI. Ну и наконец, если сравнить в React, то тут с учетом специфика ангуляра, просто добавив модуль вы можете легко использовать все компоненты экспортируемые модулем и вам не надо делать деструктинг компонентов из модуля для jsx.
Честно говоря я не измерял diff по времени запуска тестов, но при переводе проекта с Mocha+Karma на Jest я и без замеров заметил, что мои тесты стали очень долго стартовать, тратя около 3 секунд минимум на старт, в то время как раньше это занимало менее секунды. К сожалению нет сейчас проекта на Karma+Mocha чтобы померить, но на github есть много примеров откуда можно почерпнуть цифры, например тут или вот тут.
Да вы правы, код тестов не блещет красотой. У меня не было задачи написать крутые тесты, скорее я хотел показать, на примерах, как использовать инструменты. В продакш тестах мы конечно бы так не делали, а максимально использовали бы методы beforeAll и beforeEach. Например, я так делаю в тестах редьюсеров.
Да, мы тоже напоролись на ленивую валидацию слепков разработчиками. И пока используем их с осторожность, скорее как дополнительную возможность проверки.
Спасибо. Thrift интересен если брать его не только как сериализатор, а вместе с его RPC. Но вот при использовании её реализации (через TThreadedServer или TThreadedPoolServer) мы намучились с умиранием thrift серверов и другими проблемами со стабильностью сервисов, которые у нас вылезали при использовании. А если не брать RPC, то thrift далеко не самый удачный сериализатор.
ops/sec — это operations per second. Это не мой вариант сокращения, а то что выдает JSPerf. Честно говоря никогда не задумывался почему это пишется так.
Тут я конечно немного слукавил. Он не самый медленный если смотреть на него в общем смысле. Cbor по сути такой же медленный как и Bson, если посмотреть на результаты тестов JS для node, но при этом ведет себя совсем по другому в браузере. А если посмотреть на результаты тестов для Go, то, если например у MsgPack decode/encode приблизительно на одном уровне, то у Cbor с decode явный перекос в худшую сторону. А теперь представим что у нас есть два сервиса — один со своей стороны пакует данные и отсылает второму который их распаковывает. С такой разницей в распаковке и запаковке мы получим бутылочное горлышко на принимающей стороне, чего совсем бы не хотелось.
Да, Вы правы, но мы не сравнивали между собой результаты JS тестов и Go. Мы скорее смотрели как ведут себя сериализаторы в рамках каждого языка относительно друг друга, а также относительно различных этапов — emcoding, decoding и roundtrip.
Да, Вы правы можно хранить дату в UTC в числовом поле JSON, но тогда прийдется самим делать обертку сереализации/десериализации, а в случае BSON он делает все сам. Конечно не так просто использовать бонусы того, что хранится все в числовом формате, но не отметить того факта что Mongo это активно использует я не мог :)
Это только первая часть наших исследований, дальше мы рассмотрели уже более серьезные сериализаторы и в том числе смотрели и на gRPC. Чуть позднее думаю напишу чем у нас это закончилось и что мы выбрали в конечном итоге.
Спасибо, посмотрим на tree как будет время, но скажу сразу что для нас важен был факт доступности для различных языков. Не хочется самим реализовывать или портировать парсеры.
Простите за орфографию, исправим. Что касается вашего предложения, то да, так можно было сделать, но у нас стояла задача посмотреть что есть уже готового и не тратить усилия на написание своего велосипеда.
Согласен, что babel не такой уж и страшный зверь и у меня в принципе нет проблем с его настройкой, но не могу этого сказать про некоторых своих коллег. А мне надо было сделать так чтобы процесс сборки совсем не отнимал наше время. И да, конечно код получаемый babel в некоторых местах будет лучше и быстрее, но для нас это не так важно.
Модули в Angular очень похожи на стандартные es6 модули, но имеют некоторые отличия. Так например модуль это сущность для компилятора ангуляр, а значит можно использовать его конструктор как init метод (мы в нем например инжектируем локализацию в продукт). Во вторых вы помещаете весь роутинг вашего модуля внутрь модуля и это очень удобно. Также можно поступить и с сервисами для DI. Ну и наконец, если сравнить в React, то тут с учетом специфика ангуляра, просто добавив модуль вы можете легко использовать все компоненты экспортируемые модулем и вам не надо делать деструктинг компонентов из модуля для jsx.