« Rev
@JSlang   2368
Fwd »


Viktor
мысль не закончена, явно
Anonymous
А что заканчивать? Вот смотри: https://gist.github.com/MaxGraey/e7486833ae3a7abe072ac35afce8a240
꧁༒Dmitry༒꧂
с JS недавно, или я ошибаюсь?)
Да пару месяцев, на ноде пишу
꧁༒Dmitry༒꧂
Фронтендер отказался php устанавливать, а там сложная дичь на вуе
Viktor
А что заканчивать? Вот смотри: https://gist.github.com/MaxGraey/e7486833ae3a7abe072ac35afce8a240
я все прочитал, логика ясна, но вот только не все так просто
Viktor
я пользовался и пользуюсь всем из этого, больше всего rxjs
Viktor
нет, я везде
Anonymous
Очень натянутый и синтетический тест
Ну так поэтому это гист.
Viktor
Забудьте уже про lodash, ramda и прочие абстракции накладывающие нехилый оверхед и добавляющие килобайты кода
ты сказал "забудьте", и только потом добавил "ты из frontend". В абстракциях нет ничего плохого, и уж точно не в библиотеках - это абсурд
Viktor
Ну так поэтому это гист.
что касается конкретно compose через reducer - очевидно, что он будет работать быстро
Viktor
потому что ramda ужасно тяжелая из-за автокаррирования повсюду (у нее очень много внутренних оберток-абстракций в самих ее исходниках)
Denisio
ну не используй Ramdу
Denisio
используй более другие средства
Viktor
в дополнение к этому любой pure-javascript подход будет добавлять оверхед
Viktor
теперь, что касается массива с семью или сколько там нулей
Viktor
нигде на бэкенде в жизни я не обрабатывал таких массивов данных
Denisio
purejs будет чаще всего жырнее по loc и менее читабелен
Viktor
node.js бэкенд - это "скоросшиватель" небольших по своей сути ответов от БД и других сервисов
Viktor
поэтому мне не кажется, что та же ramda очень больно ударит по среднему бэкенд-сервису
Viktor
максимум, что с чем мне придется работать (и то вряд-ли) в большинстве случаев - это сотня записей из БД, которые я покажу на очередном отрезке пагинации
Viktor
где нибудь на клиенте
Viktor
поэтому для узких мест, если они будут, я применю pure-lambda-подход, в остальных случаях, я не напишу что-то более производительное лодаша, если дело зайдет дальше compose или каррирования
Anonymous
нигде на бэкенде в жизни я не обрабатывал таких массивов данных
А при чем здесь это? С маленькими массивами будет все тоже самое, просто тайминги будут нулевые у всех так как conole.timeEnd выводит только три знака после запятрой
Denisio
никуда ramda не ударит. в живой среде никто не будет 10 млн итераций гонять с помощью ramda
Denisio
десятки, сотни, единицы тысяч записей в худшем случае из БД
Denisio
если ты дергаешь миллионы записей из БД для обработки рамдой - иди писать в 1С, там таких любят
Viktor
в чем этот gist меня должен убедить? не использовать вышеупомянутые абстракции в принципе?
Anonymous
То что ты не сталкиваешься с большими данными которые нужно быстро обрабатывать еще не значит, что никто не сталкивается. Не суди всех по себе
Denisio
я как раз сталкиваюсь, только не на js :)
Viktor
мне это как-то все кажется притянутым за уши, если честно :) мне в принципе на бэкенде все вышеупомянутое не часто требовалось compose/pipe я итак руками пишу всегда и кидаю в папку utils
Viktor
в остальном, я не знаю, что мне ответить
Viktor
если мне нужно будет выполнить тройное сальто, я лучше подключу salto.js
Denisio
все эти штуки типа триангуляции и mapboxjs это всё очень очень специфичные штуки
Denisio
вживой природе овер 90% программеров этого не трогает
Denisio
и рамда и lodash будет для них прекрасным инструментом
Denisio
а когда они дойдут до бигдаты - они сами поймут каким способом и что сделать и что рамда тут лишний
Viktor
если уж мы рассуждаем о сферических проблемах в вакууме, я считаю, что удобство разработки не последний критерий
Viktor
всегда будут абстракции - это факт
Viktor
утилиты, библиотеки, хелперы - все это абстракции, без которых никак
Anonymous
Viktor
среди них всегда есть альтернативы для выбора
Anonymous
Что там про сальто говорили?) Если для таких простых вещей нужно тянуть внешние зависимости то пожалуйста, в npm подобного добра завались
Denisio
и тот же lodash и рамда прекрасные инструменты для отлаживания алгоритмов и возможно потом и не надо будет от них избавлятся потому что выясница что тормоза не из-за них
Anonymous
утилиты, библиотеки, хелперы - все это абстракции, без которых никак
Так я же не против хелперов) Я против стандартных хелперов которые к тому же являются обвертками уже втроенных средств и собраны в огроменные либы
Viktor
ты все равно в итоге напишешь велосипед
Viktor
тот же lodash.curry немного толще твоего curry будет
Anonymous
ты все равно в итоге напишешь велосипед
А зачем пользоваться чьим то велосипедом (или точнее трактором, танком и т д) если тебе нужен скейт?)
Viktor
вот это уже более конкретный вопрос
Viktor
согласен тут на 100%
Viktor
вот пример
Lyrran
есть желающие получить кучу вопросов от начинающего студента, возможно на постоянной основе?)
Viktor
мне нужен equalityCheck для потока данных в rxjs, я гляжу в lodash, там есть метод isEqual
Viktor
но он слишком нафарширован функционалом и проверками типов, которые мне не нужны
Viktor
через три минуты, я написал свой, тоненький
Viktor
без проверки rexexp, буферов
Denisio
Тут ему быстро обоснуют ;)
Viktor
моя позиция лишь в том, что нужно соотносить свойства инструмента с областью задач
Viktor
помогает он или больше вредит - дело компромисса
Denisio
Я это и пытаюсь объяснить
Denisio
Что на синтетику полагатся не надо
Viktor
а так я против тезисов, "зачем нужны жирные библиотеки, если можно сделать руками"
Lyrran
сумма должна быть 33 и по логике выводить проценты, но почему то выводит ерись. Если заменить сумму просто на число 33, то выдает правильный результат. В чем я косякнул?
Anonymous
Что на синтетику полагатся не надо
В свое время было очень модно писать на coffeescript. Сейчас это нафиг никому не нужно и все делают декоифинизацию, есть даже инстументы для этого: https://github.com/decaffeinate/decaffeinate Точно тоже самое с jQuery происходит сейчас. И с лодашем и с рамдой скоро тоже)
Anonymous
я буду рад, если некоторые вещи встроят в коробку, правда, но увы p.s я пишу на typescript :)
Я тоже кстати. Но typescript очень просто превратить в хорошо отформатированный js с последней спецификацией
Viktor
В свое время было очень модно писать на coffeescript. Сейчас это нафиг никому не нужно и все делают декоифинизацию, есть даже инстументы для этого: https://github.com/decaffeinate/decaffeinate Точно тоже самое с jQuery происходит сейчас. И с лодашем и с рамдой скоро тоже)
это больше похоже на то, как развивалась передача информации (язык, письменность и т.д.): мы тоже ушли от наскальных рисунков, тотемов, почтовых голубей. Просто раньше другого не знали
Viktor
когда-то породистая лошадь была наибольшим понтом, сейчас мерседес
« Rev
@JSlang   2368
Fwd »