Автор материала, перевод которого мы сегодня публикуем, говорит, что хочет поделиться с читателями прогнозом, который касается развития веб-технологий на ближайшие годы. В частности, здесь речь пойдёт о том, что, по мнению автора, фронтенд-разработчикам, вероятно, стоить начать изучать уже сегодня.

Всё, что связано с JavaScript, очень быстро развивается. Это касается и того, что можно отнести к сфере веб-разработки. В наши дни те, в основе чьих проектов не лежат самые современные технологии, начинают особенно сильно ощущать разрыв между тем, чем они пользуются, и тем новым, что появляется едва ли не ежедневно. К таким технологиям можно отнести Webpack, React, Jest, Vue, Angular в их современном состоянии. В то время как «население» мира фронтенд-разработки, включающее в себя технических специалистов и программистов, постоянно растёт, этот мир стремится к стандартизации. Появление новых технологий и инструментов уже меняет ситуацию.



Можно с изрядной долей уверенности говорить о том, что общим трендом развития фронтенд-технологий будет стандартизация разработки пользовательских интерфейсов. В частности, речь идёт о композиции, основанной на компонентах, о стремлении к модульности систем. Эта тенденция воздействует практически на всё — от стилизации до тестирования и даже до управления состоянием приложений. В этот тренд можно включить технологии, построенные вокруг веб-компонентов, ES-модулей, сюда же попадают соответствующие инструменты и многое другое.

Автор материала, перевод которого мы сегодня публикуем, говорит, что GitHub-репозиторий, над которым работал он и ещё несколько фрилансеров, получил, по разным причинам, около 8200 звёзд за 3 дня. Этот репозиторий попал на первое место в HackerNews и в GitHub Trending, за него отдали голоса 20000 пользователей Reddit.



В данном репозитории отражена методика разработки фулстек-приложений, которой посвящена эта статья.

Я работаю с Реактом на протяжении почти 3 лет, использовал как Redux так и MobX и у меня к текущему моменту возник вопрос. Почему абсолютное большинство front-end разработчиков продолжают свято верить в то, что Redux + Redux Saga + Reselect + 100500 других библиотек «облегчающих» жизнь — это лучшее решение на сегодняшний момент? Я приведу 4 аргумента в пользу того, чтобы в следующем проекте вы использовали MobX вместо Redux.

Мне нравится метал музыка разных направлений. Для отслеживания новинок я сделал парсер, который ищет свежие альбомы и складывает их в базу. За время существования приложения парсер я почти не трогал, хотя он и далек от идеала, а вот фронтенд был переделан несколько раз.

Под катом рассказ о том, как я переписал приложение с react-native на Svelte и опубликовал его в Google Play.

Это — первое, что ищут взглядом, когда переключаются между вкладками браузера. Только что мы дали одно из возможных описаний того, что называется «фавиконом». Пространство на экране, которое занимает ярлык вкладки веб-страницы — это гораздо более ценный ресурс, чем многие думают. Если хорошо поработать с ярлыком, то он, помимо того, что будет продолжать играть роль идентификатора страницы, может стать чем-то вроде «доски объявлений», которая сообщает о том, что именно происходит на странице.

Фавикон

Привет Хабр! Летом мы переводили цикл статей про Bash-скрипты — судя по отклику, статьи оказались для вас полезными. И, по многочисленным просьбам, мы решили сделать PDF-версию перевода.



Подробности под катом.

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



PDF-версия документа состоит более чем из 120 страниц, содержит оглавление, немного картинок и всё необходимое форматирование. Просто закидывайте файлик в читалку и готово. Или в папочку с литературой. Или… решать вам.

Скачать PDF-версию [ 1.8 Мб ]

Сегодня мы хотим представить вашему вниманию новое руководство того же автора, посвящённое JavaScript.


Мы планируем это руководство перевести, но, прежде чем приняться за работу, хотели бы предложить вам поучаствовать в небольшом опросе

ООП (Объектно-Ориентированное Программирование) стало неотъемлемой частью разработки многих современных проектов, но, не смотря на популярность, эта парадигма является далеко не единственной. Если вы уже умеете работать с другими парадигмами и хотели бы ознакомиться с оккультизмом ООП, то впереди вас ждет немного лонгрид и два мегабайта картинок и анимаций. В качестве примеров будут выступать трансформеры.

