HTML *

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Всем привет! Давно хотел и наконец написал небольшую книжку — бодрое пособие по своей профессиональной области: актуальным подходам к разметке интерфейсов, экранному дизайну и доступности. Она о моем оригинальном подходе к созданию GUI, препроцессорам CSS (для объективности, немного и об альтернативных подходах), и его эффективном практическом использовании с javascript и популярными реактивными компонентными фреймворками Vue и React. Материал представлен аккуратно последовательно, но безумно интенсивно и динамично — ничего лишнего или даже слишком подробного — для того чтобы увлеченный и подготовленный читатель не потерял интереса и «проглотил на одном дыхании». С другой стороны, текст, достаточно сложный ближе к концу, и на всем протяжении — густо насыщенный идеями, ссылками на технологии и подходы — поэтому, очевидно, будет «на вырост» начинающим. Но, в любом случае, как и если вы только начали интересоваться данной тематикой, так и если уже давно занимаетесь веб-дизайном, версткой и программированием фронтенда — вам может быть полезно на него взглянуть.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Я занимаюсь созданием сайтов в том или ином виде с 1995 года. После 25 лет работы, думаю, что накопил опыта и теперь располагаю достаточными знаниями. Ниже в произвольном порядке изложено несколько моментов, о которых я бы хотел, чтобы начинающие разработчики поразмыслили.

• Порой сайт — это всего лишь сайт.
• Браузер уже является клиентом; HTML — это язык, на котором он разговаривает.
• Веб строится вокруг визуализации на стороне сервера.
• Вы можете предоставить данные несколькими способами; рассмотрите HTML как один из способов представления данных.
• Масштабирование на стороне вашего сервера поможет всем, в то время как масштабирование на стороне клиента, помогает только тем, у кого мощное железо и быстрое соединение.
• Не каждый имеет (или может использовать) мышку.
• Не каждый имеет (или может использовать) клавиатуру.
• Не каждый имеет (или может использовать) тачскрин.
• Не у каждого цвета и картинки отображаются так же, как и у вас.

Когда к списку ключевых услуг нашего аутсорс-продакшена добавился дизайн, мы решили, что не хотим работать по общепринятым стандартам. Мы стали искать особый подход к дизайну: максимально качественно, максимально оперативно, максимально экономно. И мы его нашли — просто поменяв местами дизайнеров и верстальщиков.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

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

Идёте вы, уважаемый читатель, погожим летним вечером по улице, никого не трогаете, и тут… на вас наезжают (тьфу-тьфу-тьфу, как говорится). Хулиганы, просто прохожие, специальные товарищи (как пелось в одной старой песенке) — не столь важно. Вы достаете телефон и начинаете снимать происходящее на видео. Это не очень нравится наезжающим, и телефон у вас отбирают (или изымают на законных основаниях — нужное подчеркнуть). Свидетелей нет, видеозаписи на телефоне больше нет, доказательств для полиции и суда тоже, соответственно, никаких.

Выход из этой ситуации очевиден: видеозапись должна вестись не в локальный файл на ваш телефон, а непосредственно на удаленный сервер. Правда, готовых программных решений для реализации этой идеи не так много (например, вот): в большинстве случаев предлагаемые приложения для мобильного телефона или платные, или работают из рук вон плохо. Экзотические рекомендации типа «в случае нападения хулиганов начните трансляцию на YouTube» я не рассматриваю, так как в реальной ситуации у вас элементарно не будет времени, чтобы запустить трансляцию. Кроме того, видео будет писаться в чьё-то чужое облако, а очень часто это не есть хорошо.

Можно, конечно, подучить Java или Kotlin (а заодно и Swift) или, на худой конец, освоить PhoneGap и написать своё приложение. Однако всё гораздо проще: под катом несложное решение этой задачи посредством HTML5 video/audio API.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Недавно под вдохновением от канала The Coding Train я решил поучаствовать в одном из 10-минутных челленджей, в котором нужно было создать иллюзию полета сквозь космос с большой скоростью.

Для реализации проекта я выбрал уже хорошо знакомый мне p5.js — библиотеку для JavaScript, предназначенную для создания арта алгоритмическим способом. Почему нельзя было для этого использовать стандартные графические пакеты от Adobe?

Во-первых, делать такое кодом — это красиво.

