Видимо у нас очень разные определения тупиковости. Потому что мне время (первые минут 30) уже все показало. Например, когда для оптимизации, нужно в shouldComponentUpdate внести то, что и так очевидно из render-функции. Или необходимость указывать key-property при рендере массива. Или перечислять значения вторым аргументом в useCallback. Эти проблемы нужно решать в фундаменте, а не плагинами к бабелю. Тогда будет архитектура, а не набор костылей.
Я говорю о том, что очень много усилий вкладывается в развитие тупиковой идеи Virtual DOM diff. Если бы последние пять лет сообщество вкладывалось в развитие настоящей реактивности, то были бы защиты от дурака. И, скорее всего, они были бы лучше тех, что есть сейчас. Потому что декларативный код даёт больше возможностей для автоматического анализа, оптимизации и т.п.
Полностью согласен со всеми, кто обвинил меня в резкости. Обычно стараюсь сдерживаться. Но в этой теме меня особенно задевает не то, какой Реакт плохой, а общественная слепота. Повторю, что сказал в первом комментарии: архитектурные проблемы Реакта должны быть очевидны любому программисту с самого первого знакомства. Рич их разжёвывает 30 минут, а в комментариях несколько человек продолжают отвечать, что я «без всяких оснований» ругаю Реакт. Почему это происходит?
Так тут же дело в абстрактной идеологии. Грубо говоря, сложность программы на Реакте — O(n), хотя проблема решается за O(1). И это заложено в самой архитектуре.
Я не очень понял, что именно вам не нравится в 40к вотчерах. Проблема Ангуляра была ровно такая же, как и Реакта, только в Model слое, а не View. Ангуляр диффал данные, Реакт — виртуальный DOM. И то, и другое очевидно будет тормозить. Но дифф данных — это более хорошая архитектура. Потому что было несколько способов решить проблемы, оставив тот же подход в View. А Реакт — это шаг назад, потому что рано или поздно его все равно придётся выкинуть и сделать нормальную декларативность.
Смотря в каком смысле "предложить". Как я уже сказал, настоящая декоративность, если я не ошибаюсь, существовала в Knockout и Angular. Можно было развивать эти идеи. Я думаю, что большинство просто повелось на мнимую простоту Реакта. Для первых шагов было проще понять, как он работает. Но конечная задача все равно гораздо более сложная. И в реальном мире Реакт обрастает кучей всего, что делает этот подход таким же сложным, как Ангуляр, но совершенно тупиковым. Вынос рендера в вебворкер для внесения десятка изменений в DOM этому подтверждение.
А ещё я всем рекомендую посмотреть, как устроен View-слой в уже много лет как полумертвом DerbyJS. Например, там нет костыльного key-property. Когда вы изменяете массив в моделе, на уровне шаблона уже понятно, какие изменения нужно внести в DOM. Зачем ещё что-то сопоставлять по ключу? Хорошая программа (в данном случае фреймворк) строится от интерфейса, а не интерфейс подстраивается под то, как программисту удобнее его реализовать. Имитация декларативности через императивщину — это именно второй случай. Заморачиваться с парсингом декларативного языка долго — проще перезапускать функцию рендера. Но в итоге все равно люди обвешались babel-плагинами.
Либо меня не поняли, либо как раз поняли и обиделись. Я говорил о том, что перевычислять дерево каждый раз и искать изменения — это костыльнейшее решение, которое можно было придумать и написать на коленке как 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% результата уже достигнуто. Дальше уже тренируйте нейронные сети и прочее.
Почему бы не направить усилия на распознавание зловреда вместо того, чтобы мучить людей решением ваших проблем? В статье много написано про выкрутасы с ИИ. Но распознавание спама выглядит куда более простой задачей для ИИ. И обойти защиту значительно сложнее, чем распознавать любую капчу, потому что текст должен быть рекламным. По-моему, это очередной пример, когда настоящую задачу подменяют какой-то технической мурой.
Большое спасибо за подробное разъяснение. Я предполагал, что хуки могут запоминать порядок вызова, но решил, что это и правда слишком нелепо.) Выходит, что решения для передачи колбека в цикле по-прежнему нет. На проблему просто забивают. Ждите пока начнутся тормоза, а потом делайте уродливый компонент-прослойку, передающий в колбек дополнительный параметр. Т.е. самый простой код уже по умолчанию имеет потенциальные проблемы с производительностью. Мир сошёл с ума.
Поясните, пожалуйста, что тут недекларативного, кроме обработчика события?
Видимо у нас очень разные определения тупиковости. Потому что мне время (первые минут 30) уже все показало. Например, когда для оптимизации, нужно в shouldComponentUpdate внести то, что и так очевидно из render-функции. Или необходимость указывать key-property при рендере массива. Или перечислять значения вторым аргументом в useCallback. Эти проблемы нужно решать в фундаменте, а не плагинами к бабелю. Тогда будет архитектура, а не набор костылей.
Так-то любой декларативный код будет скомпилирован в императивный)
Так тут же дело в абстрактной идеологии. Грубо говоря, сложность программы на Реакте — O(n), хотя проблема решается за O(1). И это заложено в самой архитектуре.
Я не очень понял, что именно вам не нравится в 40к вотчерах. Проблема Ангуляра была ровно такая же, как и Реакта, только в Model слое, а не View. Ангуляр диффал данные, Реакт — виртуальный DOM. И то, и другое очевидно будет тормозить. Но дифф данных — это более хорошая архитектура. Потому что было несколько способов решить проблемы, оставив тот же подход в View. А Реакт — это шаг назад, потому что рано или поздно его все равно придётся выкинуть и сделать нормальную декларативность.
Смотря в каком смысле "предложить". Как я уже сказал, настоящая декоративность, если я не ошибаюсь, существовала в Knockout и Angular. Можно было развивать эти идеи. Я думаю, что большинство просто повелось на мнимую простоту Реакта. Для первых шагов было проще понять, как он работает. Но конечная задача все равно гораздо более сложная. И в реальном мире Реакт обрастает кучей всего, что делает этот подход таким же сложным, как Ангуляр, но совершенно тупиковым. Вынос рендера в вебворкер для внесения десятка изменений в DOM этому подтверждение.
А ещё я всем рекомендую посмотреть, как устроен View-слой в уже много лет как полумертвом DerbyJS. Например, там нет костыльного key-property. Когда вы изменяете массив в моделе, на уровне шаблона уже понятно, какие изменения нужно внести в DOM. Зачем ещё что-то сопоставлять по ключу? Хорошая программа (в данном случае фреймворк) строится от интерфейса, а не интерфейс подстраивается под то, как программисту удобнее его реализовать. Имитация декларативности через императивщину — это именно второй случай. Заморачиваться с парсингом декларативного языка долго — проще перезапускать функцию рендера. Но в итоге все равно люди обвешались babel-плагинами.
Большое спасибо за ссылку.
Готовыми ОС, компиляторами и прочим тоже лучше не пользоваться, чтобы всё не было таким огромным? Извините за сарказм, просто эти наезды на зависимости мне кажутся ужасно недальновидными.
Мы уже давно строим пирамидки из кубиков. Пирамидки растут, но на самой вершине у них всегда были маленькие, убогие и кривые недокубики. Когда-то и компиляторы были убогими, а на ассемблере можно было сделать лучше. Со временем опыт накапливается, шишки набиваются и нижние слои зависимостей крепнут и улучшаются. А без этого мы так и останемся на одной и той же ступени развития. Очень хочется взглянуть на программы людей, критикующих современные фреймворки и нагромождения зависимостей. И сказать им о том, что их софт дерьмо. Потому что сегодня абсолютно весь софт дерьмо. Но если игнорировать всё кроме производительности, потребления памяти и занимаемого места на диске то, конечно, можно гордиться своими поделками без зависимостей.
Проблема есть. Она очень серьёзная. Но даже намёки на бегство, вместо решения проблемы, считаю приступными.)
Для любителей всё возводить в абсолют: это не значит, что весь код нужно писать в одном файле, одной функции и одной строчке. Именно в том и смысл, что какого-то абсолютного, бездумного правила не может быть. Нужно смотреть на логические взаимосвязи.
Мы же обсуждаем разработку капчи, а не людей, которые подключают сторонний сервис.
Всё-таки для почты эта задача мне кажется сложнее, чем для сайтов. Да и справляются фильтры сегодня весьма хорошо. И с капчой есть «заметный процент промахов и ложных срабатываний». Если точнее — капча справляется гораздо хуже.
Почему бы не направить усилия на распознавание зловреда вместо того, чтобы мучить людей решением ваших проблем? В статье много написано про выкрутасы с ИИ. Но распознавание спама выглядит куда более простой задачей для ИИ. И обойти защиту значительно сложнее, чем распознавать любую капчу, потому что текст должен быть рекламным. По-моему, это очередной пример, когда настоящую задачу подменяют какой-то технической мурой.