Материал, перевод которого мы сегодня публикуем, посвящён созданию динамических PDF-файлов с использованием HTML-кода в качестве шаблона. А именно, речь пойдёт о том, как сформировать простой счёт на оплату неких товаров или услуг, динамические данные, включённые в который, берутся из состояния React-приложения. База React-приложения создана с помощью create-react-app, серверная часть проекта основана на Node.js, при её разработке использован фреймворк Express.



Автор этого материала отмечает, что он подготовил видео, в котором демонстрируется разработка проекта. Если вы решите и посмотреть видео, и прочитать статью, то рекомендуется поступить так. Сначала бегло просмотрите статью, потом включите видео и воссоздайте у себя рассматриваемую там систему. А после этого просто прочитайте статью.

Автор материала, перевод которого мы публикуем сегодня, занимается работой над фреймворком Quasar. Это — полнофункциональный расширяемый опенсорсный инструмент для разработки современных приложений различного назначения. Он построен на базе популярного фронтенд-фреймворка Vue.js и использует возможности Node.js, Webpack и Babel. Совсем недавно, в начале июля сего года, вышел первый стабильный релиз Quasar.

Давайте поговорим о покупке электронных компонентов в интернете. Я собрал список интересных отечественных и зарубежных магазинов:

а) которые заточены под любителей DIY и делают свои собственные крутые продукты: конструкторы, модули, обучающие курсы и т.д.;

б) для профи, с широкой номенклатурой электронных компонентов.

Продолжение: Часть II: зарубежные магазины

Предлагаю к прочтению свободный перевод небольшой статьи по практическому применению GraphQL. Оригинал доступен по ссылке (En).

Пару слов о GraphQL

GraphQL это язык запросов для API, который предлагает декларативный подход к получению данных. Он позволяет клиентам запрашивать только нужные данные с веб-сервера и ничего лишнего. Разработанный еще в 2012 году Facebook’ом, которым по-прежнему и поддерживается, GraphQL стал использоваться многими другими крупными и не очень компаниями. Среди прочих Yelp, Shopify и Github.

При использовании REST APIs обычно запросы отправляются по нескольким адресам, для получения всех необходимых данных в приложении. GraphQL API же позволяет тебе отправлять все запрос по адресу с указанием, какие именно данные ты бы хотел получить этим запросом. Поэтому, к слову, GraphQL отлично подходит при использовании в условиях медленного мобильного соединения.

Версии API могут быть головной болью для команд разработчиков. С GraphQL вы можете с этим не беспокоиться. GraphQL позволяет тебе добавить новые поля и типы (это будет обсуждаться позже) в твой GraphQL API, не затрагивая существующие запросы, старые и неиспользуемые же поля могут быть скрытыми от клиентов API. Используя единую эволюционирующую версию, GraphQL API предоставляет вашему приложению постоянный доступ к новым реализациям API и обеспечивают чистую и легко поддерживаемую базу кода.

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

Пару недель назад я начал цикл о том, как делал некоммерческий музыкальный проект (первый пост есть в «я пиарюсь», не буду ставить ссылок), но, к сожалению, в первой же статье увлекся, и вместо того, чтобы рассказывать о том, как делал конкретно его, начал вспоминать эффективные трюки из других проектов. Видимо, именно это вкупе с прописанным акцентом на сам проект привело к тому, что за мной и постом прилетело НЛО.

Однако все то, что было в статье, было по крайней мере малоизвестно, а половина ее была вообще уникальна, как я уверен, и каждый из этих советов может ощутимо облегчить работу с gulp, поэтому мне действительно было бы жаль, если этот материал безвозвратно пропал бы.

Поэтому я постарался убрать все упоминания проекта и повторно публикую (с доработками и правками) статью, которую по сути никто еще не видел. Если вы фанат grunt — почитайте хотя бы вторую часть: то, что вы не любите gulp, не значит, что вы не любите browserify.

Краткое содержание:

