Pull to refresh

Comments 73

Действительно, зачем использовать последние достижения оптимизации, зачем нам эти Vue, React, Flutter, если любое приложение можно написать на чистом Javascript самой первой версии — подумаешь, это всего лишь займет в 20 раз больше времени…

Попробуйте написать комплексное кросс-платформенное приложение не на Flutter, а на чистом JS в одиночку за 1 месяц, и поймете что тренды не просто так появляются — на чистом JS у вас через месяц будет приложение готово только 5%, а на Flutter уже будет полноценное работоспособное красивое приложение, работающее на нескольких платформах
UFO just landed and posted this here

Яро интересуюсь флаттером (в основном его с++-движком), но для веба ещё не оптимизирован.

На мастере с FLUTTER_WEB_USE_SKIA=true работает уже очень плавно. Со скроллом и анимациями проблем вроде бы нет. Потенциал большой.

Как мне кажется "на мастере с FLUTTER_WEB_USE_SKIA=true" означает, что технология находится в самом начале графика из статьи, и сама статья показывает, почему стоит избегать таких технологий, пока они не вырастут во что-то серьезное.

Без тех, кто поддался хайпу, технология рискует не вырасти во что-то серьёзное. Новым технологиям нужны альфа-бета-тестеры :)
В статье речь о том, что серьёзеным, большим проектам надо подождать, пока технологию обкатают одиночки на пет-проектах.
Тут скорее вопрос не в том, чтобы не пользоваться новым, а в том, чтобы не кидаться бездумно на хайповые тренды. Причин пользоваться менйстримом может быть много, но главная — все же это поддержка старых технологий, которые теряют свои экосистемы и потихоньку уходят и перестают поддерживаться. Но это больше об устаревание технологий чем об использовании новых.
На чистом js вы не напишите кроссплатформенное приложение без использования какого-л. фреймворка (или самостоятельного написания оного, но уже не на js), соотв. это упрощает задачу и получается, что вся разница лишь в языках js vs dart и flutter vs используемый фремворк. Поэтому сомневаюсь, что только 5% будет готово, как бы не 95, а то и все 100
и поймете что тренды не просто так появляются

Проблема не в том, что тренды появляются, а в том, что они часто меняются.
Поправлю — «не работающее» нормально ни на одной из платформ.
Флаттеру уже года 2-3, Реакту так и вообще лет 6. Они никак не вписываются в «новомодные» технологии.

Так речь про фичи в них, нигде не говорилось, что реакт — "новомодная технология"

действительно, зачем использовать стабильные версии, если можно использовать самые новые тренды, которые сомнительного качества, с кучей багов и падением производительности?
Пишу сайты на php+jquery, но однажды решил изучить что-то новое, мне порекомендовали Angular. Пока я читал документацию и продолжал делать сайты на jquery мне сказали, что Angular уже устарел и нужно использовать Angular2 потому, что он быстрее, но через некоторое время и Angular2 устарел и появился и что VUE значительно быстрее и лучше…
В результате, у меня сложилось впечатление, что новые веяния в JS, это не пригодное для маленьких компаний поделки требующие больших доработок. Продолжаю писать сайты на php+jquery.
Vue появился 7 лет назад. Эта тройка фреймворков (вью, реакт, ангуляр) уже вышла на «плато продуктивности», как мне кажется. Это не значит, что надо от jquery отказываться — они решают разные задачи.
UFO just landed and posted this here
вроде скоро vue3 выйдет, а если сейчас начать использовать vue2, тогда скоро придётся переходить на vue3?
UFO just landed and posted this here
Это зависит только от соотношения скорости изучения нового и скорости появления этого нового ;)
У реакт-хуков, раз уж статья затронула эту тему, масса недостатков. Я вернулся на классы и в массе случаев это удобней. Стоит ли сейчас писать статью на пике хайпа, чтобы триггернуть фазу «избавление от иллюзий»?
UFO just landed and posted this here
Можете перечислить основные недостатки, которые заставили вас вернуться обратно на классы?
Да, очень кратко аргументы приводил в этом треде, но без примеров реального кода и прямого сравнения альтернативных реализаций сложных компонентов выглядит недостаточно обоснованно. В целом можно разбить аргументы на семантические (синтаксис, основанный на соглашениях), анти-best-practice (смешение синхронного и асинхронного кода, сайд-эффекты в колбэках, раздувание чистых функций и смешение ответственности), сложностей в композиции (т.к. нет доступа к общим props и context, приходится передавать их в каждую функцию напрямую, что приводит к запутанному клубку), деградации перфоманса (т.к. приходится либо обкладывать многие части useCallback / useMemo, либо логика будет пересоздаваться на каждый ререндер и не будет работать сравнение по ссылкам).

