Павел

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

https://developer.mozilla.org/ru/docs/Web/JavaScri...

Мне кажется вы всё делаете правильно. Вам нужно разделить компиляцию шаблонов и их выполнение, а затем обернуть выполнение в try catch.

let tpl = _.template('<%-data%>');
let html;

try {
html = tpl(params);
} catch (e) { logError(e); }

В таком случае, если не передали необходимых ключей, ошибка будет вполне вменяема:

ReferenceError: data is not defined
    at eval (lodash.templateSources[1]:9:5

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

Хотелось бы увидеть что-то вроде $someEl.find('a').where('href',someVar).

Напишите небольшой плагин, который добавляет тот сахар, что вам подходит, это очень просто же.

Используя $el.data() они не устанавливаются в DOM, как быть с этим?

Использовать дополнительно $el.prop().

итак, поскольку у нас слишком много вариантов "как оно может быть", мы должны разбить все на следующие вопросы:

1) как запрос идет от браузера к http серверу. В этом плане мы будем рассматривать apache как черный ящик. В этом плане разницы между apache, nginx, lighttpd и т.д. мы не увидим.

тут можно либо погуглить в общем, либо и этот впрос разбить на: почитать про DNS, прочитать про HTTP (это вообще разные вещи). Паралельно было бы неплохо почитать про стэк TCP/IP в общем, и разобраться что такое TCP и что такое UDP.

2) Далее, в случае с PHP, мы должны почитать про PHP SAPI. То есть в случае с apache у нас SAPI предоставляется модулем apache2-mod-php и тд. а php-fpm уже самодостаточный сервер и менеджер php процессов, который так же предоставляет свое SAPI. По сути это та штука, которая "разбирает" и готовит запрос для php. Ну и да, стоит сказать что уже есть HTTP сервера на PHP (как альтернатива php-fpm), это и ayres и php-pm и reactphp... и судя по динамиче это будет все больше развиваться.

3) как -только мы разобрались как работает браузер с web-сервером, и как php обрабатывает http, мы должны уже исходить из конкретной связки что бы понять как web-сервер работает с php. Предыдущий пункт с большего это покрывает, особенно в случае с apache. Но вот php-fpm самодостаточная штука, и ей ничего не нужно. А стало быть nginx просто будет проксировать запросы на php-fpm.

DELETE `ud`.*
  FROM `userdata` AS `ud`
  JOIN `ufields` AS `uf` 
    ON `ud`.`dataId` = CONCAT('ufi', `uf`.`dbIncrement`) 
    AND `uf`.`podvedId` = 'val' 
    AND `uf`.`formId` = 'val' 
    AND `uf`.`parentContainerId` = 'val' 
    AND (`uf`.`descriptor_y` = 'val' OR `uf`.`descriptor_y` = 'val')

Создавать по модели на каждое представление?

Модель в контексте MVC это не модель отдельных сущностей, а модель части системы (или всей системы), которая нужна для этой конкретной view. То есть представьте себе "модель" системы как нейкий объект, внутри которого есть другие объекты, которые работают с третьими и так далее. Такая вот иерархия. Так вот вьюшки выходит коннектятся каждая к своему кусочку этой иерархии, и по сути кроме этой точки соприкосновения ничего более о системе не знают. У них весьма ограниченное представление о системе и много знать им не надо.

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

Получается на каждую сущность по 20 моделей?

Тут есть несколько подходов, основной из них - не париться и просто в рамках определенного ресурса подсовывать тот кусок данных сущности который нужен. Все же не пихать в json как-то что-то проще чем пытаться достать то чего нет.

Так же есть подход, описанный в стандарте jsonapi.org, где у вас есть дополнительные параметры в query string, которые позволяют "включать" определенные группы связанных ресурсов и т.д. Это дает нам определенную гибкость в плане работы с API но в случае например мобильных приложений есть свои нюансы.

появилась какая-то боязнь ошибиться.

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

$.when(d1,d2,d3).then( done, fail);
d1 = $.Deffered();
d1.resolve(mydata);

Promise.all([d1,d2,d3]).then( done, fail);

// если нужен сразу зарезолвенный промис
Promise.resolve(mydata)

// если нужно создать и зарезолвить когда-то потом, то сложнее
var resolver;
new Promise((resolve, reject) => {
    resolver = resolve;
});
// ...
resolver(mydata);

