Станислав Макаров

Основная идея стара как само программирование - поставить одни значения в зависимость от других. Система свойств зависимостей - это вариант реализации реактивного программирования.
Вот Эксель видели когда-нибудь? А формулами пользовались? При изменении значений в ячейках-источниках значения в ячейке с формулой автоматически пересчитывается. Вот это примерно то же самое.

Когда произошла точка перелома, что "тонкие" клиенты теперь популярней и почему? Хотя ведь мобильные приложения, это ведь тоже "толстый" клиент

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

Будем говорить о веб-клиентах и нативных клиентах (либо ненативных, но на не-веб платформе, например на дотнете или джаве).

Основная причина, по которой веб-клиенты всем нравятся - это идеальное решение вопроса деплоя приложения. Хорошо, не идеальное, но самое удобное для пользователя.
Чтобы какой-то код работал, его нужно либо доставить конечному потребителю, либо запустить у себя и доставить результат.
Сначала запускали у себя и доставляли результат в виде полностью готовой HTML-странички с минимумом скриптов или вообще без них. Это было время генерации страниц на сервере.
Клиент всегда хотел быстрого отклика и различных красивых анимашек, в общем хорошего user experience. Когда user experience и быстрый отклик был важнее, писали нативный клиент (и до сих пишут, когда это важнее).
Потом как-то собрались хорошие инженеры и запилили v8. Оказалось, что можно даже JS выполнять быстро. Планка скорости поднялась, остальные (SpiderMonkey и т.д.) начали подтягиваться.
Отклик уменьшился, больше кода стало возможным разместить на клиенте. Анимация 20 снежинок на странице больше не грузила процессор клиента на 100%.
Вопрос лёгкости деплоя кода начала перевешивать вопрос тормозного JS. Выяснилось, что facebook лучше смотреть на веб-страничке, чем скачивать отдельное приложение. А, ну и да - веб-песочница кроссплатформенна. Да, есть несовместимости между браузерами (особенно раньше), но жить гораздо приятнее, чем писать версии приложения под каждую ОС и собирать их. Программисты дешевле в разы.
Мобильные платформы тормозят сильнее. Под них продолжают писать нативные приложения.

Итог: всегда приходится решать, стоит ли приложение того, чтобы клиент заморачивался с его установкой и следил за ним. Это дело продакт-менеджера. Нет ничего проще установки и обновления веб-приложения - нужно нажать F5. Но тем не менее я всё еще хочу видеть свою IDE в качестве десктопного приложения. Ну и большинство решений на том же Электроне - это жесть. Возможно, через 10 лет всё будет совсем по-другому.

P.S. Насчёт взлома приложений не согласен - ключевую логику можно держать и на сервере, но это можно делать и в случае веб-клиента, и в случае десктопного.

Теперь осталось понять, как включить автоматическое генерирование заголовков для своих модулей и как их публиковать.

1. https://www.typescriptlang.org/docs/handbook/compi... , --declaration.
2. Используем SystemJS при генерации кода или используем бандлер.
3. Публикуем собранный js-бандл.

Отдельно о публикации - над npm я использую sinopia, хочется работать с похожей утилитой и для ts заголовков.

С TypeScript 2 никаких утилит не надо, всё публикуется в NPM. Варианта два - либо в своём пакете (имхо, предпочтительнее), либо в @types. Подробнее: www.typescriptlang.org/docs/handbook/declaration-f... . По сути, если вы не делали бандл, то тогда рядом с каждым js будет лежать .d.ts. Если вы делаете бандл, то тогда вам нужно попросить tsc сгенерить .d.ts в виде одного файла для всех имеющихся модулей, и тогда вы в package.json с помощью main и types указываете entry-файл и файл с type definitions.

Что кто может сказать про TypeScript?

Учите, не пожалеете.

• типизация поставит мозги на место;
  
• фичи, связанные с типами и инкапсуляцией надстраиваются над JS, т.е. не нужно знакомиться с полностью новым синтаксисом; даже терминологически разработчики TS стараются не расходиться с JS;
  
• язык позволяет не бояться роста проекта; собственно сейчас большой объём фронтэнд-кода и заставил нас переходить на TypeScript; чем больше кода и чем больше команда, тем выгоды от TS перевешивают затраты на внедрение;
  

Минусы:

• усложнение процесса сборки, т.к. нужна компиляция (это относится к любому из не-JS языков);
  
• придётся заботиться о наличии type definitions;
  
• есть некоторые нетривиальные вопросы во взаимодействии с JS кодом. В общем-то ничего проблемного, просто нужно понимать, что как работает;
  

Как человек, привыкший к языкам со статической типизацией, я не вижу для себя смысла писать на чистом JavaScript после освоения TS. Конечно, за исключением случаев поддержки существующего кода и скриптов на 10 строчек.

1. Потому что одной из целей при создании TypeScript была именно читабельность выходного JS-кода. Цитата из TypeScript Design Goals:

