company_banner

«Пора валить из фронтенда»: Андрей Ситник о стагнации сообщества, опенсорсе и не только



    Андрей Ситник из Злых марсиан — одно из самых известных российских имён во фронтенде: у его проектов PostCSS и Автопрефиксер счёт GitHub-звёзд идёт на десятки тысяч. Но поскольку Андрей живёт в Нью-Йорке, а путешествует по всей планете, застать в России его можно нечасто.

    В мае он будет в Петербурге на конференции HolyJS, и по этому поводу его подробно расспросили участники программного комитета HolyJS Дмитрий DmitryMakhnev Махнёв и Максим Юзва. Почему Андрей считает, что фронтенд стагнирует, а код наших проектов излишне разбухший? В чём различия IT-сообществ разных стран? Как учить английский и почему это менее важно, чем кажется? Куда пропал проект Logux, презентованный на HolyJS ещё в 2016-м?

    О текущих проектах


    Дмитрий: Для начала расскажи кратко о себе — где ты и чем занимаешься.

    Андрей: Меня зовут Андрей Ситник, я живу в Нью-Йорке, но стараюсь много путешествовать. В основном меня знают по опенсорсу и выступлениям — как сейчас популярно говорить, «медийный бренд в области IT». Не могу сказать, что я его прямо-таки заслужил, но удача мне способствовала.

    Помимо опенсорса я занимаюсь продвижением языкового разнообразия в твиттер-аккаунте @LinguoPunk, википедией в @LostInWiki и борьбой за секс-позитивизм.

    Дмитрий: Над какими проектами сейчас работаешь?

    Андрей: В опенсорсных есть несколько проектов на поддержке, самые известные — PostCSS и Autoprefixer. Возможно, PostCSS сейчас слегка активизируется: Алексей Бондаренко сделал очень большое обновление API, поэтому скоро может быть большой релиз.

    А Autoprefixer находится на поддерживающих релизах. Единственное там, что мы сейчас активно пилим — поддержку Grid для IE 10-11, но она идёт плохо из-за сопротивления Рейчел Эндрю, которая активно продвигала Grid. Она очень известный человек, и ей не нравятся любые инструменты, которые что-либо автоматически делают в CSS — такая религиозная борьба. И из-за её противодействия эта фича, к сожалению, особо не распространилась.

    Дмитрий: Как Рейчел может мешать вам делать инструмент?

    Андрей: Инструмент ничего не мешает делать, он работает. Но open source — не про программирование, open source — про общество и социализацию. Если никто не пользуется твоим продуктом или не говорит о нем медийно, нет никакой мотивации его делать. Как следствие, это бьёт по мотивации разработчиков, которые это сделали и продолжают делать. Об их геройстве мало кто говорит, но они все равно молодцы и настоящие герои.

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

    В общем, PostCSS и Autoprefixer находятся на поддержке, там фичи добавляются редко и в основном мелкие, а вот активно разработка идет у Logux. А я в этом году хочу больше посвятить себя статьям, чем конкретному опенсорсному проекту.

    Дмитрий: Ты сделал много сильно выстрелившего, а вот о Logux после презентации на HolyJS в 2016-м не очень слышно — что с ним?

    Андрей: Это хороший вопрос, потому что поднимает очень интересную тему. Дело в том, что есть разные пути распространения ПО.

    Использование опенсорса — это не какое-то рациональное принятие решений. Лучше всего разработку программного обеспечения описывает индустрия моды. Технический выбор — это, в первую очередь, мода, хайп и подобные штуки.

    Поэтому есть несколько стратегий продвижения новых решений. Например, когда что-то появляется, как следует ещё не работает, но за счёт страха упустить что-то огромное люди быстро садятся на hype train, начинают пилить и доводят до рабочего состояния.

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

    Например, у Babel-плагинов нет асинхронности. Ты не можешь сделать асинхронные функции внутри плагинов, и это ужасная проблема, я не знаю, как это попало в продакшен, потому что это ужасно ограничивает огромные рынки применения Babel. Но так он был написан, такая у него архитектура. В Babel много весёлого.

    Это один способ распространения: рассказать «всё пропало, если не выучите к завтрашнему дню — всё, рынку потребуются люди с тремя годами опыта в этой технологии». Но есть и другой способ. Например, в React сделали по-другому: сначала «варили» у себя в среде, а потом представили уже более-менее готовый к продакшену проект. Конечно, открытый вопрос, насколько именно он был готов к продакшену, но понятно, что фреймворки на 100% не подготовить.

    Logux — система связи клиент/сервер. Идея запросов, будь то GraphQL или Ajax, не предназначена для нестабильного интернета и работает в таких условиях просто отвратно — это известная проблема большинства сайтов. Logux — другой подход, и, как следствие, технически очень большое решение. Идея не новая, таких решений множество, и они проваливались, и меня это волновало. Даже GraphQL производился с ужасным скрипом, и это должно было чему-то научить.

    У меня мнение, что для такого типа задач hype train не работает. Мы не можем сделать решение, чтобы на него все наскочили и всё поехало. Когда мы поставляем решение сразу для фронтенда и бэкенда, попытки вывезти всё это на hype train приводят к противостоянию сообществ.

    Поэтому я решил, что с Logux мы не будем делать так, а пойдём аккуратно и медленно, готовя его внутри проекта. Весь этот год-два мы варили Logux внутри Амплифера, применяли на разных проектах и смотрели, как реагируют бэкендеры. Я пытался объяснять, показывать, и сейчас Дима Салахутдинов поедет на Ruby-конфу рассказать о Logux, чтобы мы посмотрели, как они реагируют, как нам его пиарить бэкендерам. Потому что говорить им то, что мы говорим фронтендерам в духе «это хайп» — неправильно, там это не работает.

    Дмитрий: Почему не работает?

    Андрей: Бэкенд перешёл на систему либо стагнации, либо поддержки: в последние годы практически нет развития. И как следствие, у них другие приоритеты: когда у тебя нет новых фреймворков каждые полгода, это на тебя влияет. Они есть где-нибудь в Rust или Go, но Ruby — что там нового? Как следствие, люди сфокусированы на другом. Конечно, я очень упрощаю, и бэкенд бэкенду рознь.

    Я хочу правильно распиарить это на бэкенде и на клиенте, хочу прийти с готовым решением, которое будет реально работать, которое мы реально проверили на продакшене. В 2017-2018 годах у нас уже была рабочая версия 0.2, но не было никакого scalability. У нас была идея, как масштабировать, и для пиара этого было бы достаточно, но на самом деле это неправильно.

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

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

    Дмитрий: Звучит достаточно интересно. И, как я понимаю, планы достаточно большие на ближайшее время?

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

    О Nano ID и быстром интернете


    Дмитрий: Ты затронул тему интернет-соединения: все привыкли к тому, что у нас интернет стабильный и хороший, а на самом деле всё совсем не так. И тут невозможно не обратить внимание на размер бандлов и прочего, вспомнить твой проект Nano ID. Почему это тебя так волнует? Начнём с размера.

    Андрей: Не кажется ли мне, что это «экономия на спичках», когда у всех нормальный интернет? Хороший вопрос.

    Nano ID — это библиотека весом в 141 байт, которая генерирует ID. Когда мы уменьшали её с 200 байт, это не имело практического смысла, а было «политическим манифестом» о том, что пора бы думать об этом.

    Размер JS — это интересная проблема. Во-первых, компиляторы её не решают, а даже наоборот: большинство бандлеров неправильно объединяют, существенно увеличивают размер или неэффективно его используют.

    И то, что скорость интернет-подключений растёт — это и правда, и в то же время нет. Как только интернет ускоряется, заявляют о себе страны, где с ним всё очень плохо — например, в Центральной Африке. А также появляются новые рынки — например, мобильный. И ещё есть хитрая проблема: скорость скачивания растёт, но при этом сайты быстрее не загружаются. Можно проверить на каком-нибудь LTE, который должен быстро всё открывать, если поделить размер страницы сайта на скорость сети.

    Проблема в том, что реальная скорость загрузки сайта зависит уже от других параметров. Например, от количества round trip’ов. Дело в том, что между запросами и первыми байтами неизбежно проходит какое-то время, когда сигнал придёт и вернётся. Это время очень большое, до 500 мс. Во-первых, из-за ограничения скорости света, во-вторых, оборудование работает медленно. И если у вас файлы по очереди загружают друг друга, то сайт будет тормозить.

    К счастью, эту проблему мы обнаружили довольно давно и научились её решать. Но она не единственная. Недавно мы столкнулись с другим: оказывается, проблема не в интернете, а в скорости компиляции. Дело в том, что 1 мегабайт картинок легко загрузить и отобразить, а 1 мегабайт JavaScript в 2-3 раза тяжелее для браузера, потому что его нужно компилировать. А количество JS растёт. И это объективная проблема низкой скорости сайтов.

    Можно хитро подойти к вопросу изучения сайта методом энтропии. Есть у нас сайт, который весит 1 МБ. Есть понятие «количество информации». Мегабайт — не просто количество строк, это сколько вообще смысла содержится в этом коде. И насколько сложным должен быть сайт, чтобы там требовался 1 МБ? Неужели настолько разные юзеркейсы на сайте, что для их покрытия должен быть такой объём кода?

    На самом деле, таких кейсов единицы. В ядре Linux столько нужно, но на сайтах — нет. И, следовательно, у нас куча лишнего кода.

    Смысл Nano ID-движения не в том, чтобы экономить каждый байт, а в том, чтобы думать: «а что у меня вообще в бандле? Какого чёрта у меня там 1 МБ? У меня не может быть задач, где требовался бы такой объём». На большинстве сайтов 75% кода не используется. Nano ID — это движение против того, чтобы мы отправляли пользователям такой код.

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

    И чаще всего этот объём — библиотеки. Знаменитая история с Moment.js: ты её подключаешь, а она из-за особенностей работы webpack грузит тебе на сайт каждый язык. И подобных случаев много.

    В своё время мне в Logux понадобилось генерировать уникальный ID, я взял библиотеку, а потом обнаружил, что она весит 100КБ. Зачем мне столько для генерации случайного ID?

    Такие размеры чаще всего из-за того, что разработчики библиотек неправильно их пишут. Поэтому главная идея — использовать Size Limit, чтобы разработчики библиотек контролировали размер своих проектов. Как ESLint, только для размера библиотек. И мы тут же видим, что огромное количество библиотек можно уменьшить в два раза.

    Дмитрий: Тебе не кажется, что вопрос не только в размере кода, но и в подходах инструментов разработки? Если я экспортирую свою библиотеку объектом вместо отдельных функций, и не подключу на свой страх и риск Google Closure Compiler, то мне никто ничего не обрежет. Может быть проблема глубже, чем просто написание кода?

    Андрей: Я бы не сказал, что проблема treeshaking действительно актуальная, потому что он в JavaScript не работает. Все думают, что тришейкинг решит проблему, но нет. Чаще всего проблема в другом: в том, что делают пакет. Используют какой-нибудь Rollup, упаковывают весь проект в один файл, и оказывается, что туда запаковывают, например, зависимости. Это огромная проблема, и мы с помощью Size Limit сильно уменьшили одну библиотеку, потому что убрали зависимости, которые в каждом проекте наверняка будут повторяться.

    Вторая проблема в том, что случайно используют какой-нибудь API из Node.js. Например, была библиотека choo.js — «компактный JS-фреймворк», где проверяли входящие аргументы с помощью Node.js-модуля assert. А он грузит почти 4 КБ. И ради крошечной библиотеки мы грузим дополнительно 4 КБ.

    И вот такие проблемы встречаются куда чаще, чем то, для чего используется treeshaking.

    Лучшая рекомендация для тришейкинга — разбивайте файлы в сборке, пусть будут отдельные функции в отдельных файлах. Но чаще всего проблема в другом. Просто запустите Size Limit с опцией --why и посмотрите огромное количество мусора, который встраивает webpack при использовании вашего модуля.

    Максим: Тогда получается, что использовать webpack для сборки — моветон?

    Андрей: Смотря о чём говорить. Если делать библиотеку, скорее всего, webpack не нужен. У вас меньше 1% пользователей, которые хотят отдельный файл, и при этом лучше их заставить использовать webpack, потому что они вставляют вашу библиотеку, как ссылку на другой файл, и сайт будет тормозить.

    А вот чем собирают пользователи ваши библиотеки, чем люди собирают сайты — на самом деле, без разницы. Мы во фронтенде привыкли, что, если неправильно использовать библиотеку, всё будет плохо, если прямо сегодня не перейдёшь с webpack на Parcel, то всё — до свиданья, ты плохой разработчик. Нет, честно говоря, плевать на инструменты.

    В webpack хватает проблем, это плохой бандлер, но если он работает у вас — работайте дальше. Я видел проекты, где он помогает решать задачи, несмотря на то, что это один из самых заброшенных проектов. Например, css-loader там поддерживается одним человеком из России. Это реальный герой, но если он занят — всё, вашу проблему никто не исправит, а проблем-то множество.

    Если я и говорю, что надо прекращать пользоваться webpack, то только потому что есть более хорошие сборщики. Но, опять же, пробуйте на новом проекте, а не меняйте на старом. Мы очень много дрочим на фреймворки и инструменты, хотя по факту они вообще не сказываются на том, как мы создаём код.

    Почему hype train и «аристократы» — плохо


    Максим: Ты сейчас говорил об уходе от webpack в пользу более крутых бандлеров. Может, есть проблема в том, что такие рекомендации от людей твоего уровня и создают хайп? Вместо того, чтобы рекомендовать использовать что-то новое, может, просто говорить «давайте поднажмём и сделаем webpack great again»?

    Андрей: Хороший вопрос. С одной стороны, действительно есть проблема, когда подобные комментарии воспринимают без понимания контекста. Но есть и другая проблема: я опасаюсь стагнации.

    Дело в том, что фронтенд стагнирует. Будем до скончания веков жить под эгидой React — ни один новый фреймворк не сможет его сместить, потому что критическая масса набрана. Это как в бэкенд-языках: старые языки не побеждены новыми, потому что нет критической массы, условий для перехода, разве что в каких-то узких задачах. Теперь и во фронтенде началось.

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

    Это как Java — огромный рынок, на котором всё хорошо, но ничего нового нет. Как с этой проблемой справиться — не знаю. Но это одна из причин, по которым я топлю за маленькие проекты и постоянно их советую.

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

    Есть сообщество, а куда его двигать — стабилизировать и дописывать старые инструменты или использовать новые — у меня нет ответа.

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

    Максим: На твой взгляд, возможно ли такое, что большие корпорации вроде Microsoft и Facebook начнут скупать главные опенсорс-проекты вроде webpack и Babel?

    Андрей: Скупать — нет. Им это невыгодно, пока сообщество приносит новые идеи, а это реальная бизнес-выгода. Они контролируют их, это работает по-другому.

    К сожалению, во фронтенде уже возникла эта проблематика, но она выражается не в том, что компания что-то скупила, а в том, что у нас есть какие-то звёзды, которые не сменятся, всегда будут наверху и говорят, как мы будем писать код. Они знают друг друга, им легче подойти друг к другу и попросить что-то сделать. Поэтому их мнение важнее, чем мнение остальных людей. Это классическая система создания элит в обществе.

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

    Основная проблема — создание аристократии, а не контроля корпораций. И это одна из вещей, из-за которой я считаю, что из фронтенда пора валить: аристократия уже сформировалась, и мы уже ничего не можем сделать. Например, на западном рынке не важно, насколько вы крутой и какую крутую идею продвигаете, скорее всего, не пробьётесь. У старых звёзд на порядок больше подписчиков, медийного влияния и их идеи будут куда более важны, чем ваши.

    Дмитрий: «Не пробьётесь» с точки зрения опенсорса и донесения каких-то глобальных идей, а не с точки зрения работы в большой компании?

    Андрей: Да. Слушай, ты говоришь, словно работа в большой компании — это благо. Конечно же, нет, это [нецензурно] галеры. О чём мы говорим?

    Дмитрий: Я думаю, тут могут быть разные ощущения. Кто-то чувствует, что может именно так менять мир, потому что вместе с бизнесом есть какая-то поддержка, если мы немного отойдём от разработки.

    Андрей: Дело в том, что бизнес разный. Я считаю, что реально хорошие компании — это, например, 37signals и DHH.

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

    Эти компании становятся монополистами, продают наши данные и принимают ужасные решения. Мне не очень нравится то, что с IT делает Долина.

    У DHH есть хорошая идея, что стартап должен расти естественно, без вливания крупных денег: как только начинают вливаться крупные деньги, возникают совершенно другие условия, и они плохо влияют не только на общество, но и на всё развитие нашего движения. Мне совершенно не нравится, что происходит с большими корпорациями.

    Дмитрий: Если вернуться к социальным лифтам. По-твоему, если всё-таки собраться и придумать что-то клёвое, возможно ли серьёзно заниматься опенсорсом без поддержки элит, или это до конца перекрытый путь?

    Андрей: Есть хороший пример с Vue.js. Это офигенный проект, но он никогда не победит React, хотя у него решено всё, за что мы критикуем React. Неважно, какой проект ты напишешь: пока есть монополия, у пользователя просто не будет причин переходить.

    Мы настолько верим в мантру «я должен написать так же, как пишут все, ни в коем случае не должен отходить от мейнстрима», что эта мантра сдерживает тебя, даже если ты предлагаешь продукт на 20–30% лучше. Исключение — это незанятые рынки. Например, Яндекс победил в России, потому что Google не было.

    Google сместить невозможно, неважно, насколько у тебя хороший поисковик. Его победить можно только либо новых рынках, как какой-нибудь Instagram или Facebook, либо на новых языковых рынках, это, например, Яндекс в России. То же самое с фреймворками. Единственная причина, почему Vue нормально существует: он победил на рынке Китая и других, куда React ещё не успел прийти.

    С другой стороны, Vue был начат как собственный проект, а потом туда пришли и присоединились корпорации. Я не считаю зазорным просить у компании деньги, и компании с удовольствием их дают, если вы правильно попросите. Поэтому находить поддержку у компаний — это нормально, это реально работает, это ситуация win/win. Компании очень редко вмешиваются и создают какие-то проблемы опенсорсу.

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

    Стоит ли вообще идти в опенсорс


    Дмитрий: Возникает вопрос, стоит ли этим заниматься.

    Андрей: Это хороший вопрос. Сразу говорю: нет, не занимаетесь, не создавайте новые опенсорс-проекты.

    Главная причина, по которой их создают — это реклама: делайте опенсорс, и вы станете таким же знаменитым, как звёзды. Но на самом деле это «ошибка выжившего». Есть Дэн Абрамов на Западе, есть я в России, а по факту под этой верхушкой айсберга есть сотни людей, которые сделали проекты не хуже, но никому не известны.

    По-хорошему, даже если вы сделаете идеальный проект, с 99-процентной вероятностью вы провалитесь. Например, я в свое время сделал Size Limit, и мы просто решили сначала написать хорошую статью, где мы будем его пиарить, а за это время другой чувак сделал проект, и о нем все рассказали, а Size Limit проиграл.

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

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

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

    Если вы приходите в компанию, и у вас есть какой-то pull request в Babel, это выглядит гораздо круче, чем если у вас есть какой-то проект с десятью звёздочками. А это, скорее всего, так и будет — неважно, насколько хорошо вы его напишете.

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

    Есть единственная причина начинать опенсорс — если вы хотите что-то изменить в этом мире. Например, PostCSS начинался, потому что я хотел, чтобы было больше CSS-инструментов. Autoprefixer был, потому что я хотел убить Compass, но потом, когда Compass мы убили, он продвигался, потому что я хотел, чтобы американские программисты перестали писать сайты только для американских браузеров, игнорируя Opera и так далее.

    Если у вас такие задачи, там, самое смешное, статьи не работают. Все эти статьи про Accessibility, про использование кнопок вместо ссылок, если нет URL, вообще не работают, потому что они люди не вспоминают о них. Что реально работает, — автоматические тулзы, которые всё это проверяют. Был миллион докладов о том, как надо писать префиксы, и ни один из них не работал, пока не появился Autoprefixer.

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

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

    Андрей: Если вас устраивает, что мир изменится, а о вас никто не узнает — то это хорошая точка, чтобы начать делать опенсорс. Если нет — то есть много более надёжных способов стать популярным.

    Максим: Я хочу перефразировать твоё утверждение. Получается, что опенсорс делать можно и нужно, и даже любые свои проекты стоит выкладывать в опенсорс, но не для хайпа.

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

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

    Дмитрий: А какого рода проблемы?

    Андрей: Люди будут приходить и требовать, чтобы вы исправили баги, не уважая вас.

    Дмитрий: Если я оказался в такой ситуации, как бы ты подсказал искать людей, которые могут с этим помочь, по каким критериям их выбирать?

    Андрей: Если вашим проектом пользуются люди, они его знают, от него зависит бизнес, при этом, это что-то фундаментальное, большое, например, то, за что люди готовы заплатить, я бы советовал начинать собирать деньги. Очень многие люди думают: «Вот я открыл Open Collective, а им никто не пользуется, компании виноваты».

    На самом деле компании заплатят, если им рассказывать. В реальном бизнесе недостаточно написать программу. Вам нужно потратить ещё столько же сил на её пиар и разговор с клиентами. Если вы хотите развивать свой проект, но лень делать это бесплатно, у вас нет сил, вложитесь в пиар. «Есть проект, от этого проекта зависят жизни людей, вы мой проект используете. У меня есть Open Collective, давайте вы выложите небольшую сумму, и ваш проект будет в безопасности. Если нет, посмотрим, как ваш бизнес пойдёт, когда я перестану проект поддерживать».

    Например, хорошо делать Babel или webpack. Они постоянно пишут: «Скидывайте деньги, вот что исправлено за них. Вот ваши issue, вот Open Collective, занесите баблишечка». Об этом нужно постоянно говорить, это отдельное приложение усилий. Холодные звонки, продажи — всё это нормально работает. Компания с удовольствием заплатит вам, если вы будете реально работать на эту систему продаж, потому что бизнес зависит от этого всего. Но у них должно быть чёткое понимание, кому сколько занести.

    Если у вас просто маленький проект, и вы сами не хотите его развивать, это сложная задача. По-хорошему, нужно открыть issue, где вы напишете, что ищется maintainer, там вы чётко и явно укажете плюсы этого проекта, кто им пользуется, почему это важно, какой медиахайп можно получить. И дальше тем, кто открывает issue, говоришь: «Слушай, ты пришёл сюда, наверное, тебе это нужно. А проект не поддерживается. Смотри, я ищу мейнтейнера, не хочешь стать им?» Но тут есть и угроза безопасности. Приходит человек, говорит «хочу», а потом хакает ваш проект. Поэтому я и говорю, что если не готовы поддерживать, то лучше не выкладывать.

    Дмитрий: А сталкивался ли ты когда-нибудь с тем, что в твои проекты пытались что-то инжектить?

    Андрей: Нет. Это больше теоретические кейсы. Люди любят говорить, что JavaScript сломан, но на самом деле все пакетные менеджеры всех инструментов сломаны. Например, хакнуть проект на Ruby на порядок проще, чем на JavaScript. Сейчас это хайп. Были попытки что-то подобное сделать, но они были единичные. Проблема объективная, об этом нужно задумываться, но это не проблема только JavaScript.

    Максим: Ты говорил, что даже pet project не стоит выкладывать в опенсорс. Допустим, я принимаю твою точку зрения, но у меня возникает новый вопрос: представим, я джуниор, работаю в веб-студии, где ещё пять таких же джунов и один миддл, которому нет дела до моего кода. Как мне попросить помощи у сообщества, чтобы они посмотрели код и сказали, хорошо я пишу или плохо?

    Андрей: В пет-проект как раз сложно попросить помощи. Если хочешь расти, я очень советую контрибьютить в уже существующие проекты. Потому что как раз тут и твой код посмотрят, и тебе напишут, и на новую нормальную работу будет проще устроиться.

    Тут возникает вопрос «куда контрибьютить». Есть реальный рабочий кейс. Вы пытаетесь развернуть проект, у вас не получается. Неправильно думать, что это вы тупой. А правильно — понять, что документация написана плохо, потому что maintainer не может написать хорошую документацию, находясь в состоянии, когда он-то всё понимает.

    А вы как джуниор как раз находитесь в идеальных условиях, когда как раз и можете помочь. Поэтому, если вы не смогли развернуть, это место для хорошего вклада. Дальше вы пытаетесь разобраться, и в худшем случае, если не разобрались, открываете issue, а в лучшем случае разбираетесь-таки и добавляете в документацию те шаги, которые в итоге помогли вам разобраться, так, чтобы другой джуниор всё понял.

    А если у тебя проект, как просить помощи? Никак. Можно на Хабр написать, но там, скорее всего, оценят только саму идею проекта. А код сложно проверять, я не знаю, как сделать это масштабируемо.

    Максим: Бывает, что к тебе стучатся ребята и просят взять в падаваны или посмотреть их проект?

    Андрей: Гораздо реже, чем мне бы хотелось. Я в феврале специально попросил людей присылать мне их проекты. Я давал рекомендации или помогал сразу же пиариться. Очень хорошо пошло, я буду такое повторять.

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

    Просьб пропиарить проект приходит слишком мало, шлите ещё. Конечно, я пропиарю только процентов 10, потому что у большинства проблемы с позиционированием, с документацией и так далее, но, как минимум, советом вам помогу.

    Максим: Ты считаешь, что это общая практика, которая должна быть в сообществе? Как по мне, это такой слегка пассивно-агрессивный подход: «Дэн Абрамов, помоги».

    Андрей: Дело в том, что все медиаперсоны, включая меня, существуют за счет случайного перста судьбы. Есть огромное количество хороших разработчиков, но судьба случайно выбрала нескольких. Я считаю, что это привилегия. «Помоги» — это другой вопрос, но я считаю, что обязанность любой медиаперсоны — пиарить молодые проекты. Понятно, что медиаперсоны получают огромное объективное преимущество, мне гораздо проще путешествовать из-за PostCSS. Я возвращаю долг комьюнити.

    Медиа концентрируется буквально на паре человек, поэтому нужно создавать какие-то силы, которые будут распространять внимание на других людей. От концентрации внимания на двух-трёх людях плохо всем: самим медийным персонам, потому что они перегружены, сообществу, потому что новые идеи не развиваются, и вообще долгосрочной перспективе для человечества, потому что нас нет социальных лифтов для новых идей.

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

    О путешествиях, необходимости знания английского и сообществах разработчиков в других странах


    Дмитрий: Ты сказал, что PostCSS помогает путешествовать. Как много ты путешествуешь, и как ты это совмещаешь с работой?

    Андрей: Честно говоря, работа даже лучше идёт. Я сейчас приехал в Нью-Йорк после небольшой поездки. Сложное путешествие, в Марокко плохой интернет, работать невозможно, но реально каждый день что-то полезное делал: статью написал, два сайта в совершенно новой технике сделал.

    Приехал в Нью-Йорк, сижу, смотрю YouTube. Я путешествую, чтобы нормально и эффективно работать. На одном месте я сразу вафлей становлюсь, лежу на диване. Я путешествую, чтобы быть более продуктивным, поэтому совмещать легко.

    Единственное правило: не думайте, что вы сможете в новом городе, работая, посмотреть его за сутки. Приезжайте с огромным запасом. Не думайте, что вы там будете везде гулять, вы реально будете всё так же работать. Вы будете обычным турецким фрилансером, который просыпается и работает, ест на улице, работает, смотрит сериальчики и спит. Если не менять города чаще, чем раз в две недели, то всё будет нормально. Проблем особо никаких нет.

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

    Андрей: Вы смеётесь? У меня отвратительный английский. Я как раз эту тему поднимаю в «Лингвопанке». Мы в школе привыкли, что язык — это правила, особенно с токсичной русской культурой, где мы постоянно критикуем разных людей. Мы привыкли, что если ты говоришь и делаешь ошибку, то всё плохо.

    На самом деле, язык — это система общения, и пока вас понимают, всё хорошо. Мы не понимаем, насколько язык дублирующая система. Это как компакт-диск или QR-код. Вы знаете, что у QR-кода можно большую часть уничтожить, и он всё равно будет читаться? Потому что там специальные алгоритмы дублирования информации. Смысл в том, что язык не нужно знать хорошо, нужно уметь общаться на нём.

    Главное моё продвижение в языке случилось, когда я просто перестал бояться. Мы все боимся, потому что нас постоянно травят в школе и в интернете — страшный русский твиттер, где за описку травят сильнее, чем за антивакционную идею. На самом деле у русских неплохой английский. Начиная с того, что это близкородственные языки: не какой-нибудь китайский, где у тебя вообще другой языковой строй. Мы не представляем, как в остальном мире, там ещё хуже.

    Россия находится на нормальном уровне. Конечно, похуже, чем Норвегия и подобные мелкие страны, которые просто вынуждены учить язык, потому что контента нет. Но в остальном русские хорошо говорят по-английски, никаких проблем нет. Главное правило — не бойтесь, просто коммуницируйте, переходите на язык жестов, бухайте перед обсуждением (это хорошо помогает понять, что на самом деле важны простые вещи).

    Второй момент — смотрите сериалы с субтитрами, это реально помогает.

    Путешествуйте, как раз язык выучите.

    И главное — постарайтесь выступить.

    Мы боимся языка, потому что в России есть проблема: мы очень мало коммуницируем с внешним миром. С одной стороны, это хорошо, так как есть внутренний рынок, который позволяет каким-то мелким людям выйти в свет. Как Яндекс вырос из монополии Google из-за языкового барьера, так есть и огромное количество социальных лифтов, по которым программист может подняться, чего никогда бы не случилось на Западе.

    Но взамен есть проблема, что рынок закрытый, мы не смотрим наружу и все поднявшиеся люди, реально хорошие чуваки, не выходят на Запад, потому что боятся английского. Моя рекомендация — заведите два аккаунта в Twitter, в одном пишите на русском, чтобы помогать своей культуре (это тоже важно), а английский для практики. Когда вы пишете на английском, вы поймете, что это не сложно. Единственное, читать вас будет мало людей, потому что на Западе хватает своих, но критическая масса таким образом всё равно набирается, свои 150-300 читателей наберёте.

    Участвуйте в англоговорящих митапах в России, это не страшно, вас никто не будет обижать, всё хорошо.

    Дмитрий: А рекомендуешь ли ты попробовать переехать куда-то на какое-то время с целью изучения языка, если да — куда?

    Андрей: Чтобы избавиться от страха, достаточно любого путешествия. А вот как дальше учить — хороший вопрос. Честно говоря, не знаю, я плохо знаю язык. Но могу сказать, что когда вы выступаете на митапе в Нью-Йорке, даже если аудитория с трудом воспринимает ваш акцент, то всем всё равно, потому что половина зрителей из Индии, половина из Китая.

    И могу сказать о другом. В России есть популярный нарратив, что надо свалить, и везде хорошо: «В России всё плохо, я свалю и буду счастливым». Честно скажу — это та мотивация, которой лучше не руководствоваться. Потому что нарратив очень старый, и исторически мы знаем, что он не работает с XVIII-XIX веков. В других странах не принципиально лучше. Есть принципиальные проблемы управления, но они рано или поздно проявляются в любых странах.

    Есть проблема выбора, когда у тебя есть задача, и она решается по-разному. Например, мы хотим, чтобы на улице было убрано, а для этого, на самом деле, нужно, чтобы было централизованное общество. Для этого нужно притеснять всех, кто думает неправильно, как в США. Там очень жёсткая система внутренних правил и противовесов о том, кто как должен думать и, на самом деле, США в этом плане похожи на Китай. Просто правила негласные, и государство этого не делает — это делает само общество.

    Я бы не сказал, что есть однозначное решение, где лучше — где дороги разбиты, или где общество говорит, как вы должны думать. Но это не бинарное решение, и это вопрос политики и социологии. И общая канва: часто другие страны в чём-то лучше, потому что в другом месте хуже.

    Лучше не переезжать сразу, а поездить по миру, и тогда вы поймёте, что вообще важно, какие вещи вы готовы отдать, чтобы взамен получить другие вещи. И вот уже с этим пониманием можно выбрать страну, куда вы можете переехать. И тогда переезжать нормально.

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

    Дмитрий: Хотелось бы узнать, какая разница в русском сообществе разработчиков и в других странах.

    Андрей: Если говорить про Штаты, это интересная ситуация. Во-первых, там действительно жёсткая система навязывания философии. Она всегда была, у них жёсткая система наказаний, к примеру, публичная травля. Но система довольно старая и, в целом, работает. Честно говоря, зато она чаще всего использует для пропаганды правильных идей, а неправильные — ну, перегибы на местах.

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

    И есть особая культура small talk — травля за неправильные идеи создает социальное напряжение, а в США огромное количество наций, и они не умеют вести конфликтную тематику общения, не переходя на травлю, поэтому у них есть список из стоп-тем.

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

    Вторая интересная особенность — там часто платят за митапы, символическая цена в 5-10 долларов, которая идет на еду. Опять же, потому что капитализм.

    Дмитрий: А если не США, а другие страны?

    Андрей: На втором месте, по тому, как я изучил комьюнити — это Китай. Там есть интересная особенность в огромном количестве разработчиков, а с другой стороны, у них интересный формат — очень мало нетворкинга. Он обычно закрытый, тебя приглашают на «особый завтрак», который проходит с лидерами сообщества. С другой стороны, люди на митапах реально приходят пообщаться на сложные темы и впитывать новые знания. Честно говоря, все эти особенности — это не рамки. Комьюнити разнообразное, и в Китае хватает анархистов, в Америке огромное количество людей тоже плевали на запреты. Ну и в России есть гостеприимные, вежливые и хорошие, а не мелочные критики.

    Другая интересная особенность Китая — они закрытые, с отдельным миром, это и плюс, и минус. У них огромное количество своих наработок, потому что есть место, где они могут развиваться. А с другой стороны, они ужасно страдают от того, что не могут свои разработки вынести наружу, как в России. Все топовые китайские спикеры боятся выступать на английском от слова «вообще», хотя они нормально говорят на английском.

    Дальше Япония. Несмотря на то, что это такая компьютерная страна, сверхдержава с развитой техникой, программирование считается хуже, чем менеджмент. Считается, что, в отличие от менеджеров, программирование — низкий труд: человеку сказали, и он пишет код. Как следствие — нет комьюнити, а ИТ развито просто ужасно, стартапы развиты несоизмеримо хуже, чем возможности страны. Нет Долины, «гениев-программистов», этого всего. А ещё там куда меньше женщин в ИТ, чем в Китае, из-за традиционного общества. В Китае с этим всё хорошо — много китаянок с интересными взглядами и опытом, хотя тоже есть куда расти.

    Есть хорошее бразильское комьюнити. У испаноговорящих стран его нет, так как все ориентированы на Америку. У Франции тоже хорошее внутреннее комьюнити.

    А вот в Шри-Ланке с ИТ-сообществом всё довольно плохо, потому что, когда выдают девушку замуж, чаще всего через семью, отец спрашивает: «а кем ты работаешь?». И есть белый список «правильных» профессий, и программисты в него пока не попали. Поэтому там очень мало программистов, хотя есть куча потенциальных плюсов: деньги, возможность иммиграции. Хороший отец оценил бы, что отдаёт дочь в хорошие руки, но такого не происходит, потому что список ещё не успел обновиться.

    Я советую выступать на китайских и индийских конференциях: туда легко попасть (они с удовольствием принимают человека извне), а вы практикуетесь в английском в среде, где не будете бояться, потому что никто английского всё равно толком не знает и все говорят с ошибками.

    Об идеальных конференциях


    Дмитрий: Если мы заговорили о конференциях, какой фактор для участия в качестве спикера для тебя решающий?

    Андрей: Для меня решающим фактором является доступность конференций. Хотя иногда, если мой путь идёт через какие-то страны, я соглашаюсь на конференции, которые не очень доступные для людей, просто чтобы прокачать доклад.

    Я считаю, есть большая проблема, что цены на конференции сильно завышают. Я понимаю, что конференциям нужно зарабатывать деньги, с этим проблем нет, но есть какие-нибудь JSConf, которые берут баснословные $500 и, честно говоря, они тратят их на те вещи, на которых можно сэкономить. Например, на обеды, мощнейшее afterparty, хотя я бы, честно говоря, лучше пивка неприятного попил, но чтобы были интересные люди.

    А огромные цены приводят к тому, что и спикерам неинтересно общаться со зрителями, иногда сложно поддержать тему, так как на конференции только работники крупных компаний, тот же создатель лучшей JS-имплементации CRDT Виктор Грищенко не смог приехать, потому что очень дорогой билет. Способов сэкономить куча, и их нужно применять, дорогие билеты — неправильно. Конференция должна быть доступной.

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

    Дмитрий: Без чего конференция не может быть хорошей? Уже ясно про нетворкинг, доступность, а что ещё?

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

    Сообщество — самое важное, что происходит на конференциях. Ощущение, что ты поговоришь, и в тебе что-то изменилось, ты что-то узнал. Есть хорошая идея, что в нашем обществе не хватает понимания «зачем». Мы ходим на конференции, чтобы получить понимание, зачем вообще мы всем этим занимаемся. И хорошая конференция наверняка решает этот вопрос.

    Дмитрий: Ты сказал «не за знаниями», это очень дискуссионный вопрос. Ты бы пошёл на конференцию, где собран набор людей с очень базовыми темами, но из очень разных комьюнити?

    Андрей: Да, конечно, это было бы очень весело.

    Дмитрий: И это было бы интереснее конференции, где серьёзные и мощные доклады?

    Андрей: Я считаю, что оба подхода хороши, и никакой проблемы тут нету.

    Дмитрий: Наверное, финальный вопрос. А что ты ожидаешь от HolyJS?

    Андрей: Хорошего тусича! В 2016 году был прямо зачётный, один из лучших в моей жизни, и тогда всё очень хорошо организовали.

    Дмитрий: А что бы ты порекомендовал в этот раз сделать, чтобы было ещё лучше? Пожелание для вечеринки?

    Андрей: Я бы попробовал сорганизоваться с местными митапами. У нас есть много местных митапов, и довольно круто получается, когда у них есть возможность что-то сделать самим — есть множество инициативных людей, нужно дать им возможность. И было бы круто, если организаторам всех локальных митапов или их ключевым спикерам дали бесплатный билет или какую-то помощь, это было бы отлично.

    На ближайшей HolyJS (Санкт-Петербург, 24-25 мая) Андрей ещё больше расскажет о продвижении опенсорс-проектов. А помимо него, там будет множество других значимых фигур JS-опенсорса: от Райана Дала (Node.js, Deno) до Мишеля Уэстстрате (MobX, Immer). Все подробности о их темах докладов — на сайте, приобрести билеты можно там же, и постепенно они дорожают.
    JUG Ru Group
    472.46
    Конференции для программистов и сочувствующих. 18+
    Share post

    Comments 296

      +2
      После этой новости от Яндекса будущее веб фронтенд разработки российских сайтов, рассчитывающих на органику со стороны Яндекс.Поиска уже под большим вопросом. Яндексу не нужен фронтенд. Ему нужен контент, который он будет отдавать сам.
        +4
        Это же ничем не отличается от Google AMP.
          0
          У каждого модного поисковика должен быть свой Google AMP
            0
            AMP вроде как не лезет на десктоп.
            Хотя я только за то, чтобы выжечь всё это калёным железом.
          +32
          Это как Java — огромный рынок, на котором всё хорошо, но ничего нового нет. Как с этой проблемой справиться — не знаю.


          Вот эту мысль было бы неплохо развить в статье. С моей личной позиции «огромный рынок, на котором всё хорошо, но ничего нового нет» — это вообще не проблема, а наоборот. И я очень рад, что сейчас во фронт-энде все гораздо более стабильно, чем 2-3 года назад, когда, если утром не прочитал новости, то к обеду ты уже не разбираешься в трендах.
            +3
            Получается, лучше всего сейчас в COBOL: зарплаты высокие, новости можно вообще не открывать :)

            Если серьёзнее — не могу говорить за Андрея/интервьюеров, но мне кажется, что это во многом вопрос личных предпочтений: для одних людей Java ощущается «застойным болотом без прогресса», а для других «отличной надёжной рабочей лошадкой», и никто из них не более прав. Ну, Андрей из числа первых.

            Но мы ещё на самой HolyJS в трансляции расспрашиваем спикеров — возможно, тогда там эту тему разовьём, спасибо за комментарий.
              +8
              Он говорит, что постоянно пересобирать фундамент, на котором одновременно остальные строят дом — это хорошо и правильно.
              С точки зрения мозгов того, кто этот фундамент пересобирает — возможно. А с точки зрения того, кто строит дом?
                0
                Зафиксируйте версию фундамента и стройте :) Собственно в строительстве так оно почти всегда и бывает.
                  +2

                  В вебе фиксация фундамента выглядит как "запретите Интернету обновлять браузеры".

                    +2
                    На одном из прошлых проектов нам подрядчики на полном серъёзе говорили «зафиксируйте версию Хрома, чтобы всё работало».
              • UFO just landed and posted this here
                  0
                  Не у нас(в смысле, не в России). В SAP, например, где-то очень глубоко есть Кобол. Правда вряд ли там когда-то надо хоть что-то менять, это тот случай, когда все обнаружимые баги ещё лет 20-30 назад выловили, если не больше.
                    0
                    Где-то очень глубоко в SAP есть ABAP, который начинался как COBOL, специфичный для продуктов SAP, но с тех пор ушел далеко в сторону. И да, он прилично развивается, особенно последнее время. Да и вообще, SAP как платформа в последние несколько лет ожил, так что, ни о какой стагнации речи не идет.
                      0
                      ABAP там как раз неглубоко. А COBOL — очень глубоко, там, куда не каждый разработчик забредал. Я, как бы, в курсе, у меня жена этим занимается, причём 3,5 года она отработала в самом SAP CIS.
                        0
                        Очень глубоко там ядро, написанное на C++, но будь по-вашему, пускай это будет COBOL.
                    0
                    «Высокие зарплаты» кобола это похоже «городская легенда»:
                    www.indeed.com/q-Cobol-Programmer-jobs.html
                    +2
                    * застойным болотом без прогресса
                    * отличной надёжной рабочей лошадкой

                    Ну или «лабиринтом с граблями, по которому, после некоторой практики, можно прекрасно научиться ходить и даже бегать»
                      0
                      Или даже граблями, которыми все забивают гвозди, хоть не удобно, потому что всем сказали, что грабли — это модно.
                      0
                      Просто то что делают в javascript сейчас в java уже давно есть или не нужно. При этом сам язык и стабильные фреймворки продолжают стабильно развиваться.
                        0
                        Не получается. Я вообще не понимаю как слова COBOL и «огромный рынок» оказались рядом.
                          0
                          Смотря чем этот рынок измерять. Если сейчас в продакшне используются больше 200 миллиардов строк COBOL-кода, то куда огромнее-то?

                          Вот людей на такое количество кода относительно немного, да. Ну так это же и есть воплощение стабильности: код десятилетиями работает и приносит человечеству пользу, когда его даже не трогают.
                            0
                            Угу. Есть 200 программ по тысяче строк, они стоят на миллионе устройств — вуаля, 220 billion lines of COBOL in use today.
                            Вообще приведённые цифры впечатляют: какой-то там банк исспользует 112,500 программ(!!!!!) на Коболе. Это как вообще?

                            Хорошее представление о «рынке языка» даёт рынок труда. А там пусто. Это и есть реальное место Кобола, а подсчёты строчек оставим изнасилованым журналистам.
                              0
                              Не какой-то банк, а достаточно старый и большой банк. И да, в банках немерянно внутренних программок (програмки конечно разные, включая «переложить файлик между серверами», но все же). И не один банк, а большенство старых и больших банков этим страдают. Да, я не имел счастье проверить все, но имел счастье посмотреть несколько из топ10 )
                              Другой вопрос, что они таки страдают, и большенство новых проэктов уже несколько лет как, заводят именно для перехода с кобола (и вообще мейнфрейм релейтед) на что угодно.
                              И совсем другой вопрос — банки большие, бюджеты жирные, так что процесс будет итти еще дооолго, и коболисты будут нужны как некроманты ;)
                        +4

                        Наверное с точки зрения JS разработчика весь остальной мир стагнирует.
                        Как можно завтракая не создать новый framework, потом начав работу и заварив чашку кофе не сделать +1 framework, потом пообедать и сделать +2 framework и т.д.,
                        очевидно что весь остальной мир падает в пучину стагнации и упадка.

                          +7
                          Вот проблема в том, что в js-е перестали происходить мини-революции, когда стек годичной давности объявляет устаревшим и отправляется на помойку. Скоро припрутся ребята с бэкенда с иконами Фаулера наперевес и детишки с трехмесячных курсов по программированию на реакте и создадут конкуренцию. Конкуренция — это плохо, пусть она лучше будет у наших работодателей.
                            0

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

                              +1
                              Да фиг с ними с лидерами, я больше про нашу разбухшую зарплату беспокоюсь.
                          0
                          Думаю, в стабильности экосистемы есть и плюсы, и минусы. Основной плюс — можно спокойно сосредоточиться на бизнес-задачах, не форся внедрение новых технологий, чтобы не отстать от жизни, чтобы самому через год не оказаться на рынке труда в положении «без актуального опыта», и чтобы работодатель через год не искал на твоё место «умение и желание разбираться с древним легаси обязательно».

                          Основной минус — если бизнес задачи не блещут разнообразием даже на активно развивающемся проекте(ах), то получишь профессиональный застой, вырваться из которого можно только (?) изобретением велосипедов или переходом на другие позиции и роли (необязательно формальным).
                            +1
                            это вообще не проблема, а наоборот

                            Да, это не обязательно плохо. В мире Java нормально можно работать и быть счастливым. Тут вопрос о препочтениях и желаниях.


                            Единственная объективная пробелма — отсутствие социальных лифтов.

                              +1

                              Он просто ещё молодой

                                –1
                                С одной стороны я согласен, с другой — нет.

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

                                Но в то же время периодически происходят более фундаментальные изменения. Переход от колбэков к промисам и асинхронным методам. Появление TypeScript и тп.

                                Да в Java ней нет назойливого хайпа, но в ней нет и действительно полезных новшеств. Может быть и не должно быть, т.к. нельзя запихнуть все в один язык с обратной совместимостью. Проблема Java в том что она со своей критической массой доминирует, а ее стабильность стагнирует умы многих разработчиков (до сих пор не понимают асинхронности, не знают ФП и не стремятся и тд.).
                                  0
                                  Ну, надо подождать, пока JS догонит Java по списку имеющихся полезных новшеств — и тогда можно будет посмотреть, где что новое появится. Пока заметные новшества скорее сначала появляются в мире Java, а потом уже проникают на фронтенд (тот же Netty старше Ноды лет на пять, Future появился в стандартной библиотеке примерно тогда же, где раньше реактивщина появилась — сложно сказать).
                                  Развитию JS сильно способствует мода переделывать фронтенд каждые год-два, в Java такое реже. Но новые проекты уже делают и функциональные и асинхронные (если это нужно) и довольно давно.
                                    0
                                    Проблема Java

                                    до сих пор не понимают асинхронности

                                    Эм, пардон, как вас тут понимать? По вашему в Java нет асинхронного кода? Или он под строгим табу?
                                    Это же «полноценный ЯП» — тут потоки ввели еще в 90-х
                                      0
                                      Это же «полноценный ЯП» — тут потоки ввели еще в 90-х

                                      Ну вот сами же и привели пример: речь об асинхронном коде, а вы про потоки.
                                      Начало адекватного асинхронного кода — CompletableFuture, который появился лишь в 8 (2014). А одного наличия не достаточно.

                                      Я не понимаю вашей цитаты. Я могу с таким же успехом надергать отдельные слова из любого поста и составить из них какую-нибудь ерунду.
                                        0
                                        Аналоги CompletableFuture в Java были и до восьмёрки, кому это очень надо было — делали свои костыли. Возьмите хотя бы Guava: ListenableFuture — это уже достаточно асинхронный код? А любая библиотека с EventLoop'ом внутри, включая JavaFX и Android?
                                        Под капотом в CompletableFuture нет ничего из ряда вон выходящего — просто к моменту выхода 8 было достаточно высокое давление от простых разработчиков (мода, то есть), плюс убрали часть ритуалов при кормлении Future callback'ами, что и послужило отправной точкой добавления именно в стандартную библиотеку.

                                        В общем, это будто вы сказали, что под Java реактивное программирование появилось только в 2018 с выходом Java 9 и тамошнего java.util.concurrent.Flow, при живом-то RxJava.
                                          +1
                                          Давайте пойдем дальше и скажем что epoll существует уже давно. Речь же не о теоритической возможности писать асинхронный код, а о состоянии языка и всей сопутствующей экосистемы.
                                          Только когда есть общепринятые абстракции можно говорить о чем-то. Без них вы запаритись интегрировать асинхронный код из разных библиотек (в одной будет свой Future, в другой event loop и тд).

                                          В общем, это будто вы сказали, что

                                          ?
                                  +6
                                  Делают каждый день новые фреймворки — плохо. Не делают каждый день новые фреймворки — тоже плохо.
                                    +5
                                    Как у нас говорят: во фронтенде — зрада :)
                                    +22
                                    > Это реально хорошо работает, медиаперсоны будут это репостить, потому что они говорят то же самое. Новые идеи не будут репостить, потому что они так же их не понимают.

                                    Вот это я никогда и не понимал. Большие серьезные мужики в 2019 году в 20ый пишут статьи про var/let/const… и ведь даже не вспоминают про выведение типов, статический анализ, JIT и другие прелести.

                                    Ну и все такие:– Еее, спасибо за статью, как же я раньше жил.
                                      0
                                      То что рынок стабилизируется это большой плюс.
                                      Всегда в выборе между бэком и фронтом был аргумент в пользу первого по причине нового вида смузи каждый день, которое нужно учить.
                                      И не вижу логики в том, что при стабильном рынке вдруг все инновации и новые фреймворки заканчиваются.
                                        +7
                                        по факту под этой верхушкой айсберга есть сотни людей, которые сделали проекты не хуже, но никому не известны.


                                        Призываю vintage излить горечь души своей
                                          +6

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


                                          Мне особо нечего добавить. По теме скажу лишь, что приложения в MAM инфраструктуре, на которой основан $mol, получаются весьма компактными, если не тянуть что попало из npm. А тянуть оттуда не очень удобно. Отчасти это сделано намеренно, чтобы не подключали всё подряд. Но в основном, конечно, чтобы решить проблемы с копипастой импортов/экспортов, тришейкингом наимпортированного (чтобы не плодить ещё больше импортов/экспортов/реэкспортов, ага) мусора, и как следствие, проблем с долгой сборкой.


                                          Для сравнения:
                                          Главная страница Реакта, где функциональности с гулькин нос — 500kb сжатых скриптов.
                                          Галерея с демонстрациями большинства $mol компонент и их онлайн редактором — 100kb сжатых скриптов.


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

                                            +1
                                            Я как раз буду выступать с докладом как пиарить опенсорс. А потом сделаю по докладу серию статей.
                                              +2

                                              Кстати, не хочешь попиарить $mol на западе или хотя бы дать обратную связь? А то я не умею в эти ваши Твиттеры.

                                                +3
                                                Конечно. Напиши мне в личку в Тви twitter.com/andrey_sitnik со ссылкой.
                                              +9
                                              Имхо проблема с $mol в том что
                                              $my_heroes $mol_view
                                                  sub /
                                                      <= Title $mol_view
                                                          sub /
                                                              <= title \
                                                      <= Title_sub $mol_view
                                                          sub /
                                                              <= title_sub @ \My Heroes
                                                      <= Rows $mol_list
                                                          rows <= rows /
                                              


                                              Сходу не могут понять ни люди, ни анализаторы кода для js (фичи ide rip, литеры rip).
                                              Повсюду какие-то слеши в разные стороны, спецсимволы, чтобы указывать на типы.

                                              $my_heroes $mol_view
                                              sub /
                                              <= Title $mol_view

                                              Стрелочка влево означает получение значения свойства, а после неё идёт собственно объявление этого свойства указанием его имени и значения через пробел.


                                              Это получить свойство Title из $mol_view или объявление его на $mol_heros или что вообще?

                                              UPD: Даже посмотрев во что это компилится, ощущения что это хороший дизайн не стало.
                                                +1
                                                Сходу не могут понять ни люди

                                                Если новую концепцию можно понять сходу, то не такая уж она и новая. И если бы вместо этого птичьего синтаксиса можно было воспользоваться каким-либо иным, более привычным, уж поверьте, я бы не стал подвергать людей лишней когнитивной нагрузке. Вот, сравните сами, как та же концепция выглядит на более привычных html и json: https://github.com/eigenmethod/mol/wiki/View-formats


                                                фичи ide rip

                                                Эти фичи IDE делают под конкретный синтаксис конкретных фреймворков. Вот, ждём, когда же в ТС позволят наконец создавать типы из плагинов и обрабатывать не только файлы с расширением ts и tsx, тогда можно будет встроиться в его language server. Но сейчас нужно очень большое медиа-влияние, чтобы побудить их не хардкодить один единственный jsx.


                                                линтеры rip

                                                Тут очень строгий синтаксис, ему не нужны линтеры. А проверкой типов занимается тайпскрипт.


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

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


                                                Это получить свойство Title из $mol_view или объявление его на $mol_heros или что вообще?

                                                Это объявить свойство Title в $mol_heroes и тут же получить его значение. Следующие два кода полностью эквивалентны:


                                                sub /
                                                    <= Title $mol_view

                                                Title $mol_view
                                                sub /
                                                    <= Title

                                                Даже посмотрев во что это компилится, ощущения что это хороший дизайн не стало.

                                                А что такое хороший дизайн в вашем представлении?

                                                  +1
                                                  А mol изначально был на TS или произошел перевод с JS?
                                                    +2

                                                    Собственно это один из первых фреймворков полностью написанных на TS.

                                                    +2

                                                    Попробую ответить на все сразу.


                                                    Вступление
                                                    Я говорил о том, почему $mol, на мой взгляд, в текущей своей форме распространенным стать не может, т.к. у него очень низкая доступность. А не про то, где его расположить на глобальной шкале фреймворков и DSL.
                                                    Сначала отвечу фидбеком, потом попробую написать полезные вещи про конкретные аспекты view tree.
                                                    Примеры ниже будут от моего лица, но, кажется, они справедливы для большинства frontend разработчиков.


                                                    Если новую концепцию можно понять сходу, то не такая уж она и новая.

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


                                                    ему не нужны линтеры

                                                    Ок, но форматтеры все еще нужны т.к. договариваться в пулл реквестах и постоянно думать про то, как оформлен код, неудобно. Тут все еще можно написать с маленькой буквы то, что принято писать с большой и поставить 2 пробела, где принято 1.


                                                    Любой синтаксис не понятен, пока не ознакомишься с документацией.

                                                    Тут есть 2 нюанса.


                                                    1. "ментальное расстояние" между 2 языками(синтаксисами), мне как-то не понадобилось читать доки, когда я первый раз увидел, скажем, jsx. Потому что он выглядит как html, где можно написать { и писать js до следующей }. Потому что писать js html я уже умею, а фигурные скобочки для переключения синтаксиса — конвенция в куче шаблонизаторов, языков, да и в самом js Right? ${true ? 'yes' : 'no'}.
                                                      Аналогичная вещи произошла с elm, если показать случайному фронту https://ellie-app.com/37gVmD7Tm9Ma1, он даже не зная elm по цвету слов и буквам в них опишет, что там происходит. Т.е. если птичий синтаксис оперирует такими же понятиями (функции, аргументы, массивы, объекты, поля, переменные) и одинаково обозначает структуры данных, его сильно легче воспринять, чем принципиально альтернативный подход. (понял большую сразу верно для кучи всего, elm, sass, toml, kotlin, C#, go, vue, т.д). Для $mol и view.tree верно скорее понял примерно ничего, почитал и стало ненамного лучше.
                                                    2. Нагрузка на память. Это главная беда решений, которые начинаются с прочтения документации. Человек не сразу запоминает связь символов и семантики, значит если код не подсказывает свой смысл сам, придется регулярно проверять, что он делает. Это долго и удручающе, никто не хочет этим заниматься. В этом главная проблема операторов, которыми пестрит view tree. Они не намекают на то, в чем их смысл. Слова это делают. Операторы которые человек уже знает. Например: [] для массивов и {} для объектов это делают, / и * — нет, более того, у многих они зарезервированы под деление и умножение (или wildcard), и приклеивать им дополнительные смыслы энергозатратно. Причем в этом же проекте их надо будет мыслить по-старом, ведь не все можно на view tree написать. Не просто так люди со скрипом пишут (если вообще справляются) regex из головы.

                                                    А что такое хороший дизайн в вашем представлении?

                                                    В данном случае говорим про дизайн языков, я бы выделил 6 критериев (которые все в сущности ведут к одному: инструментом просто решать задачи сразу)


                                                    • Простота восприятия (выразительность) — описание решения задачи на данном языке максимально понятно (не важно насколько оно короткое)
                                                      • Первичная доступность — количество усилий, которые целевой пользователь языка должен приложить, чтобы начать использовать его для своих задач
                                                      • Запоминаемость — простота восприятия и создание кода на языке без использования дополнительных источников (т.к. это быстрее, приятнее и позволяет не терять контекст задачи которую пользователь пытается решить с помощью языка)
                                                        • Безусловность (ортогональность) — насколько сущности в языке (такие как, например, значение, выражение, указатель, тип, функция и т.д.) взаимозаменяемы.
                                                      • Покрытие области — могу ли я комфортно и эффективно решить все свои задачи используя только этот язык? Нет. Какую их часть я могу так решить?
                                                    • Инструментарий совместной работы — Насколько легко использовать чужой код? Насколько легко параллельно делать несколько задач? Несколькими людьми? Есть ли инструменты, упрощающие чтение? (подсветка синтаксиса, go to definition и ему подобные, автоформаттинг (чтобы повысить привычность чужого кода, если язык позволяет разные формы записи).

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


                                                    1. На ваш язык мигрируют js разработчики. Они привыкли, что \n что-то значит, отступы — нет. Они привыкли что структуры данных открываются и закрываются. Они привыкли к модели родитель\ребенок, а не sub и т.д.
                                                    2. Операторы не намекают на свой смысл, значит, язык, в котором их много, требует больше ментального ресурса, для восприятия. (чем словесный)
                                                    3. Разрыв компонентов — шаблон не зависит от логики, структура от стилей и т.д. звучит очень красиво, но это ложь. Условия показа, интерпретация действий пользователя, повторения — инъекция логики в шаблон. Ну а будь в вебе все настолько волшебно, что структура независима от стилей div (структурное ничто) был бы не нужен, а он, наверное самый популярный тег сегодня. React + css-in-js \ Vue SFC не просто так набрали популярность. (хотя я так и не понял, $mol советует компонентный подход или что)
                                                    4. Подход "все говно, $mol \ view tree — пушка" вызывает защитную реакцию и желание искать изъяны, а не понимать чем хорошо данное предложение.
                                                    5. Отсутствие туториалов мешает пониманию. Большинству при первом знакомстве интересно "берем A B C и получаем вот такую пушку", очень желательно редактируемо и прямо в браузере. (есть примеры, но их надо смотреть отдельно, и они без вставок о философии, сущностях и целях инструмента)
                                                    6. $mol хвалится стандартной библиотекой компонентов, при этом нет не 1 примера вида: берем $mol_button и добавляем ей :active \ убираем border-radius с выделенных дат в календаре и т.д. Т.к. дизайн библиотеки компонентов $mol не в том, состоянии, чтобы брать ее дизайн как есть, а как его поправить или переопределить — непонятно. Ну а большим компаниям чужой стиль тем более не нужен, так что для них $mol — в лучшем случае "низкоурованеый фреймворк".

                                                    Итого
                                                    Скорее всего в $mol есть куча хороших идей и решений, но за ними надо непонятно где и куда копать, а его подача мотивации не прибавляет.

                                                      0

                                                      Спасибо за развёрнутый ответ.


                                                      новизна сама по себе — не то чтобы положительное свойство

                                                      Новизна — необходимое, но не достаточное условие прогресса. Нет новизны — нет и прогресса. Есть прогресс — есть и новизна. И если хочется прогресса, нужно быть готовым к новизне. Изучение ещё одного фреймворка как 2 капли воды похожего на те, что уже знаешь, — ничего полезного не даст. Да и смысла разрабатывать такой фреймворк — нет.


                                                      форматтеры все еще нужны

                                                      Тоже нет, там очень строгий синтаксис, не допускающий различий в форматировании. Кроме некоторых нюансов, которые крайне сложно формализовать типа "в каких случаях выделять подкомпонент".


                                                      Тут все еще можно написать с маленькой буквы то, что принято писать с большой и

                                                      Я пока не вижу как это формализовать и не уверен стоит ли. Но если будет понимание как и зачем, то будет изменён компилятор, а не добавлен какой-то линтер сбоку.


                                                      поставить 2 пробела, где принято 1.

                                                      Нигде нельзя 2 пробела. Когда-то был баг, допускавший это, но он давно поправлен.


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

                                                      А через сколько вы научились пользоваться им правильно? указывать ключи в циклах, кешировать хендлеры вне функции рендеринга, предоставлять пропсы для настройки отображения и тому подобные неочевидные вещи. view.tree просто не позволяет выстрелить себе в ногу, при этом давая куда большую гибкость.


                                                      если показать случайному фронту https://ellie-app.com/37gVmD7Tm9Ma1, он даже не зная elm по цвету слов и буквам в них опишет, что там происходит.

                                                      Тут тоже не сложно догадаться что происходит.


                                                      если код не подсказывает свой смысл сам

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


                                                      <= — движение данных в одну сторону
                                                      <=> — двустороннее движение данных
                                                      \ — экранирование
                                                      / — разделитель директории и вложенных файлов
                                                      ! — обязательный аргумент
                                                      ? — опциональный аргумент
                                                      ^ — значение свыше (супер класса)
                                                      @ — нестандартное начертание буквы (иные языки)
                                                      * — наименее очевидная ассоциация, да, пересечение множества линий (соответствие ключей и значений), впрочем, это весьма редкоиспольземый символ во view.tree


                                                      Условия показа, интерпретация действий пользователя, повторения — инъекция логики в шаблон.

                                                      Ничего такого во view.tree нет.


                                                      Отсутствие туториалов мешает пониманию.

                                                      https://github.com/eigenmethod/mol#tutorials


                                                      нет не 1 примера вида: берем $mol_button и добавляем ей :active \ убираем border-radius с выделенных дат в календаре и т.д.

                                                      Да полно примеров. Например, тот же ToDoMVC: https://mol.js.org/app/todomvc/
                                                      Обычные CSS переопределения, никакого рокетсаенса.

                                                        0
                                                        > github.com/eigenmethod/mol#tutorials

                                                        Туториал про таблички начинается с бага (надо снять фокус с a1 чтобы значения появилось, потом начинает норм работать)
                                                        Контрибьторы идут до хоть чего-то про инструмент, сайт — галерея компонентов без слова про фреймворк (для сравнения react начинается с описания и потом сразу примеры основных концептов и interop с внешними либами)
                                                        И в этом туториале почти сразу `<= Head -` без объяснения что за волшебный минус.
                                                        Поиграться с кодом на промежуточных стадиях нельзя. Т.е. та же проблема: доступность страдает.

                                                        > click?event <=> decrement?event null

                                                        Ну вот как-то нет
                                                        Почему я вдруг в 2 стороны связался с кликом? Я их только потреблять вроде хочу. Но как я понял тут 2 стороны это что-то вроде «я компоненту listener, а он мне в него ивенты.»
                                                        Только поигравшись в компайлере можно понять, что? влияет на event, а не на click, кстати почему так?
                                                        Что null тут делает вообще, в другом месте это вроде стандартное значение?

                                                        > а так, чтобы задействовать уже существующий ассоциации

                                                        Так определенно стало понятнее, но `=>` все еще сложно понять.
                                                        `@` тоже едва очевидный, но можно понять после объяснения
                                                        И все же, почему не парные скобки, а / * для массивов и объектов?

                                                        > интерпретация действий пользователя

                                                        Речь про ивент листенеры, они есть, да и вообще в view.tree стандартные значения пишутся (судя по `value 0`)

                                                        > повторения — инъекция логики в шаблон

                                                        Речь про map и вроде вот оно, но я не уверен.
                                                        Body $mol_grid
                                                        	col_ids <= col_ids /
                                                        	row_ids <= row_ids /
                                                        	head_cells <= head_cells /
                                                        	cells!row <= cells!row /
                                                        


                                                        UPD: А, `/` это пустой массив как стандартное значение.

                                                          0
                                                          Туториал про таблички начинается с бага (надо снять фокус с a1 чтобы значения появилось, потом начинает норм работать)

                                                          Можете подробнее описать баг и свою систему?


                                                          Почему я вдруг в 2 стороны связался с кликом? Я их только потреблять вроде хочу.

                                                          Потому, что это обычные свойства, как любые другие. И мы говорим, чтобы подкомпонент пушил ивенты не в своё свойство click, а в наше decrement.


                                                          Только поигравшись в компайлере можно понять, что? влияет на event, а не на click, кстати почему так?

                                                          Мы обсуждали вариант с click(event?), но тогда для консистентности пришлось бы все свойства писать со скобочками и тогда view.tree рисковал начать соперничать с лиспом по числу скобочек на единицу кода. В итоге сошлись на том, что излишнее подражание яваскрипту даст слишком много визуального шума и не совсем корректные ассоциации и ожидания.


                                                          Что null тут делает вообще, в другом месте это вроде стандартное значение?

                                                          Да, значение по умолчанию для свойства.


                                                          => все еще сложно понять.

                                                          Согласен, и была мысль как это переделать, однако, это довольно редкая конструкция. Так что было решено пока не рыпаться.


                                                          И все же, почему не парные скобки, а / * для массивов и объектов?

                                                          Чтобы не усложнять разбор синтаксиса.


                                                          Речь про ивент листенеры, они есть, да и вообще в view.tree стандартные значения пишутся (судя по value 0)

                                                          view.tree про композицию и расширяемость. Вся логика описывается на удобном для описания логики языке — тайпскрипте. Статические значения логикой не являются.

                                                          0
                                                          • — наименее очевидная ассоциация, да, пересечение множества линий (соответствие ключей и значений), впрочем, это весьма редкоиспольземый символ во view.tree

                                                          редкоиспользуемый — это до тех пор пока вы не реализуете Xpath для tree. Язык запросов напрашивается в стиле E4X (в память о флеше)

                                                            0

                                                            Запросы — это уже логика. view.tree принципиально не содержит логику.

                                                              0
                                                              Запросы — это уже логика. view.tree принципиально не содержит логику.

                                                              Естественно я имел ввиду запросы к контроллеру. view.tree как и model.tree могли бы быть результатом выполнения этих запросов. Но я помню, что для вас MVC это "антипаттерн".

                                                            +1
                                                            Тут тоже не сложно догадаться что происходит.

                                                            На самом деле сложно. Сложнее чем в примере про elm. Говорю как человек, который знаком с JS, HTML, JSX, PHP, Scala, Java, Objective-C и не знаком с view tree и elm.

                                                              0
                                                              А я вот знаком и с elm и с view.tree. И первый требует больше усилий для понимания. Во многом из-за функций высшего порядка.
                                                      0
                                                      то в глазах собеседника вижу лишь усталый взгляд и единственный тезис — а мы уже героически запилили свои (и в каждой компании точно такие же, но свои) компоненты на Реакте с Редуксом, нас всё устраивает

                                                      Усталость это что-то на последнем уровне психозащиты. Потому то, что ты описываешь похоже происходит всегда. Тут главное не отступать самому. А преодолеть защиту уставшего собеседника.

                                                      0

                                                      Тонко, тонко)

                                                      0
                                                      Вот полностью согласна, судьба злодейка одним дарит, а к другим задом, и они могут убиваться и впахивать, ничего у них не выходит только на хлеб заработать
                                                        +1
                                                        Спасибо
                                                          +1
                                                          У Рейчел не пройденный комплекс электры и ей не нравятся «болты» ситника в твиттере (его упражнения в расширении границ скромности), а Ситника бесит, что какая-то пацанка лезет со своим крашенным мнением на его автопрефиксер.
                                                          Продолжайте, потомки мои. Всегда ваш доктор Фрейд.
                                                            +2
                                                            Привет. Что-то я недопонял один момент. Вот вы говорите, что 500 долларов за билет — это дорого, и вообще, дорогие конференции — это неправильно. И тут же продвигаете свой HolyJs, на который билет стоит 38000 если без скидок? Это же те же 500 долларов (даже больше по текущему курсу).
                                                              0
                                                              Я вот подумал, а вдруг им нужны деньги?
                                                                +6
                                                                Про цену говорим не «мы» (организаторы HolyJS), а Андрей, его мнение может отличаться от нашего. Но если вести речь о нас, важен такой момент: цена без скидок у нас для случаев, когда за человека платит его работодатель, а для идущих «на свои» (то есть когда цена становится болезненной) мы делаем очень существенную скидку — в этом смысле мы позицию Андрея как раз поддерживаем.
                                                                +13
                                                                Кстати, кто такой Андрей Ситник я не знал до прочтения этой статьи. Да и сейчас знаю его только по этой статье. А вот Дэна Абрамова знают все, так что вот это получилось как-то совсем нескромно:
                                                                Есть Дэн Абрамов на Западе, есть я в России
                                                                  +7
                                                                  ну это нормальный феномен, если учесть, что Россия сколько там 7% от интернета занимает?
                                                                  Ситник известен тем что додумал идею одного разраба и оформил это на хайпе препроцессоров в постпроцессор PostCSS, заявляя значильную производительность при всем том же самом.
                                                                  Справедливо это или нет, но так сложились звезды, он об этом и говорит. PostCSS используют в яндексе, автор bootstrap заявил что 5-ая версия будет на PostCSS. Этого вполне достаточно, чтобы самоназваться представителем фронта от России.
                                                                    +9
                                                                    Ну там смысл не в том, что «я крутой», а в том, что «многие считают, что я крутой, но это не так — просто фортануло».
                                                                    –1
                                                                    Например, я хочу, прости господи, типы в JavaScript добавить, понятно, что это уже перебор.
                                                                    Почему перебор? Мысль здравая, а то все какие-то постцээсэс и автопрефиксеры. Но просто так добавить типы в JS не получится. Там нужно постоянно что-то подпиливать как c TypeScript происходит. Поэтому если и сделают стандарт ES2025+ с типами, то он очень быстро устареет.
                                                                      –2
                                                                      С типами перебор, потому что у них изначально неправильная мотивация: «я боюсь, что что-нибудь сломается, поэтому мне нужно ложное чувство безопасности». А ломается что-нибудь постоянно! Просто потому что бизнесу надо быстро и без лишних трат, в таких условиях невозможно обеспечить надёжность как при ракетостроении, например.

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

                                                                      Наверное, с точки зрения Job security типы тоже кому-то нравятся, но если говорить про надёжность, то академически доказанную эффективность имеют только код-ревью и написание тестов. А вот эффективность типизации за десятки лет так и не доказана. Большинство багов так вообще происходит из непредсказуемых мест.
                                                                        +6
                                                                        Типизация позволяет убрать часть багов превентивно ещё при написании кода. В этом же помогает статистический анализ кода. А та часть багов, которые непредсказуемы, она тоже появится, но суммарно багов будет меньше, особенно примитивных из-за невнимательности или копипасты.
                                                                          –2
                                                                          Ещё нужно различать динамическую и статическую типизации.
                                                                            –5
                                                                            Это распространённый миф. На деле типизация ловит лишь малый процент как правило тривиальных багов, которые и так были бы отловлены в процессе разработки-отладки. Код-ревью с тестами перекрывают ловлю таких багов с лихвой.

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

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

                                                                            В итоге получается, что типизация — дорогая игрушка, которая требует больших инвестиций и дающая слишком малый выхлоп по сравнению со всем остальным.
                                                                              +2
                                                                              Если вы полагаетесь на типизацию, и думаете, что если скомпилировалось, значит нет багов, то на самом деле багов будет больше.
                                                                              Ну так, мне кажется, только самый начинающий джун будет думать при первом компилировании. Очень скоро даже он поймёт, что так не работает.
                                                                              Особенно, если заменить типизацией реально работающие практики.
                                                                              Хорошие практики стоит дополнять друг другом.
                                                                              Типизация будет хорошо работать на длинной дистанции, хотя и на короткой даст свой эффект.
                                                                                –3
                                                                                Так только такие джуны и топят за типизирование. Без проверяемх аргументов, без измеренных цифр, ненаучно повторяя одни и те же мифы, не подтвергая их сомнению.

                                                                                Про хорошие практики полностью согласен. Только вот несмотря на все попытки доказать, про типизирование никто не доказал, что это хорошая практика. В этом проблема. Это как гомеопатия — вопрос веры и эффекта плацебо. Лекарство с недоказанной эффективностью.
                                                                                  0
                                                                                  Вас не затруднит показать динамически типизированный код, который вы считаете качественным? Хорошо, если это будет крупный проект.
                                                                                      +1

                                                                                      Статически типизированный код на пхп — так себе пример :-) Давайте JS.

                                                                                        –3
                                                                                        Это динамически типизированный код. В пхп нет статической типизации, все проверки типов в рантайме.
                                                                                          +2
                                                                                          Не важно, где осуществляется проверка типов. Важно, где тип определяется. В данном случае тип задан статически.
                                                                                        +3
                                                                                        Вы же сослались на код, в котором типизированы аргументы функций и возвращаемые значения, где это было возможно.
                                                                                          –2
                                                                                          Именно. Динамически типизированы.
                                                                                        0
                                                                                        Вопрос не имеет смысла. Любой код — это результат компромисса между ценой, скоростью разработки и выполнением требований. Причём вводные данные постоянно меняются. Хотите поспорить о том, что такое качество?

                                                                                        Код не имеет ценности сам по себе. Вопрос в том, насколько код удовлетворяет потребностям. Такой пример вы найдёте скорее всего не в опенсорсе.

                                                                                        Разработка — это процесс удовлетворения появляющихся нужд заказчика. Любой код устаревает сразу как только написан. Иногда даже раньше.
                                                                                          0
                                                                                          Не бойтесь, я не буду выискивать недостатки в коде. Так вы можете показать приличный динамический код? Ну или мне придётся выбрать для примера проект самому. Но тогда не пеняйте, что я выбрал неправильный проект, написанный джунами.
                                                                                –2
                                                                                Согласен, ценность строгой типизации преувеличена, это еще и от задачи зависит. Если нужно обрабатывать пользовательский JSON по алгоритмам, определяемым самими пользователями — не факт что Go окажется производительней JS, а уж синтаксического гемороя поимеем с этой статической типизацией. В свое время РСУБД, являясь выражением принципа статической типизации данных — проиграли более гибким key/value на определенном классе задач (не всех). Поэтому пусть JS останется таким — гибким и динамичным, надеюсь «аристократы» это понимают.
                                                                                  +4
                                                                                  Типизация не уменьшает гибкость JS, TS это все тот же JS только с прибавкой разумности.
                                                                                    –2
                                                                                    Это смотря что иметь в виду под гибкостью.
                                                                                      –1
                                                                                      В гошке уже мешает, замучаешься кастовать interface{}, думаю теперь слезть на ноду.
                                                                                        +1
                                                                                        Замучились кастовать? Я думаю с вашей архитектурой что-то не так. А в нетипизированном мире это может привести к еще большему хаосу
                                                                                          +3
                                                                                          Вот вот. Лучше уже совсем типизацию не использовать чем постоянно что-то где-то кастовать тк создается иллюзия что типизация присутствует когда ее на самом деле нет (тк постоянный каст).
                                                                                            0
                                                                                            Возможно где-то я и туплю, задача такая, что в произвольных JSON надо искать комбинацию определенных атрибутов, причем не одновременно, а в виде дерева решений — если наличествует атрибут 1 то ищем комбинацию 2+3, иначе ищем атрибут 4 и так далее. Заранее структура прилетающего объекта неизвестна. В итоге на JS лаконичнее получалось.
                                                                                              +1

                                                                                              Конечно на JS будет лаконичнее — но у вас также будет весьма условный контроль над тем, какие именно значения допустимы для 2, 3 и 4.


                                                                                              Про GO не могу сказать, но вот в Android подобное решается с помощью чего-то вроде вот такой обёртки для выхлопа достаточно простого парсера:
                                                                                              JSONObject


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

                                                                                  0
                                                                                  То ли дело раньше было, до jQuery, когда разные разработчики писали одно и то же и даже не догадывались об этом.
                                                                                  6 лет уже фронтенд стагнирует. Стагнирует-стагнирует, да невыстагнирует никак.
                                                                                    +1
                                                                                    Речь про то что стагнация только началась. Во времена jQuery легко было прийти с новыми идеями.
                                                                                      0

                                                                                      Ну это субъективно как-то.
                                                                                      По мне так все зависит от целей.
                                                                                      JavaScript сейчас даёт выбор.

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

                                                                                        А сейчас даже Parcel люди не знают (или боятся), хотя он исправляет то, за что все критикую Вебпак (отвратительный DX с кучей конфигов). То же самое с Vue — все критикую Реакт что там ничего не понятно и сторонние библиотеки (типа роутера) плохие, но продолжают боятся Vue (так как он не мейнстрим).

                                                                                        Правом выбора реально пользуются единицы.
                                                                                          +1

                                                                                          Не знаю с чего вы решили про Parcel и Vue. Выглядит как сверхобобщение. Хороший архитектор не станет брать React из-за того что сейчас так можно. Он будет стараться выбирать решение под нужды проекта. То же самое и с webpack.
                                                                                          Я когда-то костьми лег против React в одном проекте. И был прав. Сейчас у них все хорошо. И они с Vue.

                                                                                            0
                                                                                            Хороший архитектор не станет брать React из-за того что сейчас так можно.

                                                                                            Ага. Я согласен. И таких примеров единицы.

                                                                                              0

                                                                                              Блин, я там хотел сказать "модно".

                                                                                                0

                                                                                                Хороший архитектор поглядит на то, на чем сейчас лабают в компании, и какого народа больше на рынке.

                                                                                                  0
                                                                                                  Таких архитекторов единицы. Достаточно посмотреть сколько фронтендеров гордяться, что сделали блог на 3-4 поста на Gatsby.js с 500 КБ JS.
                                                                                                    0
                                                                                                    Я когда год-полтора назад начал апгрейд своей панели управления автотестами (Java, webDriver) — перевод с jQ-like на Vue-реактивку.
                                                                                                    И в процессе миграции, неизбежно надо было править поток ошибок и косяков. Так вот, я в полной мере оценил, что такое «медленная сборка бандла».
                                                                                                    Итогом стало погружение в изучение вопроса и уменьшение времени с ~12-15сек. до ~300-500мс. С прогретым кэшем, но все же.
                                                                                                    Попутно и размер бандла уменьшился в пару раз.

                                                                                                    Теперь весь js web-application умещается в < 500кб. Я рад :)
                                                                                                      0
                                                                                                      Интересно, а как вы собирали предыдущую jQ-like версию (если там вообще было понятие «сборки»)?
                                                                                                        0
                                                                                                        Там и сборки не было, верно.
                                                                                                        Ничего сложнее ajax и «ручной перерисовки UI» не было.
                                                                                                        На jQ конечно плагины полноценные были написаны, и в целом код более-менее приведен в опрятный вид.
                                                                                                        Теперь нормальная реактивность, websockets (центральный узел на Java), вся отрисовка на клиенте (раньше были банальные шаблоны на Smarty (PHP)).
                                                                                                          0

                                                                                                          Понятно, то есть внедрение сборки сократило размер бандла, даже не смотря на то, что на клиенте стало больше логики?
                                                                                                          Спасибо за интересный пример!

                                                                                                            +1
                                                                                                            Если говорить в абсолютных цифрах, то было три стадии:
                                                                                                            — jQ-world, размер был N
                                                                                                            — Webpack, babel, Vue, etc., размер 2N-3N
                                                                                                            — Изучение мануалов и тонкая настройка, размер N
                                                                                                            Т.е. с одной стороны выигрыш по размеру был лишь по сравнению с «не оптимизированной версией».
                                                                                                            С другой стороны — приложение получило максимально современный код и архитектуру. Плюс сильно расширенный функционал.
                                                                                                            И время сборки максимально-близкое по комфорту к «Ctrl+S -> Ctrl+F5».

                                                                                                            Если выкинуть весь доп.функционал, то размер будет да, меньше изначального. Ибо были как и самописные jQ плагины (счет в пределах «до 10Кб»), так и сторонние, которые могли быть весьма и весьма тяжелыми.
                                                                                                            Сейчас те же задачи решают аналоги, построенные на современном тех-стэке, местами они сильно-существенно меньше по объему.

                                                                                                            А свои плагины заменены на Vue-модули (тоже самописные).
                                                                                                            Но эти модули уже позволяют выкинуть десятки киллобайт кода, по «поддержанию/отображению данных».

                                                                                                            UPD: Посмотрел анализ бандла — если исключить все библиотеки и оставить лишь «бизнес-код», то в режиме gzip имеем менее 30кб. Что весьма похоже на правду для web-dashboard для конфигурирования системы автотестирования, назначения расписания, управления балансировщиком нагрузки, выводом списка отчетов и просмотра каждого из них.
                                                                                                              0
                                                                                                              А хотите, чтобы весь код укладывался в 50кб, а не только бизнес?
                                                                                                                0
                                                                                                                Ну… я не могу себя назвать совсем друачком — конечно хочу, только в моем случае это трудно себе представляю.
                                                                                                                Надо(хочется и удобно) же бутстрап, vue… и еще кучки всякого прочего «добра» ^_^
                                                                                                                  –1
                                                                                                                  А что если я скажу, что можно без бутстрапа, вью и при этом даже более удобно?
                                                                                                  +1
                                                                                                  Не холивара ради, но Vue многие боятся не потому что он не мейнстрим, а потому что много магии и никакущий тулинг, как только нормальный DX завезут, глядишь можно и работать будет
                                                                                                    0
                                                                                                    А что именно не нравится в тулинге и что нравится в тулинге Реакта?
                                                                                                      +2

                                                                                                      Сейчас навскидку только скажу про отсутствие автоимпортрв во вью файлах
                                                                                                      Приколоченный гвоздями export default, который тоже некисло гадит при разработке
                                                                                                      Наглухо отсутствующая типизации
                                                                                                      Директивы через литералы
                                                                                                      Пропаганда мутабельности
                                                                                                      Это из того, что вспомнил

                                                                                                        –1
                                                                                                        Тут скорее ваши предпочтения не совпадают с теми, что у разработчиков Vue.

                                                                                                        Когда я говорил про отличный DX, я имел в виду хорошую документацию (например, на русский она была переведена на год раньше Реакта), браузерный DevTools, готовые решения, а не «найди на npm и собери сам».
                                                                                                          +2
                                                                                                          Тут скорее ваши предпочтения не совпадают с теми, что у разработчиков Vue
                                                                                                          Мне видится обратная ситуация

                                                                                                          Документация не соотносится с тулингом от слова «совсем» и уж тем более, время ее перевода на русский (без английского в деве вообще тяжко, да)
                                                                                                          Браузерный DevTools у Реакта — ничем не уступающий Вьюшному.
                                                                                                          «найди на npm и собери сам» — скорее плюс, никто не прибивает разработчика гвоздями к той или иной библиотеке роутинга, или стейт менеджеру, как хочешь, так и варись
                                                                                                          Не хочется собирать все по частям? Ставишь CRA, делаешь eject, бойлерплейт проект готов
                                                                                                          Впрочем это уже тонкости, и к изначальному поинту не имеют никакого отношения
                                                                                                            +1
                                                                                                            > никто не прибивает разработчика гвоздями к той или иной библиотеке роутинга, или стейт менеджеру, как хочешь, так и варись

                                                                                                            И получается, по сути, самодельный фреймворк на каждом проекте. Приходишь и вроде всё знакомо, но ни хрена не понятно.
                                                                                                              0
                                                                                                              Таки да, есть такой минус
                                                                                                              Но тут вопрос в том, что больнее — юзать неудобный инструмент, или при смене части стека потратить пару дней на вливание в новую технологию
                                                                                                                0
                                                                                                                Далеко не пара дней может потребоваться от одной банальной cмены Redux и функционального подхода на MobX и ООП-подход. Всё в рамках React-экосистемы.
                                                                                                                  0
                                                                                                                  Ну для кого не пару, волен искать себе направление деятельности внутри своего стека в таком случае, вакансий хватает на самый разный вкус фломастеров)
                                                                                                                  Дискриминации по стейт-менеджерам благо нет, да и парадигм всего 2 (в общем случае), если работал по обе стороны, хотя бы раз, без труда разберешься и в остальных (та же суть, другое апи)
                                                                                                                  Все таки свичнуть стейт менеджер — не менять фреймворк со всей экосистемой вместе)
                                                                                                                    +2
                                                                                                                    Приложения на MobX и на Redux строятся совершенно по разному. Это не просто «свичнуть стейт менеджер».
                                                                                                                      0
                                                                                                                      МобХ можно очень легко натянуть на редаксовый код (наоборот — не уверен, потому что мобх — либа, а редакс — скорее фреймворк). Потеряв при этом, разумеется, в читабельности и вменяемости кода — но работать будет, а само натягивание будет процессом скорее механическим, чем творческим.

                                                                                                                      И да, «свичнуть стейт менеджер» — это дело нифига не простое, но и не невозможное.
                                                                                                          –2
                                                                                                          > Пропаганда мутабельности

                                                                                                          Вы так говорите, как будто это что-то плохое. :)
                                                                                                            +2
                                                                                                            Когда одна мутация вызывает другую, которая вызывает третью, которая..., которая вызывает первую.
                                                                                                            В итоге, пока найдешь, кто где что триггерит, пройдёшь все круги ада и собственно этих самых мутаций.
                                                                                                            С мутированием переменных код получается императивным, а не декларативным
                                                                                                            Так что, склонен думать, что да, плохое :D
                                                                                                              +1
                                                                                                              которая вызывает первую.

                                                                                                              В случае реактивного программирования у вас на этом шаге вылетит исключение.

                                                                                                                0
                                                                                                                Окей, тогда фан факт: предельное количество петель определяется банальным счетчиком, и когда он прощёлкивается, то система считает, что луп бесконечный и скипает остальные обновления
                                                                                                                Отсюда можем получить стейт-специфик баги и прочее)
                                                                                                                  0
                                                                                                                  Нет, на первом же лупе будет исключение. Зачем тут счётчики? Если вы пытаетесь поднять себя за волосы, значит что-то не так с логикой.
                                                                                                                    0
                                                                                                                    Пример
                                                                                                                    С ростом проекта, возможность держать граф мутаций в голове стремится к уровню «импоссибюро», и проецируя этот кейс на приведенный пример, можно прикинуть, насколько болезненными такие концепции могут быть
                                                                                                                        0
                                                                                                                        Теперь при клике пример просто падает
                                                                                                                        (даже если убрать луп)
                                                                                                                          0
                                                                                                                          Поправил.
                                                                                                                            0
                                                                                                                            А в чем его невалидность?
                                                                                                                              0

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

                                                                                                                                0
                                                                                                                                А как понять, когда нужно обернуть в экшн, а когда нет?)

                                                                                                                                UPD: увидел, с этим стало понятнее)
                                                                                                                                  +2
                                                                                                                                  В случае MobX так делать надо всегда.
                                                                                                                        0
                                                                                                                        Это конечно камень в огород мобх, потому что если б enforceActions по дефолту было бы в 'always' — этого бы не было. Но vintage вам уже собственно всё подправил одной строчкой.

                                                                                                                        ЗЫ: Кстати, а можно вопрос? Зачем вы в качестве контраргумента реактивному программированию приводите пример в духе «что-то внезапно дёргает что-то»? Реактивное программирование само по себе вам данные-то в хорошем порядке не выстроит, и граф преобразований от входов к презенташкам — тоже.
                                                                                                                          0
                                                                                                                          Тут это не причем, оно может быть реактивным и без мутаций основанных на магических геттерах и сеттерах, которые как раз таки усложняют чтение кода и дебаг.
                                                                                                                            0
                                                                                                                            Вот именно. И можно так же пользоваться той же mobx, и не основываться на магических геттерах и сеттерах. Или самому всё написать, некоторые прям таки обожают закатывать солнце вручную.

                                                                                                                            Я просто не понял, к чему был ваш аргумент. В ногу можно выстрелить? Да конечно можно. Везде можно. И с голой декларативщиной тоже можно.
                                                                                                                              0
                                                                                                                              Как пользоваться мобиксом без геттеров и сеттеров?
                                                                                                                                0
                                                                                                                                Вот так. Как и в любой другой парадигме реактивного программирования.
                                                                                                                                  0
                                                                                                                                  Упаси Бог)
                                                                                                                                  Много проектов использует такой подход?
                                                                                                                                  Даже в официальной доке про то, что это бест практис по использованию ни слова
                                                                                                                                  Да и количество бойлерплейта которое придется писать переплюнет любой редакс, провоцируя в разы больше ошибок, чем использование либы в «голом» виде
                                                                                                                                  ¯\_(ツ)_/¯
                                                                                                                                    0
                                                                                                                                    Так вы уж определитесь для себя — вам «использовать без магии» или «количество бойлерплейта провоцирует ошибки». Трусы или крестик, короче.

                                                                                                                                    Если без магии — это mov ax,bx. Если без бойлерплейта — это читаем доку, декларируем обсерваблы, экшены, вот это всё — и не жужжим.

                                                                                                                                    что это бест практис по использованию ни слова

                                                                                                                                    Потому что это не бест практис, кто вам такую глупость сказал? Вы спросили «как» — я вам ответил, как.
                                                                                                                                      0
                                                                                                                                      По моему, я достаточно определил свою точку зрения выше)
                                                                                                                                      Если инструмент пропагандирует подход, который либо трусы, либо крестик, то может проблема в инструменте?
                                                                                                                  –1
                                                                                                                  Вы так говорите, как будто императивное программирование — это что-то плохое :)
                                                                                                                    +3
                                                                                                                    Считаю, что ему место в более низкоуровневых вещах, чем в проектировании интерфейсов)
                                                                                                                      –2
                                                                                                                      Для интерфейсов можно стремиться к декларативной иммутабельности, а вот с бизнес-логикой — очень спорно.
                                                                                                                        0
                                                                                                                        Это что-то из серии «если у меня уже есть микроскоп и он довольно тяжелый, то молоток мне уже не пригодится».

                                                                                                                        И как только дело доходит до интересных случаев (например, сложной оптимизации рендера), так вы со своим микроскопом приходится, говорите «нет» мутабельности и сливаете в несколько раз больше памяти, чем было б с мутабельностью. А потом это происходит 100 раз на страницу (потому что компоненты и тэ дэ), а потом все кругом такие «ой, чёт наш прекрасный интерфейс память жрёт как не в себя».

                                                                                                                        Все совпадения с реальными случаями, разумеется, вымышлены.
                                                                                                                          +1
                                                                                                                          Это что-то из серии «если у меня уже есть микроскоп и он довольно тяжелый, то молоток мне уже не пригодится».
                                                                                                                          Лучше плохой аналогии — только никакая аналогия)

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

                                                                                                                            Ага. А в деле производительности интерфейсов рендер — самая тяжелая штука.

                                                                                                                            при замене императивного на декларативное — траблы с архитектурой

                                                                                                                            Однозначно. Но слив памяти в трубу, потому что теперь никто ничего не мутирует — сразу же за этим.
                                                                                                                              0
                                                                                                                              На данном этапе — реконсил и модификация DOMa самые тяжелые)

                                                                                                                              Приведите пример кода, который в декларативном виде отъедает много памяти, а в императивном — нет)
                                                                                                                              До этого, кейс слишком космический)
                                                                                                                                0
                                                                                                                                Хорошая попытка, но нет.
                                                                                                                                «Я тут сяду и буду голословно утверждать, а вы мне в опровержениях код пишите» работает если только на тех, кто в интернет только вчера зашел.
                                                                                                                                  0
                                                                                                                                  Да, только поинт про утечку памяти, если писать код декларативно — не я привел)
                                                                                                                                  Чьи утверждения после этого более голословны нужно бы проверить)

                                                                                                                                  Декларативность кода заключается не только в каррировании функций, да и даже в них нет никакой особой проблемы. Даже при вызове в 100 раз, хотя тут опять же проблема архитектурного масштаба, не случится ничего криминального. С большой долей уверенности, скажу — то что жрет память как не в себя в декларативном виде, отожрет ее с той же прожорливостью и в императивном, пусть даже и немного меньше. Кроме того, сильно зависит от того, как написать
                                                                                                                                    0
                                                                                                                                    Да, только поинт про утечку памяти, если писать код декларативно — не я привел)

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

                                                                                                                                    Если код пишут идиоты, то тут и в том и в другом случае много всего плохого может случиться.

                                                                                                                                    Кроме того, сильно зависит от того, как написать

                                                                                                                                    Вот именно. И возвращаясь к вашему аргументу выше по ветке — не «императивщине не место в интерфейсах», а «всё зависит от того, как написать».
                                                                                                                                      0
                                                                                                                                      Не утечку, а перерасход.
                                                                                                                                      Сути не меняет, тащемта, не я утверждал это

                                                                                                                                      Тот мизер эдж-кейсов, где императивность могла бы быть оправдана подтверждает правило, что декларативность (ВНЕЗАПНО) декларативнее, нагляднее, читабельней. Это позволяет сконцентрироваться на том, что происходит, а не как происходит. Никто не мешает написать императивно любую из низкоуровневых функций, я не накладывал на это табу в своем сообщении)
                                                                                                                                      Однако, опять же, на своей памяти в реальной жизни не встречал ни одного подобного кейса)
                                                                                                                                        –1
                                                                                                                                        Вы понимаете, что слова «нагляднее» и «читабельней» по сути своей субъективны? И вроде как раз преимуществом декларативных языков считается, что не надо вникать в то, что происходит. Это императивные языки говорят компьютеру что делать шаг за шагом, что должно происходить при выполнении.
                                                                                                                                  0

                                                                                                                                  Код не приведу, но приведу теоретические выкладки касательно редактирования в богатом редакторе текста. Вот у нас есть некоторое дерево. Нам нужна поддержка истории. В функциональном стиле сделать новый снепшот так, чтобы он переиспользовал ветви предыдущего снепшота — быстро и экономно по памяти. Однако, нам нужно совместное редактирование и чтобы у каждого пользователя была своя история. Снепшоты становятся бесполезны, а надо запоминать сами изменения. Изменения должны применяться к любой версии дерева, а значит должны быть сериализуемыми, а значит указывать на узлы по идентификаторам. Но как быстро найти узел по идентификатору в денормализованном дереве? Нужен индекс. Но перестраивать индекс на каждый чих — дорого. А нормализованный граф — сам себе индекс. Нормализованый граф — это фактически словарь с десятками тысяч ключей. Пересоздавать его на каждое изменение крайне медленно. Получается нужна ручная реализация какого-нибудь иммутабельного дерева поиска с хитрыми алгоритмами обновления за log(n).


                                                                                                                                  Либо просто берём обычную хеш-таблицу, помещаем в неё объекты с обсерваблами, провязываем перекрёстными ссылками и получаем все операции а константу.

                                                                                                                                    0
                                                                                                                                    Думаю, не мне Вас учить, как в декларативном программировании обыгрываются сайд-эффекты, проблему которых Вы описали)
                                                                                                                                    Я не пропагандирую табу любой императивщины, ибо ИТ, в своем корне — чистый императив, но говорю, что подход mobx, Vuex,… — заранее настраивает разработчиков писать императивный код. Хорошие программисты вынесут в нижние слои абстракций и не будут знать проблем, но ведь суть технологии свести проблемы проектирования приложения, архитектуры, кода к минимуму, и желательно для любого уровня программиста)
                                                                                                                                      +1
                                                                                                                                      Я описал проблему функциональщины за которую топят реакторедаксы. При этом декларативщины там не больше, чем в реактивном программировании. И, насколько я вас понял, под императивным вы понимаете интерактивный код. В то время как mobx и ко по большей части реактивный (где описываются лишь инварианты). А вот редакс — интерактив (где на изменения срабатывают обработчики, которые вносят другие изменения) в чистом незамутнённом виде.
                                                                                                                                        0
                                                                                                                                        Все дело в том, что я не вижу проблемы в приведенном выше кейсе.
                                                                                                                                        И как изначально начался тред, императивно код писать лучше в нижних слоях приложения, либо выносить это в отдельные слои.
                                                                                                                                        Почему вы думаете, что я не приемлю императивного кода ВЕЗДЕ я не знаю, я такого не говорил.
                                                                                                                                        Понятиями «интерактивного кода» и «инвариантов», я не владею, сорри.
                                                                                                                                        Под императивным я понимаю код формата
                                                                                                                                        this.props.someStore.myCounter += 1

                                                                                                                                        И этот метод описания прямо таки форсят, подавая как фичу технологии, используя такой стиль практически в каждой статье официальной доки.
                                                                                                                                        Можно и с mobx писать декларативно, но тогда по сути, это ничем не будет отличаться от тех же редаксоподобных стейт-менеджеров, на самом низшем уровне получая функцию с сайд эффектом, либо интерцепторы, которые будут аналогами локальных редьюсеров.
                                                                                                                                          –1
                                                                                                                                          Это и есть фича этой технологии: простой императивный ООП-стиль с «магической» реактивностью.
                                                                                                                                        –1
                                                                                                                                        > но ведь суть технологии свести проблемы проектирования приложения, архитектуры, кода к минимуму, и желательно для любого уровня программиста)

                                                                                                                                        Это у какой технологии такая суть? Как-по мне, суть MobX — снять с программиста заботу об отслеживании изменений в объектной модели единым и унифицированным для всего приложения способом. Он уже тот самый нижний уровень абстрации.
                                                                                                                0
                                                                                                                «Хороший архитектор не станет брать...». Выбирает не архитектор, а выбирают архитектора. Архитектор это и есть архитектура.
                                                                                                                  0
                                                                                                                  Вы меня запутали. Если архитектор это архитектура, то он и создаёт её (архитектуру), подбирая нужные инструменты.
                                                                                                                    –1
                                                                                                                    Если кому-то важны сроки подберут другого архитектора. Подходящий архитектор это человек не со знаниями о стеках, а со стеком от и до, т.е. с реально работающим проектом причем на 75% похожим на тот который нужно сейчас построить. Допустим это у него не первый стек и не первый проект — но он уже отчасти забыл предыдущий, отчасти технологии так ушли вперед что нет смысла возвращатся. Во время проекта хорошо бы до последних версий обновится и всё… «Я прочел книжку о фреймворки» — возьми с полки пирожок, но архитектуры у тебя на начало проекта нет. В вебе так.

                                                                                                                +1
                                                                                                                А сейчас даже Parcel люди не знают (или боятся), хотя он исправляет то, за что все критикую Вебпак (отвратительный DX с кучей конфигов).

                                                                                                                Мой опыт с Parcel'ом: недавно исправлял issue в библиотеке от пользователя parcel'а с тем что он не умеет подставлять значения во время сборки (DefinePlugin в вебпаке или rollup-plugin-replace в роллапе), заменил на process.env. которые parcel умеет. Дальше собираю демонстрационный проект с флажком для scope hoisting'а, прохожусь prettier'ом по собраному файлу чтоб посмотреть во что он там насобирал и с печалью вижу что у него проблемы с примитивным tree shaking'ом на уровне webpack'а и он не выкидывает кучу неиспользуемых функций.


                                                                                                                У меня нет глубокого понимания на тему внутренностей бандлеров, возможно у Parcel'а правильная архитектура итд, но на данный момент меня совершенно не устраивает тот бандл, который он генерирует.


                                                                                                                То же самое с Vue — все критикую Реакт что там ничего не понятно и сторонние библиотеки (типа роутера) плохие, но продолжают боятся Vue (так как он не мейнстрим).

                                                                                                                Небольшая история о том как развивался Vue: когда-то давно(после выхода реакта) я и ещё один человек работали над библиотеками, реализующими vdom алгоритмы и очень сильно задротствовали на тему производительности, на тот момент мы не понимали очень много мелочей о том как правильно должен работать реконсайлер, где-то через пол года появился ещё один разработчик который написал свою ещё более примитивную библиотеку, которую он делал глядя в наши исходники и естественно понимал ещё меньше о том как правильно должен работать реконсайлер(худшая библиотека на тот момент в плане поведения), потом появился Vue2, который использовал исходники этой примитивной библиотеки с добавлением своих костылей :) В итоге vue вобрал в себя ужасные идеи, которые я использовал в своих старых поделках + примитивный дифф алгоритм с кучей заплаток для эдж кэйсов, о которых все кроме авторов Реакта даже не догадывались в 2016ом.


                                                                                                                Виноваты авторы Реакта в том что у них есть большой багаж знаний и они понимают что невозможно сделать "one size fits all" решение и поэтому не пихают всё подряд в свою библиотеку? Может кому-то со стороны кажется что это всё недостатки реакта, но большинство критики реакта связано с отсутствием глубокого понимания предметной области.


                                                                                                                Реакт есть за что критиковать и разработчики реакта часто умышленно умалчивают о различных недостатках своих решений, но приводить в пример Vue как решение проблем React'а — сомнительная затея.

                                                                                                                  +1
                                                                                                                  А какие там не очевидные мелочи предусмотрены в реакте, если не секрет?
                                                                                                                    +5

                                                                                                                    На самом деле это очевидные мелочи, если не замарачиваться на тему производительности и в первую очередь думать о композиционных паттернах. Например, в моей старой библиотеке невозможно было менять рутовый элемент у компонент и это было ограничено на уровне API, а так как остальные библиотеки использовали те же самые алгоритмы, но при этом пытались делать API как у React'а, то естественно во всех библиотеках кроме реакта это не работало, и когда я рассказал другим об этой проблеме и сказал что нормальный фикс потребует изменить код в куче мест, большинство разработчиков пошли простым путём и начали использовать корявый фикс, который в случае таких кэйсов рекурсивно шёл по дереву вверх и патчил все несоответствия, в некоторых либах это даже приводило к тому что изменялся шэйп виртуальных нодов и повсюду срабатывали деоптимизации с мономорфных колсайтов на полиморфные, но так как в популярных бэнчмарках этот кэйс не проявляется, то никто не замарачивался :) В некоторых библиотеках этот кэйс до сих пор поломан.


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


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


                                                                                                                    Все эти проблемы я отношу к фундаментальным проблемам, но так как у реакта очень большая популярность, то им дополнительно приходится фиксить кучу проблем связаных с нормализацией поведения в различных браузерах. Например во vue долгое время закрывали issues'ы связаные с поведением innerHTML на svg элементах, и только когда накопилась критическая масса недовольных пользователей, то наконец-то это пофиксили. Недавно во vue начали появляться недовольные пользователи, у которых инпут поля работают неправильно в некоторых браузерах из-за порядка присваивания аттрибутов, но так как кол-во недовольных пользователей пока маленькое, то естественно там забивают на эту проблему, а в реакте из-за его популярности пришлось нормализовать поведение для всех этих мелких кэйсов и многих других, тк недовольных пользователей значительно больше.

                                                                                                                      0

                                                                                                                      Не подскажете какие библиотеки толковые?


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

                                                                                                                    0
                                                                                                                    где-то через пол года появился ещё один разработчик который написал свою ещё более примитивную библиотеку, которую он делал глядя в наши исходники

                                                                                                                    если не секрет, а что за библиотека, которую использовал vue ?

                                                                                                                  +1
                                                                                                                  Это правда. Очень жаль, что современным фронтэндом просто невыносимо пользоваться в распределённых командах и в микросервисной архитектуре. Когда в продукте 15-20 микросервисов с GUI-ями и появляются сквозные задачи, а так же задачи переиспользования UI, начинается невыносимая боль. Просто на вскидку:
                                                                                                                  1. Разные версии библиотек — практически нет шансов поддерживать одну версию библиотеки на всех стримах разработки. Постоянные накладные расходы на поднятие версий и бесконечные рефакторинги. Отсюда невозможность делать нормальные шаренные компоненты. Если и получается сделать, то это жуткий урод с несколькими реализациями под разные версии библиотек (у нас в фирме есть ангуляры от 1 (который angularJS), до 7. Причём ни реакт, ни vue особо бы не решили этих проблем);
                                                                                                                  2. Плохая уживчивость в одном UI нескольких инстансов фреймвёрка — различные методики встраивания одного приложения в другое, это адовая боль. Постоянные пересечения и ошибки при многослойном использовании. Простейшие кейсы выливаются в использование iFrame-ов и прочих костыляний;
                                                                                                                  3. Ужасная кастомизируемость — практически невозможно сделать ничего рантайм-расширяемого. Как только клиент хочет расширения, вэлком в код и пересборки всего приложения под конкретный проект внедрения. Самое лучшее что придумали это в рантайме подгрузка компилятора на клиент и сборка ts/css на клиенте (AOT — основной костяк, JIT — подгружается он-деманд при встрече с динамическими компонентами);


                                                                                                                  И это самые безобидные проблемы «кровавого микросервисного интерпрайса» в мире фронтэнда.
                                                                                                                    +2
                                                                                                                    Может вам web components пощупать с таким зоопарком?
                                                                                                                      0
                                                                                                                      Не взлетает с нашими кейсами, пробовали. Невозможно кастомизировать стили нормально под заказчиков, любые сервисы необходимо дублировать (авторизация, грант-менеджмент, локализации и т.д.), сам по себе стандарт сыроватый.
                                                                                                                      0
                                                                                                                      Отсюда невозможность делать нормальные шаренные компоненты. Если и получается сделать, то это жуткий урод с несколькими реализациями под разные версии библиотек (у нас в фирме есть ангуляры от 1 (который angularJS), до 7. Причём ни реакт, ни vue особо бы не решили этих проблем);

                                                                                                                      При активной разработке фиксация версий — дурная практика, ибо приводит к протуханию зависимостей, поддержке множества версий, замедленной обратной связи и тп. Идеальный вариант — при каждом обновлении зависимости, все зависимые проекты пересобираются с прогоном тестов. Если какой-то сломался, то уже разбираемся нужен ли фикс в зависимости или в зависимом. Про кейс "некогда разбираться, надо зарелизить вот прям щас", я в курсе, но это уже прокол менеджмента, который должен предусматривать буфер для форс-мажоров. А сильно ломающее изменение общей зависимости не должно происходить прямо перед продуктовым релизом.


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


                                                                                                                      Плохая уживчивость в одном UI нескольких инстансов фреймвёрка — различные методики встраивания одного приложения в другое, это адовая боль.

                                                                                                                      Как я уже сказал спасает единая версия всего. Ну и не обобщайте, не все фреймворки одинаково бесполезны.


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

                                                                                                                      Хотите фокус? Следите за руками:


                                                                                                                      1. Возьмём простую демку с 3 связанными друг с другом полями с подсветкой синтаксиса. Вот весь её код.
                                                                                                                      2. Грузим эту демку в рантайме, в рантайме же формируем интерфейс редактирования и можем менять эту демку как угодно. Пример, как это выглядит.

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

                                                                                                                        0
                                                                                                                        Пример, как это выглядит

                                                                                                                        Отлично! Полагаю, что собираться сверху вниз из независимых GUI компонент в сайт и лейаутиться на основе нотации tree тоже можно?

                                                                                                                          0
                                                                                                                          Да, конечно, возможна любая динамика в композиции компонент.
                                                                                                                            +1

                                                                                                                            Давно хочется уже создать простенький адаптивный сайт на $mol, используя только tree нотацию. Боюсь — не разберусь. Шутка. А если нет? Должно быть не сложнее кастомизации стандартных флешовых компонент. Где мои 47 лет… Утро началось позитивно — Андрееску снова обыграла Кербер.

                                                                                                                        –1
                                                                                                                        А можно пример «микросервиса с GUI-ями»? Как-то внутренний парсер ломается.
                                                                                                                          0
                                                                                                                          Ну тут GUI это обобщённо Graphical User Interface, речь в частности про Гипертекстовые Интерфейсы в браузерах. По привычке заиспользовал термин GUI (У нас в фирме есть до сих пор консольные интерфейсы, на флексе, десктопные и т.д.)
                                                                                                                        0
                                                                                                                        Если честно, я не очень понял, почему не держать у всех, к примеру, ангуляр 7.0.3, и централизованно его не обновлять. C ангуляром 1 понятно, что обновление равносильно переписыванию, но в остальных случаях обычно пары дней хватает чтобы обновить пару десятков зависимостей в заданном проекте.
                                                                                                                          0
                                                                                                                          Количество микросервисов у которых есть UI больше 30 штук. На каждый по «пары дней», выходит довольно жирная цифра. И на деле парой дней во многих не обойдёшься. В общем это очень сложно в деливери-плане. На бумаге и в голове это всё отлично звучит, а вот в реальном мире не работает.
                                                                                                                +4
                                                                                                                Бэкенд перешёл на систему либо стагнации, либо поддержки: в последние годы практически нет развития. И как следствие, у них другие приоритеты: когда у тебя нет новых фреймворков каждые полгода, это на тебя влияет. Они есть где-нибудь в Rust или Go, но Ruby — что там нового? Как следствие, люди сфокусированы на другом. Конечно, я очень упрощаю, и бэкенд бэкенду рознь.

                                                                                                                Господин отравлен энтерпрайзом. Понятно что топовые разработчики за спасибо не работают — но описанная ситуация это как раз махровый энтерпрайз (2% сайтов аккумулирующих 98% денег).

                                                                                                                Бэкенд не меняется, в лучшем случае, десятилетиями. Но не по причине консервативности или костенелости. Здесь работают деньги, тут нет места непроверенным технологиям и хайповым вещам, цена ошибки, как правило, довольно велика (здравствуйте перекрестные ревью и 100% покрытие тестами, которые все равно не исключают косяков, но хотя бы дают мнимую уверенность).

                                                                                                                Но это не значит, что бэкенд врос на одном месте и не движется. Вспомните появление дотнета, меньше чем за 10 лет, он смог отгрызть у явы 30% рынка. Да, за ним стоял микрософт, но он стоял и за J# о котором сейчас помнят два с половиной олдфага. Так что если сегодня появится технология способная потеснить три столпа энтерпрайза (ява, шарп, кресты) — она найдет свой угол. Просто самим фактом.
                                                                                                                  0
                                                                                                                  C# не только отгрыз у явы рынок — он ещё и саму яву заставил быстрее шевелиться, и в результате обновления и улучшения становятся заметны уже не только программистам, но и конечным пользователям. Вон уже и паттерн-матчинг где-то в обозримом будущем появился, и немного меньше причин всё выбросить и переписать на C++.
                                                                                                                  +3
                                                                                                                  Считаю что SvelteJs один их самых недооцененных фреймворков на данный момент. А уже Svelte 3 вообще космос. В прочем, почему-то редко проекты Рича Харриса становятся сильно популярными, только разве что Rollup. И то, как и в случае с Реакт, Webpack ему не победить. Не умеет он видимо в маркетинг и корпорации тоже не спешат помогать. А потом читаешь статьи из разряда «Как мы пилили примитивный компонент, используя react/redux/reselect/recompose и поверх еще rxjs», и грустишь.
                                                                                                                    –3
                                                                                                                    Реакт и вебпак исторически были прорывными шутковинами и этот факт из истории не убрать. Rollup и SvelteJs не выглядят прорывными, но тем не менее звезд там все равно много и они по свойму популярны. Svelte насколько я понимаю в некоторых областях очень применим, если допустим виджед куда-то внедрить нужно посторонний при этом не тянуть с собой фреймворки.
                                                                                                                      +3
                                                                                                                      Ну да, это всего лишь первый (и пока единственный) бандлер с нормальным tree-shaking’ом и первая (и вероятно пока единственная) реализация МИФ с полной AoT компиляцией.

                                                                                                                      Не то что React с vdom и компонентами, которые ещё в 2012 году уже были в Ractive. Или webpack, до которого конечно не было ни browserfly, ни других. Прорыв прямо.
                                                                                                                    0
                                                                                                                    А можно углубится в проблему у «Babel-плагинов нет асинхронности» — она названа, но в чем проблема то?
                                                                                                                      0
                                                                                                                      Вы правда не видите проблемы в отсутствии асинхронности?
                                                                                                                        +3
                                                                                                                        Я не вижу. Ну кроме несоответствия текущему хайпу на разноцветные функции.
                                                                                                                          +1
                                                                                                                          Что касается «отсутствия асинхронности в плагинах», я не понимаю о чем речь. Где она отсутсвует. Вынужден гадать. В вызове плагинов? В самом плагине в вызове io? В представлениях который генерирует плагин? И что там стало недоступным из за отсутсвия асинхронности? Что касается «отсутствия асинхронности в вакууме» то это действительно не проблема вообще.
                                                                                                                            +1

                                                                                                                            Смысл, что нельзя использовать асинхронный код в плагине

                                                                                                                              +1
                                                                                                                              У меня возможно тунельное мышление, но я споршу: а зачем какому-нибудь plugin-transform-typescirpt асинхронность? Вот компилятору typescript асинхронность нужна, пусть он ее и реализует, а плагину фасаду над ним зачем? Поскольку сами плагины работают всегда синхронно ну так пусть все что нужно асинхронизировать и синхронизировать будет в компиляторе Typescript. Что такое выигрывается если мы начнем ждать результат компилятора «асинхронно»? Или вы все таки хотите сказать что нужна асинхронность/паралелизм в запуске плагинов (тогда появляется смысл зачем разрешать асинхронный код в плагинах, но чтобы это могла быть за задача такая)?
                                                                                                                                0
                                                                                                                                Плагин может читать с диска или вызывать другие инструменты.

                                                                                                                                Например, давно есть идея сделать babel-плагин, чтобы прогонять postcss-плагины через CSS-в-JS. Но это сделать сложно, так как в PostCSS много асинхронных плагинов (например, те, что конвертируют картинки в WebP) — в итоге приходится делать костыли.

                                                                                                                                Или, например, плагин может читать/писать на диск какой-то кеш.
                                                                                                                                  0
                                                                                                                                  Переспрошу, я правильно Вас понимаю что сейчас из плагина нельзя сравнительно просто вызвать другой инструмент или читать с диска? (действительно не в курсе, а звучит невероятно — самый первый плагин webpackа самой первой версии должен был являтся вызовом стороннего инструмента — нельзя же было расчитывать что все перепишут существующие трансформаторы).
                                                                                                                                    0

                                                                                                                                    Да, нельзя легко вызывать функции, которые возвращают Promise

                                                                                                                          0
                                                                                                                          1. Например, внутри babel-плагина нельзя вызывать какую-то асинхронную функцию.
                                                                                                                          2. А если вызывать *Sync версии функций, то это плохо влияет на производительность
                                                                                                                            0
                                                                                                                            1. Для клиента это может и проблема, но на бэкенде есть node-fibers.


                                                                                                                            2. Мой опыт говорит о ровно противоположном. Синхронные функции во всяком случае с SSD диском работают быстрее.