Хабр, я не буду сообщать тебе об ошибках на твоем сайте

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

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

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

Естественно будут и исключения, когда номер телефона зарегистрирован на левого человека или использованы сервисы "анонимной" электронной почты. Однако и связка указанная Жаровым как достаточная для идентификации (Фото + ФИО + Номер телефона) фактически не более чем просто Номер телефона и подвержена тем же проблемам.

И даже если номер телефона левый, а почта "анонимная" это ещё не значит, что больше нечего запросить ни у провайдера ни у администратора домена.

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

Т.е. это как ответ на ваш посыл поста:

даже если я не авторизованный, не требуйте от меня мои данные за то, что я вам же отправляю бесплатные багрепорты

Бесплатные это хорошо, но ещё лучше если это действительно репорт об ошибке, а не обыкновенный спам через форму обратной связи.

В конце концов, как с вами связаться, если вдруг вам решили заплатить за найденный баг?

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

Contact Picker API, или как поделиться своими контактами с браузером

Этот API даже не учитывается в списке прав (соответственно ни как не относится к воркфлоу запроса прав). Как выше указали данный API использует по сути внешний интерфейс (на уровне браузера).

В данном случае нет необходимости в запросе постоянных прав (до отмены через интерфейс браузера) на доступ к API т.к. воркфлоу API уже подразумевает единоразовую выдачу права (каждый вызов является единоразовым запросом) пользователем через взаимодействие с интерфейсом браузера (подтверждение выбора = право предоставлено, отмена действия = право не предаставлено).

К слову это не единственный API с подобной реализацией (единоразовый доступ):

• Contact Picker API (доступ к контактам — пользователь сам выбирает каким)
• File API (доступ к содержимому файлов — пользователь сам выбирает каким, одно из первых API с подобным воркфлоу)
• Native File System API (доступ на изменение файлов/директорий — пользователь сам выбирает каких)
• Web Authentication API (доступ к ключу — опять таки пользователь выбирает к какому)
• Payment Request API (доступ к платёжной информации в т.ч. Google/Apple/Samsung/etc. Pay — аналогично)
• Web Share API (вызов/доступ к внешним приложениям — снова пользователь выбирает)

В этот же список можем добавить ещё:

• Install Banner API (запрос на добавление PWA, отличается от выше перечисленных автоматическим вызовом)
• User Activation API (как пример влияет на воспроизведение аудио/видео на мобильных — только после взаимодействия пользователя со страницей)

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

Единственное все эти API со временем можно интегрировать с User Activation API в случае злоупотребления ими как со всплывающими окнами. Т.е. если во временном окне вызова API пользователь не взаимодействовал со страницей (клик), автоматически отказывать в доступе.

Есть ещё API с альтернативной выдачей разрешения:

• SMS Receiver API (доступ к содержимому следующего входящего SMS — вызов = запросу, разрешение = содержимое SMS содержит ссылку на страницу, запрет не предусмотрен = бесконечный Promise пока не придёт SMS подходящее под критерий разрешения. Я видел вариант с дополнительным запросом разрешения по типу как у Install Banner API)

По поводу User Activation API к сожалению пока это API только Chromium-based браузеров и доступен как navigator.userActivation, однако технически в других реализациях (только internal use only) имеется в Safari и Firefox для тех же изначально нужд по авто воспроизведению медиа контента.

Contact Picker API, или как поделиться своими контактами с браузером

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

В том то и дело, что идут стандартным проторенным путём с флагами в chrome://flags и тестированию на обычных пользователях это так же особо не мешает т.к. для этого и сделали Origin Trials. По сути Origin Trials это токен, который включает необходимый флаг на конкретном сайте.

Для примера YouTube ещё в процессе перехода на Custom Elements v1 и как минимум с середины 2019 года у них на страницах имеется Origin Trials токен на Custom Elements v0, которые в свою очередь в флагах по умолчанию выключены.

Но зачем они добавляют свои "идеи" в стандартный объект navigator – непонятно.

