JavaScript *

От переводчика: После позитивного отклика на прошлый выпуск дайджеста, я решил продолжить перевод этого популярного источника последних новостей из мира Ember.js.
Как и в прошлый раз ссылки на материалы, на которые я находил перевод, я помечал (рус). Все ссылки без пометки указывают на англоязычные ресурсы. И как и всегда, на русском вопросы можно задать в нашем ламповом телеграмм-канале

С Новым годом, Эмберисты!

На этой неделе мы хотим представить вам специальный номер нашего издания, посвященный Ember Octane!

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

В этом выпуске: что такое редакция Octane? ‍♀️‍♂️, где я могу узнать больше?, как перейти на Octane? ️, отзыв от компании Outdoorsy, покорить Octane с помощью Ember Atlas и Octane на EmberConf 2020 !

Два года назад я начал разработку еще одного свободного кодогенератора из OpenAPI Specification v3 в TypeScript (он доступен на Github). Изначально, я задался целью сделать эффективную генерацию примитивных и сложных типов данных в TypeScript, с учетом различных возможностей JSON Schema, таких как oneOf/anyOf/allOf и т.п. (у родного решения от Swagger с этим были некоторые проблемы). Другая идея заключалась в том, чтобы использовать схемы из спецификаций для валидации на фронте, бэке и в других частях системы.

Недавно заинтересовался, как устроена подсветка кода изнутри. Сначала казалось, что там все дико сложно — синтаксическое дерево, рекурсия и вот это все. Однако при более близком рассмотрении оказалось, что ничего трудного здесь нет. Всю работу можно проделать в одном цикле с заглядываниями вперед и назад, более того, в получившемся скрипте почти не используются регулярные выражения.

Демо-страница: Javascript Code Highlighter

Я начинающий JS front-end разработчик. Сейчас я учусь и стажируюсь в одной минской IT компании. Изучение основ web-ui проходит на примере JS библиотеки Webix и я хочу поделиться своим первым опытом и оформить, своего рода учебное пособие по освоению этой элегантной и мощной библиотеки. Помимо этого, команда Webix предлагает собственный фреймворк для работы с библиотекой. Детальное описание работы с фреймворком Webix Jet, вы можете найти в статьях «Фреймворк Webix Jet глазами новичка. Часть 1. Композиция и навигация» и «Фреймворк Webix Jet глазами новичка. Часть 2. Взаимодействие с интерфейсом»

Приветствую Хабр! Представляю вашему вниманию перевод статьи — Asynchronous Redux Actions Using Redux Thunk, автора — Alligator.io

По умолчанию, экшены в Redux являются синхронными, что, является проблемой для приложения, которому нужно взаимодействовать с серверным API, или выполнять другие асинхронные действия. К счастью Redux предоставляет нам такую штуку как middleware, которая стоит между диспатчом экшена и редюсером. Существует две самые популярные middleware библиотеки для асинхронных экшенов в Redux, это — Redux Thunk и Redux Saga. В этом посте мы будем рассматривать первую.

Недавно опциональный доступ к аттрибутам (Optional Chaining) и значение по умолчанию для атрибутов (Nullish Coalescing) перешли на последний, четвёртый этап процесса TC39.

На практике это означает, что эти и другие нововведения станут частью стандарта JavaScript уже в этом, 2020 году. Их мы и рассмотрим в этой статье.

Отслеживать поддержку браузерами можно здесь («2020 features») — прим. перев.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Five Interesting Ways to Use Array.reduce() (And One Boring Way)" автора Chris Ferdinandi.

Из всех современных методов работы с массивами самым сложным из всех, что мне пришлось использовать, был Array.reduce().

На первый взгляд он кажется простым, скучным методом, который мало что дает. Но, не смотря на свой скромный вид, Array.reduce() является мощным и гибким дополнением к вашему набору инструментов разработчика.

Сегодня рассмотрим некоторые интересные вещи, которые можно сделать с помощью Array.reduce().

Начнем

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

Многие зададут вопрос: «Почему не использовать готовые решения?». Проблема в том, что этот функционал либо вообще не реализован, либо сделан очень плохо. Можно использовать самое простое и плохое решение:

Те телефоны, о которых идёт речь в заголовке, по-английски называют «feature phone». Они отличаются крайне скромными возможностями. Кроме того, они весьма доступны, так как стоят в районе $20-25. Их можно сравнить с облегчёнными версиями современных смартфонов. Такие телефоны позволяют сотням миллионов человек из развивающихся стран пользоваться веб-ресурсами.


Телефон Jio

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

От переводчика:
Хотя в последнее время js-фреймворк Ember переживает новый период роста, в русскоязычном js-сообществе сохраняется мнение, что его уже никто не использует и он переживает упадок, повторяя путь Backbone. Отчасти причиной этому является отсутствие материалов на русском языке. Поэтому я хочу немного исправить эту ситуацию переводом дайджеста The Ember Times. Это дайджест новостей из мира Ember, популярный в сообществе. Предлагаю вам его самый свежий выпуск номер 129.
Ссылки на материалы, на которые я находил перевод, я помечал (рус). Все ссылки без пометки указывают на англоязычные ресурсы.

С праздником, Эмберисты! ️

Темы этого выпуска: Знакомьтесь с Ember Octane, новый ember-autofocus-модификатор, 3 новых RFC для шаблонных помощников (template helpers) 3️⃣, выпущен ember-apollo-client v2 и, наконец, приглашение присоединиться к инициативе DecEmber. Осталось 1️⃣1️⃣дней!

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

Привет, Хабр! Представляю вашему вниманию перевод статьи «On let vs const» автора Дэна Абрамова.

Мой предыдущий пост содержит такой параграф:

