JavaScript *

Мы уже писали на Хабре о докладах в основных потоках FrontFest — JavaScript, вёрстка, смежные и экспериментальные технологии. Настало время рассказать о форматах. Помимо докладов будут квартирники (такой вид дискуссионных панелей) и воркшопы. Сегодня поговорим о воркшопах, и сразу главное — посещение воркшопов не требует никаких доплат и доступно по обычному билету участника. Да, вот так просто.

На воркшопах вы узнаете о хакерских способах низкоуровневых оптимизаций, приобретете навыки работы с Web Audio API и 3D на Canvas, научитесь делать свои веб-приложения нативными для iOS, Android, Windows и MacOS с помощью Ionic (Angular) и построите production-ready бекенд на Node.js с нуля.

Всем привет!

Помните эту статью? Раньше мы могли быстро собрать статичную HTML-страничку в каком-нибудь FrontPage и сайт был готов. С этим мог справится любой студент. В более сложном случае, мы писали пару строк на PHP и получали уже целый портал, собранный из разных элементов шаблона на сервере. Затем мы захотели, чтобы наш сайт как-то выделялся на общем фоне и умел чуть-чуть больше. Трон занял его-величество jQuery. Теперь же, мы оказались погребены под завалами фреймворков и библиотек, инструментов сборки, менеджеров зависимостей, препроцессоров и постпроцессоров, особых форматов, языков и стилей программирования, чтобы иметь возможность стряпать простые лэндинги. Все стало слишком сложно. Спикеры на конференциях стали соревноваться в изощренности того, каким еще образом можно сломать нам мозг. Как мы докатились до жизни такой? Чем «раньше» так сильно отличается от «сейчас»? Что нас ждет «потом»? Есть ли в современной веб-разработке некий дзен-стайл, блюдя который, можно, как в старые добрые времена, собрать себе уютный сайтик «на коленке» за пару вечеров, без ковыряния в документации десятка хипстерских технологий-однодневок? Насколько доступны нам простые решения в серьезной промышленной разработке? Куда движется веб-платформа? Предлагаю разобраться.

Перед вами — первый материал из серии, посвящённой разработке полноценного веб-приложения, которое называется Budget Manager. Основные программные средства, которые будут использованы в ходе работы над ним — это Node.js для сервера, Vue.js для фронтенда, и MongoDB в роли базы данных.



Эти материалы рассчитаны на читателей, которые знакомы с JavaScript, имеют общее представление о Node.js, npm и MongoDB, и хотят изучить связку Node-Vue-MongoDB и сопутствующие технологии. Приложение будем писать с нуля, поэтому запаситесь любимым редактором кода. Для того, чтобы не усложнять проект, мы не будем пользоваться Vuex и постараемся сосредоточиться на самом главном, не отвлекаясь на второстепенные вещи.

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

Дизайн — это фашизм. Фашизму нужна питательная среда. Он начинает раскрываться в полной мере только на крупных масштабах. Идеальная среда для фашизма — это большая компания с огромным количеством продуктов. Например, Google или… Альфа-Банк. Фашизм априори не гибок…

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

Введение

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

Компании все чаще прибегают к написанию интерфейса состоящего из множества независимых компонентов, которые могут быть использованы повторно. Многие дизайнеры создают дизайн проект который описывает каждую деталь дизайна. Они используют ряд инструментов для документирования интерфейсов, первые которые приходят на ум это axshare.com и zeplin.com. Тот же фотошоп, в котором у них все разложено строго по папочкам. Это позволяет им с легкостью работать над дизайном проекта, обновлять и добавлять новые страницы, просто копируя уже имеющиеся наработки.

Цель данной статьи — вместе с читателем написать окружение для разработки современных веб-приложений, последовательно добавляя и настраивая необходимые инструменты и библиотеки. По аналогии с многочисленными starter-kit / boilerplate репозиториями, но наш, собственный.

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

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

Этот перевод — для новичков, делающих первые шаги в JavaScript, или даже в программировании вообще.


JavaScript — мощный объектно-ориентированный (ООП) язык. Но, в отличие от многих других языков, он использует ООП-модель на основе прототипов, что делает его синтаксис непривычным для многих разработчиков. Кроме того, JavaScript работает с функциями как с объектами первого класса, что может путать программистов, не знакомых с этими концепциями. Можно обойти их, применяя производный язык вроде TypeScript, имеющий знакомый синтаксис и предлагающий дополнительные возможности. Но такие языки всё-равно компилируются в чистый JavaScript, и простое знание об этом не поможет вам понять, как они работают на самом деле, а также когда целесообразно их применять.

О чём мы поговорим в этой статье:

• Пространство имён.
• Объекты.
• Объектные литералы.
• Функции-конструкторы.
• Наследование.