По сути они заранее пишут свою идею как кандидат в стандарты, сразу завязанный на имеющихся стабильных API иначе пришлось бы после Proof of Concept реализации в движке и принятия спецификации как стандарта переписывать эту самую реализацию Proof of Concept.

Т.е. в данном случае они по мимо спецификации (сухого описания как и что) предоставляют ещё Proof of Concept реализацию для возможности сбора фидбека в процессе стандартизации. По итогу конечный вариант Proof of Concept реализации становится эталонной реализацией.

Yarn 2 — с Prolog'ом и плагнплеями

С unpkg.org всё вполне в порядке, хотя и не всегда ES Modules работают как надо. Я просто вкинул довольно новый проект, у которого слегка иной подход. И если я не ошибаюсь как раз у pika.dev есть поддержка import maps и их генерация. pika.dev пытаются стать именно универсальным регистром пакетов, который будет работать как в браузерах так и на серверах в Deno.

Yarn 2 — с Prolog'ом и плагнплеями

Для веба могу обратить внимание на pika.dev, позиционируют себя как условно браузерный npm (cdn с пакетами из npm), ES Modules-first. У них есть ещё утилита, которая под веб собирает и бандлит по пакетам все зависимости в отдельную папку.

Let vs const — что использовать?

Я немного обобщу, в общем и целом проблемы в выборе let и const нет, минус названный вами в сторону const вами же отображен и на let. Описанный подход prefer-const и вами prefer-let по своей сути идентичны +- (просто инверсия). 99.9% замена const на let ничего не ломает и эти же проценты переиспользование let тоже, однако всегда есть 0.1% когда это приводит к багам.

Соответственно стреляет не let и не const (шансы у них примерно равны), а непосредственно разработчики, которые либо невнимательны, либо безответственны, а иногда и то и другое.

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

Let vs const — что использовать?

Случайный дубль комента по двойному клику. Хабр стоит переводить кнопку в disabled по первому клику.

Let vs const — что использовать?

Сравните с вариантом, когда у вас одно объявление и — внезапно — нужен let. Вроде же по-русски писал, одно с другим связать не можете?

Вы лучше сразу пример приведите, как я просил с самого начала. Если у вас одно объявление и внезапно понадобился let, сделайте новое в чём проблема?

Речь не о можно, а том, что в случае const нельзя иначе. Вы вообще обдумываете свои решения или идёте на поводу толпы?

Речь именно о можно и нужно. В случае с const можно иначе и это let. Вот серьёзно в каком месте не понятно моё краткое объяснение правила prefer-const? "Если вы не меняете ссылку на значение — const иначе let". Где явно случай с вашим тернарным const лучше реализовать через let и с нормальными if. Это правило обращаю внимание не противоречит тому, что вы "пытаетесь донести" не вникнув в то, что я вам писал изначально. Вот для начала сами по обдумывайте то о чём говорит собеседник.

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

И уж тем более я не "иду на поводу толпы" т.к. эта самая толпа категорически против приватных полей у классов в JS с текущим синтаксисом #fieldName. Я же в этом синтаксисе вижу плюсы: 1. хард приватность, а не "соглашение о приватности", нарушается постоянно; 2. сразу синтаксис показывает, что это приватное поле и не нужно вносить опять таки "соглашение по именованию приватных полей". Тут всё принёс язык и это хорошо.

Просто? Разговор с того и начался, что prefer-const не даст вам просто поменять, потому что при деструктуризации останутся незименные переменные.

Просто и про останутся неизменные переменные, ну и пускай останутся. Чем это мешает вам? Вот серьёзно это такая придирка ну серьёзно с натяжкой. Я просто вынесу из const необходимую/мые переменные в let и всё, если это одна, то можно вообще даже в let не пихать если задуматься.

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

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

Впрочем, вы даже на русском неаккуратно пишите.

Ну и как обычно, что в прочем не удивительно по "идёте на поводу у толпы" это попытка съехать на личности. Вероятно вы сами не менее плохо пишите код, с уверенностью в своей правоте.

P.S. Вдобавок, ниже уже привели ссылки на статьи, почему const не работает. Как верно подмечено, prefer-const заставляет использовать const, когда так совпало, что переменная не изменяется, а не только когда она реально должна быть константой.

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