1. Простой способ обработки ошибок;
2. Универсальная структура для хранения исходных файлов;
3. Объединение нескольких потоков (например, скомпилированный coffee и js) в один;
4. Создание потока из текста;
5. создание собственных плагинов для Browserify;
6. создание плагинов из плагинов Gulp для Browserify.

Все, кто знаком с Vue, знают, что у Vue-приложения одна точка входа — файл main.js. Там, помимо создания экземпляра Vue, происходит импорт и своего рода Dependency Injection всех ваших глобальных зависимостей (директив, компонентов, плагинов). Чем больше проект, тем больше становится зависимостей, которые, к тому же, имеют каждая свою конфигурацию. В итоге получим один огромный файл со всеми конфигурациями.
В этой статье речь пойдет о том, как организовать глобальные зависимости, чтобы этого избежать.

Доброго времени!
У нас вышла книга Закаса «JavaScript для профессиональных веб-разработчиков»



Эта книга ориентирована на три группы читателей:
— профессиональные разработчики, имеющие опыт объектно-ориентированного программирования и желающие изучить JavaScript в контексте традиционных объектно-ориентированных языков, таких как Java и C++;
‰‰- разработчики веб-приложений, которым нужно сделать свои веб-сайты и веб-приложения более удобными в использовании;
— ‰‰начинающие разработчики на JavaScript, желающие лучше понять этот язык.

Предлагаю вашему вниманию перевод статьи «Tasks, microtasks, queues and schedules» Джейка Арчибальда (Jake Achibald), занимающего должность Developer Advocate for Google Chrome.

Когда я сказал своему коллеге Мэту Ганту, что подумываю о написании статьи об очерёдности микрозадач и порядке их исполнения внутри событийного цикла браузера, он сказал «Джейк, буду честен, я об этом читать не стану». Что ж, я всё же написал, поэтому откиньтесь на спинку кресла и давайте вместе в этом разберёмся, ладно?

На самом деле, если вам будет проще посмотреть видео, есть замечательное выступление Филиппа Робертса на JSConf, которое рассказывает о событийном цикле – оно не покрывает микрозадачи, но в остальном является отличным вступлением в тему. В любом случае, погнали…

Давайте рассмотрим следующий код на JavaScript:

console.log('script start');

setTimeout(function() {
  console.log('setTimeout');
}, 0);

Promise.resolve().then(function() {
  console.log('promise1');
}).then(function() {
  console.log('promise2');
});

console.log('script end');

Как вы думаете, в каком порядке должны вывестись логи?

I. В чём проблема

Расширения для браузеров — мощный инструмент продвинутого веб-сёрфинга, самая доступная, развитая и распространённая часть целого ряда инструментов. Однако расширения имеют и слабые стороны: каждый браузер требует знания и применения своих правил и форматов, а это дополнительная сложность для создателя. Расширения не кроссбраузерны, что сразу ограничивает их адресат. Есть попытки обобщить создание расширений, но они могут добавлять уже свою дополнительную прослойку форматов и правил.

Когда расширение улучшает специфические стороны браузерного интерфейса, без него не обойтись. Но некоторые задачи универсальны, не связаны с частными средствами браузера и, тем не менее, без расширения их тоже не выполнить. Одна из таких задач — кроссдоменные XMLHttpRequest запросы, нарушающие политику одного источника.

Запаситесь попкорном — я поведаю вам интересную историю… В общем, это будет одно из тысячи сочинений на тему «Как я написал свою игру». Сначала я планировал осветить как можно больше технических деталей, но потом понял, что их слишком много для одной статьи и она получится огромной. Поэтому «первая серия» будет, скорее, обзорной. Если будет интересно, то продолжу. Итак.

Уже очень давно мне хотелось попробовать создать проект, который бы представлял собой настоящие JavaScript Application, а именно толстый клиент, без backend и своего хостинга, на основе open source и какого-нибудь BaaS/DaaS. К тому же я окончательно устал от jsperf.com, от этих бессмысленных двух шагов, от отсутствия хоть какого-то редактора кода и нормального поиска и от постоянной потери своих тестов, а история с капчой, которая не всегда срабатывает, окончательно добила меня. Я наконец выкроил время, чтобы осуществить давно задуманное и убить двух зайцев, реализовав альтернативу jsperf.