Во-вторых, код позволяет на лету, поменяв буквально несколько параметров, получить другой результат, скорость экспериментов и итераций значимо увеличивается.

Ну и в-третьих, этот код потом легко интегрировать в любой веб-проект в виде скрипта на JS.

Ну что же, в бесконечность и далее…

Привет.

Сегодня я хочу рассказать, как написать html парсер, а также с какими проблемами я столкнулся, разрабатывая подобный парсер на php. А проблем было много. И в первой части я расскажу о проектировании парсера, и о возникших проблемах, ведь html парсер отличается от парсера привычных всем языков программирования.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Идея о том, что можно писать веб приложение без JavaScript интересна многим, а особенно тем кто начинал свой путь в программирование с серверного языка. Внедрение Web Assembly может (наконец-то) позволить это полноценно реализовать. Писать всю логику приложения на одном языке — звучит довольно заманчиво. Тем более, если этот код компилируется в бинарник, а не в промежуточный язык.

Эту технологию хотелось бы увидеть в не типичных веб-приложениях. Например, как это — писать что-то более интерактивное на Web Assembly (Blazor). Предлагаю попробовать создать простую текстовую интерактивную игру. В игре есть возможность создать свой вопрос и отвечать на вопросы других игроков, набирая очки за правильные ответы. Всё на одной странице и с помощью Blazor.



Результат:

Github
Demo

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Привет, меня зовут Женя, и я просто еще один из обитателей JavaScript вселенной, который хочет поделиться с вами интересным опытом в frontend-разработке, а именно как кастомизировать диаграмму Ганта.

Не так давно я присоединился к команде энтузиастов, которая работает над проектом по производству оборудования для ремонта автомобилей. Как и для любого проектного менеджмента, нам нужен был инструмент для планирования задач с следующим функционалом:

• оптимальное распределение ресурсов и нагрузки между сотрудниками
• мониторинг выполнения задач
• оценка эффективности и временных рамок проекта

Во многих современных приложениях для управления проектами для решения таких задач используются диаграммы Ганта. И я взялся за реализацию ее функциональности в нашем приложении.

Хотя можно было бы использовать готовый софт, в нашем случае нужно было сильно кастомизировать Гант под нужды проекта. Альтернатива разработки диаграммы с нуля — это слишком накладное и времязатратное мероприятие. Посовещавшись с коллегами, мы решили, что лучше всего найти готовый компонент среди библиотек JavaScript и настроить его под наш проект.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Что такое Neutralino.js?

Данная технология представляет из себя достаточно интересный аналог устоявшихся на данный момент Electron и NodeWebkit. Чем же оно отлично от вышеприведённых технологических решений? Если верить заявлениям предоставленным в официальной документации, то отлична сама используемая архитектура построения приложения, которая позволяет создавать кроссплатформенные приложения на веб-технологиях с достаточно малым размером конечного билда.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Привет, Хабр!

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

• DOM — это стейт. Поскольку у нас нет фреймворка, сразу забываем про функциональщину, и возвращаемся к императивному ООП. Веб-компоненты — это долгоживущие узлы DOM, инкапсулирующие свой стейт и имеющие публичное API. Они не пересоздаются, а изменяются. Значит DOM мы должны рассматривать не только как представление, но как хранилище бизнес-объектов, а значит и строить иерерхию компонентов нужно с учетом удобства их взаимодействия.
• Взаимодействие компонентов. Компоненты могут взаимодействовать посредством прямых вызовов, обмена колбэками, или посредством восходящих / нисходящих пользовательских событий DOM. Последний способ наиболее предпочтителен, так как снижает взаимную зацепленность (coupling), и упорядочивает граф связей (см. пример ниже).

На собеседовании многие начинающие (и не только) претенденты на позиции, связанные с HTML, неожиданно понимают, что не могут ответить на одни и те же типовые, и казалось бы, элементарные вопросы. Но ведь когда-то этому должен настать конец? Думаю, ответ на этот вопрос вы точно знаете.

Мы собрали список вопросов и ответов по HTML, которые, скорее всего, зададут во время собеседования. Разобравшись в них, соискатель сможет продемонстрировать достаточно высокий уровень знаний о предмете. Если перед собеседованием кандидат хорошо подготовит ответы на эти вопросы и сможет быстро реагировать на них, это произведёт приятное впечатление и даст ему преимущество по сравнению с более «медленными» конкурентами.