let vs const vs var: Обычно, все что вам нужно, — это let. Если вам нужно запретить перезаписывание переменной, вы можете использовать const. (Некоторые очень педантичны по этому поводу и предпочитают использовать const, когда бывает только одно назначение переменной).

Это утверждение оказалось очень спорным, на Twitter'e и Reddit'e сразу же начались жаркие обсуждения по этому поводу. Похоже наиболее популярное мнение (или по крайней мере, устно высказанное большинством) это то, что следует всегда использовать const и обращаться к let только при необходимости, что может быть обеспечено ESLint правилом prefer-const.

В этом посте я коротко перечислю все за и против, которые я встретил, и выскажу свое личное мнение по этому поводу.

Тренер дает наставление перед игрой:
— Вот ты, Иванов, сколько забьешь бразильцам? Ты же старший ответственный нападающий, мне нужна точная цифра!

Верстаешь экран, и как-то лого не так в правом нижнем углу, начинаешь двигать его вправо-влево-вниз, фигак — уже на обед зовут, два часа улетели куда-то. Или вот сложный таск, разбил его на части: библиотечный и клиентский код; пилишь скромную библиотечку, прям хорошо! Тестами обложил, но в душе знаешь, что будут изменения под клиентский код (а там и тесты нужно будет править :(

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

И потом оправдываешься: но вы же знаете, есть три стадии написания кода: 1) сделай, чтоб работало; 2) сделай, чтоб работало правильно; 3) сделай, чтоб работало быстро. Ну ok, до третьей стадии редкий фронтэнд-разработчик допишет, но все же — код был переписан дважды. Или так подробно разъясняешь: любой html разработчик решает задачу: a) просто и неправильно; затем б) сложно и неправильно; затем в) сложно и правильно; затем г) просто и правильно. И это не так просто — многие начинают с пункта «б», да там и остаются.

Примечание переводчика: в текущий момент я подготавливаю материалы для обещанной статьи по монадам. К сожалению, это занимает довольно много времени, не говоря о том, что я всё же должен заниматься основной работой и уделять время семье, но процесс идёт. А пока представляю вам перевод небольшой свежей заметки от замечательного товарища Mark Seemann'а, которая мне показалась любопытной.

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

Церемонность

Люди, которые предпочитают динамически типизированные языки статически типизированным, часто подчеркивают тот факт, что отсутствие церемонности делает их продуктивнее. Это звучит логично, однако, это ложная дихотомия.

Церемония — это то, что вы делаете до того, как начнете делать то, что вы действительно собирались сделать.

Venkat Subramaniam

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

Это привело меня к мысли о том, что существует злосчастная Зона Церемонности:

Конечно же, эта диаграмма всего лишь упрощение, но я надеюсь, что она демонстрирует суть. C++, Java и C♯ — языки, которые требуют церемонности. Справа от них находятся языки, которые мы могли бы назвать транс-церемониальными, включая F♯ и Haskell.

Привет, Хабр! Представляю вашему вниманию перевод статьи «How to optimize image loading on your website».

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

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

Проблема

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

На КДПВ — стикер, созданный командой браузера Samsung Internet

Больше 12 лет прошло с тех пор, как Стив Джобс впервые представил идею веб-приложений, «которые выглядят и ведут себя точно так же, как и нативные приложения». Больше 4 лет прошло с момента появления термина «PWA». Что из себя представляют прогрессивные веб-приложения в начале 2020 года? Что из того, что было добавлено в экосистему в 2019 году, вы могли упустить? Давайте выясним.

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



За многие годы я сформировал ментальную модель JavaScript, которая дала мне ощущение уверенности. Здесь я собираюсь поделиться с вами весьма сжатым вариантом этой модели. Её структура напоминает словарь. Каждое понятие описано в нескольких предложениях.

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

TypeScript стал одним из необходимых навыков для современного веб разработчика. В 2019 он вошел в ТОП-10 наиболее используемых языков на GitHub, его поддержку полностью добавили в Create react app, и можно найти массу других свидетельств роста его популярности. В то же время такие языки, как Java и C продолжают сдавать позиции.

Когда мы говорим о преимуществах TypeScript, на ум обычно приходит следующий список:

• TypeScript поддерживает статическую типизацию
• TypeScript делает код проще для чтения и понимания
• TypeScript помогает избежать множества болезненных багов, которые обычно совершают разработчики, благодаря проверке типов в коде
• TypeScript поощряет разработчиков следовать лучшим ООП практикам
• Как следствие вышеперечисленного — TypeScript экономит время разработчиков

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

В мире серверного JavaScript'а я — новичок с чистым, практически незамутнённым разумом. Поэтому когда я узнал о существовании менеджеров процессов, а конкретно — о pm2, то сразу же попробовал применить его для запуска какого-нибудь простейшего backend-сервиса на nodejs в целях самообразования. Мне очень импонирует возможность подключения модулей в JS-коде через import (ES6 modules), т.к. он позволяет использовать один и тот же код как в браузере, так и на серверной стороне, и я запилил простой сервис с ES6-модулями.

Если вкратце, то запустить ES6-версию приложения под pm2 у меня не получилось, для запуска таких приложений лучше использовать либо forever, либо systemd. Под катом — отчёт о результатах для тех, кто любит тексты подлинее.

Привет, Хабр! Представляю Вашему вниманию перевод статьи «Improve SPA performance by splitting your Angular libraries in multiple chunks» автора Kevin Kreuzer.

Angular — отличный фреймворк. Мы все его любим <3.

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

Сегодня благодаря Angular CLI библиотеки легко создать. Они прекрасно подходят для того, чтобы делиться кодом между несколькими приложениями.

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

В Frontend есть разные типы производительности. runtime — производительность и initial load. В этой статье мы сосредоточимся на initial load.

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