Ну и теперь я пишу, что вы идёте на поводу у толпы, которая категорически не приемлет использование const в тех ситуациях, для которых и разрабатывалось это ключевое слово. Даже в proposal на эту фичу были примеры из ряда prefer-const, однако опять таки никто не читает документацию, и следует правилу "в других же языках так, значит и тут так и по другому не может быть".

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

Let vs const — что использовать?

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

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

Let vs const — что использовать?

Возможно вы немного промахнулись и писали Aingis. Я же совершенно как и вы использую prefer-const.

Let vs const — что использовать?

А теперь сделайте имена реально длины и вложенности (settings.product.someParams) и добавьте ещё пару переменных, и вместо искусственного примера сразу увидите раздутие.

Хорошо, вот тот же отрывок с "реальной длинной":

const { width, title } = settings.product.someParams
let { height, aspect } = settings.product.someParams

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

А нужен let затем, зачем и в топике написано. Чтобы, например, не делать плохо читаемые вложенные тернарники, а нормально читаемые последовательные if'ы.

Это уже аргумент с натяжкой т.к. эти же тернарки можно писать и в let и в var. Это уже зависит от разработчика и его желаний сократить код. А вообще это вопрос умения применять тернарки, если правильно оформлять, то и вложенные не будет особых трудностей читать. И да конечно же везде, где можно обойтись без тернарок или сложность условий велика лучше и нужно использовать if.

Вообще исходный код должен быть читаемым, а то, что пойдёт в продукт уже будет обработано каким-нибудь Terser'ом.

Что значит «нежелательных»?

То и значит. Иногда сломать весь код можно и банальным случайным или намеренным изменением значения переменной. К примеру, вот ожидаете объект и выполняете запрос к полю foo.bar, а выше какой-нибудь "Вася" в каком-нибудь if'е на каком-нибудь условии без церемоний записал в ваш let foo значение null. По логике "Васи" всё верно т.к. foo в конечном итоге возвращается из функции.

Вы либо меняете, либо нет. Не знаете что пишете?

Я может и знаю, что пишу, а вот те кто будет потом поддерживать и дальше развивать код не знают этого.

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

Не окажется, я просто изменю первоначальное ключевое слово const на let и всё, остальной код как работал так и будет работать. А если использовать хорошие инструменты, то они вообще сами эту работу выполнят.

Проблема надумана, как и остальные доводы. Ни разу не встречался на практике.

Если вы не встречались, не значит, что проблемы нет. Я вот на практике видел такие ситуация. Это из той же оперы, когда вы начинаете использовать "приватные" поля и методы классов, по тому, что так быстрее получаете данные, а то, что упускаете/провоцируете сайд-эффекты и т.д. без разницы.

Let vs const — что использовать?

Почему?

const options = {
    width: 100,
    height: 200
}

const { width } = options
let { height } = options
height += width / 16 * 9
options.height = height

А вообще ключевое, всё-таки если вам надо менять ссылку на значение в переменной, делайте её let иначе const. Это и есть всё правило.

const options = {
    width: 100,
    height: 200
}

const { width } = options
let { height } = options
height += width / 16 * 9
options = { ...options, height }

Но не проще ли в подобном случае сразу делать так:

const options = {
    width: 100,
    height: 200
}

options.height += options.width / 16 * 9

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

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

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

Относительно последнего абзаца я кстати пробовал и TypeScript и Flow, а в итоге вернулся к чистому ECMAScript с документацией в комментариях по типу JSDoc/ESDoc. VSCode совершенно спокойно распознаёт эти комментарии и выдаёт всё те же подсказки по типам, что и с TypeScript. И в данной ситуации не требуется компилировать в JS/ES и нет проблем с идеологией как у TypeScript (в частности по приватным полям).

Let vs const — что использовать?

Сравниваете не сравниваемое, если в const из ECMAScript хранить примитивы (которые по своей природе immutable), так же как вы это делаете в других языках с приведёнными величинами (G, PI, e, etc.), то отличий никаких эти константы полностью иммутабельны т.к. ссылка на них иммутабельна и значения-примитивы тоже иммутабельны.

