Владислав Килин

1. Оптимизируйте селекторы.
#valmovaya #area-h1 - вот это плохой селектор, потому что он ищет по идентификатору внутри элемента с идентификатором, но вторая часть уже лишена особого смысла, поскольку первый идентификатор по определению и так уникален. Оставьте просто #area-h1. А еще лучше вообще уберите из идентификатора указатель на название тега, это архидурной тон.

2. val возвращает строковое значение. Работать со строками как с числами - очень плохая затея, даже в языках с динамической типизацией. Либо пользуйтесь parseInt(vaml_h1), либо вообще кастом в духе +valm_h1.

3. jQuery не считает, арифметические расчеты это зона контроля JavaScript.

Любой из этих трех вариантов вам подойдет, в принципе.

var valm_w1 = +$("#area-w1").val();
var valm_w3 = parseInt($("#area-w3").val());
var valm_h1 = parseFloat($("#area-h1").val());

import googleClientApi from 'google-client-api'

googleClientApi(function (gapi) { /* lalala */ })

В JavaScript не существует двумерных массивов, по сути матрица будет "вектором векторов". Обращение к элементу по его индексам будет выглядеть как-то так: myMatrix[i][j].

Транспонирование матрицы в этом контексте вообще не имеет никакого смысла, ведь для этого достаточно просто поменять местами i и j. Я бы посоветовал написать фасад над работой с массивом, например так:

class Matrix {
  constructor (arr, transposed) {
    this._arr = arr
    this._transposed = !!transposed
  },

  get (i, j) {
    return this._transposed
      ? this._arr[j][i]
      : this._arr[i][j]
  },
  transpose () {
    return new Matrix(this._arr.map(row => row.slice()), true)
  }
}

var matrixA = new Matrix([[1,2],[3,4],[5,6]])
matrixA.get(1, 0) // 3
var matrixB = matrixA.transpose()
matrixB.get(0, 1) // 3

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

Этот подход "псевдоооп", хотя у вас и есть какие-то объекты, вы лишаете себя целой кучи полезных вещей - наследования, полиморфизма, не очень оптимально работаете с памятью.

В JS ооп принято варить через прототипы. Например, вот так:

(function (my) {
my.Form = function () {
  $(document).on('submit', 'form', function (evt) {
    // это же просто пример, так?
  });
};
my.Form.prototype.submit = function () {
  // ...
};
})(MY);

В дальнейшем, если вам понадобится не просто форма, а, например, валидируемая форма, или даже AJAX-форма, вы сможете без проблем отнаследоваться от этой формы и добавить ништяков. Например.

(function (my) {
my.ValidatedForm = function () {
  // something
};
my.ValidatedForm.prototype = new my.Form();
my.ValidatedForm.prototype.isValid = function () {
  // ...
};
})(MY);

Также у вас появится доступ к состоянию инстанса через ключевое слово this: для этого потребуется создавать экземпляры через оператор new. Будет выглядеть как-то так:

var myForm = new MY.Form();
myForm.submit();

Это не всегда нужно делать именно так, но все зависит только от того, чего вы в конечном счете пытаетесь достичь. Я очень советую почитать статьи Ильи Кантора, автора сайта javascript.ru про ООП в JS. Он прилично пишет и хорошо разбирается в предметной области.

Попробуйте

showOnly = function (cat) {
    return function (evt) {
        $(this).addClass('active');
        worksAll.hide();
        cat.show('fast', function () { cat.appendTo('.works-flow'); });
    };
};

А еще поузнавайте про делегаты в JavaScript.

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

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

Я бы советовал на событии onLoad (аналог jquery document.ready) вешать что-то вроде:

$(function () {
    var YMEventHandler = (function () {
        var _timerDelta = 100,
             _timerCookieName = "___TimerYM___"
             _timerElapse = 2 * 60 * 1000, // two minutes
        _timer = setInterval(function () {
             var timerValue = parseInt(_getTimerValue()) || 0;
             timerValue += _timerDelta;
             _setTimerValue(timerValue);
             if (timerValue >= _timerElapse) {
                 clearInterval(_timer);
                 // вызов того, что нужно было вызвать!!!
             }
        }, _timerDelta);

        function _getTimerValue() {
             return _getCookie(_timerCookieName);
        };

        function _setTimerValue(value) {
             _setCookie(_timerCookieName, value);
        };

        function _getCookie(name) {
            var matches = document.cookie.match(new RegExp("(?:^|; )" + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g, '\\$1') + "=([^;]*)"));
            return matches ? decodeURIComponent(matches[1]) : undefined;
        };

        function _setCookie(name, value) {
            document.cookie = name + "=" + value;
        };

    })();
});

Это достаточно топорно, но работать вроде бы должно.

Да, есть такое средство - найди того, кто писал, посади рядом с собой и пиши код. Это немного похоже на парное программирование, только надо при этом надеть на голову велосипедный шлем или шлем для мотоцикла.