Сергей Протько

идите постепенно, вещи вроде Angular и React намного проще изучить когда у вас уже есть определенный уровень в JS, а именно четкое понимание базовых концепций. А так это будет просто тыканье на месте и не продуктивно потраченное время.

Берусь за jquery, json, sass,lessи ничего толком выучить не могу

Учить JSON? бред. Осоздайте необходимость появления форматов типа JSON/XML/etc. Целенаправленно учить less/sass, то же не ок. Учите CSS (less/sass/postcss это лишь инструменты которые позволяют вам более грамотно организовать ваш код), и не в плане свойства/селекторы, а в плане подходов к верстке (БЭМ, MCSS и т.д.). Ну и да, заучите что такое DRY и почему вообще возникла необходимость в инструментах типа less/sass.

ajax

Не изучайте AJAX, изучайте HTTP. Тогда будет проще отделить реализацию от общей концепции. Хватит бездумно говорить "сделаю AJAX запрос", давайте говорить "сделаю HTTP запрос".

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

Ну вот есть DOM. Он медленный, и дергать его просто так не стоит. А есть виртуальный DOM, что-то типа прослойки между вашим кодом и реальным DOM. Вы можете дергать виртуальный DOM сколько вам душе угодно, а прослойка эта соберет всю инфу о том как вы чего делали, и попробует оптимизировать взаимодействие с реальным DOM что бы вышло как можно меньше действий.

Пример - задача простая, у вас есть таблица и нужно постоянно обновлять ячейки новым значением. Значение приходят из апишки раз в пару десятков милисекунд (какая-то реалтайм статистика к примеру). Значения эти - просто массив данных.

Решение в лоб - каждый раз когда приходят данные, дропать старую таблицу, проходить циклом по массиву и формировать новую. Это куча операций с DOM. У вас каждые n милисекунд будет полностью перестраиваться вся эта штука, дропаться и создаваться новые элементы и все это будет ужасно долго пересчитываться и перерисовываться.

А теперь добавим между всем этим виртуальную апишку, которая запоминает что она там в прошлый раз создала и что надо в этот раз создать. Вы все так же влоб проходите циклом по массиву и просите виртуальный дом построить новую апишку, а виртуальный дом будет стараться переиспользовать то что у него уже есть, ну и все в таком духе. За счет этого получается нефиговый прирост производительности (но есть потери на работу самого виртуального DOM, зато можно фигачить как хочешь).

Если же прослойку эту сделать со своим интерфейсом, можно получить слой абстракции для работы с UI. Именно это предлагает тот же React. Слой абстракции над UI. Вы можете работать с реактом, но UI будет отрисовываться не через DOM а скажем... это может быть нативный интерфейс мобильной платформы (гуглить native-react). Ну и т.д.

Обычно в html у блока прописываем id, а в js скрипте получаем к нему доступ через document.getElementById("id")

и получаем море проблем.

в React вы работаете с компонентами, и можете встраивать свою специфичную логику внутрь конкретных компонентов. Скажем есть метод componentDidMount который вызовется после рендринга DOM и вы можете там обращаться к нодам уже DOM и что-то делать.

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

https://facebook.github.io/react/docs/component-sp...

static int timeoutId()
{
    static int lastUsedTimeoutId = 0;
    ++lastUsedTimeoutId;
    // Avoid wraparound going negative on us.
    if (lastUsedTimeoutId <= 0)
        lastUsedTimeoutId = 1;
    return lastUsedTimeoutId;
}

исходя из этого кода - негативным timeoutID быть не может. Там есть проверка, если все id-шки закончились и пошло переполнение - то ресетится в единицу. Но это хром. В других браузерах может быть все совсем по другому. Главное не привязывать логику к формату timeoutID и все будет хорошо.

Ну давайте рассуждать. Если вы приказали собрать мусор и он собрался и удалился, значит сборщик сам бы все почистил если бы памяти стало малова-то. Просто вы не дождались этого момента. С другой стороны, если после ручной сборки мусора память не опустилась до baseline то есть вероятность утечки памяти.

Задачка на каррирование и понимание работы областей видимости и цикла жизни переменных.

Функции mystery и mystery3 возвращают функции, которые имеют доступ к переменным родительского скоупа. Функция создается каждый раз при вызове функций mystery/mystery3 потому не возникает проблем с повторным вызовом.

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

Вот собственно и все.

Вам же уже ответили на этот вопрос.

stackoverflow.com/questions/24119329/fieldset-and-...

Можно написать директиву для формы, можно определить директиву fieldset что бы не менять разметку...

Если для формы, вы можете назначать атрибуту промис, и внутри директивы трекать что когда закончится. По окончанию действия ресетить промис и ждать следующего. Ну и т.д. Так можно почистить контроллер от ненужных вещей.

Пример

Это запрос с клиента. Есть конечно шанс что расширение посылает дополнительную финформацию о себе в заголовках, но вообще Same-origin policy не должно давать просто так расширению делать запросы к к серверу не поддерживающее CORS. А если CORS поддерживается, то можно в заголовках выставить ограничения.

Как подключить CORS в sailsjs

sailsjs - backend, angular - frontend. Между ними rest. так что ищите отдельно. Есть и то и то под кофе я так понимаю

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

Советую так же посмотреть доклад "Javascript глазами Jit компилятора"

Регулярные выражения парсят хорошо только регулярную грамматику.

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

Почитайте про то как происходит разбор селекторов и все встанет на свои места. Селекторы разбираются слева на право (или снизу вверх по дереву). То есть селекторы вида:

.some-specific-element

будут относительно быстрее

#some-hight-specific-element .some-not-so-specific-element

пососкольку не нужно сильно далеко траверсить DOM дерево.

Самый медленный вариант селекторов:

body.someSpecificClass *,
* + span,
html span

benfrain.com/css-performance-revisited-selectors-b...

идею вы должны уловить. Чем ближе в дереве - тем быстрее. А вообще с вложенными селекторами и каскадированием стилей лучше не баловаться слишком сильно. Учитывая что у вас есть препроцессоры.

Ну и про BEM почитайте (У Вадима Макеева был неплохой доклад на эту тему).
Использовать не агитирую но идеи которые в этой методологии заложены должны сильно облегчают жизнь.

p.s. посмотрите в сторону autoprefixer и избавьте свой CSS от этих ужасных миксинов. Как уже заметили выше добавлять префиксы для border-radius уже не имеет смысла. Ваши миксины это не учитывают, а autoprefixer имеет актуальную статистику и позволяет вообще не париться по поводу таких вот вещей.

Хотел бы спросить вашего мнения, господа!

Берем готовый фреймворк предоставляющий нам структуру - готово. Главное не делать лишних зависимостей и не пилить велосипеды. Low coupling и high cohesion.

Ну и да, если вы думаете о будущем но не пишите тестов - вы не думаете о будущем. Либо у вас или ваших QA слишком много свободного времени для поиска регрессий.

MVC (и развития этих идей: MVVM, MVP, MVA, PAC...)

Идея проста... между двумя слоями вводим третий который изолирует одно от другого. Слоеное лучше бисквита.

p.s. Если вы не знаете как это организовать, лучше на самом деле взять фреймворк или библиотеку, которая организует для вас слой представления и абстрагирует ваш код от него (React например).