Множество JS-пакетов в одном репозитории

Им можно и backend и отдельные библиотеки билдить, получается не так уж и плохо. Один минус — скорость сборки, но это можно частично обойти правильной конфигурацией webpack. Но в целом же, все равно это все грязные хаки и костыли :(

Рак. Что с этим делать и чего делать не надо. Личный опыт

Боюсь показаться мракобесом или еще кем-то, но все-таки, не пробовали ли вы использовать каннабис (марихуана, гашиш, но преимущественно гашишное масло)? Почему-то часто попадались success stories связанные с этим. Даже есть исследования на эту тему.

Пять перспективных языков программирования со светлым будущим

Зря вы так пренебрежительно о PureScript отзываетесь :( В соседнем топике я уже писал об этом, но все же, PureScript — это самый прагматичный подход на данный момент. Если говорить по-честному, то экосистема у обоих языков пока недостаточно развита, чтобы целиком писать на них продакшен, поэтому сейчас очень важна простота взаимодействия с существующим js кодом (и тут Elm пока сильно проигрывает). Я попробовал оба варианта и заметил, что если у меня проблема с реализацией чего-то в PureScript я легко могу откатиться в старый добрый JS, но если у меня проблема с Elm, то как правило это значит, что я сильно влип. C PureScript я могу целиком использовать всю мощь экосистемы Node.js и знакомых инструментов, не говоря уж о том, что его можно легко использовать на сервере. Elm хороший язык, но подойдет только для специфических задач (шаг влево, шаг вправо — расстрел), PureScript более универсальный. И то, что это не молодой язык, а проверенный временем Haskell (почти), я считаю скорее плюсом. P.S: Не имею ничего против Elm, но мне грустно, когда хороший инструмент (PureScript) называют "поделкой". Elm получил внимание на волне популярности React/Redux и получил спонсорство от компании в которой работал Эван, а PureScript достиг всего только благодаря сообществу.

Жаргон функционального программирования

Мне кажется, что то, как сейчас построена работа железа на низком уровне вовсе не означает, что применения ФП там нет и быть не может. Просто так сложилось — мы сделали императивное железо и начали писать императивный код. Но если применить принципы ФП в нужном месте, то можно получить большой плюс, даже в отношении железа. Я считаю, что яркий пример — шейдеры. Раньше компьютерная графика была довольно слабой, но распараллелив вычисления удалось достигнуть большого прироста производительности. А распараллелить удалось применив принципы ФП. Ведь шейдеры, по сути — функции без сайд-эффектов: мы передаем данные в вершинный шейдер, а результат вычисления в фрагментный шейдер. Так что, с «инерцией мышления» я очень согласен.

Жаргон функционального программирования

Тысячи их :) Но из всех них к терминам в статье ближе всего именно PureScript, т.к. он ближе всего к Haskell. Конечно, есть еще ghcjs, но это не особо прагматичный подход и тянет за собой большой рантайм (в первую очередь из-за сохранения семантики Haskell, а именно laziness). У PureScript вообще нет рантайма, его очень легко начать использовать в проекте (например, с webpack loader'ом) и сразу получить все плюсы чисто-функционального языка, не отказываясь при этом от богатой экосистемы Node.js (потому что у PureScript супер простой FFI). Что касается Elm, то это скорее «all-or-nothing» решение. Если захочется использовать third-party js библиотеки, то надо быть готовым к тому, чтобы городить огород кода (как js, так и elm). А еще, в отличие от PureScript, который уже достаточно стабилен (он все-таки копирует Haskell), Elm все еще развивается и буквально в недавнем релизе снова поменялся API. В общем, я считаю, что для продакшена он пока не готов, хотя идея довольно интересная. P.S.: Сам уже устал от js, «undefined is not a function», тонны рантайм ошибок, boilerplate'а из Immutable.js и пр., поэтому потратил довольно много времени на выбор альтернативы и остался с PureScript, т.к. это наиболее прагматичный из всех подход.

Книга «Веб-разработка с применением Node и Express. Полноценное использование стека JavaScript»

Читал в оригинале, хорошая книга. Даже не как по Express и Node.js, а в принципе по веб-разработке. Можно почерпнуть что-то полезное, но ожидать объяснения того, как, например, потоки в Node.js работают, не стоит.

JavaScript: где мы сейчас и куда двигаться

Ну, у Elm судя по обсуждениям на hackernews есть свои проблемы, в частности запутанный ffi (вызов js из elm). К тому же это довольно упрощенный Haskell ориентированный на фронтенд, т.е. не язык общего назначения. Мне самому очень нравится Haskell и поэтому это меня немного огорчает… Смотрю в сторону ghcjs и purescript. Что о них думаете?

Почему, ну почему, эти #?@! придурки используют vi?

Ну, vim сравнивать с IDE нечестно. Даже автор называет никудышным именно редактор IDE, а не саму IDE. В той же Idea можно включить vi mode. Хотя, если честно, для языков с динамической типизацией нет большой разницы между использованием IDE или vim с кучкой плагинов.

Честный MVC на React + Redux

Согласен почти со всем, но насчет локального state мне кажется, что ограничения можно сделать полегче. В частности, использовать state только тогда, когда данные в нем нужны только самому этому компоненту и его дочерним элементам. Если они становятся нужны где-то еще, то вынести их в основной store. Простой пример: в компоненте для вкладок номер текущей вкладки хранить в state, но если потребуется переключать вкладку извне, то вынести это в store. Весь рефакторинг будет заключаться в замене setState на dispatch и передаче добавленных в store данных по цепочке компонентов через props. Это может занять немного времени, но по-крайней мере это прямолинейная, рутинная работа, над которой не нужно думать (может быть можно даже сделать плагин для IDE, который будет делать это сам). А вот через ref такие проблемы решать — на самом деле антипаттерн.

Обзор новорождённой платформы Scorocode

Ну, из русских BaaS есть еще, как минимум, reindex.io. Так что не надо тут :) А вообще да — очень радует.

Конкурс по программированию на JS: Классификатор слов (дополнение)

Почитал комментарии к прошлой статье и возник вопрос: почему никому применение нейронных сетей здесь не кажется странным? Это же совсем не задача машинного обучения. Его задача — классификация и обобщение, но уж никак не запоминание. А тут, судя по сетам правильных и неправильных слов (честно признаюсь, не сильно в них всматривался, но все же), они сгенерированы одним и тем же генератором, т.е. нет никаких паттернов, по которым их можно было бы различить. Нейронные сети тут будут выдавать более-менее приемилимый результат только в результате переобучения, а в этом случае теряется весь смысл нейронных сетей. P.S: Хотя вот задача распознования лиц тоже решается нейронными сетями и это может ввести в заблуждение, но только вот там применяются CNN, которые, грубо говоря, отображают лица в набор особенностей и производят переобучение на этих наборах. Т.е. их использовать удобно потому что они автоматически выявляют признаки, а не потому что у них хорошая память.

Производительность без цикла событий

По-моему, тема event-loop'а не раскрыта (хотя он упоминается в названии статьи). Только вскользь сказано, что их минус — callback'и, хотя проблему с callback hell в js, например, уже давно решают с async/await. Это, конечно, претензия к оригиналу, но хотелось бы подробностей, как горутины помогают удобнее писать код, задействующий все ядра процессора.

NPM и left-pad: мы разучились программировать?

вместо того чтобы потратить 2 минуты и написать эту базовую функцию самому
Если каждый разработчик сэкономит эти 2 минуты при решении своей задачи, то вся индустрия в целом сэкономит много человеко-часов. А таких функций может быть довольно много. На мой взгляд, автор просто не хочет замечать других проблем: отсутствие стандартизированной процедуры для верификации/ревью пакетов и ненадежная политика хранения пакетов.