Можно было просто слайды выложить подряд, зачем между ними ещё текст? Ну а если серьёзно: код это текст, да и текст это… гм, текст. Зачем вы весь код и местами даже текст скриншотами накидали? Удачи прочитать это на мобильных, удачи скопировать, удачи понять.
Вы фактически перевели руководства с CSS-Tricks. Почему бы не оформить это как перевод? Чтобы было понятно, кто это написал и где искать оригинал, который дополняется и правится, в отличие от поста на Хабре.
Код картинками — это лениво и неудобно читать, не говоря уже про копирование. Определять современность браузера регуляркой по Chrome — это просто странно, когда есть Safari и Firefox.
Для иллюстрации поместил в ленту статьи из нашего блога. The Bell пишут на острые социальные и политические темы, которые не хочется обсуждать в рамках данного поста.
Layout — это не макет. Макет (дизайн) — это макет. Layout — это раскладка. Вы снова переводите хорошие материалы плохими словами, которые либо никто не употребляет на практике, либо просто искажают смысл.
Фантастика конечно. Как писать код так, чтобы его точно никто не понял. Мелькнули и сгорели фантазийные Sass (в синтаксисе на отступах) и CoffeeScript — их заменили Sass (SCSS) или CSS и JS/TS в совместимом и понятном виде. Но нет — найдутся желающие так же сверкнуть и невостребовано сгореть.
Также их можно использовать, чтобы посмотреть, что этот пост из-за гифок весит 76 Мб. GIF — это самый неэффективный формат для передачи видео: вы не только теряете качество, но и нагружаете пользователя лишним трафиком. Не надо так.
Заменим сабмит на обычную кнопку,
и будем вызывать проверку формы вручную, немного изменив пример.
К сожалению, вы воспроизводите популярную ошибку среди разработчиков SPA, я бы назвал её «сделаю всё сам (и забуду про важное)».
Вы отправляете форму по клику на кнопку. То есть если я хочу залогиниться и нажму в поле Enter, как делает любой продвинутый пользователь, форма не отправится. Вместо этого нужно повесить обработчик submit на саму форму, оставить нормальную кнопку с типом submit и делать preventDefault.
Вы кажется ни разу не выходили из дома с ноутбуком, не уезжали в командировки, не сидели в кафе с перегруженным вайфаем. Иначе бы вы такие странные вещи про офлайн для десктопных PWA не говорили. Тот же Squoosh.app у меня на десктопе всегда под рукой, а не только когда есть сеть. И это много раз спасало.
Есть такая группа аргументов, которая цепляется к большей и принципиальной проблеме, и пытается доказать свою важность. Это очень плохой метод. Потому, что вопросы доступности — это часто принципиальная невозможность пользоваться интерфейсом. Не просто неудобство или раздражающая особенность, а блокер — всё равно, что сайт, который не открылся.
Можно было просто написать статью про методы улучшения интерфейса и не пытаться изобразить, как «страдают» люди, у которых всё в порядке. Это было бы просто этичнее, что ли. А так впечатление смазано и как-то не очень.
Вы начали статью с идеи, что SPA безусловно лучше для пользователей и только плохие поисковики нам мешают жить лучше. Но это не так или не совсем так.
Обычный SPA, в среднем, лучше обычной статики на сервере — особенно в случае коробочного е-комерц. Но хорошая статика с оптимизированного бэка почти всегда лучше SPA, особенно по скорости первой отрисовки. И это безумно важно, почитайте про опыт Amazon. А ещё в комплекте идёт полная совместимость с поисковиками. Минус один: нужно сделать хорошо и улучшить сервис-воркерами, офлайном, оптимизацией и вот этим всем.
Можно было просто слайды выложить подряд, зачем между ними ещё текст? Ну а если серьёзно: код это текст, да и текст это… гм, текст. Зачем вы весь код и местами даже текст скриншотами накидали? Удачи прочитать это на мобильных, удачи скопировать, удачи понять.
…на неё нельзя попасть и активировать с клавиатуры, это по сути
<span>. Ссылкой её делает именноhref.Когда-нибудь, вы сможете перевести и сохранить его смысл. А пока грид-макеты, серьезно?
Вы фактически перевели руководства с CSS-Tricks. Почему бы не оформить это как перевод? Чтобы было понятно, кто это написал и где искать оригинал, который дополняется и правится, в отличие от поста на Хабре.
Код картинками — это лениво и неудобно читать, не говоря уже про копирование. Определять современность браузера регуляркой по Chrome — это просто странно, когда есть Safari и Firefox.
Самый плохой тип цензуры — самоцензура.
Круто, вы начали с того, что как раз не стоит делать на React — с лендингов и блогов.
Ваш перевод, но статья не ваша всё же.
Оригинальный пост 2012 года, ну вы чего. Ладно дубликат, но какая актуальность может быть 8 лет спустя?
Layout — это не макет. Макет (дизайн) — это макет. Layout — это раскладка. Вы снова переводите хорошие материалы плохими словами, которые либо никто не употребляет на практике, либо просто искажают смысл.
Фантастика конечно. Как писать код так, чтобы его точно никто не понял. Мелькнули и сгорели фантазийные Sass (в синтаксисе на отступах) и CoffeeScript — их заменили Sass (SCSS) или CSS и JS/TS в совместимом и понятном виде. Но нет — найдутся желающие так же сверкнуть и невостребовано сгореть.
Так Front Core или Web Core? :) Вы определитесь, в статье то одно, то другое.
Я не знаю, откуда вы скопировали категории, но так не говорят по-русски:
Поправьте, пожалуйста. А то очень машинно звучит и путает.
Очень хорошая мотивация, но вы упустили важное:
Элемент
<dialog>в нынешнем его состоянии использовать не рекомендуется. Почему — рассказывает Скотт Охара.А что использовать? Например, вот этот компонент Filament Group.
Надеюсь, вы найдёте время поправить пост.
Также их можно использовать, чтобы посмотреть, что этот пост из-за гифок весит 76 Мб. GIF — это самый неэффективный формат для передачи видео: вы не только теряете качество, но и нагружаете пользователя лишним трафиком. Не надо так.
К сожалению, вы воспроизводите популярную ошибку среди разработчиков SPA, я бы назвал её «сделаю всё сам (и забуду про важное)».
Вы отправляете форму по клику на кнопку. То есть если я хочу залогиниться и нажму в поле Enter, как делает любой продвинутый пользователь, форма не отправится. Вместо этого нужно повесить обработчик submit на саму форму, оставить нормальную кнопку с типом submit и делать preventDefault.
Вы кажется ни разу не выходили из дома с ноутбуком, не уезжали в командировки, не сидели в кафе с перегруженным вайфаем. Иначе бы вы такие странные вещи про офлайн для десктопных PWA не говорили. Тот же Squoosh.app у меня на десктопе всегда под рукой, а не только когда есть сеть. И это много раз спасало.
Есть такая группа аргументов, которая цепляется к большей и принципиальной проблеме, и пытается доказать свою важность. Это очень плохой метод. Потому, что вопросы доступности — это часто принципиальная невозможность пользоваться интерфейсом. Не просто неудобство или раздражающая особенность, а блокер — всё равно, что сайт, который не открылся.
Можно было просто написать статью про методы улучшения интерфейса и не пытаться изобразить, как «страдают» люди, у которых всё в порядке. Это было бы просто этичнее, что ли. А так впечатление смазано и как-то не очень.
Вы начали статью с идеи, что SPA безусловно лучше для пользователей и только плохие поисковики нам мешают жить лучше. Но это не так или не совсем так.
Обычный SPA, в среднем, лучше обычной статики на сервере — особенно в случае коробочного е-комерц. Но хорошая статика с оптимизированного бэка почти всегда лучше SPA, особенно по скорости первой отрисовки. И это безумно важно, почитайте про опыт Amazon. А ещё в комплекте идёт полная совместимость с поисковиками. Минус один: нужно сделать хорошо и улучшить сервис-воркерами, офлайном, оптимизацией и вот этим всем.
Работает. Гугл индексирует SPA, только делает это медленнее и с некоторыми нюансами, вот вам (и автору статьи) серия про JS SEO от Гугла.