Разработка изоморфного RealWorld приложения с SSR и Progressive Enhancement. Часть 3 — Routing & Fetching


Стандартный язык разметки web-страниц

Привет, Хабр! Представляю вашему вниманию перевод статьи "Font (More) Awesome — an iconic invention" автора Pubudu Dodangoda.
Создаёте ли вы веб-сайт, мобильное или настольное приложение, есть несколько вещей, которых вам не удастся избежать. Правильное использование графики и иконок является одной из таких базовых потребностей. Стильные иконки также важны, как выравнивание и цветовые комбинации — просто потому, что одна иконка может выразить то, что едва поместится в сотню слов.


После прочтения ряда статей (например, этой) решил перейти на современный подход с использованием Node.js при написании простых сайтов с подхода «динозавров». Ниже представлен разбор примера сборки простого статического сайта с помощью Webpack 4. Статья написана, так как инструкции с решением моей задачи не нашел: пришлось собирать всё по кусочкам.

Здравствуйте, недавно послушал новый выпуск Веб-стандартов и там был момент с обсуждением статьи «Время переменных» где автор решил поэкспериментировать с CSS переменными и создать на основе них аналоговые часы. Все выглядит шикарно и главное работает, но у меня появилось много вопросов и я решил немного поэкспериментировать и заодно вам рассказать о своих умозаключениях.
Не подумайте ничего плохого, я люблю CSS переменные и все новое в CSS, но как всегда есть пару но. Во первых, мне лично очень не нравиться идея писать в DOM каждую секунду, ведь все что связано с ним достаточно ресурсозатратно, но тут я не совсем уверен насколько это может быть плохо. Во вторых, не смотря на то что CSS переменные очень удобно использовать, все же их нужно использовать с умом, ведь каждый раз при изменении переменной вы вызываете перерисовку каждого элемента, который ее использует. И тут я вижу главную проблему для себя.
Вкладка Rendering в консоли Chrome помогла подтвердить факт перерисовки:

Приветствую, коллеги, и представляю вашему вниманию продолжение серии статей о веб-компонентах, первая часть которой доступна вот тут
В этой статье речь пойдет о спецификации теневого DOM (shadow DOM) версии от 01.03.2018 г.. Последний черновик спецификации датирован 08.03.2018г.
АПИ теневого DOM позволяет нам инкапсулировать содержимое страницы, посредством помещения разметки в древовидную структуру, называемую shadow tree, которая, хотя и будет внедрена в DOM, не будет ее полноправной частью в привычном нам контексте: ее нельзя получить для взаимодействия стандартными методами js для работы с обычными потомками в DOM. Именно это АПИ в разрезе всех АПИ для создания веб-компонентов, дает нам возможность не только скрывать внутреннюю реализацию компонентов, но и инкапсулировать стили с минимальными усилиями.
Этим летом после лекции на веб-конференции у меня состоялась увлекательная беседа с молодой студенткой, которая изучает цифровой дизайн. Было интересно сравнить наши карьерные пути. У меня пятнадцать лет опыта дизайна для веб-клиентов, у неё — один год, но каким-то образом мы оказались в одинаковой ситуации: мы наслаждались работой, но были совершенно дезориентированы и обескуражены быстро растущей сложностью всего вокруг. Что за ерунда произошла? (Конечно, это риторический вопрос).@media screen. Ибо кодbody{font-size: 1em;}
@media screen and (max-width: 1024px){
body{font-size: 0.8em;}
}
TL;DR: в этих сериях вы узнаете, как заставить React и Redux управлять SVG элементами для создания игры. Полученные в этой серии знания позволят вам создавать анимацию не только для игр. Вы можете найти окончательный вариант исходного кода, разработанного в этой части, на GitHub.




Актуальны ли ещё угрозы XSS? Прошло около 20 лет с тех пор, как Cross Site Scripting (XSS) появился как вид атаки. С тех пор мы получили богатый опыт и знания, защита наших сайтов стала намного сложнее, а многочисленные фреймворки были призваны оберегать нас от ошибок. Но последние данные показывают совсем другую картину: в первых кварталах 2017 года количество сообщений об XSS-атаках и количество найденных уязвимостей выросло в несколько раз.
В этом хабропосте мы расскажем, как страшно жить, почему ваши приложения в опасности, почему фреймворки не спасают, как находить уязвимости и какие инструменты для этого использовать.
Прототипом статьи является доклад на конференции HolyJS 2017 Moscow. Алексей — фронтенд-тимлид/архитектор в компании EPAM Systems и один из лидеров сообщества FrontSpot в Минске. Основные области профессиональных интересов: архитектура и инфраструктура приложений, управление разработкой.
В этом тексте огромное количество картинок со слайдов. Осторожно, трафик!
В Первой части мы подготовили нашу страницу.
После прочтения комментариев хочется сделать небольшое отступление: я не говорю что этот подход идеальный, или всем надо следовать и теперь писать только так. Я знаю о наличии программ для этого. Но суть статьи была поделиться мыслями как это можно сделать самому, и заодно разобраться в разных технологиях. Всегда интересно искать новые пути, пусть они и неверные, или слишком длинные, но они учат нас чему-то новому, пусть даже мы их прошли с ошибками.
Имитация базы, как мне уже писали в комментариях, это json файлы с содержанием нужного текста. Вопрос: "Зачем тут Vue? Если это можно написать и на скриптах?". Если честно — для красоты html верстки. Ну и изучения новых технологий.
Передо мной встала задача по обновлению текущего сайта одной компании, и в соответствии тренду выбор пал на landing page с поддержкой мультиязычности.
Посмотрев на реализации представленные в интернете я ужаснулась. В теле страницы куча текста! С такой разметкой же невозможно работать. А если надо поменять информацию? Это надо лезть в html, искать нужное, и менять в нескольких местах. Короче ужас! И я подумала что хорошо бы использовать базу данных, но это же обычная страница, и разворачивать ради нее целый сервер? и базу? как то перебор! Работая с Angular2 я подумала что было бы классно с его помощью создать страницу, но он очень тяжелый, и не подходит… И тут я вспомнила о его аналоге Vue.js. Легкая библиотека, для создания приложений. Я подумала: "А почему бы не создать сайт с помощью vue и добавить имитацию базы?".
Обдумав все за и против, посмотрев на другие подходы, мне захотелось внести немного "красоты" в html верстку.
Для объяснения подхода я решила сделать небольшую страничку, потому что выкладывание полного кода существующей страницы считаю слишком "тяжелым".
Но пришлось все равно разбивать статью на 2ве части, тут описывается только подготовка небольшой страницы и добавление меню для смены языка.



Данная статья — первая часть из небольшой серии статей о создании веб-компонентов нативными средствами HTML и JS
Компонентный подход к разработке веб-приложений опирается на создание независимых модулей кода, которые могут быть использованы повторно, объединяемых по общему признаку, а также обладающие способностью хранить и восстанавливать свои состояния, взаимодействовать с другими компонентами и при этом не зависеть от других компонентов.
Для реализации такого подхода, в настоящее время разрабатываются три спецификации, о первой из которых, пойдет речь в этой статье. Итак, знакомимся — спецификация пользовательских элементов (custom elements), рабочий черновик которой оупбликован 13.10.2016 и последняя версия которого датирована 04.12.2017.
Пользовательский элемент является наиболее важной частью АПИ, входящих в пакет веб компонент, поскольку именно он предоставляет ключевые возможности, а именно: