1. UX затрагивается в статье во многих местах. Конкретно эта проблема, на мой взгляд, описывается в пункте Navigation:
Мы ожидаем, что интерфейс будет «стабильным» при взаимодействии с ним. Элементы не должны внезапно исчезать
… и прыгать.
2. Пусть так. Но прыгать в интерфейсе ничего не должно. Тогда изменение ширины нужно анимировать. Но мне кажется, что в большинстве случаев фиксированная ширина сработает лучше.
3. Я, кстати, не уверен. Меняя DOM при скроле вы решили одну проблему, создав другую.
4. Очень много вопросов хорошо разобраны в советах Бюро: bureau.ru/bb/soviet. Не какие-то догмы, а аргументированные разборы задач.
Я ненавижу Реакт не меньше вашего. И как раз хотел написать комментарий, что Дэн отбросил сообщество в создании качественного UX назад. Если добавление самой микроскопической функции требует изменение нескольких слоёв, разбросанных по нескольким файлам — на хороший UX внимания уже не остаётся. Если базовые задачи раздроблены на десятки плохо связанных библиотек — на хороший UX внимания уже не остаётся.
Вы как всегда пытаетесь сделать вид, что у $mol всё хорошо из коробки. Но вот вам камень в оба огорода: что в документации Redux, что в демках $mol не сохраняется положение скролла при движении по истории (History Back). Наши инструменты должны сами решать такие проблемы по умолчанию, без прикладывания усилий.
Конечно, элемент, который обрамлён рамкой, лучше заметен. В этом и проблема. Если всё обвести рамками, всё начнёт кричать. Под «шумом» подразумевается то, что каждый элемент (в том числе и пустоту) мозгу необходимо прочитать и обработать. Но пустоты считываются легче. Всё это особенно критично, когда мы учимся работать с интерфейсом. Конечно, потом мозг привыкает и быстрее отбрасывает мусор. Но вероятность совершить ошибку всё равно выше, потому что мусор продолжает создавать лишнюю нагрузку.
То что в Материале есть карточки, не значит, что их нужно использовать везде.
Не думаю, что матчасть противоречивая. Скорее её мало кто знает. Я программист, немного интересующийся дизайном. И даже при этом вижу грубые ошибки повсюду. То что дизайнеры убирая рамки и увеличивая отступы, например, забывают о контрасте и правиле внутреннего и внешнего, не значит, что рамки нужно пихать везде. Приёмов ещё много.
Особенно достало читать в комментах выпады в сторону анимации. Если вас анимация бесит, это значит, что анимация хреновая, а не то что она не нужна. И тоже самое с другими современными тенденциями в дизайне. Не тенденции плохие, а дизайнеры (или программисты), которые не понимают их сути. Достаточно посмотреть на тот же Материал и на CSS-фреймворки, его реализующие.
Чем лучше видишь боковым зрением элемент, тем быстрее попадёшь в него мышкой. Логично?
Не логично. Если только вы не покажите, как вы попадаете мышкой в цель, которая находится в области бокового зрения.
Вот об этом я и писал выше. Почему??? Кто придумал это правило, и почему его надо применять везде? А критически поразмыслить не судьба?
Как уже написали выше: потому что отступы создают меньше шума. Именно поэтому правило так и звучит: «предпочтение лучше отдавать». И это не значит, что везде нужно использовать отступы, а не бордеры. Это значит, что как раз нужно использовать критическое мышление. Для которого хорошо бы сначала изучить матчасть.
Приятно, что хоть кто-то ещё в мире называет костыль «костылем». Не подскажете, есть ли хоть какие-то более-менее популярные фреймворки, которые не пытаются эмулировать декларативность через императивщину? Из непопулярных-то я знаю. DerbyJS имеет замечательную архитектуру с честными декларативными шаблонами. Но интересно, существует ли какой-нибудь более популярный проект?
Так и не понял, в чем разница между ИП на НПД и физлицом на НПД? Зачем платить лишние 2%? Можно быть одновременно и тем и другим? Чтобы не менять договоры со старыми клиентами, заключенными на ИП, а новый заключать уже как физлицом?
Это бенчмарки, показывающие, что JS и так уже очень быстрый. Замена его на другие языки повлияет только на узком классе задач.
Вы правы, это не доказывает, что большая часть времени в современных приложениях уходит на другие вещи. Мне не попадалось статьи, в которой бы исследовалась производительность большого количества сайтов. На отдельном взятом сайте вы можете проверить медлительность DOM с помощью профайлера.
Я даже не знаю, какие ссылки искать. В каждой статье про JS-фреймворки будет написано про оптимизацию работы с DOM. Это и есть путь решения. А бенчмарки показывают, что JS — один из самых быстрых языков.
> У него напрочь отсутствуют инструменты по оптимизации и ускорению.
Рискую продемонстрировать свою некомпетентность. А что это за инструменты, кроме профайлера?
> Процент хорошего кода\программистов — наименьший среди всех популярных языков.
На каком исследовании вы основываетесь?
> На JS и его фреймворках можно писать так, что все будет летать
> ускорение фреймворков (в разы, возможно на порядки)
Так фреймворки сделаны хорошо или нет? Если их можно ускорить в разы, очевидно, что плохо. Значит вы всё-таки считаете, что JS хоть и быстр, но настолько провоцирует написание плохого кода, что заменив его на другой язык можно будет убрать кучу лишних действий из фреймворков и получить прирост скорости в разы?
> всё упирается именно в скорость исполнения скриптов
Только скорость исполнения скриптов зависит не только от скорости языка. В данном случае, всё упирается в DOM. Уж столько раз об этом сказано…
Я про бизнес, а применения могут быть разные. Например, недавно была задача писать сообщения клиентам, которые сбрасывают звонок. Еслиб вотсап имел API можно было бы и на мессенджеры положиться. А без него всех не охватишь. СМСками было бы надёжнее.)
А если я буду отправлять рекламные СМС с сим-карты, Мегафон, Билайн и МТС тоже заплатят за это полмиллиона? Понятно, что есть ограничения на отправку с буквенного номера, и что нельзя подставить подтвержденный сторонний номер. Но классно было бы иметь возможность переписываться с виртуального номера.
Чтобы легче было различать назову первую сложность «качеством интерфейса» (а можно и читать как «качество программы», потому что интерфейс — и есть суть программы), а вторую — «сложность реализации». Очевидно, что наша задача — повышать качество интерфейса. И чтобы это делать, приходится бороться со сложностью реализации. И единственный способ это сделать — слой абстракции. Т.е. опираться на другой интерфейс, скрывающий другую сложность реализации.
Все проблемы, которые вы описали — лишь от того, что слои абстракции недостаточно хорошо сделаны. Как я уже писал здесь же в комментариях — пример качественно сделанной абстракции — язык Си.
а) Выдаваемый код лучше оптимизирован, чем это тот, что напишет человек на Ассемблере.
б) Опускаться на нижний слой не требуется.
в) Гибкость такая же как у Ассемблера.
г-д) эти сложности я понял недоконца.)
Конечно, я немного приврал.) Конечно, идеального слоя абстракции не может существовать. И наслоения будут давать издрежки. Но другого способа всё равно нет. Просто разработка ПО сейчас находится в зачаточном состоянии. Нижние слои абстракции уже неплохие, а наверху — сплошной бардак. И причина этого в сегментировании. На нижних слоях основывается большее количество решений, чем на верхних. На одной процессорной архитектуре работают множество языков программирования. Для каждого языка существует множество фреймворков. Для каждого фреймворка — множество библиотек решающих одну и туже подзадачу. И чем выше по дереву — тем ниже качество. Сегментирование не даёт нормально развиваться ПО. Дерево растёт вширь, а не вверх. Чтобы оно росло вверх, нижние слои должны укрепляться. Но это обычный эволюционный процесс.
Я и не спорю, что штука отличная для своих задач. Просто надеялся, что она подойдёт и мне. Очень привлекало то, что не придётся для записи гнать голосовой трафик через лишний сервер. Но оказалось, что эта АТС мимо меня. Хотелось бы чего-то, управляемого почти как Asterisk. Например, чтобы DTMF можно было обработать веб-хуком, ну и всякое в таком роде. Т.е. это инструмент для простых пользователей или эникейщиков, но не для программистов. И я не говорю, что это плохо.
… и прыгать.
2. Пусть так. Но прыгать в интерфейсе ничего не должно. Тогда изменение ширины нужно анимировать. Но мне кажется, что в большинстве случаев фиксированная ширина сработает лучше.
3. Я, кстати, не уверен. Меняя DOM при скроле вы решили одну проблему, создав другую.
4. Очень много вопросов хорошо разобраны в советах Бюро: bureau.ru/bb/soviet. Не какие-то догмы, а аргументированные разборы задач.
Я ненавижу Реакт не меньше вашего. И как раз хотел написать комментарий, что Дэн отбросил сообщество в создании качественного UX назад. Если добавление самой микроскопической функции требует изменение нескольких слоёв, разбросанных по нескольким файлам — на хороший UX внимания уже не остаётся. Если базовые задачи раздроблены на десятки плохо связанных библиотек — на хороший UX внимания уже не остаётся.
Вы как всегда пытаетесь сделать вид, что у $mol всё хорошо из коробки. Но вот вам камень в оба огорода: что в документации Redux, что в демках $mol не сохраняется положение скролла при движении по истории (History Back). Наши инструменты должны сами решать такие проблемы по умолчанию, без прикладывания усилий.
Я видел пару ваших демок. Таблица, у которой прыгают границы столбцов во время прокрутки — это точно не вписывается в принципы хорошего дизайна.
То что в Материале есть карточки, не значит, что их нужно использовать везде.
Не думаю, что матчасть противоречивая. Скорее её мало кто знает. Я программист, немного интересующийся дизайном. И даже при этом вижу грубые ошибки повсюду. То что дизайнеры убирая рамки и увеличивая отступы, например, забывают о контрасте и правиле внутреннего и внешнего, не значит, что рамки нужно пихать везде. Приёмов ещё много.
Особенно достало читать в комментах выпады в сторону анимации. Если вас анимация бесит, это значит, что анимация хреновая, а не то что она не нужна. И тоже самое с другими современными тенденциями в дизайне. Не тенденции плохие, а дизайнеры (или программисты), которые не понимают их сути. Достаточно посмотреть на тот же Материал и на CSS-фреймворки, его реализующие.
Не логично. Если только вы не покажите, как вы попадаете мышкой в цель, которая находится в области бокового зрения.
Как уже написали выше: потому что отступы создают меньше шума. Именно поэтому правило так и звучит: «предпочтение лучше отдавать». И это не значит, что везде нужно использовать отступы, а не бордеры. Это значит, что как раз нужно использовать критическое мышление. Для которого хорошо бы сначала изучить матчасть.
Так и не понял, в чем разница между ИП на НПД и физлицом на НПД? Зачем платить лишние 2%? Можно быть одновременно и тем и другим? Чтобы не менять договоры со старыми клиентами, заключенными на ИП, а новый заключать уже как физлицом?
Вы правы, это не доказывает, что большая часть времени в современных приложениях уходит на другие вещи. Мне не попадалось статьи, в которой бы исследовалась производительность большого количества сайтов. На отдельном взятом сайте вы можете проверить медлительность DOM с помощью профайлера.
habr.com/post/254121
Рискую продемонстрировать свою некомпетентность. А что это за инструменты, кроме профайлера?
> Процент хорошего кода\программистов — наименьший среди всех популярных языков.
На каком исследовании вы основываетесь?
> На JS и его фреймворках можно писать так, что все будет летать
> ускорение фреймворков (в разы, возможно на порядки)
Так фреймворки сделаны хорошо или нет? Если их можно ускорить в разы, очевидно, что плохо. Значит вы всё-таки считаете, что JS хоть и быстр, но настолько провоцирует написание плохого кода, что заменив его на другой язык можно будет убрать кучу лишних действий из фреймворков и получить прирост скорости в разы?
Только скорость исполнения скриптов зависит не только от скорости языка. В данном случае, всё упирается в DOM. Уж столько раз об этом сказано…
Все проблемы, которые вы описали — лишь от того, что слои абстракции недостаточно хорошо сделаны. Как я уже писал здесь же в комментариях — пример качественно сделанной абстракции — язык Си.
а) Выдаваемый код лучше оптимизирован, чем это тот, что напишет человек на Ассемблере.
б) Опускаться на нижний слой не требуется.
в) Гибкость такая же как у Ассемблера.
г-д) эти сложности я понял недоконца.)
Конечно, я немного приврал.) Конечно, идеального слоя абстракции не может существовать. И наслоения будут давать издрежки. Но другого способа всё равно нет. Просто разработка ПО сейчас находится в зачаточном состоянии. Нижние слои абстракции уже неплохие, а наверху — сплошной бардак. И причина этого в сегментировании. На нижних слоях основывается большее количество решений, чем на верхних. На одной процессорной архитектуре работают множество языков программирования. Для каждого языка существует множество фреймворков. Для каждого фреймворка — множество библиотек решающих одну и туже подзадачу. И чем выше по дереву — тем ниже качество. Сегментирование не даёт нормально развиваться ПО. Дерево растёт вширь, а не вверх. Чтобы оно росло вверх, нижние слои должны укрепляться. Но это обычный эволюционный процесс.