Есть и плюсы, конечно, у этих хуков, но реализовав несколько проектов с очень сложными компонентами (с композицией десятков и сотен хуков), первоначальное желание с ними работать пропало. Я не готов обсуждать детально в комментариях эти аргументы сейчас, так как сам не проводил тщательное параллельное сравнение, это просто навскидку.
UFO just landed and posted this here
Почему же не сплю? При средней продуктивности 2к строк качественного кода в неделю сотня хуков набирается за рабочий месяц, при использовании хуков в виде замены классовых методов. Ну и побольше, чем год уже хукам, если статью по ним писал в апреле 2019 уже по релизной версии Реакта)
Про мое умение компонировать сейчас не очень хочется говорить, если буду писать статью, то представлю полдесятка концептов композиции функций, но сделаю вывод, что по удобству разработки все они не дотягивают до классовых методов. Пока что тут нечего обсуждать.
Посмотрел видео, про контекст там не говорится, там про передачу стейта несколькими путями, кроме контекста и инджекта, а я использую как раз последние в продуктовой разработке.
UFO just landed and posted this here
context hell — это наверное при использовании их в иерархичном подходе вместо глобального? Тогда поддерживаю, это нелепость. Функционал разный — wysiwig, тултипы, селекты, графики и системы из них, сложные галереи с динамическими раскладками, таблицы со всякими сортировками-дозагрузками, календари ну и что там еще фронтенд-разработчикам прилетает. Стараюсь вникать в сложные проекты, так как и оплата там соответствующая, поэтому от недостатка количества функционала не страдаю — бывают документации по десяткам страниц на компонент и чтобы работало на десятках устройств с разным отображением)
UFO just landed and posted this here
При работе с асинхронно дозагружаемыми компонентами и их внутренним состоянием я предпочитаю мерджить его в глобальный стейт для универсальной схемы работы. То, что при загрузке 5 страниц (каждая из них — условно отдельный фронт) у меня будет единый стейт, в котором хранится их состояние, вместо 6 разных стейтов (на каждую страницу + рут) — это большое преимущество.

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

  useOnOpen(params);
  useScrollToCurrentOption(params);
  useClickOutside(params.selectRef, () => handleOutsideClick(params));
  useSetValidation(params);
  useDisabledChange(params);
С начала 2020-го постепенно, осторожно перевожу существующие проекты на хуки, но еще пока рискую начинать использовать их в новых (больше из-за того, что начинает страдать скорость разработки). И пока остается redux с коннекторами, еще более-менее приятно работать с глоб. стейтом. Но когда пытаюсь избавиться от него в пользу контекста с селекторами (хуками), то сталкиваюсь с тем, что вы написали выше: длинный перечень useCallback/useMemo. Пытаюсь скомпоновать. Плохо удается.

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

Я вот смотрю в сторону effector, как замену redux. Пока только на пэт проекте пробую — вроде все хорошо.

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

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

До этого было много всего, начиная от различных не-ИТ-профессий, и заканчивая SEO/маркетингом в том же ИТ.

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

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

P.S.
С чем это связано — для меня загадка. Может быть, так решается внутреннее желание отрефакторить старый код. Ведь если просто сказать — «надо все переписать» — то нужно будет признать, что код был плохой (и сразу падает тень на тех, кто его писал). А если рефакторинг делается под предлогом «монолит это плохо, вот сейчас все перепишем на микросервисы и будет круто» — то звучит уже не так стыдно.
Мне кажется Вы немножко путаете причину и следствие.

Представлю мою гипотезу про «с чем это связано».

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

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

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

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

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


