Для дебагу коду на JavaScript використовуйте консоль браузера. Для цього натисніть Ctrl+Shift+I, і у тій панелі, що відкриється, натисніть закладку «Console» (ну чи «Консоль»).

Там ви зможете використовувати console.log(); для перегляду вмісту будь-якого типу. У вашому випадку ви можете вивести в консоль об’єкт arguments:

function showMenu({title: menu, size = 10}) {
  console.log(arguments);
}

showMenu({title: 1, size: 25});
// Arguments[0]: {title: 1, size: 25}

showMenu({title: 1, size: 25}, 222);
// Arguments[0]: {title: 1, size: 25}
// Arguments[1]: 222

В даній консолі при натисненні на Enter відбувається виконання коду. Щоб написати багаторядковий код, Enter слід натискати разом із Shift.

Ви зациклились на «ієрархія, не ієрархія», «рівні права, не рівні права». Ви ж не вирішуєте устрій великої компанії... Задача корисної платформи для кооперації фрілансерів може полягати наприклад в тому, щоб автоматизувати виявлення потрібних фрілансерів, щоб автоматизувати координацію їхніх дій, щоб автоматизувати виплату їм ЗП і т.д.

Кооперація між фрілансерами потрібна, ваша платформа — ні.

Чому? Тому що «равные права в кооперативах» мабуть взагалі ніколи не потрібні. Значно важливіше: зробити вчасно свою роботу і отримати вчасно відповідні гроші.

Перше що спадає на думку — модель роботи, по якій працює таксі Uber. Тобто, Uber пропонує платформу, завдяки якій враховуються інтереси й можливості замовника, інтереси, можливості і рейтинг виконавця і т.д.

От якщо б вам вдалось збудувати аналогічну платформу для фрілансерів, зірвали б джекпот.

Назар, сподіваюсь вам не більше 14 років, бо якщо більше...

Колись і я десь в 12-14 років був злий на людей, що вони віддаляються від природи, виготовляють сурогати, замічують навколишнє середовище і т.д.

Дорослі люди мають пропонувати конкретні рішення для конкретних проблем...

Спікери будуть говорити англійською? Чому питання у формі англійською? Чи це банальний випендрьож?

Всякий раз, коли тільки можливо, пиши анонімні функції. Їх значно легше рефакторити: одразу видно що вони ніде більше не використовуються, ні з чим більше не пов′язані.
wrap — змінна не потрібна, напиши просто «return function» і це буде зрозуміло.

Анонімні функції важче дебажити, в порівнянні з іменованими. Тобто якщо навіть в коді логіка не змінюється return function() { } чи return function someName() { }, дебажити краще другий варіант, хоча — так, читати краще перший.

Якщо цю жесть написали ви (як джуніор) щоб розібратись з особливостями роботи функцій в JavaScript, то це ще куди не йшло... Але якщо це вас попросили розібрати на співбесіді, то не раджу йти в таку компанію, там вас нічому хорошому не навчать.

По задачці. Ось цим sum = throttle(sum, 1000); — ви встановлюєте функцію і час для setTimeout. Ось цим sum(1, 0); — ви спочатку встановлюєте значення для вашої змінної arg, але тут же перевстановлюєте його другим викликом sum(2, 0);, оскільки функція, передана в setTimeout, ще не встигла відпрацювати, а змінна arg видима для обох викликів.

Якщо змінну arg оголосити на початку функції wrap, то ця змінна буде видима лише в поточному виклику wrap, причому функція для setTimeout відпрацює лише за перше встановлення змінної time, оскільки у вас є умова if (time != undefined ) return;.

До речі, ось такою простою функцією можна згладити піки кількості викликів певної функції до прийнятного timeout:

var nextTime = 0, timeout = 1000;
 
function throttle(callback) {
  nextTime += timeout;
  
  setTimeout(function() {
      nextTime -= timeout;
      callback();
    },
    nextTime
  );
}

Користуватись можна так:

function callback() { console.log('called callback!') }
throttle(callback);
throttle(callback);
throttle(callback);
throttle(callback);
throttle(callback);
throttle(callback);

Posted by mediator: Ashdown Group

Чітко і ясно — як в рекламі...

Усі негативи є похідними від слабкостей чи від відсутності необхідних ресурсів.

Хтось не має фізичних даних, але може компенсувати це інтелектуальними даними, чи навпаки. Хтось сьогодні робить «так» лише через брак досвіду, а завтра зробить «по-іншому» і заслужено критикуватиме тих, хто робить «по-старому». Ще хтось йде в той же гемблінг, бо бо йому кажуть про це лише після прийняття офера... а у нього з англійською не дуже, через що він не є суперпопулярним серед роботодавців... ще й сів на фінансову мілину і т.д.

Ммда, ну і реакція на даний топік... Чергове підтвердження, що на ДОУ аудиторія дуже близька до аудиторії на eba..oe.it — жесть.

