youngmysteriouslight

$ ls -lR > before
...
$ ls -lR > after
$ diff -u before after

Как-то так подойдет?

у вас видимо в PATH нет текущей папки.
И нужно выполнять
. ./config
что означает
source ./config
что означает
вызвать файл config из текущей ./ папки

p.s. По умолчанию, линукс не ищет файл для выполнения в текущей директории. Ищет строго по списку директорий, заданных в переменной PATH

Promise.all() принимает массив промисов и разрешается массивом результатов

let core = require('core');
    let promises = multipleElements.map(singleElement => core.somePromise(singleElement));
    Promise.all(promises)
        .then(resultArray => console.log(resultArray.join('')))

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

Это просто исторически сложилось, и связано не столько с операционной системой, сколько с файловой системой.

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

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

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

requirejs умеет только в amd, то есть с commonjs-модулями (а в npm подавляющее большинство такие) и тем более es6 ничего не получится. В общем и целом, брать его сейчас смысла нет.

webpack + code splitting ответ на ваш вопрос.

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

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

Ответ концептуальный. Ромбическое наследование. От А наследуются B и C, от них обоих наследуется D.
1) Если в A есть поле, в D что, это поле будет в двух экземплярах? А если оно protected и в B мы добавили метод, который его меняет?
2) Если B и C переопределяют какой-то метод foo(), как быть D? А если нужна и версия B.foo(), и C.foo(), и они обе вызывают A.foo — получатеся D.foo вызовет A.foo дважды? А если в C есть второй метод bar(), который вызывает foo() и начинает вести себя не так, как надо, если мы берём реализацию B.foo()?
В общем, множественное наследование — хорошая штука, но ромбическое — штука опасная. В языке, где любое множественное наследование неизменно ромбическое, всё, что остаётся — делать такие условия, при которых ни 1, ни 2 не сработает.
Одно из таких условий — унаследоваться от одного класса и нескольких интерфейсов. 1) У интерфейса нет полей, и 2) эталонная реализация, существующая в некоторых языках программирования, в любом случае менее приоритетна, чем конкретная реализация из класса. Вызывать ту и другую нет смысла: если программист написал свою сверх эталонной — значит, он хочет сделать то же другим путём.

Если при этом нет csrf, xss и этот код не может изменить хакер, то безопасно .

"Client-side и Server-side" и "Frontend и Backend" - это абсолютно разные и никак не связанные понятия

Клиент - это приложение, которое делегирует часть своего функционала другому приложению - серверу
Сервер - это приложение, которое обслуживает множество клиентов, предоставляя им свой функционал
Frontend - это часть приложения, отвечающая за интерфейс (GUI, CLI, etc.), то есть то, что непосредственно видит пользователь, с чем пользователь взаимодействует
Backend - это часть приложения, отвечающая за бизнес логику, за фоновые задачи, за то что скрыто от пользователя

Практически любое приложение содержит backend часть, не зависимо от того клиент оно, сервер или вообще работает без клиент-серверного взаимодействия
frontend часть может содержать как клиент, так и сервер, хотя сервера содержат ее не часто
Яркий пример - X.org (сервер GUI в Linux и некоторых других *nix системах) содержит frontend часть - рисует на экране, получает пользовательский ввод (клавиатура, мышь, джойстик, etc.), а простейшие WindowManager (например awesome), являющиеся клиентами по отношению к X.org, frontend части не содержат

Конкретно в web это идет с тех времен, когда вся логика была на сервере, а на клиенте были статичные html страницы, а js использовался только для красотулечек-финтифлюшечек

P.S. Еще про web, а конкретно про его клиентскую часть, то есть браузер:
Когда пишем html, css - это frontend (пусть "чистые" верстальщики порадуются)
Когда пишем js код взаимодействующий с DOM, CSSOM, рисующий на Canvas - это frontend
Когда в js обрабатываем пользовательские события (keyup, click, focus, touchstart, etc.) - это frontend
Когда на js производим расчеты, проверки ввода, вешаем таймеры, работаем с локальными хранилищами, отправляем ajax запросы - это backend
Когда обрабатываем такие события как load, message, DOMContentLoaded - это backend
Код работающий в WebWorker'е - это backend
Продолжать можно долго, суть думаю ясна

Можно использовать bind:

setTimeout(function() {
  console.log(this.resorts.join(', '));
}.bind(this), delay);

Или в переменную сохранить текущий контекст до вызова setTimeout и использовать её вместо this:

var that = this;
setTimeout(function() {
  console.log(that.resorts.join(', '));
}, delay);

const result = arr.reduce((a, b) => a + b.sum, 0);

// let result = 0;

// for (let i = 0; i < arr.length; i += 1) {
//     result += arr[i].sum;
// }

поставить обратный слэш перед долларом? не?

Чисто технически, в конструктор могут прилететь свойства, которые будут участвовать в создании методов(методы в своем замыкании будут хранить их значения), а в инстанс самого объекта они не попадут, потому и методы прототипа к ним достучаться не смогут. И еще одно отличие в shadowing-e, если у инстанса есть метод и с таким же названем есть еще и метод в прототипе, то вызовется метод инстанса.

А на деле, если есть цепочка наследования, то наследуются от .prototype через Object.create(), т.е. методы контруктора унаследованы не будут. Удобно, если мы этого не хотим (но так тоже бывает редко, потому что обычно вызывается родительский конструктор).