Основные Web API

[torsar]

Web API очень много развелось
(смотрел MDN)

Накидайте основных, которые надо знать.
Типа Geolocation, localstorage и тд...

[ruslan_mart]

Да сами АПИ все запоминать смысла нет

Просто важно знать какие есть возможности у браузера и всегда уметь загуглить

Все зависит от специфики продукта, который вы разрабатываете

В классическом SPA важно знать инструкменты и фреймворки, нежели чем Web API.

Из основного/интересного я бы почитал: Web Workers, RedizeObserver. Intersection Observer. Proxy, CSS Painting, View Transitions

[voraa]

которые надо знать.

Которые надо знать для чего? Конкретно для работы или для собеседований?
Для работы я ни разу не использовал Geolocation и толком не знаю его. Просто знаю, что такое есть. Для работы мне в голову не придет использовать CSS Painting и View Transitions потому, что их пока нет в файрфоксе и сафари.
Для работы надо познакомится со всеми, а использовать и хорошо знать только те, что реально используются. С остальными достаточно просто познакомится, что бы представлять, что они могут дать. Вдруг когда-нибудь пригодятся.

[webgraph]

Да сами АПИ все запоминать смысла нет

Просто важно знать какие есть возможности у браузера и всегда уметь загуглить

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

Первоначально отталкивайтесь от поставленной задачи. На основании этого будет ясно понять на какие API обратить внимание и что использовать в своём проекте.

• Используйте Can I Use для тестирования поддержки браузерами.

Вообще для работы с DOM и сетевыми запросами часто используются:

/*
*
Часто используется для работы с DOM и Request
*
*/
//1. 
const items = document.querySelectorAll(''); // выбираем необходимые элементы, н-р, все ссылки на странице или какие-то блоки с определенным классом

//2. 
items.forEach((element) => {}); // перебираем выбранные элементы из п.1 и работаем с каждым по отдельности

//3. 
element.addEventListener('event', () => {}); // отлавливаем события конкретного элемента, например, когда на него нажали и т.д.

//4. 
fetch(); // отправляем запрос по url — н-р, для работы со сторонними API

Главное чтоб у вас был интерес к выбранному API, потому что одну и ту же задачу можно решить разными способами. А интерес может как раз таки зависеть от скорости выполнения задачи и понятности кода. Поэтому стремитесь к реактивности и отказоустойчивости решения. Тестируйте разные варианты.

[voraa]

items.forEach((element) => {}); // перебираем выбранные элементы из п.1 и работаем с каждым по отдельности

С таким же успехом можно использовать

for (const element of items) {
}

Как + не тратится время на вызов функции.

[webgraph]

Как + не тратится время на вызов функции.

хм, интересненько) а если надо индекс еще, то как тогда?)

Плюсом со стороны forEach — это быстрое и наглядное понимание и чтение кода. Видно вначале, что это массив и что он перебирается.

Работа с forEach, более того, несколько последовательнее и от того проще)

Даже и не припоминается, когда последний раз for() использовался)

[webgraph]

С таким же успехом можно использовать

а если надо массив налету создать?

['item1','item2'].forEach((e) => {
        ...
});

//P.S. достаточно часто такая конструкция используется


С помощью for() так тоже можно?)

[voraa]

а если надо массив налету создать?

['item1','item2'].forEach((e) => {
        ...
});

[QUOTE=webgraph]Плюсом со стороны forEach — это быстрое и наглядное понимание и чтение кода. Видно вначале, что это массив и что он перебирается.[/QUOTE]

Дело привычки. Видно, что в цикле что то перебирается

[ruslan_mart]

С помощью for() так тоже можно?)

Конечно

for (const item of ['item1','item2']) {

}

Но это быдлокод

Используйте forEach, нет смысла экономить на вызове функций, если вы не пишите ПО для очень слабых систем или какую-то библиотеку.

К тому же, есть вероятность, что в проекте for..of может транспилиться в другой код для поддержки совместимости, а это на выходе будет еще больше функций-оберток, нежели чем forEach.

Обычно for циклы полезны, чтобы сделать преждевременный break. Но опять же, зависит от конкретной задачи, так как может быть достаточно методов find/some.

[voraa]

К тому же, есть вероятность, что в проекте for..of может транспилиться в другой код для поддержки совместимости, а это на выходе будет еще больше функций-оберток, нежели чем forEach.

В этом случае и для forEach будет использоваться полифил, что тоже скажется на времени.
Ну и про наглядность - по мне вложенные for нагляднее, чем вложенные forEach (а по скорости еще лучше, т.к не тратится время на создание и компиляцию вложенной функции)