• 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Или DerbyJS.
  • Инструменты Node.js разработчика. Удаленный вызов процедур на веб-сокетах
    +1
    Посмотрите ещё на WAMP.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Key-prop — это частный случай общей проблемы. Сами по себе шаблоны статичны. Если их описывать декларативно, то можно точно сопоставить, какие изменения данных как именно изменяют DOM. Императивно перевычислять куски шаблона и сравнивать их со старыми кусками не нужно. Поэтому хотелось бы видеть к MobX нормальный View-слой, который не будет отбрасывать информацию об изменениях данных, чтобы потом перебирать Virtual DOM в поисках изменений.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    vintage говорит о полном ререндеринге вашего компонента App, когда достаточно заменить innerText у h1. В шаблоне всё написано (будь он декларативным, этой информацией можно было бы пользоваться), mobx может точно сказать, какие именно данные изменились, но реакт не может этой информацией воспользоваться, а может только перевычислять рендер-функцию заново. Так что такой отличной вещи, как MobX очень не хватает нормальный View.
    Приведу другой пример для объяснения. Использование key-prop при генерации html в цикле по значениям массива — это жуткий костыль. MobX может дать информацию, как именно изменился массив и из этой информации и декларативного шаблона однозначно понятно, как менять DOM — добавить/удалить куски или поменять что-то местами.
  • Svelte 3: Переосмысление реактивности
    +1
    Да уж, за абстрактными словами вы имели ввиду конкретные вещи.) Теперь я вас понял.
  • Svelte 3: Переосмысление реактивности
    +1

    Что вас не устраивает в существующих решениях? Даже если брать старый Ангуляр, там были проблемы с Model, но что было не так с View-слоем? Или чем вас не устраивает Svelte?

  • Svelte 3: Переосмысление реактивности
    +1

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

  • Почему дорожное движение внезапно превращается в пробку
    0

    Извините, промахнулся. Ответил ниже.

  • Svelte 3: Переосмысление реактивности
    +1

    Посмотрите видео.

  • Svelte 3: Переосмысление реактивности
    0

    Зачем же вы создание 40к вотчеров? Если у вас столько компонентов, то чем это отличается от Реакта, который также будет тормозить?


    В чем проблема обеспечить настоящую декларативность шаблонов с помощью джаваскрипта в браузере?

  • Svelte 3: Переосмысление реактивности
    +2

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

  • Svelte 3: Переосмысление реактивности
    0

    А почему вы уверены, что выражение в скобках может быть любым кодом? DerbyJS, например, парсит джаваскрипт в скобках как декларативное выражение. Вплодь до того, что count + 1 можно присвоить значение 2 и count станет равным единице

  • Svelte 3: Переосмысление реактивности
    0

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

  • Почему дорожное движение внезапно превращается в пробку
    –2

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

  • Svelte 3: Переосмысление реактивности
    0

    Привязка декларативна, я имел ввиду сам обработчик. Что за "программная логика"?

  • Почему дорожное движение внезапно превращается в пробку
    –5

    Типичное движение на московской кольцевой. Пять рядов едущих 80 кмч при разрешенных 100. Протискиваешься вперед — километр пустой дороги, а потом новое стадо. Я называю этот эффект "тупостью".


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

  • Svelte 3: Переосмысление реактивности
    +1

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

  • Svelte 3: Переосмысление реактивности
    +1

    Видимо у нас очень разные определения тупиковости. Потому что мне время (первые минут 30) уже все показало. Например, когда для оптимизации, нужно в shouldComponentUpdate внести то, что и так очевидно из render-функции. Или необходимость указывать key-property при рендере массива. Или перечислять значения вторым аргументом в useCallback. Эти проблемы нужно решать в фундаменте, а не плагинами к бабелю. Тогда будет архитектура, а не набор костылей.

  • Svelte 3: Переосмысление реактивности
    0

    Так-то любой декларативный код будет скомпилирован в императивный)

  • Svelte 3: Переосмысление реактивности
    +1
    Я говорю о том, что очень много усилий вкладывается в развитие тупиковой идеи Virtual DOM diff. Если бы последние пять лет сообщество вкладывалось в развитие настоящей реактивности, то были бы защиты от дурака. И, скорее всего, они были бы лучше тех, что есть сейчас. Потому что декларативный код даёт больше возможностей для автоматического анализа, оптимизации и т.п.
  • Svelte 3: Переосмысление реактивности
    +1
    Полностью согласен со всеми, кто обвинил меня в резкости. Обычно стараюсь сдерживаться. Но в этой теме меня особенно задевает не то, какой Реакт плохой, а общественная слепота. Повторю, что сказал в первом комментарии: архитектурные проблемы Реакта должны быть очевидны любому программисту с самого первого знакомства. Рич их разжёвывает 30 минут, а в комментариях несколько человек продолжают отвечать, что я «без всяких оснований» ругаю Реакт. Почему это происходит?
  • Svelte 3: Переосмысление реактивности
    +1

    Так тут же дело в абстрактной идеологии. Грубо говоря, сложность программы на Реакте — O(n), хотя проблема решается за O(1). И это заложено в самой архитектуре.

  • Svelte 3: Переосмысление реактивности
    +1

    Я не очень понял, что именно вам не нравится в 40к вотчерах. Проблема Ангуляра была ровно такая же, как и Реакта, только в Model слое, а не View. Ангуляр диффал данные, Реакт — виртуальный DOM. И то, и другое очевидно будет тормозить. Но дифф данных — это более хорошая архитектура. Потому что было несколько способов решить проблемы, оставив тот же подход в View. А Реакт — это шаг назад, потому что рано или поздно его все равно придётся выкинуть и сделать нормальную декларативность.

  • Svelte 3: Переосмысление реактивности
    +4

    Смотря в каком смысле "предложить". Как я уже сказал, настоящая декоративность, если я не ошибаюсь, существовала в Knockout и Angular. Можно было развивать эти идеи. Я думаю, что большинство просто повелось на мнимую простоту Реакта. Для первых шагов было проще понять, как он работает. Но конечная задача все равно гораздо более сложная. И в реальном мире Реакт обрастает кучей всего, что делает этот подход таким же сложным, как Ангуляр, но совершенно тупиковым. Вынос рендера в вебворкер для внесения десятка изменений в DOM этому подтверждение.


    А ещё я всем рекомендую посмотреть, как устроен View-слой в уже много лет как полумертвом DerbyJS. Например, там нет костыльного key-property. Когда вы изменяете массив в моделе, на уровне шаблона уже понятно, какие изменения нужно внести в DOM. Зачем ещё что-то сопоставлять по ключу? Хорошая программа (в данном случае фреймворк) строится от интерфейса, а не интерфейс подстраивается под то, как программисту удобнее его реализовать. Имитация декларативности через императивщину — это именно второй случай. Заморачиваться с парсингом декларативного языка долго — проще перезапускать функцию рендера. Но в итоге все равно люди обвешались babel-плагинами.


    Большое спасибо за ссылку.

  • Svelte 3: Переосмысление реактивности
    +5
    Либо меня не поняли, либо как раз поняли и обиделись. Я говорил о том, что перевычислять дерево каждый раз и искать изменения — это костыльнейшее решение, которое можно было придумать и написать на коленке как Proof of Concept лет 10 назад. Если я не ошибаюсь, уже в AngularJS была настоящая декларативность. Почему же большинство выбирало изначально костыльное решение, строит поверх ещё ворох костылей и упорно защищает это уродство? Все babel-плагины: JSX, react-css-modules, hooks.macro — это же всё маленькие шажки, пытающиеся сделать императивный React хоть немного декларативным. И даже Vue — продолжение всё тех же идей. Разве не очевидно, что нужно строить нормальное декларативное решение с самого низа?
  • Svelte 3: Переосмысление реактивности
    –5
    Удивительная выдержка у Рича — 37 минут говорит о том, что люди должны понимать уже через 5 минут после знакомства с Реактом. Желаю Svelte остановить это костыльное безумие.
  • Язык Bosque — новый язык программирования от Microsoft
    +1
    Если я правильно понял ваш первый комментарий, вы затронули сразу две темы — и визуальный шум, как точки с запятой, и специальные конструкции, как стрелочки. Насчёт шума я вас полностью поддерживаю. Но я хотел узнать именно про второе. Меня удивляет, что есть люди, предпочитающие писать «function», а не "=>". Пытаюсь понять причину.
  • Язык Bosque — новый язык программирования от Microsoft
    +1
    Вероятно, люди деляться на тех, кому проще в кванторы, и тех, кому проще в слова. И это очень странно. Потому что смысл абсолютно одинаковый, но короткие специализированные знаки должны считываться и обрабатываться мозгом быстрее. Возможно, что вы недостаточно выработали навык их чтения. Но я встречал других людей, кто предпочитает естественный язык специализированному.
  • Язык Bosque — новый язык программирования от Microsoft
    +1
    Как вам удобнее читать формулировки теорем — в кванторах или в словах?
  • Наша проблема c зависимостями
    +1
    > Проблема сложности.

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

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

    Проблема есть. Она очень серьёзная. Но даже намёки на бегство, вместо решения проблемы, считаю приступными.)
  • Холиварный рассказ про линтеры 
    +4
    Давайте дружить?) Полностью с вами согласен, хотел только добавить, что мантра «не засовывать логику в шаблон» озвученная в разделе об F-строках ужасно надоела. Это всё продолжение той же истории, что и про @staticmethod и прочую разбивку кода на основе «синтаксиса», а не смысла. Люди с огромной радостью проглатывают идею складывать все компоненты в одну директорию, делать тонкие html-шаблоны и т.д. Потому что так не надо использовать голову. Чуть лучше, но в ту же степь, все эти проверки на количество операций в строчке, количество переменных, методов и классов. Хороший код структурируется на основе логической взаимосвязи его кусков, а не «синтаксиса». Длинное выражение, функция или класс могут в принципе не иметь разбивки на смысловые куски. Тот же вызов username.title() в шаблоне — восхитителен. При чтении мы сразу видим, зачем вызывается метод title. Мы автоматически пропускаем вызов метода, если нас не интересует содержание строчки. Этот вызов логически привязан к шаблону и должен быть с ним как можно ближе.

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

    Мы же обсуждаем разработку капчи, а не людей, которые подключают сторонний сервис.

    То-то в почтовых сервисах Гугла и Яндекса над этим работают целые отделы

    Всё-таки для почты эта задача мне кажется сложнее, чем для сайтов. Да и справляются фильтры сегодня весьма хорошо. И с капчой есть «заметный процент промахов и ложных срабатываний». Если точнее — капча справляется гораздо хуже.
  • Почему капчи стали такими сложными
    0
    Я о том и говорю, что когда-то это было нормальным решением. Но если сейчас капча требует того же ИИ для её создания и доставляет настоящую боль пользователям, то нужно вернуться к изначальной задаче и подумать ещё раз. Для распознавания спама сильный ИИ не нужен. Задача явно не сложнее создания спама. Начнём с того, что у нас изначально есть очень хороший признак для классификации текстов — наличие URL'а. 80% результата уже достигнуто. Дальше уже тренируйте нейронные сети и прочее.
  • Почему капчи стали такими сложными
    +1

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

  • Работа с callbacks в React
    +1
    Большое спасибо за подробное разъяснение. Я предполагал, что хуки могут запоминать порядок вызова, но решил, что это и правда слишком нелепо.) Выходит, что решения для передачи колбека в цикле по-прежнему нет. На проблему просто забивают. Ждите пока начнутся тормоза, а потом делайте уродливый компонент-прослойку, передающий в колбек дополнительный параметр. Т.е. самый простой код уже по умолчанию имеет потенциальные проблемы с производительностью. Мир сошёл с ума.
  • Работа с callbacks в React
    0
    Что если в одной рендер-функции определяются несколько разных колбеков. Переданные массивы могут совпасть и последствия будут ужасны.) Или я чего-то не понимаю?
  • Работа с callbacks в React
    –2
    Не хочется нахватать минусов, но просто не могу сдержаться.

    Зачем? Зачем вы едите этот кактус? Как этот ворох костылей мог стать мейнстримом?

    Мне повезло, я столкнулся с проблемой переопределения колбеков в самом начале знакомства с React. Больше всего меня поразило, что эта проблема никого особо не волнует. Ок, разработчики Реакта наконец выдали какое-то решение. Но ведь это же редкое уродство. Во второй аргумент useCallback ещё нужно добавить какой-нибудь идентификатор, чтобы мемоизировать несколько разных колбеков. Мемоизатор скорее всего будет жрать память. Всё это громоздко и неудобно.

    Конечно, кроме мемоизации другого решения и не найти, если колбек передаётся в цикле. Почему не признать, что подходы Реакта тупиковые? Нет, продолжают костылять: «In the future, a sufficiently advanced compiler could create this array automatically.» А может пора отбросить попытки эмулировать декларативность императивщиной и использовать нормальный DSL?
  • Карта ДТП
    +2
    Поделитесь ссылкой, пожалуйста.
  • Новости DerbyJS 09.2014
    0
    Удивительнее то, насколько Дерби опередил своё время. 4 года стагнации, а фреймворк остаётся одной из лучших технологий. Весь веб-дев зигзагами плетётся примерно в том же направлении, не видя конечную цель и не понимая, что она уже давно была достигнута.

    Последние 5 лет я работал с Дерби. Было много набитых шишек и боли. Постоянно сомневался, не стоит ли вернутся к более трендовым технологиям. Два месяца назад пришлось начать работать с Реактом. До сих пор шокирован, насколько в трендах всё не лучше. Столько хайпа вокруг React+Redux — а никаких Best Practice точно также нет. В тоннах статей описывают решения только примитивнейших задач. И даже при этом решения имеют явные проблемы. В итоге на многих современных сайтах всё скачет при загрузке, не работает нормально Browser History и другие UX-недоработки.