Тобто чмырь говорить діло, а я до нього придовбуюсь? Ти на стільки «повзрослела», шо так оцінюєш ситуацію? Хм, тоді мені так «взрослеть» як ти — не треба.

Ти молодець, чмырь, молодець! Он тобі і кожаєв плюсанув — це ваш із ним стиль. Так тримати! Ти заслужено носиш своє знамените прізвище!

отсеять объявления от посредников

Оцей єдиний пункт працював би як треба — ви зірвали б «джек пот» без купи інших фільтрів «з перламутровими пугвицами».

Кажу — одужуйте по-швидше!

Ну я і калашом вмію користуватись, головне ж інше...

Так, згоден. Але з огляду на мотиви, озвучені в даній темі, очевидно, що він йде на поправку.

Поставте себе на місце рекрутерів. Дивилися б ви на github, якщо б кандидат на вакансію говорив, що він шарить, але показати свої роботи не може, бо усі проекти були закритими? Навіть якщо кандидат говорить, що приймав участь у створенні певного сайта, то що там можна побачити чітко, окрім HTML-верстки?

Однозначно — відкриті проекти на github варто створювати, ну або робити Pull Requests у відомі проекти, якщо вам є що їм запропонувати. А якщо у вашого проекта з’являться ще й зірочки на github, чи у нього буде солідна статистика скачувань, наприклад, з npmjs.com... Рекрутери це точно оцінять.

Аутентифікацію та авторизацію я привів лише, як приклад.

Ви навели цей приклад в контексті аргументації своїх слів про «більшість логіки на бекенді»...

І авторизація на клієнті... серйозно? Можете розкрити детальніше, що Ви маєте на увазі?

Так, серйозно. Ви сумніваєтесь, що можна на клієнті прописати роль користувача і його право заходити на певні закрити сторінки?

Завантажити header&footer та відрендерити простий html може бути не такою вже і великою проблемою в порівнянні з перевантаженою логікою, яка буде «перегрівати» процесор.

А для чого порівнювати «перевантажену логіку» із «неперевантаженою»? Якщо вас цікавить SPA і не SPA архітектура, то для початку беріть однакові умови, порівнюйте їх... А тоді ще зважте додаткові можливості SPA-архітектури, що абсолютно недосяжні для «статичної» архітектури...

Для чого скажімо деякі фреймворки мають сервер-рендерінг режим?

У вас явно не вистачає терпіння погуглити, почитати документацію на цю тему... а без цього в розробці ніяк...

Вам показати кількість вакансій на сайтах пошуку роботи для першої версії Angular? Ви зможете протиставити якийсь інший фронтенд-фреймворк, що згадується більше разів в описі вакансій?

По-моєму, це значно вагоміший аргумент, ніж кількість сервісів Google, написаних на Angular.

1) Оскільки ідея SPA працювати на одній сторінці, значить все, що в принціпі вміє ваша програма має поступово підвантажуватись до пам’яті браузера? Якщо це не пару хелло ворлд екранів, це все здатно суттєво роздути пам’ять на клієнті. А можливостей звільняти(вивантажувати зайві скрипти), начебто в сучасних браузерах немає?
Тобто вони дуже не ефективні для серйозних програм з велигою кількістю різних екранів, функцій?

В Angular v2+, слід враховувати мабуть чотири базові поняття в цьому плані:

1. Сервіси, чиї дані можуть зберігатись у пам’яті браузера, поки користувач не покинув поточний application. Хоча ці дані можна, звичайно ж, видаляти коли заманеться.

Angular має дуже гнучкий інструмент — Dependency Injection — він дозволяє створювати довільну ієрархію і відповідну тривалість життя інстанса сервіса. Наприклад, якщо вам потрібно щоб дані завантажувались, існували й видалялись при кожному зверненні до певного компонента — немає проблем — передавайте провайдерів для dependency injection на рівні компонента.

2. JavaScript DOM-дерево, де кожна частина живе у пам’яті браузера, до поки її не видалили. Якщо користувач переходить від одного компонента до іншого, в’юха попереднього компонента видаляється з DOM-дерева й пам’ять браузера звільняється.

3. Функції, що виконуються асинхронно, наприклад, setTimeout, setInterval, код, написаний на RxJS. Тут дійсно можна написати код, що призведе до витоку пам’яті, але цього не знають хіба що джуни...

Angular автоматично відписується від RxJS Observable, якщо його код зустрічається у в’юхах або у HttpClient. В усіх інших випадках потрібно обов’язково відписуватись від підписок на нього.

4. Service Workers, за допомогою яких браузер зберігає кеш даних, що беруться з бекенда. Ця фіча поводить себе також досить контрольовано, тому вона зберігатиме тільки те, що ви скажете їй зберігати. Серед іншого, вона дозволяє емулювати запити на бекенд навіть при відсутності підключення до інтернету...