Если же вы храните в const объект (мутабельный по умолчанию), то и получаете иммутабельную ссылку на мутабельный объект. Чтобы объект был иммутабельным нужно его залочить Object.freeze() (блокирует конкретный объект).

const immutableObject = Object.freeze({
    name: 'Alice',
    age: 25,
})

Данный пример полностью иммутабельный т.к. мы используем иммутабельную ссылку, на иммутабельный объект с иммутабельными значениями переменных.

Главное понимать, что var, let, const это всё переменные, которые в сущности являются просто ссылками на значения, соответственно ключевое слово влияет только на область видимости и мутабельность этой самой ссылки, но никак не значения.

Let vs const — что использовать?

Самое правильное с моей точки зрения это правило prefer-const из eslint. Кратко и просто: Если переменную не перезаписываем, то const. Иначе let. Больше никаких рассуждений не нужно.

function processItems(id) {
   const items = fetchItems(id);
   for(const item of items) {
        doSomething(item)
   }
}

В данном случае обе переменные const т.к. мы их не меняем (изменение атрибута переменной item не относится к изменению переменной).

Если мы меняем хранимое значение, то let:

let counter = 0
counter++

const object = {
    name: 'Bob'
}
object.name = 'Alice'

Грета Тунберг права? Самолеты VS поезда

Вот интересный момент, во всех этих статистических данных относительно Ж/Д транспорта в учёт судя по результатом брали только электрифицированные участки, однако не везде это возможно или целесообразно.

Новая эра веб-разработки или «всё уже есть»

Как только WebAssembly как-то взлетит клей в виде JS уберут.

Единственная такая перспектива, это встраивание WebAssembly как ES Module. Не более.

Новая эра веб-разработки или «всё уже есть»

Это вот как раз в тему что надо сделать поддержку не только отображения документов, но и приложений. В этом случае просмотр документов отдельно, запуск приложения отдельно. К чему в случае с webassembly и идем.

В случае с WebAssembly отображение будет либо через DOM API, что так же как и с JS. Либо отрисовка в Canvas, что опять таки так же как в JS. В любом случае WebAssembly вклеивается посредством JS.

А ещё так для информации есть инициатива у Google, Mozilla и Apple сделать бинарный формат JS. Т.е. будешь компилить, а на клиент будет прилетать уже готовый код такого же формата, что и для WebAssembly по сути.

Новая эра веб-разработки или «всё уже есть»

А флеш как-то изменял при этом документ? Насколько я помню нет. И его отсутствие только ломало возможность пользоваться функциями встроенного приложения и все.

Иногда весь документ был флешем на всё пространство HTML документа. Т.е. как для пользователя да меняло документ.

Новая эра веб-разработки или «всё уже есть»

Эммм что? Размер интерпретатора lua-5.1 у меня в системе 25 килобайт. Вместе с компилятором 200 килобайт. Бинарник nodejs весит 1.1 мегабайт. Его наоборот всюду тащат поскольку он легкий и хорошо встраивается.

Тяжеловат не в плане веса интерпритатора/кода/бинарника, а именно написания на нем вот этого всего. А ведь к этому всему всё-равно пришло бы в не зависимости от доминирующего языка.

Ну и ещё момент, стандарт ECMAScript это именно встраиваемый язык как и lua, JS реализует именно ECMAScript.

Только вот NodeJS с собой тащит ещё много всякого своего, там работы с операционкой, файлами, CommonJS модули. Всё это добавляет вес. V8 в чистом виде более лёгкий.

Новая эра веб-разработки или «всё уже есть»

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

Отлично, а макросы в MS Word или Excel это что? По моему макросы это как раз язык программирования и никак не вставки видео/аудио, однако это всё-ещё документы. Про потоки с камеры/микрофона, так вот во флеше я видел кучу ситуаций когда делали именно так в вебе. И в такой ситуации флеш ничем не отличается от того, что имеем сейчас.