21.03.2019 10:02
phillennium 206 51500 Источник


Андрей Ситник из Злых марсиан — одно из самых известных российских имён во фронтенде: у его проектов 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). Все подробности о их темах докладов — на сайте, приобрести билеты можно там же, и постепенно они дорожают.

Комментарии (206)


  1. tuxi
    21.03.2019 13:15
    #19919860

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


    1. Fenzales
      21.03.2019 15:09
      #19920472

      Это же ничем не отличается от Google AMP.


      1. Alexufo
        21.03.2019 18:03
        #19921562

        У каждого модного поисковика должен быть свой Google AMP


      1. sumanai
        22.03.2019 00:30
        #19923262

        AMP вроде как не лезет на десктоп.
        Хотя я только за то, чтобы выжечь всё это калёным железом.


  1. Perlovich
    21.03.2019 15:07
    #19920456
    +5

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


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


    1. phillennium Автор
      21.03.2019 16:48
      #19921142

      Получается, лучше всего сейчас в COBOL: зарплаты высокие, новости можно вообще не открывать :)

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

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


      1. shogunkub
        21.03.2019 17:31
        #19921400

        Он говорит, что постоянно пересобирать фундамент, на котором одновременно остальные строят дом — это хорошо и правильно.
        С точки зрения мозгов того, кто этот фундамент пересобирает — возможно. А с точки зрения того, кто строит дом?


        1. VolCh
          21.03.2019 17:41
          #19921458

          Зафиксируйте версию фундамента и стройте :) Собственно в строительстве так оно почти всегда и бывает.


          1. akryukov
            22.03.2019 11:54
            #19925126
            +1

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


            1. VolCh
              22.03.2019 11:55
              #19925140
              +1

              На одном из прошлых проектов нам подрядчики на полном серъёзе говорили «зафиксируйте версию Хрома, чтобы всё работало».


      1. dedyshka
        21.03.2019 17:35
        #19921422

        С этим коболом была пара «жёлтых» новостей и всё…
        Где вы видите высокие зарплаты?


        1. shogunkub
          21.03.2019 20:09
          #19922112

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


        1. agarus
          23.03.2019 14:56
          #19930386

          «Высокие зарплаты» кобола это похоже «городская легенда»:
          www.indeed.com/q-Cobol-Programmer-jobs.html


      1. klvov
        21.03.2019 21:50
        #19922550

        * застойным болотом без прогресса
        * отличной надёжной рабочей лошадкой

        Ну или «лабиринтом с граблями, по которому, после некоторой практики, можно прекрасно научиться ходить и даже бегать»


        1. Iskin
          21.03.2019 23:33
          #19923010

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


      1. grinCo
        22.03.2019 02:06
        #19923492

        Просто то что делают в javascript сейчас в java уже давно есть или не нужно. При этом сам язык и стабильные фреймворки продолжают стабильно развиваться.


      1. max_mustermann
        22.03.2019 08:13
        #19923904

        Не получается. Я вообще не понимаю как слова COBOL и «огромный рынок» оказались рядом.


        1. phillennium Автор
          22.03.2019 08:15
          #19923910

          Смотря чем этот рынок измерять. Если сейчас в продакшне используются больше 200 миллиардов строк COBOL-кода, то куда огромнее-то?

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


          1. max_mustermann
            22.03.2019 16:00
            #19926678

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

            Хорошее представление о «рынке языка» даёт рынок труда. А там пусто. Это и есть реальное место Кобола, а подсчёты строчек оставим изнасилованым журналистам.


            1. mkovalevskyi
              22.03.2019 22:44
              #19928228

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


    1. apro
      21.03.2019 17:37
      #19921428
      +1

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


      1. ganqqwerty
        21.03.2019 18:04
        #19921572
        +4

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


        1. fetis26
          22.03.2019 15:22
          #19926466

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


          1. ganqqwerty
            22.03.2019 16:13
            #19926718

            Да фиг с ними с лидерами, я больше про нашу разбухшую зарплату беспокоюсь.


    1. VolCh
      21.03.2019 17:39
      #19921452

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

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


    1. Iskin
      21.03.2019 18:03
      #19921566
      +1

      это вообще не проблема, а наоборот

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


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


    1. zim32
      21.03.2019 23:11
      #19922920

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


    1. Dgolubetd
      22.03.2019 15:07
      #19926372

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

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

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

      Да в Java ней нет назойливого хайпа, но в ней нет и действительно полезных новшеств. Может быть и не должно быть, т.к. нельзя запихнуть все в один язык с обратной совместимостью. Проблема Java в том что она со своей критической массой доминирует, а ее стабильность стагнирует умы многих разработчиков (до сих пор не понимают асинхронности, не знают ФП и не стремятся и тд.).


  1. Forensy
    21.03.2019 16:31
    #19921056

    Делают каждый день новые фреймворки — плохо. Не делают каждый день новые фреймворки — тоже плохо.


    1. evil_random
      22.03.2019 04:34
      #19923668

      Как у нас говорят: во фронтенде — зрада :)


  1. kashey
    21.03.2019 16:42
    #19921114
    +3

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

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

    Ну и все такие:– Еее, спасибо за статью, как же я раньше жил.


  1. wrqqq
    21.03.2019 16:59
    #19921220

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


  1. Alexufo
    21.03.2019 17:52
    #19921510
    +3

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


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


    1. vintage
      21.03.2019 19:45
      #19922020
      +2

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


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


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


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


      1. Iskin
        21.03.2019 20:20
        #19922154
        +1

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


        1. vintage
          21.03.2019 20:56
          #19922304
          +1

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


          1. Iskin
            21.03.2019 20:57
            #19922314
            +3

            Конечно. Напиши мне в личку в Тви twitter.com/andrey_sitnik со ссылкой.


      1. Kuorell
        22.03.2019 00:18
        #19923216
        +2

        Имхо проблема с $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. vintage
          22.03.2019 06:52
          #19923788

          Сходу не могут понять ни люди

          Если новую концепцию можно понять сходу, то не такая уж она и новая. И если бы вместо этого птичьего синтаксиса можно было воспользоваться каким-либо иным, более привычным, уж поверьте, я бы не стал подвергать людей лишней когнитивной нагрузке. Вот, сравните сами, как та же концепция выглядит на более привычных 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. serf
            22.03.2019 10:18
            #19924456
            +1

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


            1. vintage
              22.03.2019 10:54
              #19924734

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


      1. babylon
        22.03.2019 04:12
        #19923640

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

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


    1. franzose
      22.03.2019 03:58
      #19923628

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


  1. sjuja
    21.03.2019 18:03
    #19921560

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


  1. nikolayshabalin
    21.03.2019 18:03
    #19921564
    +1

    Спасибо


  1. Alexufo
    21.03.2019 18:12
    #19921628
    -1

    У Рейчел не пройденный комплекс электры и ей не нравятся «болты» ситника в твиттере (его упражнения в расширении границ скромности), а Ситника бесит, что какая-то пацанка лезет со своим крашенным мнением на его автопрефиксер.
    Продолжайте, потомки мои. Всегда ваш доктор Фрейд.


  1. yudinetz
    21.03.2019 18:15
    #19921654

    Привет. Что-то я недопонял один момент. Вот вы говорите, что 500 долларов за билет — это дорого, и вообще, дорогие конференции — это неправильно. И тут же продвигаете свой HolyJs, на который билет стоит 38000 если без скидок? Это же те же 500 долларов (даже больше по текущему курсу).


    1. ganqqwerty
      21.03.2019 18:16
      #19921664

      Я вот подумал, а вдруг им нужны деньги?


    1. phillennium Автор
      21.03.2019 18:23
      #19921708
      +3

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


  1. yudinetz
    21.03.2019 18:17
    #19921670
    +6

    Кстати, кто такой Андрей Ситник я не знал до прочтения этой статьи. Да и сейчас знаю его только по этой статье. А вот Дэна Абрамова знают все, так что вот это получилось как-то совсем нескромно:

    Есть Дэн Абрамов на Западе, есть я в России


    1. Alexufo
      21.03.2019 18:22
      #19921702
      +3

      ну это нормальный феномен, если учесть, что Россия сколько там 7% от интернета занимает?
      Ситник известен тем что додумал идею одного разраба и оформил это на хайпе препроцессоров в постпроцессор PostCSS, заявляя значильную производительность при всем том же самом.
      Справедливо это или нет, но так сложились звезды, он об этом и говорит. PostCSS используют в яндексе, автор bootstrap заявил что 5-ая версия будет на PostCSS. Этого вполне достаточно, чтобы самоназваться представителем фронта от России.


    1. Iskin
      21.03.2019 18:30
      #19921740
      +4

      Ну там смысл не в том, что «я крутой», а в том, что «многие считают, что я крутой, но это не так — просто фортануло».


  1. serf
    21.03.2019 18:47
    #19921798

    Например, я хочу, прости господи, типы в JavaScript добавить, понятно, что это уже перебор.
    Почему перебор? Мысль здравая, а то все какие-то постцээсэс и автопрефиксеры. Но просто так добавить типы в JS не получится. Там нужно постоянно что-то подпиливать как c TypeScript происходит. Поэтому если и сделают стандарт ES2025+ с типами, то он очень быстро устареет.


    1. Aingis
      21.03.2019 19:24
      #19921926

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

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

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


      1. Grox
        22.03.2019 02:08
        #19923494
        +1

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


        1. VolCh
          22.03.2019 10:27
          #19924530

          Ещё нужно различать динамическую и статическую типизации.


        1. Aingis
          22.03.2019 12:13
          #19925282
          -1

          Это распространённый миф. На деле типизация ловит лишь малый процент как правило тривиальных багов, которые и так были бы отловлены в процессе разработки-отладки. Код-ревью с тестами перекрывают ловлю таких багов с лихвой.

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

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

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


          1. Grox
            22.03.2019 12:33
            #19925410

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


            1. Aingis
              22.03.2019 17:29
              #19927080
              -2

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

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


              1. vintage
                22.03.2019 18:04
                #19927240

                Вас не затруднит показать динамически типизированный код, который вы считаете качественным? Хорошо, если это будет крупный проект.


                1. VolCh
                  22.03.2019 18:28
                  #19927370

                  Первій попавшийся github.com/symfony/symfony/blob/master/src/Symfony/Component/DependencyInjection/ReverseContainer.php


                  1. vintage
                    22.03.2019 19:21
                    #19927552

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


                  1. Grox
                    22.03.2019 19:47
                    #19927656

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


                1. Aingis
                  23.03.2019 12:29
                  #19929816

                  Вопрос не имеет смысла. Любой код — это результат компромисса между ценой, скоростью разработки и выполнением требований. Причём вводные данные постоянно меняются. Хотите поспорить о том, что такое качество?

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

                  Разработка — это процесс удовлетворения появляющихся нужд заказчика. Любой код устаревает сразу как только написан. Иногда даже раньше.


                  1. vintage
                    23.03.2019 12:42
                    #19929876

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


      1. epishman
        22.03.2019 09:37
        #19924186

        Согласен, ценность строгой типизации преувеличена, это еще и от задачи зависит. Если нужно обрабатывать пользовательский JSON по алгоритмам, определяемым самими пользователями — не факт что Go окажется производительней JS, а уж синтаксического гемороя поимеем с этой статической типизацией. В свое время РСУБД, являясь выражением принципа статической типизации данных — проиграли более гибким key/value на определенном классе задач (не всех). Поэтому пусть JS останется таким — гибким и динамичным, надеюсь «аристократы» это понимают.


        1. serf
          22.03.2019 10:14
          #19924440

          Типизация не уменьшает гибкость JS, TS это все тот же JS только с прибавкой разумности.


          1. VolCh
            22.03.2019 10:29
            #19924548

            Это смотря что иметь в виду под гибкостью.


          1. epishman
            22.03.2019 10:58
            #19924760

            В гошке уже мешает, замучаешься кастовать interface{}, думаю теперь слезть на ноду.


            1. Lailore
              22.03.2019 14:06
              #19925924

              Замучились кастовать? Я думаю с вашей архитектурой что-то не так. А в нетипизированном мире это может привести к еще большему хаосу


              1. serf
                22.03.2019 17:10
                #19926992
                +2

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


              1. epishman
                22.03.2019 19:09
                #19927510

                Возможно где-то я и туплю, задача такая, что в произвольных JSON надо искать комбинацию определенных атрибутов, причем не одновременно, а в виде дерева решений — если наличествует атрибут 1 то ищем комбинацию 2+3, иначе ищем атрибут 4 и так далее. Заранее структура прилетающего объекта неизвестна. В итоге на JS лаконичнее получалось.


                1. transcengopher
                  22.03.2019 19:45
                  #19927642
                  +1

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


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


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


  1. evil_random
    21.03.2019 19:58
    #19922064
    -2

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


    1. Iskin
      21.03.2019 20:20
      #19922158
      +1

      Речь про то что стагнация только началась. Во времена jQuery легко было прийти с новыми идеями.


      1. evil_random
        21.03.2019 20:23
        #19922166

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


        1. Iskin
          21.03.2019 20:26
          #19922174
          -1

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

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

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


          1. evil_random
            21.03.2019 20:38
            #19922230

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


            1. Iskin
              21.03.2019 20:41
              #19922244

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

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


            1. evil_random
              21.03.2019 20:43
              #19922250

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


            1. ganqqwerty
              21.03.2019 22:04
              #19922616

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


              1. Iskin
                21.03.2019 23:34
                #19923012

                Таких архитекторов единицы. Достаточно посмотреть сколько фронтендеров гордяться, что сделали блог на 3-4 поста на Gatsby.js с 500 КБ JS.


            1. tehSLy
              21.03.2019 23:00
              #19922868

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


              1. Iskin
                21.03.2019 23:35
                #19923016

                А что именно не нравится в тулинге и что нравится в тулинге Реакта?


                1. tehSLy
                  22.03.2019 00:03
                  #19923156
                  +1

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


                  1. Iskin
                    22.03.2019 00:11
                    #19923192

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

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


                    1. tehSLy
                      22.03.2019 10:29
                      #19924550
                      +1

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

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


                      1. VolCh
                        22.03.2019 10:33
                        #19924582

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

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


                        1. tehSLy
                          22.03.2019 10:59
                          #19924764

                          Таки да, есть такой минус
                          Но тут вопрос в том, что больнее — юзать неудобный инструмент, или при смене части стека потратить пару дней на вливание в новую технологию


                          1. VolCh
                            22.03.2019 11:59
                            #19925168

                            Далеко не пара дней может потребоваться от одной банальной cмены Redux и функционального подхода на MobX и ООП-подход. Всё в рамках React-экосистемы.


                            1. tehSLy
                              22.03.2019 12:15
                              #19925290

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


                              1. vintage
                                22.03.2019 12:17
                                #19925304

                                Приложения на MobX и на Redux строятся совершенно по разному. Это не просто «свичнуть стейт менеджер».


                                1. JustDont
                                  22.03.2019 15:37
                                  #19926532

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

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


                  1. VolCh
                    22.03.2019 10:31
                    #19924560

                    > Пропаганда мутабельности

                    Вы так говорите, как будто это что-то плохое. :)


                    1. tehSLy
                      22.03.2019 10:56
                      #19924752

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


                      1. vintage
                        22.03.2019 11:06
                        #19924816

                        которая вызывает первую.

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


                        1. tehSLy
                          22.03.2019 12:10
                          #19925254

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


                          1. vintage
                            22.03.2019 12:13
                            #19925280

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


                            1. tehSLy
                              22.03.2019 12:57
                              #19925566

                              Пример
                              С ростом проекта, возможность держать граф мутаций в голове стремится к уровню «импоссибюро», и проецируя этот кейс на приведенный пример, можно прикинуть, насколько болезненными такие концепции могут быть


                              1. vintage
                                22.03.2019 15:06
                                #19926364

                                Поправил ваш пример.


                                1. tehSLy
                                  22.03.2019 15:42
                                  #19926570

                                  Теперь при клике пример просто падает
                                  (даже если убрать луп)


                                  1. vintage
                                    22.03.2019 17:10
                                    #19926988

                                    Поправил.


                                    1. tehSLy
                                      22.03.2019 17:15
                                      #19927022

                                      А в чем его невалидность?


                                      1. vintage
                                        22.03.2019 17:23
                                        #19927046

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


                                        1. tehSLy
                                          22.03.2019 17:28
                                          #19927076

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

                                          UPD: увидел, с этим стало понятнее)


                                          1. vintage
                                            22.03.2019 18:05
                                            #19927244
                                            +1

                                            В случае MobX так делать надо всегда.


                              1. JustDont
                                22.03.2019 15:42
                                #19926572

                                Это конечно камень в огород мобх, потому что если б enforceActions по дефолту было бы в 'always' — этого бы не было. Но vintage вам уже собственно всё подправил одной строчкой.

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


                                1. tehSLy
                                  22.03.2019 17:26
                                  #19927066

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


                                  1. JustDont
                                    22.03.2019 17:31
                                    #19927094

                                    Вот именно. И можно так же пользоваться той же mobx, и не основываться на магических геттерах и сеттерах. Или самому всё написать, некоторые прям таки обожают закатывать солнце вручную.

                                    Я просто не понял, к чему был ваш аргумент. В ногу можно выстрелить? Да конечно можно. Везде можно. И с голой декларативщиной тоже можно.


                                    1. tehSLy
                                      22.03.2019 17:51
                                      #19927178

                                      Как пользоваться мобиксом без геттеров и сеттеров?


                                      1. JustDont
                                        22.03.2019 17:57
                                        #19927210

                                        Вот так. Как и в любой другой парадигме реактивного программирования.


                      1. VolCh
                        22.03.2019 11:59
                        #19925176

                        Вы так говорите, как будто императивное программирование — это что-то плохое :)


                        1. tehSLy
                          22.03.2019 12:11
                          #19925260

                          Считаю, что ему место в более низкоуровневых вещах, чем в проектировании интерфейсов)


                          1. VolCh
                            22.03.2019 13:17
                            #19925644
                            -1

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


                          1. JustDont
                            22.03.2019 15:57
                            #19926646

                            Это что-то из серии «если у меня уже есть микроскоп и он довольно тяжелый, то молоток мне уже не пригодится».

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

                            Все совпадения с реальными случаями, разумеется, вымышлены.


                            1. tehSLy
                              22.03.2019 17:20
                              #19927038

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

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


                              1. JustDont
                                22.03.2019 17:28
                                #19927078

                                В большинстве кейсов, затык в производительности

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

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

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


                                1. tehSLy
                                  22.03.2019 17:35
                                  #19927112

                                  На данном этапе — реконсил и модификация DOMa самые тяжелые)

                                  Приведите пример кода, который в декларативном виде отъедает много памяти, а в императивном — нет)
                                  До этого, кейс слишком космический)


                                  1. JustDont
                                    22.03.2019 17:37
                                    #19927128

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


                                    1. tehSLy
                                      22.03.2019 17:43
                                      #19927152

                                      Да, только поинт про утечку памяти, если писать код декларативно — не я привел)
                                      Чьи утверждения после этого более голословны нужно бы проверить)

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


                                      1. JustDont
                                        22.03.2019 17:50
                                        #19927176

                                        Да, только поинт про утечку памяти, если писать код декларативно — не я привел)

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

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

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

                                        Вот именно. И возвращаясь к вашему аргументу выше по ветке — не «императивщине не место в интерфейсах», а «всё зависит от того, как написать».


                                        1. tehSLy
                                          22.03.2019 18:02
                                          #19927226

                                          Не утечку, а перерасход.
                                          Сути не меняет, тащемта, не я утверждал это

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


                                          1. VolCh
                                            22.03.2019 18:50
                                            #19927448
                                            -1

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


                                  1. vintage
                                    22.03.2019 19:17
                                    #19927538

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


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


            1. RomanPokrovskij
              22.03.2019 01:15
              #19923390

              «Хороший архитектор не станет брать...». Выбирает не архитектор, а выбирают архитектора. Архитектор это и есть архитектура.


              1. evil_random
                22.03.2019 04:33
                #19923662

                Вы меня запутали. Если архитектор это архитектура, то он и создаёт её (архитектуру), подбирая нужные инструменты.


                1. RomanPokrovskij
                  22.03.2019 05:43
                  #19923726

                  Если кому-то важны сроки подберут другого архитектора. Подходящий архитектор это человек не со знаниями о стеках, а со стеком от и до, т.е. с реально работающим проектом причем на 75% похожим на тот который нужно сейчас построить. Допустим это у него не первый стек и не первый проект — но он уже отчасти забыл предыдущий, отчасти технологии так ушли вперед что нет смысла возвращатся. Во время проекта хорошо бы до последних версий обновится и всё… «Я прочел книжку о фреймворки» — возьми с полки пирожок, но архитектуры у тебя на начало проекта нет. В вебе так.


          1. nuit
            22.03.2019 03:31
            #19923590
            +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. vintage
              22.03.2019 05:58
              #19923742

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


              1. nuit
                22.03.2019 08:25
                #19923934

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


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


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


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


            1. duodvk
              22.03.2019 14:49
              #19926216

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

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


              1. nuit
                22.03.2019 14:55
                #19926270
                +1

                medium.com/the-vue-point/vue-2-0-is-here-ef1f26acf4b8

                «The rendering layer has been rewritten using a light-weight Virtual DOM implementation forked from snabbdom»


          1. Raspy
            22.03.2019 08:19
            #19923920

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

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


            И это самые безобидные проблемы «кровавого микросервисного интерпрайса» в мире фронтэнда.


            1. serf
              22.03.2019 10:21
              #19924492
              +1

              Может вам web components пощупать с таким зоопарком?


              1. Raspy
                22.03.2019 20:15
                #19927742

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


            1. vintage
              22.03.2019 10:37
              #19924606

              Отсюда невозможность делать нормальные шаренные компоненты. Если и получается сделать, то это жуткий урод с несколькими реализациями под разные версии библиотек (у нас в фирме есть ангуляры от 1 (который angularJS), до 7. Причём ни реакт, ни vue особо бы не решили этих проблем);

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


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


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

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


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

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


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

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


              1. babylon
                23.03.2019 05:29
                #19928942

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

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


                1. vintage
                  23.03.2019 11:05
                  #19929518

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


                  1. babylon
                    24.03.2019 09:00
                    #19933260

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


            1. VolCh
              22.03.2019 10:38
              #19924608

              А можно пример «микросервиса с GUI-ями»? Как-то внутренний парсер ломается.


              1. Raspy
                22.03.2019 11:38
                #19925018

                Ну тут GUI это обобщённо Graphical User Interface, речь в частности про Гипертекстовые Интерфейсы в браузерах. По привычке заиспользовал термин GUI (У нас в фирме есть до сих пор консольные интерфейсы, на флексе, десктопные и т.д.)


                1. VolCh
                  22.03.2019 12:01
                  #19925190

                  Я не понимаю как микросервиc может быть с GUI. Вернее зачем он такой нужен.


                  1. vintage
                    22.03.2019 12:03
                    #19925210

                    Микросервис авторизации, микросервис платежей, микросервис корзины, микросервис чатов… Я тут уже давал ссылку на встраиваемый микросервис редактирования компонент.


            1. ganqqwerty
              22.03.2019 13:06
              #19925592

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


              1. Raspy
                22.03.2019 20:25
                #19927784

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


  1. FreeBa
    22.03.2019 00:35
    #19923280

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

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

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

    Но это не значит, что бэкенд врос на одном месте и не движется. Вспомните появление дотнета, меньше чем за 10 лет, он смог отгрызть у явы 30% рынка. Да, за ним стоял микрософт, но он стоял и за J# о котором сейчас помнят два с половиной олдфага. Так что если сегодня появится технология способная потеснить три столпа энтерпрайза (ява, шарп, кресты) — она найдет свой угол. Просто самим фактом.


    1. transcengopher
      22.03.2019 16:07
      #19926702

      C# не только отгрыз у явы рынок — он ещё и саму яву заставил быстрее шевелиться, и в результате обновления и улучшения становятся заметны уже не только программистам, но и конечным пользователям. Вон уже и паттерн-матчинг где-то в обозримом будущем появился, и немного меньше причин всё выбросить и переписать на C++.


  1. PaulMaly
    22.03.2019 01:17
    #19923398

    Считаю что SvelteJs один их самых недооцененных фреймворков на данный момент. А уже Svelte 3 вообще космос. В прочем, почему-то редко проекты Рича Харриса становятся сильно популярными, только разве что Rollup. И то, как и в случае с Реакт, Webpack ему не победить. Не умеет он видимо в маркетинг и корпорации тоже не спешат помогать. А потом читаешь статьи из разряда «Как мы пилили примитивный компонент, используя react/redux/reselect/recompose и поверх еще rxjs», и грустишь.


    1. serf
      22.03.2019 10:24
      #19924504

      Реакт и вебпак исторически были прорывными шутковинами и этот факт из истории не убрать. Rollup и SvelteJs не выглядят прорывными, но тем не менее звезд там все равно много и они по свойму популярны. Svelte насколько я понимаю в некоторых областях очень применим, если допустим виджед куда-то внедрить нужно посторонний при этом не тянуть с собой фреймворки.


      1. PaulMaly
        22.03.2019 12:05
        #19925218

        Ну да, это всего лишь первый (и пока единственный) бандлер с нормальным tree-shaking’ом и первая (и вероятно пока единственная) реализация МИФ с полной AoT компиляцией.

        Не то что React с vdom и компонентами, которые ещё в 2012 году уже были в Ractive. Или webpack, до которого конечно не было ни browserfly, ни других. Прорыв прямо.


  1. RomanPokrovskij
    22.03.2019 01:19
    #19923400

    А можно углубится в проблему у «Babel-плагинов нет асинхронности» — она названа, но в чем проблема то?


    1. evil_random
      22.03.2019 04:32
      #19923660

      Вы правда не видите проблемы в отсутствии асинхронности?


      1. vintage
        22.03.2019 05:53
        #19923738

        Я не вижу. Ну кроме несоответствия текущему хайпу на разноцветные функции.


      1. RomanPokrovskij
        22.03.2019 06:05
        #19923746

        Что касается «отсутствия асинхронности в плагинах», я не понимаю о чем речь. Где она отсутсвует. Вынужден гадать. В вызове плагинов? В самом плагине в вызове io? В представлениях который генерирует плагин? И что там стало недоступным из за отсутсвия асинхронности? Что касается «отсутствия асинхронности в вакууме» то это действительно не проблема вообще.


        1. Iskin
          22.03.2019 17:04
          #19926946
          +1

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


          1. RomanPokrovskij
            22.03.2019 17:54
            #19927190
            -1

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


            1. Iskin
              22.03.2019 18:01
              #19927218

              Плагин может читать с диска или вызывать другие инструменты.

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

              Или, например, плагин может читать/писать на диск какой-то кеш.


              1. RomanPokrovskij
                22.03.2019 18:16
                #19927312

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


                1. Iskin
                  22.03.2019 18:25
                  #19927352

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


    1. Iskin
      22.03.2019 17:03
      #19926944

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


      1. vintage
        22.03.2019 17:21
        #19927042

        1. Для клиента это может и проблема, но на бэкенде есть node-fibers.


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



        1. Iskin
          22.03.2019 17:31
          #19927092

          1. Костыль. Почему не сделать нормальный асинхронный API для плагинов?
          2. Ты неправильно тестируешь. Запусти много задач, которые будут читать диск или что-то ожидать от системы. Асинхронность позволит другому JS-коду выполняться, пока твоя функция ожидает данные от файловой системы или сети. Без асинхронности вся виртуальная машина будет заблокирована одним HTTP- или IO-запросом. Но на математике или на одной функции результата не будет — ты прав.


          1. vintage
            22.03.2019 19:54
            #19927682

            1. Наоборот. Почему не завести нормальные сопрограммы в браузеры?)
            2. Я изначально сделал свой сборщик асинхронным, но работал он медленно. Потом перевёл его на синхронную модель и он стал летать. Всё дело в том, что ссд диски очень быстрые, а перед ними ещё и дисковый кэш операционной системы. А асинхронные функции — штуки не бесплатные и плохо оптимизируются. Ну вот, человек бенчмаркал и получил разницу в 3 раза: http://qaru.site/questions/2410357/moving-100000-files-in-nodejs-sync-async-performance-and-speed


            1. Iskin
              22.03.2019 22:03
              #19928098

              Этот бенчмарк очень синтетический. Он использует блокировку по одному и тому же ресурсу.


  1. RomanPokrovskij
    22.03.2019 01:40
    #19923452
    +1

    "webpack — это один из самых заброшенных проектов. Например, css-loader.." а можно другие примеры не из мира `test: /\.(scss|css)$/`? Ну понятно что css и webpack это вообще отдельная история. Умный в гору не пойдет.


    1. justboris
      22.03.2019 02:27
      #19923524

      А разве этой одной причины мало? Удивительно, что инструмент со словом "web" в названии не может нормально работать с CSS. К 5й версии пытались что-то улучшить, но в конечном итоге отказались.


      1. RomanPokrovskij
        22.03.2019 06:13
        #19923758

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


    1. Iskin
      22.03.2019 17:04
      #19926948

      Документация для плагинов — тоже довольно плохая.


  1. evil_random
    22.03.2019 04:31
    #19923658

    Сборщики и React задали тон: современный веб сейчас торморзит ужасно, порой даже почти также как во времена dial-up. И если во времена dial-up в основном картинки грузились долго, то сейчас «хороший сайт» блокирует весь процесс. Зачем фейсбуку 2.2 Мб яваскрипта на главной? Фильмы они туда зашивают что ли. Как они смогли сделать так, что их сайт тормозит даже core i7/16 Gb RAM/SSD? Майнят потихоньку?

    Одно время только в веб было комфортно находиться: когда начал появляться ADSL, но люди ещё не включали 10 мб (или сколько его там) momentjs только для того чтобы один раз дату отформатировать. А из статьи я узнал что оказывается ещё и разработчики браузеров в этом замешаны.
    Сейчас каналы позволяют хоть сотни мегабайт пропускать и всем стало по барабану на размер кода. Теперь «Hello World» весит один мегабайт и на несколько секунд укладывает процессор на лопатки при инициализации.

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

    Было бы интересно, если бы гугль додумается сайты маркировать индексом легковесности.


    1. epishman
      22.03.2019 09:56
      #19924344

      Я тоже вот думаю, если взять на сайте фейсбука посчитать количество используемых уникальных веб-компонент, и сравнить с количеством промежуточных абстракций используемого фреймворка — не окажется ли первое число меньше второго? А если так — не проще было ли было эти компоненты в HTML сверстать? Нам говорили, что создание новых абстракций уменьшает количество уникальных сущностей, которые нужно держать в голове, но похоже все наоборот — наши бедные головы должны помнить о каждом компоненте, их взаимодействии, о синтаксисе фреймворка, не забывать стандарты HTML/JS и т.д. Проблема фронтенда только лишь в том, что ленивые жирные дяди из W3C не развивали JS десятилетие, а сейчас, когда спохватились, все уже столько костылей наговнокодили.


    1. justboris
      22.03.2019 11:08
      #19924828

      Сборщики и React задали тон

      не думаю, что React тут как-то выделяется. Есть Gmail, написанный на технологиях на 7 лет старше реакта и тормозной ужасно.


    1. nmrulin
      22.03.2019 16:44
      #19926846

      Так тяжеловестность как раз и результат того, что постоянно вводили новомодные штучки. Если бы на чём-то одно остановились, то пошла бы оптимизация. А сейчас не до того, надо туда перебежать, потом совсем в обратную сторону в погоней за модой. Собственно даже бэкенд грешит гонками за новомодностью. Но если бы люди каждый год переходили, с С++, на С--, на следующий год на C##, а потом на С'', то можно было бы заранее выбрасывать такой код на помойку. Хороший язык это который и отец «в школе» учил и сын :-). Тогда есть огромная база хорошего кода на все случаи жизни. С/С++ тому пример.


    1. botyaslonim
      23.03.2019 00:02
      #19928500

      React причём? Он лёгкий и быстрый.
      NPM-среда, пакеты с зависимостями (сегодня только удалял «лёгкую» страничку на Ангуляре с 1200 папками и 70+ тыс файлами в node_modules)и, как следствие, ужасно раздутые бандлы


      1. evil_random
        23.03.2019 05:44
        #19928958

        В каком это он месте быстрый? Разве он уже может быстро отрендерить список из 1000 айтемов? Когда я последний раз задавался этим вопрос время рендера колебалось между 300 и 500 мс что очень много.


  1. inf
    22.03.2019 09:35
    #19924176

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


    1. evil_random
      22.03.2019 12:09
      #19925248

      Да-да. Microsoft так тоже говорил, когда пятого осла релизил.


    1. Iskin
      22.03.2019 17:08
      #19926976
      +1

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


      1. inf
        22.03.2019 17:14
        #19927014

        Ну теперь правит мнение сообществ, в не истина. Куда деваться?


  1. transcengopher
    22.03.2019 14:10
    #19925950

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

    В чём, собственно, проблема-то? Если на рынке нет новинок — значит, имеющийся спрос удовлетворён. В данном конкретном случае (так как речь идёт о языке — инструменте для решения неких задач бизнеса), это значит, что это не платформа стагнирует — это принципиально новых проблем у бизнеса не появляется, а существующих инструментов с лихвой хватает на good-enough решение. Проблемы конкретно в Java сконцентрированы на самой передовой, где действительно есть запросы бизнеса, например, обработать запросов ещё на миллион (но лучше — десять) в секунду больше, чем сейчас. Вот на этой целине сейчас действительно бурления, от новых фреймворков до языков или кастомных сборок виртуальных машин. Даже хорошо забытые парадигмы программирования прикручивают.


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


    1. Iskin
      22.03.2019 17:08
      #19926980

      Проблема в том, что из-за моды все берут ожно и то же решение, даже для задач, где оно не подходит


      1. transcengopher
        22.03.2019 19:23
        #19927560

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

        Я, конечно, могу сам накидать примеров из любой кодовой базы, где из-за моды все стали писать list.stream().forEach(...) вместо любого другого варианта итерации, или бесконечные вопросы на StackOverflow, мол, "вот у меня работающий код, а как мне переписать всё на C++ Stream". Но тут масштаб не тот немного.


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


    1. VolCh
      22.03.2019 18:26
      #19927360
      -1

      Бурление происходит, по-моему, по запросу бизнеса: ещё нельзя достичь хотя бы двух из трёх быстро, качественно, дешево.


      1. transcengopher
        22.03.2019 19:30
        #19927586

        Просто бизнесу нужно показать Project Management Triangle и объяснить, что когда по условному проекту Х треугольник достигнет желаемых ими измерений, у конкурентов уже несколько лет будут
        X + N >>> X.


        Вообще странно, что это по-прежнему не общеизвестная штука, тем более в нашей профессии.


  1. fetis26
    22.03.2019 15:48
    #19926602

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


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


    В мире Java, на которые все ссылаются, не все тихо, Kotlin набирает обороты, как примерно TypeScript в мире фронтенда, а с ним и новые фреймворки. Я думаю так же будет и во фронте. После затишься появятся и новые фреймворки, и новые подходы. Все просто устали и хотят отдышаться.


    1. transcengopher
      22.03.2019 16:30
      #19926790

      Kotlin/Java неправильно сравнивать с TypeScript/JavaScript.
      TypeScript это надстройка над JavaScript, целиком наследует семантику и (если я правильно понимаю) не имеет собственной стандартной библиотеки.

      Тогда как Kotlin — это самостоятельный язык, который, как и Java, компилируется в JVM-байткод… но может и не компилироваться, и ничего важного при этом, по сути, не потеряет.


      1. fetis26
        22.03.2019 22:43
        #19928226

        ну JS сам по себе тоже стандартной библиотекой не блещет, поэтому обвинять в этом TypeScript как-то странно.


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


    1. Iskin
      22.03.2019 17:10
      #19926990
      +1

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


    1. PaulMaly
      22.03.2019 20:09
      #19927716

      Я, например, не собираюсь изучать Vue. Просто не понимаю, что он может мне дать чего нет сейчас в Angular.

      Мне показалось что ключевая мысль по поводу Vue была вот в чем:

      … хотя у него решено всё, за что мы критикуем React.

      Если для вас Angular итак идеален и Vue не решает никаких проблем Angular лучше, тогда действительно, зачем переходить? Не нужно.


      1. fetis26
        22.03.2019 22:46
        #19928234

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


        1. PaulMaly
          23.03.2019 11:25
          #19929572

          В том то и дело, что изучать новое и уж тем более переписывать старое нужно только если свербит и лень писать сложно и долго на том инструменте, который уже освоил. Если же у нас нет проблем с Angular и вам лень учить новое и преимущества не понятны, то и не за чем. Условно говоря, чтобы на React получить DX близкий к Vue из коробки, нужно ещё освоить как минимум Mobx. Вот это должно быть лень и эта лень как раз может спровоцировать изучить Vue. Если в Angular уже итак есть все что вам нужно и не смущают его размеры, то и Vue вам не нужен.


          1. vintage
            23.03.2019 12:46
            #19929892
            +1

            Обычно фразы в духе `у нас нет проблем с ${чтоТо}` являются следствием синдрома Даннига-Крюгера приправленного Стокгольмским. Человек просто не знает, что может быть меньше боли, поэтому предпочитает существующую боль не замечать. В особо запущенных случаях — требовать от других технологий того же уровня боли.


            1. fetis26
              23.03.2019 22:31
              #19932356

              легко :)


            1. PaulMaly
              23.03.2019 23:56
              #19932584

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


              1. vintage
                24.03.2019 08:43
                #19933236

                Есть разные классы проблем:


                1. Невозможно сделать ${чтоТо}.
                2. Чтобы сделать ${чтоТо} нужно написать много кода.
                3. Чтобы сделать ${чтоТо} нужно решить головоломку.
                4. Легко сделать ${чтоТо}, но потом это ${чтоТо} приходится долго дебажить.
                5. Легко сделать ${чтоТо} медленным, но сложно потом оптимизировать.
                6. Легко сделать ${чтоТо} и не менее легко ${чтоТо} ненамеренно сломать.
                7. Легко сделать ${чтоТо}, но сложно его потом использовать.
                8. Легко сделать ${чтоТо} в одном проекте, но сложно воспользоваться им в нескольких.

                Многие из них человек не осознаёт. А те, что осознаёт считает свойством платформы / предметной области / хорошей практики.


          1. fetis26
            23.03.2019 22:30
            #19932352

            что такое DХ?


            1. PaulMaly
              23.03.2019 23:54
              #19932574

              Developers eXperience


  1. Gorthauer87
    22.03.2019 21:30
    #19927986

    Вообще wasm развивается и в перспективе серьезно встряхнет фронтенд.


    1. justboris
      23.03.2019 13:59
      #19930158

      Судя по тому, что размеры wasm-бандлов начинаются от 400 Кб и до 2 Мб, пользователям придется грузить еще больше данных. В такой ситуации даже 100-килобайтный React покажется маленьким.


      1. Gorthauer87
        23.03.2019 14:11
        #19930208

        Это в любом случае будет лучше в будущем, не в плане обьема, а в плане того, что этот wasm код можно быстро откомпилировать в нативный и сайты смогут работать быстро. В конце концов разбирать байткод намного быстрее, чем высокоуровневый js


        1. justboris
          23.03.2019 14:28
          #19930280

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


          1. Gorthauer87
            23.03.2019 15:26
            #19930512

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


            1. sumanai
              23.03.2019 22:27
              #19932336

              Или сделать общий репозиторий wasm модулей и не качать одно и тоже по 10 раз.

              С JS такое толком и не сделали.


              1. Lailore
                24.03.2019 01:47
                #19932910

                ну как же. CDN разве не про это?


          1. serf
            24.03.2019 10:33
            #19933430

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


  1. rexen
    23.03.2019 10:26
    #19929402

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


  1. lega
    24.03.2019 01:16
    #19932832
    +1

    нет, не занимаетесь, не создавайте новые опенсорс-проекты...
    Я пришел к выводу, что опенсорс проекты нужно делать «just for fun», а ответственность за проекты должна уже обговариваться.

    Про деньги, иногда возникает мысль что «художник должен быть голодным», пример команда Angular — осваивает деньги и должна выдавать какой-то результат, в итоге разработчики, которые не «едят» свой продукт, генерят кучу кода, тем самым создавая неповоротливого монстра, или Meteorjs — нанимали «джунов» для «освоения» раундов, подобно выглядит и Vue где первая версия была простая, но после потока денег появилась ответсвенность «в развитие», и он тоже начал обрастать, медленно превращаясь в монстра (хотя это только взгляд со стороны, на vue уже давно не смотрел), с другой стороны, без денег проект может просто умереть.

    Ещё есть грустные примеры с MongoDB и Amazon, или то что PHP вытянул MySQL, в результате автор mysql разбогател, а автор PHP не особо, или то что Марк Цукерберг разбогател воспользовавшись этим самым PHP, а получил ли что-то автор?

    Вообщем OpenSource это не про деньги, и в этом плане что то тут «сломано», т.к. как раз благадоря open source появились гуглы, фейсбуки и подобные…