1) А как это делать без jquery, на нативном es6, и так же, в две строчки?

Deffered в jQ - это недобитый Promise. А они поддерживаются теперь почти везде, а для остальных есть полифил.

2) У меня рендерятся поля. Их может быть очень много. Сильно ли скажется на производительности, если каждый из этих полей будет иметь свойство-объект с deferred? Отложенное свойство мне нужно для отслеживания рендеринга полей на странице. Я использую рендер полей пачками по 30 через setTimeout.

На производительности вообще не скажется, только на потреблении памяти.

3) Можно ли, отказаться от setTimeout(func,0) в сторону чего-то более быстрого? (в моем случае, рендер 1 поля занимает 1,9-2,4 мс, а время ожидания между циклами setTimeout(func,0) - 25-30ms, что очень критично. Поэтому и ренедрю пачками по 30 штук. -- получается (1,9...2,4)*30 ~ 60-70ms + 25-30ms делэй от таймера.

Вы setTimeout используете, чтобы каждая порция рендерилась на следующем тике, чтобы UI не повис? В таком случае, возможно, стоит вынести рендеринг в WebWorker.

Да, ты не понимаешь асинхронность в JS и MVC.
Нужно рендерить после получения данных. Например, можно вызывать функцию render в колбеке getJSON. Ещё лучше вернуть промис и вызывать рендрер в колбеке then.
Но это всё равно ни разу не MVC.

А не могли бы вы помочь, как это делать в парадигме MVC?

Ну тут всё не так просто. Если ты хочешь использовать MVC-фреймворки, то смотри, как там всё организовано у них. Примеры реализации простого MVC приложения см. тут.

Если же забыть про тонны готовых MVC, то можно сделать всё самому. Тут важно понимать, что:
1) Модель - это вся бизнес-логика. И она не знает ни про View, ни про Controller. В классическом MVC модель оповещает всех подписчиков об изменении своих данных.
2) Вид (view) должен знать про модель, но не про контроллер. В классическом MVC вид подписывается на события модели и при возникновении события он перерисовывается.
3) Контроллер знает про вид и про модель. В классическом MVC он связывается с каким-то видом и при определённом действии пользователя что-то делает. Например, он может вызывать какие-то методы у модели. А может и изменять состояния вида (хотя так лучше не делать в идеале, так как повысится связность системы, что плохо).

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

Сперва посмотри в script.js.

Там есть класс-модель. Чтобы связать Model и View обычно применяют паттерн проектирования observer. У модели есть список слушателей. Каждый слушатель - просто функция-коллбек, которая принимает 1 аргумент - данные этой модели. При этом, сама модель не знает вообще ни про какой View. Слушатели в модели - это просто массив функций, которые будут вызваны.
В модели есть метод для добавления слушателя и для оповещения всех слушателей о получении новых данных. Метод getData эмулирует асинхронный запрос данных. В этом методе создаётся промис. Если данные найдены, то вызывается метод оповещения всех слушателей и промис резолвится. Если данные не найдены, то промис реджектится.

Далее, небольшая иерархия view-классов.
Класс BaseView. Там есть конструктор, который связывает экземпляр класса с DOM-элементом; метод subscribe, который добавляет к модели простого слушателя. Слушатель вызывает метод render с данными, которые нужно отрендерить и записывает полученный из метода render HTML в элемент. В самом классе BaseView метод render выплюнет ошибку, так что нужно написать несколько классов-наследников.
Класс ListView наследуется от BaseView и просто добавляет вспомогательный метод, который просто обрамляет каждый объект из массива с данными в элемент .
Ну и наконец, есть 2 класса, которые непосредственно реализуют метод render.
В итоге, класс UlView генерирует из массива данных ненумерованный список, а класс OlView - нумерованный.

Теперь в самом index.html можно увидеть всё в деле. Создаём модель и 2 view. Каждый view инициализируем соответствующим div-элементом. Далее,
При нажатии на кнопку вызывается коллбек, который вызывает метод модели. Если модель смогла получить данные, то подписанные на эту модель вьюхи рендерят эти данные, причём каждый view делает это по-разному. Как тут можно заметить, модель вообще никак не зависит от view. Можно связывать сколько угодно вьюх без какого-либо изменения самой модели.

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

Эх опять... делегирование событий почитайте https://learn.javascript.ru/event-delegation
простой пример https://jsfiddle.net/DigitalBrain/bufchjtq/1/