Goals
...
4. Emit clean, idiomatic, recognizable JavaScript code.
...
Non-goals
2. Aggressively optimize the runtime performance of programs. Instead, emit idiomatic JavaScript code that plays well with the performance characteristics of runtime platforms.

2. Потому что TypeScript прежде всего - это строгая типизация (а также сокрытие и прочие связанные вещи). Поэтому бОльшая часть рантайм-проверок не нужна в коде, генерируемом TS - компилятор всё проверяет при сборке. Сравним результаты компиляции следующих фрагментов кода Бабелем и tsc:
фрагмент на ES6:

class Foo {
  constructor(a, b) {
    this.a = a;
    this.b = b;
  }
  
  bar() {
    return this.a + this.b;
  }
}

фрагмент на TS:

class Foo {
  private a: number;
  private b: number;

  constructor(a, b) {
    this.a = a;
    this.b = b;
  }
  
  bar() {
    return this.a + this.b;
  }
}

Как вы можете заметить, TS генерирует только самое необходимое, в то время как Бабель в дефолтных настройках генерирует хелперы вроде _createClass и _classCallCheck, которые определены достаточно нетривиально. Зачем он это делает? Затем, что Бабель генерирует код, "безопасный" в райнтайме. Он не рассчитывает на то, что какие-либо проверки будут выполняться при компиляции. Например, в хелпере _classCallCheck проверяется, что конструктор не был вызван, как обычная функция.
TS считает такие проверки избыточными - его разработчики считают, что все они должны происходить именно при компиляции. Дополнительных проверок для вызывающего кода не производится.

скорее всего это cbCOM.SelectedItem, у которого вы пытаетесь вызвать ToString().

Есть простая таблица notes для мини-блога: id_author, header, text. И мне нужно найти вторые пять записей пользователя

В реляционной БД таблица - она же отношение (relation) - это множество записей, а не список. Т.е. они не упорядочены, и если сейчас вам запрос на выборку выдаёт их в одном порядке, то завтра он будет это делать в другом порядке. В записи нигде не хранится время её добавления, поэтому СУБД может перекладывать их как пожелает.
Чтобы решить это проблему, вам нужно добавить поле для хранения порядка записей. Проще всего добавить время публикации. Также вам, возможно, пригодится поле id или number для хранения номера самой записи, т.к. сейчас непонятно, может ли быть несколько записей от одного автора или нет (в теории - может, но непонятно тогда как вы их различаете. По заголовку?).
Затем вам возможно пригодится индекс (id_author, postdatetime), чтобы выборки с сортировкой по времени были эффективными.
Теперь вы сможете выбрать:

select header, text from notes where id_author = <автор> order by postdatetime limit 5, 5

используя nosql-базы

Шаг 1. Убрать из лексикона термин "NoSQL". Хотя бы временно.

как наиболее правильно хранить пользовательские данные, комментарии, лайки, медиа-данные.

Шаг 2. Выписать или запомнить три важнейших свойства любой СУБД:

• модель данных: что является элементом данных, что является коллекцией элементов, чего в СУБД должно быть постоянное количество, есть ли схема и в каком виде, как обеспечиваются связи между элементами данных на уровне модели;
  Пример: MongoDB, элемент данных - документ, описывается как JSON-документ с некоторыми специфичными для Монги расширениями. Коллекция элементов - коллекция документов. Количество коллекций более-менее постоянное, количество документов растёт.
  
• ограничения и гарантии физической реализации модели данных - какие операции какую сложность имеют, какую цену (в плане пространства на устройстве хранения и процессорного времени) имеет каждая используемая структура данных или алгоритм; какие параметры как будут расти во время эксплуатации БД.
  Пример: графовые БД, имеющие "настоящий" графовый движок, т.е. такой, который хранит физические ссылки из одной вершины на другую, гарантируют константное время выборки связанных вершин. В связи с этим их выгодно использовать для сильносвязанных нечасто изменяющихся данных (графы друзей в социалочках и т.п.)
  
• инструментарий логического и физического уровня: по сути это предыдущие пункты более подробно - какие структуры данных доступны, в частности какие есть индексы, какие способы выборки/фильтрации/сортировки присутствуют; для чего гарантируется транзакционность (особо важный вопрос); где находится база в CAP диаграмме; какие есть средства логического уровня, например представления (view);
  

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

Шаг 3. Научиться ставить задачу с точки зрения обрабатываемых данных:

• какие данные будут иметь постоянный объем или расти медленно, а какие - быстро и постоянно;
  
• какие будут запросы к данным, что будет выбираться как есть, а что нужно будет дополнительно агрегировать;
  
• какие запросы будут плановые, а какие придётся выполнять внепланово;
  
• какой нужен уровень доступности, какова ценность хранящихся данных и цена простоя.
  

Шаг 4. Ознакамливаться с СУБД здесь: nosql-database.org и выбирать нужную с учётом:

• вашей задачи;
  
• порога вхождения;
  
• наличия доступных специалистов.