По теме статьи – если брать шире, речь вообще не про хайп, а про архитектуру решений.


Люди пользуются инструментами чтобы решать задачи быстро и качественно. Проблема в том, что в современных приложениях почти отсутствует проектирование архитектуры, потому что поставляются сильно связанные решения (тот же Angular и его экосистема). Эти Реакты, Vue, и прочее должны быть заменяемыми инструментами в решении, как и axios, чтобы в случае проблемы с инструментов его можно было просто заменить без переписывания системы.


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


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


Поэтому, имхо, нужно работать на трендовом инструменте, пытаясь по-возможности выкрутить опции в сторону абстракции.

> Хороший абзац с очень известной технической книги

Вроде бы абзац ИЗ книги, а не С?

Просто достала глобальная замена «из» -> «с». «Стрелять с автомата», «сделанные со старых автомобильных шин» и т.д.

Обычно обращаю внимание на мелочи в орфографии, но про это даже не знал, спасибо! )

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

Есть сейчас достаточно большое приложение на RN, переход на useEffect вместо componentDidUpdate позволяет все таки сделать код гораздо чище

Просто решили так
— Сначала, когда нужно внести правку в какой-то из компонентов UiKit переводим его на функциональный стиль
— Затем, понемногу, переписываем все экраны.

А переходить со связки Redux/Redux-Saga на какой-нибудь Recoil смысла нет вообще

Recoil так же не понравился.
Что скажете на счет effector?
Есть одна штука, вот такой код просто пишете и это работает.
this.isFetching = true;
const response = await apiRequest(`GET /items`);
this.items = response.items; 
this.isFetching = false;

Что скажете?
Вы хотите писать вот такой код и чтобы все работало?
fetchData = async () => {
     // Компонент который использует эту переменную перерендеривается и показывается  лоадер
    this.isFetching = true;
    // Получаем список чего-нибудь из АПИ
    const response = await apiRequest(`GET /items`);
     // Компонент который использует эту переменную теперь имеет данные для     
    рендера
    this.items = response.items; 
     // Компонент который использует эту переменную перерендеривается и убирает     лоадер и выводит список из переменной items
    this.isFetching = false;
}

Как это касается моего вопроса?)
Если знаете подводные камни effector — буду рад услышать, что бы опробовать самому.
То, что вы сторонник mobx я уже понял)
Но пока что он меня так не впечатлил.

То есть это избыточно, сложно и т.п. да? А в effector все гораздо проще и компактнее?
this.isFetching = true;
const response = await apiRequest(`GET /items`);
this.items = response.items; 
this.isFetching = false;

Я не говорил проще, и я не говорил компактнее (хотя скорее всего так и есть).
Если вы хотите сказать, что в mobx компактнее — окей)


По существу — вы сталкивались с подводными камнями в effector? Поделитесь таковыми, пожалуйста.

Таки смысл использовать заранее кастрированный и неудобный инструмент? Когда есть тот, который решен этих недостатков.
Подводные камни — иммутабилен, неудобен в использовании, примитивен как палка, уровень раскрытия возможностей JS — 0%.
Если вы хотите поднасрать кому нибудь в проект, то да, притащить это будет хорошая идея.
В чем неудобство и кастрированость то собственно?)
Иммутабелен
не уверен, что это минус.
Неудобен в использовании
субъективное суждение
Примитивен, как палка
так вы определитесь, он либо сложный, либо примитивен, как палка)
Уровень раскрытия возможностей JS — 0%.
почему не -100% ?)

Ну и к слову, стоит ожидать от вас статьи «effector vs mobx vs ...»?
С удовольствием бы прочел!
В чем неудобство и кастрированость то собственно?)

Если для вас это не очевидно, то извиняйте, разговор ни о чем) Тем более вы говорите что знакомы с MobX и имеете такое мнение, для меня это нонсанс) Видать все таки не знакомы на самом деле.
И снова вы за своё?) Зачем выдавать свои субъективные суждения за данность?)

