Можно аналогично делать без спец. сайтов. Например брать текст состоящий из:
название сайта + пароль (соль)
Считать от этого текста хэш, с помощью MD5. Использовать результат хэша в качестве пароля. Но ещё добавить статичную комбинацию больших букв и спец. символов, чтобы подходить для всех масок по сложности пароля. Считаем, что статичная часть всем известна. Тогда сложность определяется только символьной длинной MD5. Что обладает достаточной криптостойкостью. Но тут сразу можно решить вопрос с публичностью алгоритма для MD5. Он и так везде есть. Даже для мобильного телефона отдельные приложения, которые не лезут в сеть. Можно хоть самому написать за пару часиков (что кстати и сделал).
Подскажи кто уже читал. Имеет смысл читать, если уже прочитал https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321 .
А как это у вас получается? Что в документации для Redux, что для React, строго необходимо менять все объекты по пути к изменённому свойству. Исходя из этого, независимо от того на какой глубине произошло изменение, корневой объект всегда будет новый, и поэтому всегда будет достаточно ленивого сравнения. Т.е. shouldComponentUpdate если все делать правильно никогда ненужно трогать, если происходит наследование от PureComponent. Считаю это справедливым для чистого React и React + Redux. Насчет React + MobX ничего не могу сказать.
5. Производительность. Как бы я, скорее всего, понял вторую часть этого раздела, не зная ничего про Vue и React: «В React-е необходимо много возиться с shouldComponentUpdate, а во Vue все работает из коробки.»
Но подождите? На самом деле в React достаточно наследовать класс от PureComponent вместо Component. И на моей практике этого всегда было достаточно, с точки зрения работы с методом shouldComponentUpdate. А если вы используете Redux, то и этого делать не нужно! Да там упомянули про PureComponent. Но для человека не работающего с React, может быть непонятно, что в этом нет проблем. А если это так, то зачем запутывать людей? Вы спросите, а почему это может запутать? Да потому что, когда ведётся сравнение, в детали обычно имеет смысл вдаваться только, когда объясняют разницу, а не сходство.
Суть той части в том, что и во Vue и в React проблем с настройкой производительности нет. Стоит ли об этом говорить, если это не отличие? Мне кажется, что нет. А может ли это запутать?…
Мне кажется, подобным сравнительным статьям не хватает несколько примеров с задачами на порядок выше HelloWorld и с демонстрацией решения. У меня есть небольшой опыт разработки под React и нет опыта в Vue. И мне бы было бы искренне интересно посмотреть на каких конкретных примерах лучше один из фреймворков. Читая подобные статьи, лично у меня создается какое-то поверхностное представление. И я понимаю, что, чтобы действительно разобраться, мне нужно самому попробовать, но при этом хотелось бы получить эти знания из сравнительной статьи. А так получается, что это ещё одна статья из множества про поверхностное сравнение фреймворков только обновленная.
Вот например, разговор про CSS. Неужели это действительно важная и сложная проблема? Работая с React, никогда не возникало никаких проблем в этом плане. Во Vue, я так понимаю, таких проблем тоже нет. Тогда зачем об этом говорить? Неужели в React это сделано настолько хуже и это должно меня мотивировать использовать Vue?
Сравнение HTML-шаблонов и JSX. Об этом наверно уже было очень много разговоров. И одно и тоже. Вот лично у меня была проблема с JSX. Представим ситуацию, когда необходимо, чтобы HTML и CSS мог редактировать человек, без пересборки билда и запуска webpack dev сервера или его аналогов. Лично у меня не нашлось адекватного решения. А то что мне известно про фреймворки на основе HTML-шаблонов, в этом нет никаких проблем, т.к. HTML отделен от JS. React же по сути только JS, зная что JSX-это обертка над JS-кодом.
Если сравнивать эту статью с её многочисленными аналогами, то она лучше только за счет своей актуальности. Она не хуже других. Но в абсолютном значении, мне все также необходимо изучить Vue, чтобы понять то, что мне бы хотелось понять после её прочтения.
Можно аналогично делать без спец. сайтов. Например брать текст состоящий из:
название сайта + пароль (соль)
Считать от этого текста хэш, с помощью MD5. Использовать результат хэша в качестве пароля. Но ещё добавить статичную комбинацию больших букв и спец. символов, чтобы подходить для всех масок по сложности пароля. Считаем, что статичная часть всем известна. Тогда сложность определяется только символьной длинной MD5. Что обладает достаточной криптостойкостью. Но тут сразу можно решить вопрос с публичностью алгоритма для MD5. Он и так везде есть. Даже для мобильного телефона отдельные приложения, которые не лезут в сеть. Можно хоть самому написать за пару часиков (что кстати и сделал).
Подскажи кто уже читал. Имеет смысл читать, если уже прочитал https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/1449373321 .
Но подождите? На самом деле в React достаточно наследовать класс от PureComponent вместо Component. И на моей практике этого всегда было достаточно, с точки зрения работы с методом shouldComponentUpdate. А если вы используете Redux, то и этого делать не нужно! Да там упомянули про PureComponent. Но для человека не работающего с React, может быть непонятно, что в этом нет проблем. А если это так, то зачем запутывать людей? Вы спросите, а почему это может запутать? Да потому что, когда ведётся сравнение, в детали обычно имеет смысл вдаваться только, когда объясняют разницу, а не сходство.
Суть той части в том, что и во Vue и в React проблем с настройкой производительности нет. Стоит ли об этом говорить, если это не отличие? Мне кажется, что нет. А может ли это запутать?…