Либо меня не поняли, либо как раз поняли и обиделись. Я говорил о том, что перевычислять дерево каждый раз и искать изменения — это костыльнейшее решение, которое можно было придумать и написать на коленке как Proof of Concept лет 10 назад. Если я не ошибаюсь, уже в AngularJS была настоящая декларативность. Почему же большинство выбирало изначально костыльное решение, строит поверх ещё ворох костылей и упорно защищает это уродство? Все babel-плагины: JSX, react-css-modules, hooks.macro — это же всё маленькие шажки, пытающиеся сделать императивный React хоть немного декларативным. И даже Vue — продолжение всё тех же идей. Разве не очевидно, что нужно строить нормальное декларативное решение с самого низа?
Удивительная выдержка у Рича — 37 минут говорит о том, что люди должны понимать уже через 5 минут после знакомства с Реактом. Желаю Svelte остановить это костыльное безумие.
Если я правильно понял ваш первый комментарий, вы затронули сразу две темы — и визуальный шум, как точки с запятой, и специальные конструкции, как стрелочки. Насчёт шума я вас полностью поддерживаю. Но я хотел узнать именно про второе. Меня удивляет, что есть люди, предпочитающие писать «function», а не "=>". Пытаюсь понять причину.
Вероятно, люди деляться на тех, кому проще в кванторы, и тех, кому проще в слова. И это очень странно. Потому что смысл абсолютно одинаковый, но короткие специализированные знаки должны считываться и обрабатываться мозгом быстрее. Возможно, что вы недостаточно выработали навык их чтения. Но я встречал других людей, кто предпочитает естественный язык специализированному.
Готовыми ОС, компиляторами и прочим тоже лучше не пользоваться, чтобы всё не было таким огромным? Извините за сарказм, просто эти наезды на зависимости мне кажутся ужасно недальновидными.
Мы уже давно строим пирамидки из кубиков. Пирамидки растут, но на самой вершине у них всегда были маленькие, убогие и кривые недокубики. Когда-то и компиляторы были убогими, а на ассемблере можно было сделать лучше. Со временем опыт накапливается, шишки набиваются и нижние слои зависимостей крепнут и улучшаются. А без этого мы так и останемся на одной и той же ступени развития. Очень хочется взглянуть на программы людей, критикующих современные фреймворки и нагромождения зависимостей. И сказать им о том, что их софт дерьмо. Потому что сегодня абсолютно весь софт дерьмо. Но если игнорировать всё кроме производительности, потребления памяти и занимаемого места на диске то, конечно, можно гордиться своими поделками без зависимостей.
Проблема есть. Она очень серьёзная. Но даже намёки на бегство, вместо решения проблемы, считаю приступными.)
Давайте дружить?) Полностью с вами согласен, хотел только добавить, что мантра «не засовывать логику в шаблон» озвученная в разделе об F-строках ужасно надоела. Это всё продолжение той же истории, что и про @staticmethod и прочую разбивку кода на основе «синтаксиса», а не смысла. Люди с огромной радостью проглатывают идею складывать все компоненты в одну директорию, делать тонкие html-шаблоны и т.д. Потому что так не надо использовать голову. Чуть лучше, но в ту же степь, все эти проверки на количество операций в строчке, количество переменных, методов и классов. Хороший код структурируется на основе логической взаимосвязи его кусков, а не «синтаксиса». Длинное выражение, функция или класс могут в принципе не иметь разбивки на смысловые куски. Тот же вызов username.title() в шаблоне — восхитителен. При чтении мы сразу видим, зачем вызывается метод title. Мы автоматически пропускаем вызов метода, если нас не интересует содержание строчки. Этот вызов логически привязан к шаблону и должен быть с ним как можно ближе.
Для любителей всё возводить в абсолют: это не значит, что весь код нужно писать в одном файле, одной функции и одной строчке. Именно в том и смысл, что какого-то абсолютного, бездумного правила не может быть. Нужно смотреть на логические взаимосвязи.
Для владельцев сайтов капча — просто подключаемый сервис.
Мы же обсуждаем разработку капчи, а не людей, которые подключают сторонний сервис.
То-то в почтовых сервисах Гугла и Яндекса над этим работают целые отделы
Всё-таки для почты эта задача мне кажется сложнее, чем для сайтов. Да и справляются фильтры сегодня весьма хорошо. И с капчой есть «заметный процент промахов и ложных срабатываний». Если точнее — капча справляется гораздо хуже.
Я о том и говорю, что когда-то это было нормальным решением. Но если сейчас капча требует того же ИИ для её создания и доставляет настоящую боль пользователям, то нужно вернуться к изначальной задаче и подумать ещё раз. Для распознавания спама сильный ИИ не нужен. Задача явно не сложнее создания спама. Начнём с того, что у нас изначально есть очень хороший признак для классификации текстов — наличие URL'а. 80% результата уже достигнуто. Дальше уже тренируйте нейронные сети и прочее.
Почему бы не направить усилия на распознавание зловреда вместо того, чтобы мучить людей решением ваших проблем? В статье много написано про выкрутасы с ИИ. Но распознавание спама выглядит куда более простой задачей для ИИ. И обойти защиту значительно сложнее, чем распознавать любую капчу, потому что текст должен быть рекламным. По-моему, это очередной пример, когда настоящую задачу подменяют какой-то технической мурой.
Большое спасибо за подробное разъяснение. Я предполагал, что хуки могут запоминать порядок вызова, но решил, что это и правда слишком нелепо.) Выходит, что решения для передачи колбека в цикле по-прежнему нет. На проблему просто забивают. Ждите пока начнутся тормоза, а потом делайте уродливый компонент-прослойку, передающий в колбек дополнительный параметр. Т.е. самый простой код уже по умолчанию имеет потенциальные проблемы с производительностью. Мир сошёл с ума.
Что если в одной рендер-функции определяются несколько разных колбеков. Переданные массивы могут совпасть и последствия будут ужасны.) Или я чего-то не понимаю?
Не хочется нахватать минусов, но просто не могу сдержаться.
Зачем? Зачем вы едите этот кактус? Как этот ворох костылей мог стать мейнстримом?
Мне повезло, я столкнулся с проблемой переопределения колбеков в самом начале знакомства с React. Больше всего меня поразило, что эта проблема никого особо не волнует. Ок, разработчики Реакта наконец выдали какое-то решение. Но ведь это же редкое уродство. Во второй аргумент useCallback ещё нужно добавить какой-нибудь идентификатор, чтобы мемоизировать несколько разных колбеков. Мемоизатор скорее всего будет жрать память. Всё это громоздко и неудобно.
Конечно, кроме мемоизации другого решения и не найти, если колбек передаётся в цикле. Почему не признать, что подходы Реакта тупиковые? Нет, продолжают костылять: «In the future, a sufficiently advanced compiler could create this array automatically.» А может пора отбросить попытки эмулировать декларативность императивщиной и использовать нормальный DSL?
Удивительнее то, насколько Дерби опередил своё время. 4 года стагнации, а фреймворк остаётся одной из лучших технологий. Весь веб-дев зигзагами плетётся примерно в том же направлении, не видя конечную цель и не понимая, что она уже давно была достигнута.
Последние 5 лет я работал с Дерби. Было много набитых шишек и боли. Постоянно сомневался, не стоит ли вернутся к более трендовым технологиям. Два месяца назад пришлось начать работать с Реактом. До сих пор шокирован, насколько в трендах всё не лучше. Столько хайпа вокруг React+Redux — а никаких Best Practice точно также нет. В тоннах статей описывают решения только примитивнейших задач. И даже при этом решения имеют явные проблемы. В итоге на многих современных сайтах всё скачет при загрузке, не работает нормально Browser History и другие UX-недоработки.
Не думаю, что кто-то заморачивался над скроллами каждого блока на странице. Опять же, мы просто не подошли к этой проблеме. Куча более банальных вещей требуют нашего внимания.
Что касается инпутов и прочего, я решал так: делал в глобальном стейте ветки, синхронизированными с History state и c URL query. Дальше остаётся только поместить нужные данные внутрь этих веток и их состояние будет сохраняться при переходах по истории или даже при перезагрузке страницы. Всё ещё нужно задуматься, какие данные где хранить, но дальше дополнительных действий не требуется.
Я имел ввиду, что нас отбросили назад Реакт и Редакс.
Реакт слишком низкоуровневый. Отказ от двустороннего датабиндинга — ошибка. Это не решение проблемы, а бегство. Аналогично можно отказываться от высокоуровневых ЯП и писать всё на Ассемблере, чтобы делать всё явно. На простых задачах десятки строк Реакта и Редакса — просто двусторонний датабиндинг написанный явным образом. На сложных — все эти ограничения по потокам данных никак не помогают. С двусторонним датабиндингом легко запутаться. А в решении проблем, которые созданы ограничениями Редакса, невозможно не запутаться.
На практике это будет не так. Кто-то будет в обоих случаях целится в надпись, а кто-то — в область вокруг. Здесь личный опыт сработает сильнее всяких рамок. Если хотите, чтобы 100% пользователей поняли, что вся область кликабельна, сделайте каждый пункт меню в виде большой нестилизованной <button>. И радуйтесь, что вы решили эту задачу, убив всё остальное.
Если человек не видит размеры области нажатия из‐за отсутствия границ, то он склонен считать областью саму надпись и будет целиться именно в неё.
Человек не думает ни о каких областях нажатия. Он кликнет так, чтобы ему было понятно, чего он хочет. А когда из-за плохого дизайна машина его не поймёт, он переучиться кликать на саму надпись, а не на область. И бордеры не исправят это. Только cursor: pointer и время, проведённое с нормальным интерфейсом.
Готовыми ОС, компиляторами и прочим тоже лучше не пользоваться, чтобы всё не было таким огромным? Извините за сарказм, просто эти наезды на зависимости мне кажутся ужасно недальновидными.
Мы уже давно строим пирамидки из кубиков. Пирамидки растут, но на самой вершине у них всегда были маленькие, убогие и кривые недокубики. Когда-то и компиляторы были убогими, а на ассемблере можно было сделать лучше. Со временем опыт накапливается, шишки набиваются и нижние слои зависимостей крепнут и улучшаются. А без этого мы так и останемся на одной и той же ступени развития. Очень хочется взглянуть на программы людей, критикующих современные фреймворки и нагромождения зависимостей. И сказать им о том, что их софт дерьмо. Потому что сегодня абсолютно весь софт дерьмо. Но если игнорировать всё кроме производительности, потребления памяти и занимаемого места на диске то, конечно, можно гордиться своими поделками без зависимостей.
Проблема есть. Она очень серьёзная. Но даже намёки на бегство, вместо решения проблемы, считаю приступными.)
Для любителей всё возводить в абсолют: это не значит, что весь код нужно писать в одном файле, одной функции и одной строчке. Именно в том и смысл, что какого-то абсолютного, бездумного правила не может быть. Нужно смотреть на логические взаимосвязи.
Мы же обсуждаем разработку капчи, а не людей, которые подключают сторонний сервис.
Всё-таки для почты эта задача мне кажется сложнее, чем для сайтов. Да и справляются фильтры сегодня весьма хорошо. И с капчой есть «заметный процент промахов и ложных срабатываний». Если точнее — капча справляется гораздо хуже.
Почему бы не направить усилия на распознавание зловреда вместо того, чтобы мучить людей решением ваших проблем? В статье много написано про выкрутасы с ИИ. Но распознавание спама выглядит куда более простой задачей для ИИ. И обойти защиту значительно сложнее, чем распознавать любую капчу, потому что текст должен быть рекламным. По-моему, это очередной пример, когда настоящую задачу подменяют какой-то технической мурой.
Зачем? Зачем вы едите этот кактус? Как этот ворох костылей мог стать мейнстримом?
Мне повезло, я столкнулся с проблемой переопределения колбеков в самом начале знакомства с React. Больше всего меня поразило, что эта проблема никого особо не волнует. Ок, разработчики Реакта наконец выдали какое-то решение. Но ведь это же редкое уродство. Во второй аргумент useCallback ещё нужно добавить какой-нибудь идентификатор, чтобы мемоизировать несколько разных колбеков. Мемоизатор скорее всего будет жрать память. Всё это громоздко и неудобно.
Конечно, кроме мемоизации другого решения и не найти, если колбек передаётся в цикле. Почему не признать, что подходы Реакта тупиковые? Нет, продолжают костылять: «In the future, a sufficiently advanced compiler could create this array automatically.» А может пора отбросить попытки эмулировать декларативность императивщиной и использовать нормальный DSL?
Последние 5 лет я работал с Дерби. Было много набитых шишек и боли. Постоянно сомневался, не стоит ли вернутся к более трендовым технологиям. Два месяца назад пришлось начать работать с Реактом. До сих пор шокирован, насколько в трендах всё не лучше. Столько хайпа вокруг React+Redux — а никаких Best Practice точно также нет. В тоннах статей описывают решения только примитивнейших задач. И даже при этом решения имеют явные проблемы. В итоге на многих современных сайтах всё скачет при загрузке, не работает нормально Browser History и другие UX-недоработки.
Что касается инпутов и прочего, я решал так: делал в глобальном стейте ветки, синхронизированными с History state и c URL query. Дальше остаётся только поместить нужные данные внутрь этих веток и их состояние будет сохраняться при переходах по истории или даже при перезагрузке страницы. Всё ещё нужно задуматься, какие данные где хранить, но дальше дополнительных действий не требуется.
Реакт слишком низкоуровневый. Отказ от двустороннего датабиндинга — ошибка. Это не решение проблемы, а бегство. Аналогично можно отказываться от высокоуровневых ЯП и писать всё на Ассемблере, чтобы делать всё явно. На простых задачах десятки строк Реакта и Редакса — просто двусторонний датабиндинг написанный явным образом. На сложных — все эти ограничения по потокам данных никак не помогают. С двусторонним датабиндингом легко запутаться. А в решении проблем, которые созданы ограничениями Редакса, невозможно не запутаться.
Человек не думает ни о каких областях нажатия. Он кликнет так, чтобы ему было понятно, чего он хочет. А когда из-за плохого дизайна машина его не поймёт, он переучиться кликать на саму надпись, а не на область. И бордеры не исправят это. Только cursor: pointer и время, проведённое с нормальным интерфейсом.