Где я говорил, что знаком с mobx?
Я вообще говорил, что mobx плох?)
Перепутал вас с другим, тоже про effector спрашивал, ну не суть) Тем более вы даже не познакомились с другими решениями для управления состоянием. Если бы познакомились не было бы вообще этого треда)
Так я и знакомлюсь — в этом же и была суть моего вопроса) Я смотрю варианты и пробую.

Стоит ожидать от вас статьи-сравнения?) А то пока что аргументов против толком не было — только вкусовщина.
Писать статьи лень, гораздо быстрее будет вам понять что лучше/удобнее и т.п. Это просто сделать аналоги
Раз
codesandbox.io/s/interesting-snyder-v8k4o
И два
codesandbox.io/s/affectionate-keldysh-7mpwt

На effector'e и вообще на чем душе угодно и сравнить код с MobX'овским и сделаете выводы
Вы не разделили строны на глобальный и локальный, у вас оба стора глобальные.

Вариант два я думаю вы так и не сделаете, потому что он не такой мега простой и банальный, и на effector'e вам уже гарантированно не понравится реализация)

А так в целом уже посмотрите на код, ведь очевидно насколько effector выглядит нелепо по сравнению с MobX и это на супер простом и банальном примере не имеющим отношения к реальной жизни, толи было бы хотя бы с примером номер два, который вы не сделали, вот там будет конкретный вырвиглаз) И не забываем, понятия локального стейта и глобального разные, это не одно и то же)

Исходя из вашего комментария, я понимаю, что effector вы даже не пробовали. Почитайте хотя бы о его концепциях.
И мне непонятно, зачем тогда effector везде хаять и превозносить mobx?

Моего опыта с 2012 года с головой хватает, чтобы без применения чего-либо в реальном проекте понимать хлам это или нет. Effector это чистый воды хлам.
Код говорит сам за себя. Такое просто противопоказано применять не в одноразовых проектах где работает более одного человека.
const incr1Fx = createEvent("incr1");
const incr2Fx = createEvent("incr2");
const onTitleChanged1Fx = createEvent("onTitleChanged1Fx");
const onTitleChanged2Fx = createEvent("onTitleChanged2Fx");

const title1Fx = onTitleChanged1Fx.map(e => e.target.value);
const title2Fx = onTitleChanged2Fx.map(e => e.target.value);

const $counter1 = createStore(0).on(incr1Fx, state => state + 1);
const $counter2 = createStore(0).on(incr2Fx, state => state + 1);
const $title1 = createStore("First title").on(title1Fx, (state, e) => e);
const $title2 = createStore("Second title").on(title2Fx, (state, e) => e);

//...
const counter1 = useStore($counter1);
const counter2 = useStore($counter2);
const title1 = useStore($title1);
const title2 = useStore($title2);

Если по аналогии с вашим кодом, в примере с MobX тоже все сделать Inline, то будет так:
class LocalState {
    @observable counter = 0;
    @observable title = "title";
    incr = () => { this.counter++; };
    handleTitleChange = e => { this.title = e.target.value; };
}

class GlobalState {
    @observable counter = 0;
    @observable title = "global title";
    incr = () => { this.counter++; };
    handleTitleChange = e => { this.title = e.target.value; };
}

const globalState = new GlobalState();

///...
const [state] = useState(() => new LocalState());

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

Даже в тупую сравнить кол-во символов:
MobX — 416 сами стейты и 49 инициализация внутри компонента, итого 465 символов
Effector — 600 сами стейты и 155 инициализация внутри компонента, итого 755 символов
40% разница и это в банальном примере, в чем-то похожем на реальную жизнь разница уже будет в разы.

И того, с чего я или ещё кто-то должен выбрать Effector вместо MobX'a? Если он хуже вообще по всем фронтам и параметрам. Да и не реакивный стейт менеджер в принципе никак не может быть лучше или сопоставим с реактивным, потому что это как сравнивать жигули 1980 года и Tesla Model X, и то и другое машина и то и другое может довести от точки А в точку Б, но то как они тебя повезут, и то какие технологии применены, тут уже целая пропасть между ними.
Исходя из ваших ответов — вам все равно что за технология, потому что вы знаете mobx и он автоматически лучше.
Вы своё субъективное мнение выставляете за данность уже, в который раз.

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