Читая чат русскоязычного react сообщества в телеграмме (https://t.me/react_js), я вижу как с постоянной регулярностью появляются обсуждения mobx-а, сравнения с redux-ом с аргументациями про магию, сложность и "мутабельность" и у многих есть большое недопонимание что такое mobx и какие задачи он решает. И я решил написать эту статью с "разбором полетов" чтобы можно было собрать всю аргументацию в одном посте. Мы разберем как работает mobx изнутри путем реализации собственной версии mobx-а и сравним с тем как работает redux.

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



Кроме того, я разыскал некоторые старые демки, сделанные на TypeScript в самом начале работы над проектом (тогда он назывался Strada), для того, чтобы посмотреть их вместе с теми, кто работает над TypeScript сейчас.

Сегодня я хочу рассказать о том, с чего начинался TypeScript.

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

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

Перед вами четвёртая часть серии материалов, посвящённых внутренним особенностям работы JavaScript. Эти материалы, с одной стороны, направлены на изучение базовых элементов языка и экосистемы JS, с другой, содержат рекомендации, основанные на практике разработки ПО в компании SessionStack. Конкурентоспособное JS-приложение должно быть быстрым и надёжным. Создание таких приложений — та цель, к которой, в конечном счёте, стремится любой, интересующийся механизмами JavaScript.

В новой версии JavaScript есть только 2 новые функции. Вот как они работают.



Речь пойдет о последней версии JavaScript: ECMAScript 2016 (более известный как ES7). ES7 предлагает две новые функции: Array.prototype.includes() и новый экспоненциальный оператор: **

Facebook переписал большую часть React'а и выпустил 16 версию. React 16 был очень ожидаемым обновлением, особенно ввиду нового способа рендеринга Fiber, который сильно повышает производительность. Команда разработчиков React в последней версии усердно помечала методы и пакеты устаревшими (deprecated), и мы видели их предупреждения в консоли. В действительности же, миграция не так проста для большого проекта.

Мы в Discord только что запустили обновление нашего приложения на основе React 16 и хотим поделиться нашим опытом, который мы получили в ходе миграции.

Изображения — это, как правило, самая «тяжелая» статика в вебе. Многие фронтендеры знают об адаптивных изображениях, которые позволяют использовать определённые изображения для разных разрешений. Но это не единственный их плюс, ведь то, как и когда мы их загружаем, тоже влияет на скорость вашего веб-приложения.

На FrontFest 2017 к нам приезжает Хосе М. Перес (Jose M. Perez) из Spotify, с докладом «Progressive Image Rendering». Он расскажет о техниках прогрессивного рендеринга, основанных на плейсхолдерах, доминирующих цветах, размытых изображениях и ленивой загрузке, которые помогут улучшить производительность.

Накануне конференции мы поговорили с Хосе про веб-стек, релизы и управление процессами в Spotify, отношение к Open Source и погоду в Испании, Швеции и России.

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

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

С тех пор я потратил много времени, рассуждая о стиле кодирования и выбирая инструменты для его осуществления. Настало время что-то менять.

Тяжело выбрать, имея так много опций.

React стал open-source проектом в 2013. С тех пор он очень развился. Поискав в интернете, вы можете найти старые посты с разными подходами. Здесь я опишу восемь ключевых решений которые ваша команда должна поддерживать, когда пишут на React.

FrontFest — это улётная конференция для фронтенд-разработчиков, которая пройдет 18 ноября в Москве. В этой статье мы расскажем о том, что приготовили для вас в секции JS. Спикеры из Microsoft, Booking, 2ГИС, Wrike и Злых Марсиан поделятся опытом использования Preact, ClosureScript, React, JS для IoT и Angular.

Предыстория

Небольшое вступление для понимания “зачем мне это надо”. Так получилось, что организация, в которой я работаю, выпускает несколько продуктов, результатом работы одного из них является HTML документ. Продукты десктопные, и HTML документ приходится открывать в WEB-браузере с локального диска. Всё бы ничего, если бы не ограничения браузеров, которые работают на “движке” Chromium. В моём случае в “хроме” нельзя из одного iframe изменить src другого iframe. Вернее это ограничение можно обойти, если “хром” запустить с ключом: chrome.exe – allow-file-access-from-files. Но, к сожалению, это срабатывает только в том случае, если ни одной копии “хрома” не загружено. Всё это накладывает ограничения или, вернее, неудобства при работе с документами.

Практически каждый человек сталкивается с ведением какого-либо учета, сбором и анализом данных: от использования таблиц в экселе до работы с данными в клиент-банковском приложении. Повсеместно для такого учета используются различные системы управления базами данных (СУБД).

В статье я хотел бы рассказать о своем пути поиска такой системы.