Так о каком опыте вы говорите? Беспочвенного хейтерства?
Из разряда:«Красные ягоды несладкие — вот я пробовал клюкву, и она была кислой. Так что клубника так же кислая — не ешьте.»

Количество символов? Вы серьёзно? Более веского аргумента нету? Ах да, вы ж не пробовали — у вас эфемерный опыт.
И так же вы сами решили, что он не реактивный — ну, у вас же опыт.

И как бы effector появился позже чем mobx, так что еще вопрос, кто тут tesla.
И tesla так же сперва не воспринимали всерьёз )…

Но вы и далее продолжайте хейтить то, с чем даже не ознакамливались.

На этом, я считаю, наш диалог окончен. Удачи)
Лол, удачи) Как я уже ранее говорил, если для вас не очевидно что Effector это дно, то увы и ах)
С вашей «очевидностью» без аргументов — спасибо. Пожалуй, такая очевидность мне не нужна.

Во всех инструментах есть плюсы и минусы. Вы же настолько превозносите один инструмент, что даже не разбираетесь с другими. Ну, удачи)
Удачи обосрать кому нибудь проект притащив туда Effector или любой подобный инструмент (они все плюс минус одинаковые, поэтому и относятся к классу «очередной хлам»), учитесь на своих ошибках, мне то что, мне с вами на одном проекте не работать =) Я думаю если вы купите машину с кондиционером, то в жару вы им не будете пользоваться, вам и так будет нормально) Вот такая же аналогия, JS вам дает просто уйму возможностей, а вы используете каплю из этого преднамеренно, попахивает мазохизмом конечно)
Вы прям, как заложник одной технологии. Что ж вы такой заскорузлый?
Аргументов не наводите, зато желчь аж хлещет.
Всё очень спорно;

иммутабилен — это плюс, когда бэкенд весь иммутабилен,
и не надо туда-сюда голову перекючать ради 5% кода на js;

чем более примитивен инструмент, тем проще понять, как он внутри работает;

mobx работает как-бы _интуитивно_, но понять, как он _точно_ работает скорее всего будет сложней;
не все модные возможности JS хочется раскрывать, начиная от слетающего «this», и заканчивая прокси, когда написано одно короткое выражение, а отрабатывает хитрая магия.

Ну, если писать на mobx ежедневно, то возможно есть смысл со всем этим хорошенько разобраться и печатать на 25% символов меньше.

Или тут какие-то принципиальные бонусы?

Если что, я сам пока ни того, ни другого не выбрал.
По-моему, статья подходит к вопросу односторонне: со стороны производителя продукта, его интересов. А потому оценивает переход на новые технологии исключительно с точки зрения того, как они могут улучшить (читай — удешевить) разработку и сопровождение продукта (ну, или повысить его продажи).
Однако большинство программистов являются не производителями, а немными работниками, работающими на производителя. Поэтому объем продаж продукта и оптимизация затрат находятся, в лучшем случае, вне круга их материальных интересов. Интерес у них другой — поднять свою цену на рынке труда. А факт владения модной технологией при прочих равных условиях поднимает эту цену, и весьма заметно.
Так что для программистов, работающих по найму есть прямой материальный смысл следовать модным трендам, несмотря на все те аргументы, которые приводятся в статье.
Автор, рекомендую посмотреть определение слова «тренд» в вики или в словаре. «Тренд» — это основная тенденция (в отрасли, в данном случае). Так в чем основной посыл статьи — следовать или нет основным течениям в отрасли? Конечно да, следовать. «Хайп» и «тренд» — это скорее противоположные по смыслу понятия. А пока, уж извините, я слабо понимаю о чем статья.
Идея понятна, но пример неудачный. Замена axios на fetch позволяет сэкономить 5 гзипованных кб.
Давайте рассмотрим практический пример. Я пользовался axios, это — отличная библиотека. Её код хорошо покрыт тестами, она отличается широкой поддержкой, у неё много GitHub-звёзд и так далее. Однажды мне попалась публикация, в которой дана рекомендация о том, что от axios нужно отказаться, создав собственное решение для загрузки различных материалов.

Мне кажется тут скорее проблема у самого автора.
Sign up to leave a comment.